Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
>> There doesn't seem to be any very nice way to fix this. There is
>> not any existing support mechanism (comparable to query_tree_walker)
>> for scanning whole plan trees, which means that searching a cached plan
>> for regclass Consts is going to involve a chunk of new code no matter
>> how we approach it. We might want to do that someday --- in particular,
>> if we ever try to extend the plan inval mechanism to react to
>> redefinitions of non-table objects, we'd likely need some such thing
>> anyway. I'm disinclined to try to do it for 8.3 though. The use-case
>> for temp sequences seems a bit narrow and there are several workarounds
>> (see followups to bug report), so I'm feeling this is a
>> fix-some-other-day kind of issue.
>
> Given that sequences are in fact relations is there some way to work around
> the issue at least in this case by stuffing the sequence's relid someplace
> which the plan invalldation code can check for it?
Hm... couldn't this be worked around by doing
create or replace function dynamic_oid(text) returning regclass as
'select $1::regclass' language 'pl/pgsql' stable;
And then writing
nextval(dynamic_oid('mysequence')).
I didn't test this, but it it actually works, maybe we should just stick this
into the docs somewhere. It's probably too late to add that function to the
backend, though...
As long as mysequence is really a temporary sequence, this wont even have
searchpath issues I think, because those are always on top of the searchpatch
anyway, aren't they?
greetings, Florian Pflug
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to
majordomo@postgresql.orgso that your message can get through to the mailing list cleanly