From: | Raúl Marín Rodríguez <rmrodriguez(at)carto(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Do all rows from a set have the same TupleDesc? |
Date: | 2018-08-09 15:53:35 |
Message-ID: | CAM6_UM6dJBRjpETY_+QbEdk=0aaBukSwvZrJ4FRW7MhG=NMrMA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Tom,
> 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.
The implementation of record_out is exactly what I was planning plus some
extra defenses. I'd consider the record type changing mid aggregation a
race condition, so I'll drop those checks.
Thanks a lot for the information.
Regards,
--
*Raúl Marín Rodríguez *carto.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2018-08-09 16:10:46 | Re: POC for a function trust mechanism |
Previous Message | Tom Lane | 2018-08-09 15:44:27 | libpq should append auth failures, not overwrite |