From: Tom Lane <tgl@sss.pgh.pa.us>
To: Francisco Olarte <folarte@peoplecall.com>
cc: Abhishek Hatgine <hatgineabhishek99@gmail.com>,
        pgsql-general@postgresql.org
Subject: Re: Feature Proposal: Column-Level DELETE Operation in SQL
In-reply-to: <CA+bJJbxTXhUD2MjQgzJnAL-md1zRjmD7USvNXB90=W9_41NJMA@mail.gmail.com>
References: <CAD2voTQMUmNCKBok-_HvYLqFNECRWNkvqPruq0NcsFgd6g-Odw@mail.gmail.com> <CA+bJJbxTXhUD2MjQgzJnAL-md1zRjmD7USvNXB90=W9_41NJMA@mail.gmail.com>
Comments: In-reply-to Francisco Olarte <folarte@peoplecall.com>
	message dated "Wed, 23 Apr 2025 17:37:53 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1417512.1745426343.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Apr 2025 12:39:03 -0400
Message-ID: <1417513.1745426343@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1417513.1745426343%40sss.pgh.pa.us>
Precedence: bulk

Francisco Olarte <folarte@peoplecall.com> writes:
> On Tue, 22 Apr 2025 at 14:09, Abhishek Hatgine
> <hatgineabhishek99@gmail.com> wrote:
>> However, there=E2=80=99s no specific, expressive way to delete the valu=
e of a column directly. The typical workaround is to use:
>> UPDATE Customers SET Address =3D NULL WHERE CustomerID =3D 103;
>> While this works fine, it doesn't semantically express that the develop=
er intends to remove the value =E2=80=94 not just update it.

> But there is not a concept of removed value in relational.

Yeah, that.  The entire foundation of SQL, and relational databases in
general, is that a table is an array with rows and columns, and there
is something in every cell of that array --- maybe only a NULL value,
but something.  You can't expect to change that without pretty much
earth-shattering consequences.  As an example, are you suggesting
that it should be an error to try to fetch that specific column, but
only from that row?  There's not a SQL application on the planet that
wouldn't be broken by such behavior.

I grant that the notion of "no, it's not there" makes sense in some
NoSQL applications, and that's fine.  But there are reasons why NoSQL
is not SQL, and this is one.

You can already approximate this sort of behavior in Postgres by
storing the less-structured aspects of your data in a JSON or XML
column.  I'd suggest pursuing that approach rather than trying
to get us to mangle fundamental SQL semantics beyond recognition.

			regards, tom lane