Re: BUG #1532: typecast problem between arrays of an int8
От | Joe Conway |
---|---|
Тема | Re: BUG #1532: typecast problem between arrays of an int8 |
Дата | |
Msg-id | 42433F1F.9070503@joeconway.com обсуждение исходный текст |
Ответ на | Re: BUG #1532: typecast problem between arrays of an int8 derived datatype and varchar[] (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #1532: typecast problem between arrays of an int8 derived datatype and varchar[]
|
Список | pgsql-bugs |
Tom Lane wrote: > "Ezequiel Tolnay" <mail@etolnay.com.ar> writes: >>I've created the cardnumber_t datatype, which is an int8, to provide >>implicit typecasting with varchar padding the result with zeroes. >>Conversions work as expected between int4, int8, cardnumber_t and varchar. >>They also work fine between int4[], int8[] and cardnumber_t[], but when an >>attempt is made to convert a cardnumber_t[] to a varchar[], the connection >>is dropped. > > What's going on here is that array_map thinks it can use fn_extra of the > passed FmgrInfo for its own purposes. That means that if the function > to be called tries to use fn_extra for *its* own purposes, we have a > conflict that is going to lead to core dumps in most cases. In other > words, array_map pretty much doesn't work for calling anything except > built-in functions. > > I think the best solution to this is to require array_map's caller to > provide the state storage array_map wants, instead of doing it locally. > Both of the existing callers can easily incorporate array_map's state > data into their own state structs. Joe, you have any better ideas? > That certainly looks like the least invasive fix for 8.0.x and 7.4.x. I have thought before that we were overloading fn_extra a bit too much. Is there any merit in having more than one "extra" member in FmgrInfo going forward? Joe
В списке pgsql-bugs по дате отправления: