Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

From: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
To: Gilles Darold <gilles(at)migops(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Date: 2021-10-14 15:38:56
Message-ID: 20211014153856.GA17956@ahch-to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 14, 2021 at 01:16:45PM +0200, Gilles Darold wrote:
> Hi,
>
>
> Here is a proposal to implement HIDDEN columns feature in PostgreSQL.
>

Great! Actually I found this very useful, especially for those people
using big fields (geometry, files, large texts).

> 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.
>
> I agree that views are done for that or that using a SELECT * is a bad
> practice

An a common one, even if we want to think otherwise. I have found that
in almost every customer I have the bad luck to get to see code or
SELECTs.

Not counting that sometimes we have columns for optimization like Dave
saved about hidden a ts_vector column.

Another use case I can think of is not covered in this patch, but it
could be (I hope!) or even if not I would like opinions on this idea.
What about a boolean GUC log_hidden_column that throws a LOG message when
a hidden column is used directly?

The intention is to mark a to-be-deleted column as HIDDEN and then check
the logs to understand if is still being used somewhere. I know systems
where they carry the baggage of deprecated columns only because they
don't know if some system is still using them.

I know this would be extending your original proposal, and understand if
you decide is not a first patch material.

Anyway, a +1 to your proposal.

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bossart, Nathan 2021-10-14 16:02:15 Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
Previous Message Peter Geoghegan 2021-10-14 15:08:55 Re: Next Steps with Hash Indexes