Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

I wrote:
> Yeah, me too.  I think it would add a lot of clarity if we defined this
> as "this affects the behavior of SELECT * and nothing else" ... although
> even then, there are squishy questions about how much it affects the
> behavior of composite datums that are using the column's rowtype.

Re-reading that, I realize I probably left way too much unstated,
so let me spell it out.

Should this feature affect
    SELECT * FROM my_table t;
?  Yes, absolutely.

How about
    SELECT t.* FROM my_table t;
?  Yup, one would think so.

Now how about
    SELECT row_to_json(t.*) FROM my_table t;
?  All of a sudden, I'm a lot less sure --- not least because we *can't*
simply omit some columns, without the composite datum suddenly not being
of the table's rowtype anymore, which could have unexpected effects on
query semantics.  In particular, if we have a user-defined function
that's defined to accept composite type my_table, I don't think we can
suppress columns in
    SELECT myfunction(t.*) FROM my_table t;

And don't forget that these can also be spelled like
    SELECT row_to_json(t) FROM my_table t;
without any star visible anywhere.

So the more I think about this, the squishier it gets.  I'm now sharing
the fears expressed upthread about whether it's even possible to define
this in a way that won't have a lot of gotchas.

            regards, tom lane