I wrote: > Well, the main point here seems to be that you've got a function > returning record, not just a scalar value which is what your initial > example suggested. I've been able to duplicate the error and confirm > that the behavior changed in 9.0, but have not yet tracked down why. > More news as it develops ...
I've looked into this and concluded that it is a bug, or at least undesirable behavior. The reason for the change is that 9.0 is actually checking that the typmods (length constraints) of the record fields match what they are supposed to be, which prior versions never did. (You can get this function to return more than 8 characters in one of the record fields, for instance, if using pre-9.0.) However, plpgsql doesn't pass variable typmods into the main executor, so the record field is identified as char-without-length-constraint here: > return_pieces := (new_card_id, magic_byte, crazy_eights); and then the new checking code quite properly complains about that not matching the record type specified in the calling query. A workaround while we figure out what to do about it is to add explicit casts to the row constructor: return_pieces := (new_card_id, magic_byte::char(8), crazy_eights::char(8)); I'm moving the discussion about what to do about it to pgsql-hackers: http://archives.postgresql.org/pgsql-hackers/2011-05/msg00738.php since while it's fairly clear what to change in HEAD, it's not at all obvious whether we ought to try to change this in released branches. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
