On 22 January 2012 05:30, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> The syntax for constants is sufficiently simple that I think that a
> good set of regression tests should make this entirely practicable,
> covering all permutations of relevant factors affecting how the
> implementation should act, including for example
> standard_conforming_strings. There's no reason to think that the SQL
> syntax rules for constants should need to change very frequently, or
> even at all, so we should be fine with just knowing the starting
> position. It's quicker and easier to do it this way than to argue the
> case for my original implementation, so that's what I'll do. Whatever
> overhead this independent, pg_stat_statements-internal const parsing
> may impose, it will at least only be paid once per query, when we
> first require a canonicalised representation of the query for the
> pg_stat_statements view.
I've decided that a better approach to this problem is to use the
low-level scanner API (declared in scanner.h) which is currently
exclusively used for plpgsql. This seems to work well, as I'm using
the authoritative scanner to scan constants. Obviously this does not
imply that everyone must pay any overhead, so this seems like the best
of both worlds.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services