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