Greg Stark <st...@mit.edu> writes: > On 22 February 2017 at 15:08, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Indeed. When I wrote the comment you're referring to, quite a few years >> ago now, I thought that popular demand might force us to allow omitted >> aliases. But the demand never materialized. At this point it seems >> clear to me that there isn't really good reason to exceed the spec here. >> It just encourages people to write unportable SQL code.
> For what it's worth while it wouldn't be a *bad* thing to avoid > conflicts I think this is being held to an inconsistent standard here. True, but there are reasons for it: 1. We don't insist on column names in a SQL query being unique. We do insist on table aliases being unique. So a name generation rule for table aliases that fails to ensure uniqueness will result in duplicate-alias failures, where the same doesn't happen for non-unique column aliases unless you try to reference them. (BTW, I would argue that a query that leaves an alias undetermined, and then tries to reference the column or table by name anyway, is broken by design. So I'm unimpressed by any complaints based on that scenario.) 2. Our standards are higher than they were twenty years ago. Somebody who submitted the current approach to generating column aliases today would likely get laughed off the mailing list. I doubt it's worth the costs of changing it, but that doesn't mean I'm prepared to adopt an equally sloppy solution in a place where the stakes are higher. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers