Re: Is temporary functions feature official/supported? Found some issues with it.

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alexey Bashtanov <bashtanov(at)imap(dot)cc>, pgsql-bugs(at)postgresql(dot)org, mmitar(at)gmail(dot)com
Subject: Re: Is temporary functions feature official/supported? Found some issues with it.
Date: 2019-01-05 00:00:37
Message-ID: 20190105000037.GA1626@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2019-01-05 00:27:36 Re: BUG #15446: Crash on ALTER TABLE
Previous Message a Marath 2019-01-04 23:04:48 Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name