From: | Matt Magoffin <postgresql(dot)org(at)msqr(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Properly handling aggregate in nested function call |
Date: | 2021-12-16 02:11:12 |
Message-ID: | D1E590B4-305C-472D-9063-F0061BEB2974@msqr.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 16/12/2021, at 2:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Of course what this function is actually returning is numeric[].
> There is some code such as array_out that will look at the
> element type OID embedded in the array value, and do the right
> thing. But other code will believe the function's declared
> result type, and that sort of code will go wrong.
(Hand slap to face!) Oh my, thank you for spotting that, this has been driving me to distraction, thinking I was doing something wrong with memory contexts or anything other than that copy/paste error.
> Alternatively you can declare one set of polymorphic
> functions and aggregates, in which case you'll need to closely
> study the stuff about the finalfunc_extra option [2].
Thanks for the tips, I have been eyeing that documentation.
— m@
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Demleitner | 2021-12-16 11:00:14 | SELECT DISTINCT <constant> scans the table? |
Previous Message | Дмитрий Иванов | 2021-12-16 01:50:55 | Re: Best Strategy for Large Number of Images |