Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Gilles Darold <gilles(at)migops(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Date: 2021-10-15 18:51:29
Message-ID: 20211015185129.GA29872@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 15, 2021 at 11:32:53AM +0200, Laurenz Albe wrote:
> On Thu, 2021-10-14 at 13:16 +0200, Gilles Darold wrote:
> > Here is a proposal to implement HIDDEN columns feature in PostgreSQL.
> >
> > The user defined columns are always visible in the PostgreSQL. If user
> > wants to hide some column(s) from a SELECT * returned values then the
> > hidden columns feature is useful. Hidden column can always be used and
> > returned by explicitly referring it in the query.
>
> When I read your proposal, I had strangely mixed feelings:
> "This is cute!" versus "Do we need that?". After some thinking, I think
> that it boils down to the following:
>
> That feature is appealing to people who type SQL statements into psql,
> which is probably the majority of the readers on this list. It is
> immediately clear that this can be used for all kinds of nice things.
>
> On the other hand: a relational database is not a spreadsheet, where
> I want to hide or highlight columns. Sure, the interactive user may
> use it in that way, but that is not the target of a relational database.
> Databases usually are not user visible, but used by an application.
> So the appeal for the interactive user is really pretty irrelevant.
>
> Now this patch makes certain things easier, but it adds no substantially
> new functionality: I can exclude a column from display as it is, simply
> by listing all the other columns. Sure, that's a pain for the interactive
> user, but it is irrelevant for a query in an application.
>
> This together with the fact that it poses complicated questions when
> we dig deeper, such as "what about whole-row references?", tilts my vote.
> If it were for free, I would say +1. But given the ratio of potential
> headache versus added real-life benefit, I find myself voting -1.

I can see the usefulness of this, though UNEXPANDED seems clearer.
However, it also is likely to confuse someone who does SELECT * and then
can't figure out why another query is showing a column that doesn't
appear in SELECT *. I do think SELECT * EXCEPT is the better and less
confusing solution. I can imagine people using different EXCEPT columns
for different queries, which HIDDEN/UNEXPANDED does not allow. I
frankly can't think of a single case where output is specified at the
DDL level.

Why is this not better addressed by creating a view on the original
table, even perhaps renaming the original table and create a view using
the old table name.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

If only the physical world exists, free will is an illusion.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2021-10-15 19:22:48 Re: XTS cipher mode for cluster file encryption
Previous Message Andres Freund 2021-10-15 18:50:30 Re: [RFC] building postgres with meson