Re: relation OID in ReorderBufferToastReplace error message

"Schneider (AWS), Jeremy" <schnjere(at)amazon(dot)com> writes:
>> On Jul 1, 2021, at 18:57, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> But I wonder why
>> print the parent's OID, when we have access to its name.

> Seems like a few people do schema-based multi-tenancy with similarly named relations in different namespaces, so I’d have a preference for OID over an unqualified relation name. Also the error message shows the OID for the toast relation so this is consistent.

Um, well, the reason we're printing the OID for the toast rel is exactly
that we've not been able to resolve an associated relation, so the OID is
the *only* thing that we have. But we do have the parent rel's relcache
entry at hand.

> Relation name could work too though, especially if the schema was included

I'm definitely -1 on trying to print the schema name, because that would
require an additional catalog fetch. If we're in this situation at all,
catalog fetches are suspect; we could easily end up hitting an additional
failure that will probably print a *totally* uninformative message.

I understand your point about similarly-named tables in different schemas,
but Postgres' error messages are uniformly unfriendly to that case, and
I'm not seeing a good reason why this one needs to be different. On the
other side, I think there are good reasons not to print an OID when we
don't have to: there are plenty of situations where you can't readily
trace the OID to anything at all. For example, if this error showed up
in a buildfarm run, what do you think the odds would be of identifying
which table the OID referred to? Maybe you could do it given knowledge
that the error could only be referencing one of a few specific tables,
but it'd still be questionable.

So I think the relation name is what to print here. That's generally
what we do, and there's not much argument for this case to be different.

(I'm not unsympathetic to the idea that printing schema names
would be helpful. Just that here is not where to start with
that. Maybe we could consider sucking in the schema name
during relcache entry build, and then print from that copy so we
don't need an additional catalog fetch under error conditions?)

regards, tom lane