Dimitri Fontaine <dfonta...@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 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
