On Fri, Dec 20, 2013 at 9:56 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Dec 20, 2013 at 7:51 AM, Andres Freund <and...@2ndquadrant.com> wrote: >>> I wondered that, too, but it's not well-defined for all tuples. What >>> happens if you pass in constructed tuple rather than an on-disk tuple? >> >> Those should be discernible I think, t_self/t_tableOid won't be set for >> generated tuples. > > I went looking for existing precedent for code that does things like > this and found record_out, which does this: > > HeapTupleHeader rec = PG_GETARG_HEAPTUPLEHEADER(0); > ... > /* Extract type info from the tuple itself */ > tupType = HeapTupleHeaderGetTypeId(rec); > tupTypmod = HeapTupleHeaderGetTypMod(rec); > tupdesc = lookup_rowtype_tupdesc(tupType, tupTypmod); > ncolumns = tupdesc->natts; > > /* Build a temporary HeapTuple control structure */ > tuple.t_len = HeapTupleHeaderGetDatumLength(rec); > ItemPointerSetInvalid(&(tuple.t_self)); > tuple.t_tableOid = InvalidOid; > tuple.t_data = rec; > > This appears to be a typical pattern, although interestingly I noticed > that row_to_json() doesn't bother setting t_tableOid or t_self, which > I think it's supposed to do. The problem I see here is that this code > seems to imply that a function passed a record doesn't actually have > enough information to know what sort of a thing it's getting. The use > of HeapTupleHeaderGetTypeId and HeapTupleHeaderGetTypMod implies that > it's safe to assume that t_choice will contain DatumTupleFields rather > than HeapTupleFields, which doesn't seem to bode well for your > approach. > > Am I missing a trick?
If not, here's a patch done the way I originally proposed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pg-tuple-header.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers