From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Cache lookup errors with functions manipulation object addresses |
Date: | 2018-12-13 17:58:02 |
Message-ID: | 20181213175802.pz75lgq3rhgbdzwz@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-Dec-13, Michael Paquier wrote:
> > I support 0001 other than those two points.
>
> Attached is an updated version for that as 0001. Thanks for the
> review. Does that part look good to you now?
+1.
> > +SELECT * FROM pg_identify_object_as_address('pg_proc'::regclass, 0, 0); -- no function
> > + type | object_names | object_args
> > +------+--------------+-------------
> > + | {} | {}
> > +(1 row)
> >
> > All the other cases you add have a non-empty value in "type".
>
> On this one I would expect NULL for object_names and object_args, as
> empty does not make sense for an undefined object, still "type" should
> print... "type".
Hmm ... "routine"?
I'm not sure if NULLs are better than empty arrays, but I agree that we
should pick one representation for undefined object and use it
consistently for all object types.
> > I think this is our chance to fix the mess. Previously (before I added
> > the SQL-access of the object addressing mechanism in 9.5 I mean) it
> > wasn't possible to get at this code at all with arbitrary input, so this
> > is all a "new" problem (I mean new in the last 5 years).
Obviously I failed to subtract 11 from 9.5 correctly ... I meant 4
years.
> This requires a bit more work with the low-level APIs grabbing the
> printed information though. And I think that the following guidelines
> make sense to work on as a base definition for undefined objects:
> - pg_identify_object returns the object type name, NULL for the other fields.
> - pg_describe_object returns just NULL.
> - pg_identify_object_as_address returns the object type name and NULL
> for the other fields.
Sounds good to me.
> There is some more refactoring work still needed for constraints, large
> objects and functions, in a way similar to a26116c6. I am pretty happy
> with the shape of 0001, so this could be applied, 0002 still needs to be
> reworked so as all undefined object types behave as described above in a
> consistent manner. Do those definitions make sense?
I think so, yes.
Thanks for taking care of this.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-12-13 18:43:52 | Re: tab-completion debug print |
Previous Message | David Steele | 2018-12-13 17:48:36 | Re: Add timeline to partial WAL segments |