> 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:
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
In response to
pgsql-bugs by date
|Next:||From: Bernd Helmle||Date: 2011-05-12 22:08:43|
|Subject: Re: BUG #6024: pg_dump won't dump ALTERed inherited fields |
|Previous:||From: Robert Haas||Date: 2011-05-12 20:26:47|
|Subject: Re: BUG #6022: Postgre84+RHEL6+Veritas file system?|