Re: Out parameters handling

Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> I'd sure be happy not having to do it explicitly, but schema-style
> prefixing has the drawback of needing to avoid any user defined
> schema.

No, not really, because it'd be the wrong number of naming levels.

Assuming that we were to switch to Oracle-style naming rules, we
would have:

x in the context of a table name = table x

x.y in the context of a table name = table y, schema x

x in the context of an expression = first of
column x from some table of the current command
most-closely-nested plpgsql variable x

x.y in the context of an expression = first of
column y from table x of the current command
plpgsql variable y in block x

The important point here is that the main SQL parser can tell whether
it's looking at a table name or a column name, whereas plpgsql is
currently too stupid for that and will always substitute for a name
that matches a plpgsql variable name. Once we get rid of that problem
there isn't really any conflict with schema names. You might have a
conflict between table aliases and block names, but that can be
dealt with by local renaming of aliases within the problematic command.

(Note: as pointed out by Pavel, it's already the case that named
parameters are implicitly assigned a block name equal to the function
name; so you can qualify them if you have to.)

regards, tom lane