Skip site navigation (1) Skip section navigation (2)

Re: BUG #1532: typecast problem between arrays of an int8 derived datatype and varchar[]

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ezequiel Tolnay" <mail(at)etolnay(dot)com(dot)ar>
Cc: pgsql-bugs(at)postgresql(dot)org, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: BUG #1532: typecast problem between arrays of an int8 derived datatype and varchar[]
Date: 2005-03-24 20:43:52
Message-ID: 5536.1111697032@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Ezequiel Tolnay" <mail(at)etolnay(dot)com(dot)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

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2005-03-24 22:27:45
Subject: Re: pg_dump table ordering bug [8.0.1]
Previous:From: Tom LaneDate: 2005-03-24 19:22:22
Subject: Re: BUG #1552: massive performance hit between 7.4 and 8.0.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group