Re: Idea about estimating selectivity for single-column expressions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Idea about estimating selectivity for single-column expressions
Date
Msg-id 26388.1250706159@sss.pgh.pa.us
Whole thread Raw
In response to Re: Idea about estimating selectivity for single-column expressions  (Greg Stark <gsstark@mit.edu>)
Responses Re: Idea about estimating selectivity for single-column expressions  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> Another thought. In the above case it would actually be fine to catch
> the error with PG_TRY() without a subtransaction. As long as no shared
> database state has been modified when the error is thrown then the
> subtransaction isn't needed to roll them back.

I think catching general errors coming out of possibly user-defined code
without using a subtransaction is just too scary to contemplate.
There's too much stuff that could need to be cleaned up and would not
have been.

It may be that a subtransaction will actually be acceptable overhead,
as long as we don't go overboard and invoke this mechanism for "simple"
WHERE clauses.  Hard to tell without coding it up and testing it though.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: We should Axe /contrib/start-scripts
Next
From: Tom Lane
Date:
Subject: Re: Why ACL_EXECUTE is checked on FindConversion()?