Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes:
> On 15.02.2011 21:13, Tom Lane wrote:
>> Hmm. I don't have a problem with adding relkind to the planner's
>> RelOptInfo, but it seems to me that if parse analysis needs to know
>> this, you have put functionality into parse analysis that does not
>> belong there.
> Possibly. We throw the existing errors, for example if you try to do
> "FOR UPDATE OF foo" where foo is a set-returning function, in
> transformLockingClause(), so it seemed like the logical place to check
> for foreign tables too.
> Hmm, one approach would be to go ahead and create the RowMarkClauses for
> all relations in the parse analysis phase, foreign or not, and throw the
> error later, in preprocess_rowmarks().
I think moving the error check downstream would be a good thing.
Consider for example the case of applying FOR UPDATE to a view. You
can't know what that entails until after the rewriter expands the view.
IIRC, at the moment we're basically duplicating the tests between parse
analysis and the planner, but it's not clear what the value of that is.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
