On Mon, Nov 24, 2014 at 2:07 PM, Tom Lane <tgl@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
