On Mon, Nov 24, 2014 at 2:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Two comments on that: > > 1. What is the likely use-case for such a thing (considering SQL is not > exactly friendly to pointers or reference types),
I happen to know that Oracle supports more possible LHS syntaxes in PL/SQL than we do in PL/pgsql, including things like foo(1) := 3. There is more than one problem with supporting that syntax in PL/pgSQL, and I haven't heard anyone complaining about its absence. But it doesn't have to be that thing particularly: anything that even vaguely resembles a general expression syntax on the LHS is going to run into this. > and is it more > interesting than new statements that we are going to reject on the grounds > that we don't want to reserve any more plpgsql keywords? Probably not, but my crystal ball isn't working too well today. > 2. The actual behavior would be the same as it would be for the case of > implicit-CALL that we discussed upthread. Namely, that it'd work just > fine as long as "foo" isn't any unreserved keyword. So the net effect > would be that plpgsql keywords would be sort of semi-reserved, much like > col_name_keywords in the core grammar: you can use 'em as variable names > but not necessarily as function names. With the current behavior where > they're fully reserved, you can't use them as either, not even where the > context is completely unambiguous. I have not heard anyone complaining > that col_name_keyword is a dumb idea and we should make all keywords fully > reserved. I see. Well, that sounds fine, then. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers