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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers