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

Re: BUG #1532: typecast problem between arrays of an int8

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ezequiel Tolnay <mail(at)etolnay(dot)com(dot)ar>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1532: typecast problem between arrays of an int8
Date: 2005-03-24 22:28:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Tom Lane wrote:
> "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?

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?


In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2005-03-24 22:33:38
Subject: Re: BUG #1513: pg_dump -t doesn't include sequences for pre-v8-created tables
Previous:From: Tom LaneDate: 2005-03-24 22:27:45
Subject: Re: pg_dump table ordering bug [8.0.1]

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