Pursuant to
http://www.postgresql.org/message-id/29007.1396038...@sss.pgh.pa.us
I've been working on a patch to prevent external toast pointers from
appearing in composite Datums. I noticed that this patch completely
breaks the make_tuple_indirect() test case added by commit 36820250.
The regression test doesn't fail (meaning the test case fails to
actually prove that any indirection is happening), but it certainly
isn't doing what's intended, because the "indirect" pointers get
flattened out of the tuple returned by make_tuple_indirect() before
control ever leaves the function.
Even in the code as it stands in HEAD, such indirect pointers would
get flattened out of other container types such as arrays and ranges.
And for that matter, it's a bit silly to be testing make_tuple_indirect
in a BEFORE INSERT/UPDATE trigger, because even if the tuple gets out
of the trigger without being flattened, it will certainly get flattened
mere nanoseconds later before it gets written out to disk. (If it did
not, the test case would fail altogether, since the indirect values
in memory only survive for the length of the current transaction.)
So I'm wondering exactly what use-case this test is supposed to represent.
Or is the whole thing just a toy anyway? Because the more I look at that
patch, the less it looks like it could do anything useful, short of adding
a ton of infrastructure that's not there now.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
