From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Joe Wildish <joe-postgresql(dot)org(at)elusive(dot)cx> |
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 23:07:29 |
Message-ID: | 87pnwvewny.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "Joe" == Joe Wildish <joe-postgresql(dot)org(at)elusive(dot)cx> writes:
>> 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.
Joe> Thanks for the pointer. I've had a quick look at pg_aggregate, and
Joe> back at my code, but I think there is more to it than just the
Joe> sorting property. Specifically we need to know about the aggregate
Joe> function when combined with connectors <, <=, < ANY, <= ANY, < ALL
Joe> and <= ALL (and their equivalents with ">" and ">=").
The presence of an aggsortop means "this aggregate function is
interchangeable with (select x from ... order by x using OP limit 1)",
with all of the semantic consequences that implies. Since OP must be the
"<" or ">" member of a btree index opclass, the semantics of its
relationships with other members of the same opfamily can be deduced
from that.
Joe> Also, it looks like COUNT and SUM don't have a sortop
Right, because those currently have no semantics that PG needs to know
about or describe.
--
Andrew (irc:RhodiumToad)
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2018-09-29 23:38:46 | Re: Odd 9.4, 9.3 buildfarm failure on s390x |
Previous Message | Andrew Dunstan | 2018-09-29 22:25:37 | Re: Cygwin linking rules |