Skip site navigation (1) Skip section navigation (2)

Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Date: 2012-02-29 09:05:01
Message-ID: CAAZKuFZFousg18xmmLWR1E+3Z3xc2K+BUxyVei+cdix9v4zz2g@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Feb 27, 2012 at 4:26 AM, Peter Geoghegan <peter(at)2ndquadrant(dot)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

Attachment: Straw-man-to-show-the-effects-of-the-change-to-const.patch
Description: application/octet-stream (6.5 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Andrea SuisaniDate: 2012-02-29 09:22:05
Subject: Re: swapcache-style cache?
Previous:From: Simon RiggsDate: 2012-02-29 08:18:05
Subject: Re: Parameterized-path cost comparisons need some work

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group