Re: Implementing SQL ASSERTION - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Implementing SQL ASSERTION
Date
Msg-id 877ejah19l.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Implementing SQL ASSERTION  (Joe Wildish <joe-postgresql.org@elusive.cx>)
Responses Re: Implementing SQL ASSERTION  (Joe Wildish <joe-postgresql.org@elusive.cx>)
List pgsql-hackers
>>>>> "Joe" == Joe Wildish <joe-postgresql.org@elusive.cx> writes:

 Joe> Agreed. My assumption was that we would record in the data
 Joe> dictionary the behaviour (or “polarity") of each aggregate
 Joe> function with respect to the various operators. Column in
 Joe> pg_aggregate? I don’t know how we’d record it exactly.

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.

(For a given aggregate foo(x), the presence of an operator oid in
aggsortop means something like "foo(x) is equivalent to (select x from
... order by x using OP limit 1)", and the planner will replace the
aggregate by the applicable subquery if it thinks it'd be faster.)

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. For example, the planner can assume that WHERE x=y AND x=1
implies that y=1 (assuming x and y are of appropriate types) not because
it assumes that "=" is the name of a transitive operator, but because
the operators actually selected for (x=1) and (x=y) are both "equality"
members of the same btree operator family. Likewise proving that (a>2)
implies (a>1) requires knowing that > is a btree comparison op.

--
Andrew (irc:RhodiumToad)


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Proposal for Signal Detection Refactoring
Next
From: Michael Paquier
Date:
Subject: Re: Revoke execution permission of pg_stat_statements_reset() frompg_read_all_stats role