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