Re: Is temporary functions feature official/supported? Found someissues with it. - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: Is temporary functions feature official/supported? Found someissues with it.
Date
Msg-id 20190105000037.GA1626@paquier.xyz
Whole thread Raw
In response to Re: Is temporary functions feature official/supported? Found some issues with it.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Is temporary functions feature official/supported? Found someissues with it.  (Michael Paquier <michael@paquier.xyz>)
List pgsql-bugs
On Fri, Jan 04, 2019 at 09:54:39AM -0500, Tom Lane wrote:
> Hm, I had forgotten that we had such an error message.  Really that
> restriction needs to apply to any object in the temp namespace, not only
> tables.

The cleanest way I can think we need to set up the flag each time
InitTempTableNamespace() *could* be called.  If myTempNamespace is
valid, the routine may however not be called.  So an idea is to return
immediately from InitTempTableNamespace() if myTempNamespace is valid
instead, which would mean removing its assertion at the top.  Using a
wrapper on top of InitTempTableNamespace() is also possible but I
think that we should design things so as only one code path sets
MyXactFlags, and one good thing is that InitTempTableNamespace() is
the only code path setting myTempNamespace.

For the tests, it is possible to use "\c -" to enforce a reconnection
which would be able to discard the previous temp namespace and allow
reproducibility, however as this problem applies to any objects which
can be schema-qualified this is not necessary for all the tests.

I think I can get that worked out with a back-patchable approach,
still it looks a bit sensitive because of the creation-pending logic
which relies on the assertion at the top of InitTempTableNamespace,
which is a case we may want to handle with an extra flag for the
caller of InitTempTableNamespace(), aka "fail if myTempNamespace is
valid instead of just returning back".
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: a Marath
Date:
Subject: Re: BUG #15572: Misleading message reported by "Drop functionoperation" on DB with functions having same name
Next
From: Michael Paquier
Date:
Subject: Re: BUG #15446: Crash on ALTER TABLE