On 2021-Nov-15, Tom Lane wrote:
> NOTICE: DROP TABLE dropped object: table constraint public.<NULL> t1_pkey on public.t1
> NOTICE: DROP TABLE dropped object: index public.t1_pkey public.t1_pkey
> DROP TABLE
>
> Note the faulty output for the pkey constraint. I've not looked
> for the cause.
Ah yeah. For objects which have a "schema/name" combination that is
unique (is_nsp_name_unique in ObjectPropertyType), we supply a name,
otherwise we don't. Constraints don't have unique names in a schema
(this also applies to other objects that live under such as triggers and
rules).
Strangely, the schema is also null for triggers, but not for
constraints; I don't remember what the reason is for constraints to have
namespaces, but triggers don't have them.
Anyway, although this is documented, I'm not 100% sure that it was the
best possible design decision. As I recall, the idea was that the user
should be able to construct an equivalent DROP command for the object in
a replica server, and the schema/name combination could not be used for
that purpose for things like constraints, so we decided to leave the
name null.
The code for this is in EventTriggerSQLDropAddObject, which could
perhaps stand some additional commentary.
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"How strange it is to find the words "Perl" and "saner" in such close
proximity, with no apparent sense of irony. I doubt that Larry himself
could have managed it." (ncm, http://lwn.net/Articles/174769/)
