Re: More deficiencies in outfuncs/readfuncs processing - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: More deficiencies in outfuncs/readfuncs processing
Date
Msg-id 20180917104256.GS4184@tamriel.snowman.net
Whole thread Raw
In response to More deficiencies in outfuncs/readfuncs processing  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Patch 0002 addresses several more-or-less-independent issues that are
> exposed by running the regression tests with patch 0001 activated:
>
> * Query.withCheckOptions fails to propagate through write+read, because
> it's intentionally ignored by outfuncs/readfuncs on the grounds that
> it'd always be NIL anyway in stored rules.  This seems like premature
> optimization of the worst sort, since it's not even saving very much:
> if the assumption holds, what's suppressed from a stored Query is only
> " :withCheckOptions <>", hardly a big savings.  And of course if the
> assumption ever fails to hold, it's just broken, and broken in a non
> obvious way too (you'd only notice if you expected a check option
> failure and didn't get one).  So this is pretty dumb and I think we
> ought to fix it by treating that field normally in outfuncs/readfuncs.
> That'd require a catversion bump, but we only need to do it in HEAD.
> The only plausible alternative is to change _equalQuery to ignore
> withCheckOptions, which does not sound like a good idea at all.

I'm fine with this change (as I believe I've said before...).  I agree
that it's just a minor optimization and shouldn't be an issue to remove
it.

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Collation versioning
Next
From: Rajkumar Raghuwanshi
Date:
Subject: Multiple primary key on partition table?