Re: Perhaps a possible new feature to a future PostgreSQL release - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: Perhaps a possible new feature to a future PostgreSQL release
Date
Msg-id 441942d6e18bc5b89cfe5df24e7447b3a23df613.camel@cybertec.at
Whole thread Raw
In response to Perhaps a possible new feature to a future PostgreSQL release  (Erki Eessaar <erki.eessaar@taltech.ee>)
List pgsql-hackers
On Mon, 2023-11-20 at 09:52 +0000, Erki Eessaar wrote:
> Let me assume that there is a table T with columns a, b, c, d, e, f, g, and h.
>
> If one wants to select data from all the columns except d and e, then one has to write
>
> SELECT a, b, c, f, g, h
> FROM T;
>
> instead of writing 
>
> SELECT ALL BUT (d, e)
> FROM T;
>
> or something similar (perhaps by using keywords EXCEPT or EXCLUDE).

This has been discussed before (repeatedly); see for example
https://www.postgresql.org/message-id/flat/CANcm6wbR3EG7t-G%3DTxy64Yt8nR6YbpzFRuTewJQ%2BkCq%3DrZ8M2A%40mail.gmail.com

All previous attempts went nowhere.


> I think that such syntax would be useful and if more and more DBMS-s start to
> offer it, then perhaps one day it will be in the SQL standard as well.

One of the reasons *against* the feature is that the SQL standard committee
might one day come up with a feature like that using a syntax that conflicts
with whatever we introduced on our own.

Yours,
Laurenz Albe



pgsql-hackers by date:

Previous
From: Erki Eessaar
Date:
Subject: Perhaps a possible new feature to a future PostgreSQL release
Next
From: Peter Eisentraut
Date:
Subject: Re: should check collations when creating partitioned index