pgsql: Revise plpgsql's scanner to process comments and string literals

From: tgl(at)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Revise plpgsql's scanner to process comments and string literals
Date: 2009-04-19 18:52:58
Message-ID: 20090419185258.3D2C17540E2@cvs.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Log Message:
-----------
Revise plpgsql's scanner to process comments and string literals in a way
more nearly matching the core SQL scanner. The user-visible effects are:

* Block comments (slash-star comments) now nest, as per SQL spec.

* In standard_conforming_strings mode, backslash as the last character of a
non-E string literal is now correctly taken as an ordinary character;
formerly it was misinterpreted as escaping the ending quote. (Since the
string also had to pass through the core scanner, this invariably led
to syntax errors.)

* Formerly, backslashes in the format string of RAISE were always treated as
quoting the next character, regardless of mode. Now, they are ordinary
characters with standard_conforming_strings on, while with it off, they
introduce the same set of escapes as in the core SQL scanner. Also,
escape_string_warning is now effective for RAISE format strings. These
changes make RAISE format strings work just like any other string literal.

This is implemented by copying and pasting a lot of logic from the core
scanner. It would be a good idea to look into getting rid of plpgsql's
scanner entirely in favor of using the core scanner. However, that involves
more change than I can justify making during beta --- in particular, the core
scanner would have to become re-entrant.

In passing, remove the kluge that made the plpgsql scanner emit T_FUNCTION or
T_TRIGGER as a made-up first token. That presumably had some value once upon
a time, but now it's just useless complication for both the scanner and the
grammar.

Modified Files:
--------------
pgsql/doc/src/sgml:
plpgsql.sgml (r1.139 -> r1.140)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/plpgsql.sgml?r1=1.139&r2=1.140)
pgsql/src/pl/plpgsql/src:
gram.y (r1.121 -> r1.122)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/gram.y?r1=1.121&r2=1.122)
pl_comp.c (r1.134 -> r1.135)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_comp.c?r1=1.134&r2=1.135)
pl_funcs.c (r1.76 -> r1.77)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_funcs.c?r1=1.76&r2=1.77)
plpgsql.h (r1.110 -> r1.111)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/plpgsql.h?r1=1.110&r2=1.111)
scan.l (r1.67 -> r1.68)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/scan.l?r1=1.67&r2=1.68)
pgsql/src/test/regress/expected:
plpgsql.out (r1.70 -> r1.71)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/plpgsql.out?r1=1.70&r2=1.71)
pgsql/src/test/regress/sql:
plpgsql.sql (r1.59 -> r1.60)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/plpgsql.sql?r1=1.59&r2=1.60)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2009-04-19 19:46:33 pgsql: Fix estimate_num_groups() to not fail on PlaceHolderVars, per
Previous Message Tom Lane 2009-04-19 15:49:35 pgsql: Mention as a potential incompatibility the fact that SELECT