Re: Review of: pg_stat_statements with query tree normalization - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Review of: pg_stat_statements with query tree normalization
Date
Msg-id 1326755749-sup-8411@alvh.no-ip.org
Whole thread Raw
In response to Review of: pg_stat_statements with query tree normalization  (Daniel Farina <daniel@heroku.com>)
Responses Re: Review of: pg_stat_statements with query tree normalization
Re: Review of: pg_stat_statements with query tree normalization
List pgsql-hackers
Excerpts from Daniel Farina's message of dom ene 15 08:41:55 -0300 2012:

> Onto the mechanism: the patch is both a contrib and changes to
> Postgres.  The changes to postgres are mechanical in nature, but
> voluminous.  The key change is to not only remember the position of
> Const nodes in the query tree, but also their length, and this change
> is really extensive although repetitive.  It was this swathe of change
> that bitrotted the source, when new references to some flex constructs
> were added.  Every such reference has needs to explicitly refer to
> '.begins', which is the beginning position of the const -- this used
> to be the only information tracked.  Because .length was never
> required by postgres in the past, it fastidiously bookkeeps that
> information without ever referring to it internally: only
> pg_stat_statements does.

I wonder if it would make sense to split out those changes from the
patch, including a one-member struct definition to the lexer source,
which could presumably be applied in advance of the rest of the patch.
That way, if other parts of the main patch are contentious, the tree
doesn't drift under you.  (Or rather, it still drifts, but you no longer
care because your bits are already in.)

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Scott Mead
Date:
Subject: Re: IDLE in transaction introspection
Next
From: Andrew Dunstan
Date:
Subject: Re: automating CF submissions (was xlog location arithmetic)