From: | Joe Wildish <joe-postgresql(dot)org(at)elusive(dot)cx> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Implementing SQL ASSERTION |
Date: | 2018-09-29 16:50:58 |
Message-ID: | 67609C95-7A93-439F-8F45-1D1BCCE9AEA5@elusive.cx |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Andrew,
On 25 Sep 2018, at 01:51, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
> I haven't looked at the background of this, but if what you want to know
> is whether the aggregate function has the semantics of min() or max()
> (and if so, which) then the place to look is pg_aggregate.aggsortop.
Thanks for the pointer. I've had a quick look at pg_aggregate, and back
at my code, but I think there is more to it than just the sorting property.
Specifically we need to know about the aggregate function when combined with
connectors <, <=, < ANY, <= ANY, < ALL and <= ALL (and their equivalents
with ">" and ">="). Also, it looks like COUNT and SUM don't have a sortop
(the other aggregates I've catered for do though).
When I come to do the rework of the patch I'll take a more in-depth look
though, and see if this can be utilised.
> As for operators, you can only make assumptions about their meaning if
> the operator is a member of some opfamily that assigns it some
> semantics.
I had clocked the BT semantics stuff when doing the PoC patch. I have used
the "get_op_btree_interpretation" function for determining operator meaning.
-Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2018-09-29 16:51:18 | Re: Online enabling of checksums |
Previous Message | Joe Wildish | 2018-09-29 16:35:18 | Re: Implementing SQL ASSERTION |