Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Daniel Farina <daniel@heroku.com>
From: Daniel Farina <daniel@heroku.com>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2012-02-29T09:05:01Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
- 9dbf2b7d75de 9.2.0 cited
-
Extend the parser location infrastructure to include a location field in
- a2794623d292 8.4.0 cited
-
Teach eval_const_expressions() to simplify an ArrayCoerceExpr to a constant
- 6734182c169a 8.4.0 cited
Attachments
- Straw-man-to-show-the-effects-of-the-change-to-const.patch (application/octet-stream) patch
On Mon, Feb 27, 2012 at 4:26 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote: > This does not appear to have any user-visible effect on caret position > for all variations in coercion syntax, while giving me everything that > I need. I had assumed that we were relying on things being this way, > but apparently this is not the case. The system is correctly blaming > the coercion token when it finds the coercion is at fault, and the > const token when it finds the Const node at fault, just as it did > before. So this looks like a case of removing what amounts to dead > code. To shed some light on that hypothesis, attached is a patch whereby I use 'semantic analysis by compiler error' to show the extent of the reach of the changes by renaming (codebase-wide) the Const node's location symbol. The scope whereby the error token will change position is small and amenable to analysis. I don't see a problem, nor wide-reaching consequences. As Peter says: probably dead code. Note that the cancellation of the error position happens very soon, after an invocation of stringTypeDatum (on two sides of a branch). Pre and post-patch is puts the carat at the beginning of the constant string, even in event there is a failure to parse it properly to the destined type. -- fdr