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

Re: A couple of issues with psql variable substitution

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A couple of issues with psql variable substitution
Date: 2011-08-25 17:16:06
Message-ID: 1314292430-sup-2544@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Excerpts from Tom Lane's message of jue ago 25 14:00:57 -0300 2011:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Thu, Aug 25, 2011 at 12:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> 1. Somebody broke the no-backtracking property back in 9.0 while adding
> >> quoted variable substitution.  According to the flex manual, use of
> >> backtracking creates a performance penalty.  We once measured the
> >> backend's lexer as being about a third faster with backtrack avoidance,
> >> and presumably it's about the same for psql's.  This is not hard to fix,
> >> but should I consider it a bug fix and back-patch?  We've not had
> >> complaints about psql getting slower as of 9.0.
> 
> > That may well have been me.
> 
> [ checks "git blame" ]  Well, you commmitted the patch anyway: d0cfc018.
> 
> > How would I have known that I broke it?
> 
> Per the header comments in the backend lexer, you should run flex with
> "-b" switch and verify that the resulting lex.backup file says "no
> backing up".  I've occasionally thought about automating that, but I'm
> not sure if the output is entirely locale- and flex-version-independent.

It is locale dependent, though of course for the automated check you
could just run flex under LC_ALL=C.

$ /usr/bin/flex -Cfe -b /pgsql/source/REL8_4_STABLE/src/bin/psql/psqlscan.l
$ cat lex.backup 
Sin retroceso.
$ LC_ALL=C /usr/bin/flex -Cfe -b /pgsql/source/REL8_4_STABLE/src/bin/psql/psqlscan.l
$ cat lex.backup 
No backing up.



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

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2011-08-25 17:40:05
Subject: Re: A couple of issues with psql variable substitution
Previous:From: Tom LaneDate: 2011-08-25 17:00:57
Subject: Re: A couple of issues with psql variable substitution

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