Re: Implementing SQL ASSERTION - Mailing list pgsql-hackers

From Joe Wildish
Subject Re: Implementing SQL ASSERTION
Date
Msg-id 67609C95-7A93-439F-8F45-1D1BCCE9AEA5@elusive.cx
Whole thread Raw
In response to Re: Implementing SQL ASSERTION  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Implementing SQL ASSERTION  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
Hi Andrew,

On 25 Sep 2018, at 01:51, Andrew Gierth <andrew@tao11.riddles.org.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



pgsql-hackers by date:

Previous
From: Joe Wildish
Date:
Subject: Re: Implementing SQL ASSERTION
Next
From: Stephen Frost
Date:
Subject: Re: Online enabling of checksums