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

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 (view raw or flat)
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)

pgsql-committers by date

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

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