Re: [sqlsmith] Failed assertion in joinrels.c - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [sqlsmith] Failed assertion in joinrels.c
Date
Msg-id CA+Tgmoah9DyjU-SNL+S6H5MX92dfmS4aQTj3bBq+uoKyN2mAgA@mail.gmail.com
Whole thread Raw
In response to Re: [sqlsmith] Failed assertion in joinrels.c  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [sqlsmith] Failed assertion in joinrels.c
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Wrong defeinition of pq_putmessage_noblock since 9.5
Next
From: Robert Haas
Date:
Subject: Re: pg_dumping extensions having sequences with 9.6beta3