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
