Re: [sqlsmith] Failed assertion in joinrels.c

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [sqlsmith] Failed assertion in joinrels.c
Дата
Msg-id CA+Tgmoah9DyjU-SNL+S6H5MX92dfmS4aQTj3bBq+uoKyN2mAgA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [sqlsmith] Failed assertion in joinrels.c  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [sqlsmith] Failed assertion in joinrels.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Jul 26, 2016 at 9:27 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Jul 27, 2016 at 5:11 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Committed with minor kibitizing: you don't need an "else" after a
>> statement that transfers control out of the function.
>
> Thanks. Right, I forgot that.
>
>> Shouldn't
>> pg_get_function_arguments, pg_get_function_identity_arguments,
>> pg_get_function_result, and pg_get_function_arg_default get the same
>> treatment?
>
> Changing all of them make sense. Please see attached.

Committed.

> While looking at the series of functions pg_get_*, I have noticed as
> well that pg_get_userbyid() returns "unknown (OID=%u)" when it does
> not know a user. Perhaps we'd want to change that to NULL for
> consistency with the rest?

That's probably correct in theory, but it's a little less closely
related, and I'm not entirely sure how far we want to go with this.
Remember, the original purpose was to avoid having an internal error
(cache lookup failed, XX000) exposed as a user-visible error message.
Are we at risk from veering from actual bug-fixing off into useless
tinkering?  Not sure.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Wrong defeinition of pq_putmessage_noblock since 9.5
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg_dumping extensions having sequences with 9.6beta3