Dimitri Fontaine <dfontaine@hi-media.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
plpgsqlvariable x
x.y in the context of an expression = first of column y from table x of the current command plpgsql variable y in
blockx
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