diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2022-06-10 10:35:57 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2022-06-10 10:35:57 -0400 |
| commit | 254cd7f31f60f02de0548c8dcdc2c402c0cf02d8 (patch) | |
| tree | c964a1e0da277964176b8a9e76f009077498bcde /src/backend/access/gist/gistbuildbuffers.c | |
| parent | 2bc7dffa300819e44051a80cda0edcffbf673ea8 (diff) | |
| download | postgresql-254cd7f31f60f02de0548c8dcdc2c402c0cf02d8.tar.gz postgresql-254cd7f31f60f02de0548c8dcdc2c402c0cf02d8.zip | |
Un-break whole-row Vars referencing domain-over-composite types.
In commit ec62cb0aa, I foolishly replaced ExecEvalWholeRowVar's
lookup_rowtype_tupdesc_domain call with just lookup_rowtype_tupdesc,
because I didn't see how a domain could be involved there, and
there were no regression test cases to jog my memory. But the
existing code was correct, so revert that change and add a test
case showing why it's necessary. (Note: per comment in struct
DatumTupleFields, it is correct to produce an output tuple that's
labeled with the base composite type, not the domain; hence just
blindly looking through the domain is correct here.)
Per bug #17515 from Dan Kubb. Back-patch to v11 where domains over
composites became a thing.
Discussion: https://postgr.es/m/17515-a24737438363aca0@postgresql.org
Diffstat (limited to 'src/backend/access/gist/gistbuildbuffers.c')
0 files changed, 0 insertions, 0 deletions