I got interested in this problem again now that we have a user complaint about it (bug #7553).
Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> writes: > On Wed, Feb 1, 2012 at 11:01 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Feb 1, 2012 at 12:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> ... It seems >>> reasonable to me to try to handle relation renames but draw the line >>> at disambiguating column names. But others might find that distinction >>> artificial. >> I sure do. > For me the relation names problem and column aliases problems are two > independent problems. I think they are independent problems, and I also think that people are far less likely to trip over column-name problems in practice. Columns of a table are not independent objects and so people aren't so likely to think they can just rename them freely. Moreover, if you rename columns that are used in views, you can get breakage of things like USING or NATURAL joins, and that is something we *cannot* provide a workaround for --- it's a failure inherent in the language definition. As far as the relation-rename problem goes, I propose that what we should do is have ruleutils.c invent nonconflicting fake aliases for each RTE in the query tree. This would allow getting rid of some of the dubious heuristics in get_variable: it should just print the chosen alias and be done. (It still has to do something different for unnamed joins, but we can leave that part alone I think.) We can do this as follows: 1. If there's a user-assigned alias, use that. (It's possible this is not unique within the query, but that's okay because any actual variable reference must be to the most closely nested such RTE.) 2. Otherwise, if the relation's current name doesn't conflict with any previously-assigned alias, use that. 3. Otherwise, append something (underscore and some digits probably) to the relation's current name to construct a string not matching any previously-assigned alias. This might result in printouts that are a bit uglier than the old way in such cases, but anybody who's offended can select their own aliases. 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