Обсуждение: What use case is make_tuple_indirect() supposed to illustrate?
Pursuant to http://www.postgresql.org/message-id/29007.1396038881@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
Hi, On 2014-04-22 20:22:23 -0400, Tom Lane wrote: > 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.) Well, that's part of what it's essentially testing. We better not end up with a indirect datum, pointing to memory after all, ending up in a disk tuple. > So I'm wondering exactly what use-case this test is supposed to represent. Testing stuff I was concerned could break without tests. Especially as this was committed before the rest of the decoding stuff was. > 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. Indirect toast tuples are actively used in logical decoding. So there is a usecase. I think there's further potential uses for both the infrastructure for further toast types in general and specifically indirect toast tuples. But we'll see. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services