Hi,
while reviewing the "shared record typmod" patchseries I noticed that
that the last version [1] of the patchset didn't consider the constraint
in the computed hashvalue, but comparison did. In the ensuing IM
discussion Thomas and I noticed that assign_record_type_typmod() already
doesn't properly deal with this.
It's possible to get tupledescs with constraints blessed, e.g. because
plpgsql is fairly liberal in doing so. But as
assign_record_type_typmod(), creates its cache entries with
CreateTupleDescCopy(), the end result is that we'll never find an
existing blessed tupledesc when doing a lookup - the cached ones will
all have no constraints and thus the comparison will fail.
In many cases that'll not be immediately observable, because the blessed
tupledesc, rather than its cached copy, will have it's tdtypemod updated
too, therefore avoiding future blessings. But that won't work if another
copy is used for the lookup.
Does anyone see a case where it'd be good to consider constraints in
blessed tupledescs? Please note that that'd also be problematic for
parallelism. Both for existing code (tqueue doesn't handle constraints)
and proposed future code (it'd be considerably more complicated to share
constraints too).
Greetings,
Andres Freund
[1] http://archives.postgresql.org/message-id/CAEepm%3D04LM87Ya_Avgw40934Wh3G4Oyy%2BmmthYHuMb9m5WZwaQ%40mail.gmail.com