| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Viliam Ďurina <viliam(dot)durina(at)gmail(dot)com> |
| Subject: | Re: MIN/MAX functions for a record |
| Date: | 2024-07-09 00:44:06 |
| Message-ID: | ZoyH1k3ayLXCB9JS@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 08, 2024 at 12:20:30PM +0300, Aleksander Alekseev wrote:
> Here is the corrected patch.
313f87a17155 is one example of a similar change with pg_lsn, with four
entries added to pg_proc and two to pg_aggregate. That's what this
patch is doing from what I can see.
- and arrays of any of these types.
+ and also arrays and records of any of these types.
This update of the docs is incorrect, no? Records could include much
more types than the ones currently supported for min()/max().
I am not sure to get the concerns of upthread regarding the type
caching in the context of an aggregate, which is the business with
lookup_type_cache(), especially since there is a btree operator
relying on record_cmp(). Tom, what were your concerns here?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-07-09 00:54:31 | Re: MIN/MAX functions for a record |
| Previous Message | Fujii Masao | 2024-07-09 00:32:47 | Re: pg_wal_summary_contents() and pg_walsummary may return different results on the same WAL summary file |