| From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
|---|---|
| To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: ANY_VALUE aggregate |
| Date: | 2022-12-06 03:52:21 |
| Message-ID: | 90e7a585-4613-7a00-cfd9-6c33473f30db@postgresfriends.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/5/22 20:31, Corey Huinker wrote:
>
> Adding to the pile of wanted aggregates: in the past I've lobbied for
> only_value() which is like first_value() but it raises an error on
> encountering a second value.
I have had use for this in the past, but I can't remember why. What is
your use case for it? I will happily write a patch for it, and also
submit it to the SQL Committee for inclusion in the standard. I need to
justify why it's a good idea, though, and we would need to consider what
to do with nulls now that there is <unique null treatment>.
--
Vik Fearing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2022-12-06 03:54:45 | Re: Generate pg_stat_get_* functions with Macros |
| Previous Message | Amit Kapila | 2022-12-06 03:51:16 | Re: Perform streaming logical transactions by background workers and parallel apply |