]> git.ipfire.org Git - thirdparty/postgresql.git/commit
> Sean Chittenden <sean@chittenden.org> writes:
authorBruce Momjian <bruce@momjian.us>
Thu, 12 Sep 2002 00:24:10 +0000 (00:24 +0000)
committerBruce Momjian <bruce@momjian.us>
Thu, 12 Sep 2002 00:24:10 +0000 (00:24 +0000)
commitb3f52320f6cb8374f3db5397e63b82f595c90681
tree838a5b8f866b54fce0996e9b7a433bc10a119b3c
parent81186865fec2e39a6a66e9435b32d7048c03dd32
> Sean Chittenden <sean@chittenden.org> writes:
>
>>::sigh:: Is it me or does it look like all
>>of pl/pgsql is schema un-aware (ie, all of the declarations).  -sc
>
>
> Yeah.  The group of routines parse_word, parse_dblword, etc that are
> called by the lexer certainly all need work.  There are some
> definitional issues to think about, too --- plpgsql presently relies on
> the number of names to give it some idea of what to look for, and those
> rules are probably all toast now.  Please come up with a sketch of what
> you think the behavior should be before you start hacking code.

Attached is a diff -c format proposal to fix this. I've also attached a short
test script. Seems to work OK and passes all regression tests.

Here's a breakdown of how I understand plpgsql's "Special word rules" -- I
think it illustrates the behavior reasonably well. New functions added by this
patch are plpgsql_parse_tripwordtype and plpgsql_parse_dblwordrowtype:

Joe Conway
src/pl/plpgsql/src/pl_comp.c
src/pl/plpgsql/src/plpgsql.h
src/pl/plpgsql/src/scan.l
src/test/regress/sql/plpgsql-nsp-testing.sql [new file with mode: 0644]