Re: Two questions about "pg_constraint"

No, I’m not proposing any code change. I'm simply seeking the proper understanding in this space. This started off with what I thought were two simple questions.

One was about the "pg_constrain.consrc" column that vanished at some release boundary between PG Version 11, where it was present, and PG 14, where it wasn't. Adrian answered that promptly. And I learned from his reply, and what it referred to, that the Version 11 implementation was faulty and that a robust alternative way to get the answer that the "consrc" column aimed to give was available. I learned, too, a little bit more about how to navigate the PG docs. So "case closed" (and closed very quickly) there.

My other question was about the "connamespace" column. It seemed to me, both at first and still now, that this is a clear instance of a transitive dependency. And I tried to ask only if I'd understood it right. A quick, straightforward, reply, thus:

« Yes, "connamespace" does indeed hold a derived value and could be removed. However, such a change would have only a tiny practical benefit. And the effort to remove it would not be small. Therefore it will simply live on. »

would have been perfect. I would have learned that my analysis was correct. And, if I saw no reason to reference the redundant column, then I simply wouldn't. In other words, it would've been "case closed" there too.

However, my question was met by an assertion that the column was needed.

Adrian showed an experiment that was meant to show that, in the "pg_constraint" table, the "(conname, connamespace)" tuple is a unique key. But you can see that this isn't the case from `\d` on that table, the docs, and from the experiment that I showed.

Tom said that "conname" was necessary because you can have a constraint on each of a table and a domain. But `\d`, the docs, and another experiment that I showed demonstrate that this isn't the case either.

That's why this thread has gone from turn to turn.

Nobody has yet agreed that "connamespace" is indeed a transitive dependency. You, Christophe, _seem_ to agree because you did say "it can be derived from other tables". But that's not quite like saying, simply and directly, that my analysis is sound.

This leaves me, then, in doubt. I fear that I must be missing something. And this fear has now become my main concern.

See what I mean, now?