| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Inconsistencies between dependency.c and objectaddress.c |
| Date: | 2019-02-14 16:43:05 |
| Message-ID: | 19935.1550162585@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
In <26527(dot)1549572789(at)sss(dot)pgh(dot)pa(dot)us> I speculated about adding a
function to objectaddress.c that would probe to see if an object
with a given ObjectAddress (still) exists. I started to implement
this, but soon noticed that objectaddress.c doesn't cover all the
object classes that dependency.c knows. This seems bad; is there
a reason for it? The omitted object classes are
AccessMethodOperatorRelationId
AccessMethodProcedureRelationId
AttrDefaultRelationId
DefaultAclRelationId
PublicationRelRelationId
UserMappingRelationId
What's potentially a lot worse, the two subsystems do not agree
as to the object class OID to be used for large objects:
dependency.c has LargeObjectRelationId but what's in objectaddress.c
is LargeObjectMetadataRelationId. How did we get to that, and why
isn't it causing serious problems?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitry Dolgov | 2019-02-14 16:45:33 | Re: libpq compression |
| Previous Message | Sergei Kornilov | 2019-02-14 16:36:55 | Re: pg11.1: dsa_area could not attach to segment |