Re: AllocSetContextCreate changes breake extensions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: AllocSetContextCreate changes breake extensions
Date
Msg-id 28302.1543768404@sss.pgh.pa.us
Whole thread Raw
In response to Re: AllocSetContextCreate changes breake extensions  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: AllocSetContextCreate changes breake extensions
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>     With this change, there is no reason for anybody to call
>     AllocSetContextCreateExtended directly, so in HEAD I renamed it to

> except there IS such a reason: if you need (as I do in pl/lua) to wrap
> the call in a catch block, inside a function which takes the name and so
> on as a parameter, then you have no option but to do so (since using the
> macro errors out on the non-const parameter).

I'm kind of unimpressed by your example, because you're deliberately
breaking the safety check the macro sets out to provide.  With code
structure like this, it's impossible to be sure that what was passed to
the wrapper function is actually a constant string.  You'd be better
off using the workaround the comment suggests, which is to just pass ""
to AllocSetContextCreate and then use MemoryContextSetIdentifier to
copy the passed string.

> At least let's revert the pointless name change.

I don't think it's entirely pointless: it's keeping the "Extended"
name available for possible future use.  If I revert, what name
are we going to use when we really do need an API-incompatible
version of AllocSetContextCreate?

            regards, tom lane


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [proposal] Add an option for returning SQLSTATE in psql error message
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Log CSV by default