Re: AllocSetContextCreate changes breake extensions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: AllocSetContextCreate changes breake extensions
Дата
Msg-id 28302.1543768404@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: AllocSetContextCreate changes breake extensions  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Ответы Re: AllocSetContextCreate changes breake extensions  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [proposal] Add an option for returning SQLSTATE in psql error message
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Log CSV by default