Re: Proposal to suppress errors thrown by to_reg*() - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Proposal to suppress errors thrown by to_reg*()
Date
Msg-id CA+hUKGJXDA947SNj-Yw_2Fw75poS4eeN57LXvAqqGd5yCdhJSQ@mail.gmail.com
Whole thread Raw
In response to Re: Proposal to suppress errors thrown by to_reg*()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal to suppress errors thrown by to_reg*()  (Takuma Hoshiai <hoshiai@sraoss.co.jp>)
List pgsql-hackers
On Wed, Jul 31, 2019 at 4:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Takuma Hoshiai <hoshiai@sraoss.co.jp> writes:
> > [ fix_to_reg_v2.patch ]
>
> I took a quick look through this patch.  I'm on board with the goal
> of not having schema-access violations throw an error in these
> functions, but the implementation feels pretty ugly and bolted-on.
> Nobody who had designed the code to do this from the beginning
> would have chosen to parse the names twice, much less check the
> ACLs twice which is what's going to happen in the success path.
>
> But a worse problem is that this only fixes the issue for the
> object name proper.  to_regprocedure and to_regoperator also
> have type name(s) to think about, and this doesn't fix the
> problem for those:

...

> So I think you ought to drop this implementation and fix it properly
> by adjusting the behaviors of the functions cited above.

Hello Hoshiai-san,

Based on the above review, I have set this to 'Returned with
feedback'.  If you plan to produce a new patch in time for the next
Commitfest in September, please let me know very soon and I'll change
it to 'Moved to next CF', but otherwise please feel free to create a
new entry when you are ready.

Thanks!

-- 
Thomas Munro
https://enterprisedb.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: concerns around pg_lsn
Next
From: Michael Paquier
Date:
Subject: Re: refactoring - share str2*int64 functions