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
