Re: plpgsql: numeric assignment to an integer variable errors out

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql: numeric assignment to an integer variable errors out
Date: 2009-01-22 05:37:37
Message-ID: 162867790901212137u17d57a37nd6f9508bcb98d16c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/1/22 Bruce Momjian <bruce(at)momjian(dot)us>:
> Nikhil Sontakke wrote:
>> > > PFA, patch which uses find_coercion_pathway to find a direct
>> > > COERCION_PATH_FUNC function and uses that if it is available. Or is there
>> > a
>> > > better approach? Seems to handle the above issue with this patch.
>> >
>> > +1
>> >
>> > I thing, so some values should by cached, current patch could by slow.
>>
>>
>> Agreed, it can slow things down a bit especially since we are only
>> interested in the COERCION_PATH_FUNC case. What we need is a much simpler
>> pathway function which searches in the SysCache and returns back with the
>> valid/invalid castfunc immediately.
>>
>> PFA, version 2.0 of this patch with these changes in place. I could have
>> added a generic function in parse_coerce.c, but thought the use case was
>> restricted to plpgsql and hence I have kept it within pl_exec.c for now.
>
> Where are we on this? 8.5?
>

I hope, so this patch will be in next commitfest

Pavel

> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2009-01-22 06:18:58 Re: Lock conflict behavior?
Previous Message Robert Haas 2009-01-22 04:12:54 Re: Pluggable Indexes (was Re: rmgr hooks (v2))