From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Sergej Sergeev <sergej(at)commandprompt(dot)com>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: plperl features |
Date: | 2005-06-25 12:41:49 |
Message-ID: | 42BD510D.60602@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
This was the patch that I took the array processing piece from and
attempted to fix, since it was badly broken. However, I'm not happy
about any of the ways of doing it, and suspect I won't get it done for
8.1. I think we need that piece done before we look at ANYELEMENT/ANYARRAY.
cheers
andrew
Bruce Momjian wrote:
>Sergej, are you going to repost this patch?
>
>---------------------------------------------------------------------------
>
>Tom Lane wrote:
>
>
>>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>>
>>
>>>Also, I don't think the arg_is_p variable is really the proper fix for
>>>this, but I am unsure what to recomment. Others?
>>>
>>>
>>The thing I didn't like about that was that it assumes there is only
>>one pseudotype behavior that is or ever will be interesting for plperl.
>>
>>I think it'd probably make more sense to store an array of the parameter
>>type OIDs and then check for ANYELEMENT or ANYARRAY as such in the
>>places where the patch uses arg_is_p.
>>
>> regards, tom lane
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 7: don't forget to increase your free space map settings
>>
>>
>>
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-06-25 13:31:12 | Re: plperl features |
Previous Message | Andrew Dunstan | 2005-06-25 10:45:13 | Re: COPY FROM performance improvements |