Re: Implementing SQL ASSERTION

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)

In response to

Responses

Browse pgsql-hackers by date

  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