Thread: [HACKERS] objsubid vs subobjid
pg_get_object_address() currently returns a field called subobjid, while pg_depend calls that objsubid. I'm guessing that wasn't on purpose (especially because internally the function uses objsubid), and it'd be nice to fix it. Attached does that, as well as updating the input naming on the other functions for consistency. I stopped short of changing the instances of subobjid in the C code to reduce backpatch issues, but maybe that should be done too... -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
On 2/22/17 19:35, Jim Nasby wrote: > pg_get_object_address() currently returns a field called subobjid, while > pg_depend calls that objsubid. I'm guessing that wasn't on purpose > (especially because internally the function uses objsubid), and it'd be > nice to fix it. I'm in favor of changing it, but it could theoretically break someone's code. I don't know what the practical use for these functions is. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut wrote: > On 2/22/17 19:35, Jim Nasby wrote: > > pg_get_object_address() currently returns a field called subobjid, while > > pg_depend calls that objsubid. I'm guessing that wasn't on purpose > > (especially because internally the function uses objsubid), and it'd be > > nice to fix it. > > I'm in favor of changing it, but it could theoretically break someone's > code. Yes, it was an oversight. +1 for changing. > I don't know what the practical use for these functions is. This was originally written for BDR use in DDL replication. Partly the interfaces exist for testing purposes (to make sure that object addresses can roundtrip between internal OID numerical representation and set of names); what BDR uses is the path that goes via event triggers (pg_event_trigger_ddl_commands and pg_event_trigger_dropped_objects). I didn't find any use of the name "subobjid" anywhere in BDR. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3/1/17 09:51, Alvaro Herrera wrote: > Peter Eisentraut wrote: >> On 2/22/17 19:35, Jim Nasby wrote: >>> pg_get_object_address() currently returns a field called subobjid, while >>> pg_depend calls that objsubid. I'm guessing that wasn't on purpose >>> (especially because internally the function uses objsubid), and it'd be >>> nice to fix it. >> >> I'm in favor of changing it, but it could theoretically break someone's >> code. > > Yes, it was an oversight. +1 for changing. OK done. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3/1/17 9:24 AM, Peter Eisentraut wrote: > On 3/1/17 09:51, Alvaro Herrera wrote: >> Peter Eisentraut wrote: >>> On 2/22/17 19:35, Jim Nasby wrote: >>>> pg_get_object_address() currently returns a field called subobjid, while >>>> pg_depend calls that objsubid. I'm guessing that wasn't on purpose >>>> (especially because internally the function uses objsubid), and it'd be >>>> nice to fix it. >>> >>> I'm in favor of changing it, but it could theoretically break someone's >>> code. >> >> Yes, it was an oversight. +1 for changing. > > OK done. BTW, did you backpatch as well? The function was added in 9.5. Presumably we wouldn't normally do that, but if we think this is unused enough maybe it's worth it. -- Jim Nasby, Chief Data Architect, OpenSCG
On 3/5/17 16:10, Jim Nasby wrote: > BTW, did you backpatch as well? The function was added in 9.5. > Presumably we wouldn't normally do that, but if we think this is unused > enough maybe it's worth it. It's a catalog change, so we can't backpatch it. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services