Re: Do all rows from a set have the same TupleDesc?
| От | Tom Lane |
|---|---|
| Тема | Re: Do all rows from a set have the same TupleDesc? |
| Дата | |
| Msg-id | 27424.1533824305@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Do all rows from a set have the same TupleDesc? (Raúl Marín Rodríguez <rmrodriguez@carto.com>) |
| Ответы |
Re: Do all rows from a set have the same TupleDesc?
|
| Список | pgsql-hackers |
=?UTF-8?B?UmHDumwgTWFyw61uIFJvZHLDrWd1ZXo=?= <rmrodriguez@carto.com> writes:
> I have an user defined aggregate (Postgis' St_AsMVT) that receives rows as
> input and I was wondering if all these tuples have the same TupleDesc.
Yes, they should. It's possible that the tuples themselves might have
visible inconsistencies (primarily, smaller t_natts in some than the
tuple descriptor says), but as long as you confine yourself to using
the standard tuple-disassembly functions that won't matter.
> The idea behind this question is that, if this were true, I could cache
> some information (number of attributes, oids, some internal stuff related
> to each attribute) until the end of the aggregation to avoid having to
> retrieve or calculate them for each one of the rows.
Yeah, caching such info is common. It's traditional to code defensively
about the validity of the cache (see e.g. record_out), but I'm not sure
to what extent that's really necessary for aggregates. In the case of
record_out, paranoia is probably justified because FmgrInfo structs for
I/O functions may get cached and re-used across statements, but I doubt
that can happen for an aggregate.
regards, tom lane
В списке pgsql-hackers по дате отправления: