Le 14/10/2021 à 20:43, Tom Lane a écrit :
> 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
You mean this ? :-)
gilles=# CREATE TABLE htest0 (a int PRIMARY KEY, b text NOT NULL HIDDEN);
CREATE TABLE
gilles=# INSERT INTO htest0 (a, b) VALUES (1, 'htest0 one');
INSERT 0 1
gilles=# INSERT INTO htest0 (a, b) VALUES (2, 'htest0 two');
INSERT 0 1
gilles=# SELECT * FROM htest0 t;
a
---
1
2
(2 rows)
gilles=# SELECT t.* FROM htest0 t;
a
---
1
2
(2 rows)
gilles=# SELECT row_to_json(t.*) FROM htest0 t;
row_to_json
--------------------------
{"a":1,"b":"htest0 one"}
{"a":2,"b":"htest0 two"}
(2 rows)
gilles=# SELECT row_to_json(t) FROM htest0 t;
row_to_json
--------------------------
{"a":1,"b":"htest0 one"}
{"a":2,"b":"htest0 two"}
(2 rows)
You should have a look at the patch, I don't think that the way it is
done there could have gotchas.
--
Gilles Darold
