Re: plperl features

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
>>
>>
>>
>
>
>

In response to

Responses

Browse pgsql-patches by date

  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