Re: BUG #1532: typecast problem between arrays of an int8 derived datatype and varchar[] - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #1532: typecast problem between arrays of an int8 derived datatype and varchar[]
Date
Msg-id 5536.1111697032@sss.pgh.pa.us
Whole thread Raw
In response to BUG #1532: typecast problem between arrays of an int8 derived datatype and varchar[]  ("Ezequiel Tolnay" <mail@etolnay.com.ar>)
Responses Re: BUG #1532: typecast problem between arrays of an int8  (Joe Conway <mail@joeconway.com>)
List pgsql-bugs
"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?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #1552: massive performance hit between 7.4 and 8.0.1
Next
From: Tom Lane
Date:
Subject: Re: pg_dump table ordering bug [8.0.1]