Greg Stark <stark@mit.edu> writes:
> On 22 February 2017 at 15:08, Tom Lane <tgl@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