Re: SQL feature requests - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: SQL feature requests
Date
Msg-id 87ps1evbuo.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: SQL feature requests  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SQL feature requests  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: SQL feature requests  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> In short, lots of downsides here, and not a whole lot of upside.

I highly doubt the spec would ever conflict with allowing the user to elide
the aliases given that Oracle (and others?) have always allowed this. Moreover
if it's been 15 years without them adding it surely that argues we can be
pretty sure they won't add them?

This seems like a particularly petty case compared to a lot of other
extensions we do allow. Surely allowing arbitrary expressions in GROUP BY is
far more likely to conflict in the future given how it constrains our grammar.
And in theory that provides no added functionality over aside from programmer
convenience as well. There are tons of extensions to the spec in the Postgres
grammar. This would be one of the simplest safest ones.

The upside is the convenience which after all is the same upside as most of
our spec grammar extensions. Many many programmers are accustomed to entering
ad-hoc queries of this form and forcing them to enter an alias for no purpose
is just silly pedanticism from their point of view. The portability of ad-hoc
queries is meaningless and if you don't refer to the alias in the query then
it's truly pointless.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: SQL feature requests
Next
From: Zdenek Kotala
Date:
Subject: Re: [COMMITTERS] pgsql: Add configure option --with-system-tzdata to use operating system