Re: [PATCHES] plperl features

2005-06-29 Thread Sergej Sergeev
Bruce Momjian wrote: Sergej, are you going to repost this patch? Sorry for delaying. Yes, I working on it, but I wait for decision about Andrew and Abhijit patches. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PATCHES] plperl features

2005-06-29 Thread Andrew Dunstan
Sergej Sergeev said: Bruce Momjian wrote: Sergej, are you going to repost this patch? Sorry for delaying. Yes, I working on it, but I wait for decision about Andrew and Abhijit patches. This is the polymorphic types plus perl to pg array patch, right? I am not working on this right now

Re: [PATCHES] plperl features

2005-06-25 Thread Bruce Momjian
Do we need a TODO item? --- Andrew Dunstan wrote: 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

Re: [PATCHES] plperl features

2005-06-25 Thread Andrew Dunstan
Bruce Momjian wrote: Do we need a TODO item? Sure, Maybe two: . pass arrays natively instead of as text between plperl and postgres . add support for polymorphic arguments and return types to plperl cheers andrew ---(end of

Re: [PATCHES] plperl features

2005-06-09 Thread Bruce Momjian
Sergej Sergeev wrote: Sergej Sergeev [EMAIL PROTECTED] writes: What happens if you feed other pseudotypes, like cstring or language_handler? Shouldn't that be disallowed or something? Other pseudo-types are disallowed (no-change) No, because you diked out

Re: [PATCHES] plperl features

2005-06-09 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.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

Re: [PATCHES] plperl features

2004-10-11 Thread Bruce Momjian
I assume this is an 8.0 fix. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it.

Re: [PATCHES] plperl features

2004-10-11 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: I assume this is an 8.0 fix. It looks more like a new feature to me ... regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PATCHES] plperl features

2004-10-11 Thread Joshua D. Drake
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I assume this is an 8.0 fix. It looks more like a new feature to me ... They were requested features that we did not get done before freeze. It would be great if we could get them applied. We are continuing to

Re: [PATCHES] plperl features

2004-10-11 Thread Bruce Momjian
Peter Eisentraut wrote: Joshua D. Drake wrote: We expected this to a degree of course, but if we can get some of them in, it would be nice for the community who wants to use plPerl. On the other hand, it wouldn't be that nice for the community that respects a good freeze. As you know,

Re: [PATCHES] plperl features

2004-10-11 Thread Joshua D. Drake
Entirely expected (at least by me). I certainly respect a good freeze (what a nice phrase). However, there are outstanding patches from Abhijit Menon-Sen that are genuine bug fixes that need to be queued, reviewed and applied. It was worth a shot ;) Joshua D. Drake cheers andrew

Re: [PATCHES] plperl features

2004-10-11 Thread Bruce Momjian
Andrew Dunstan wrote: Considering that we're already a long time into the beta phase, and we're still working out portability issues especially in the various plug-ins, we really ought to be strict about the freeze in that area if we ever want to get finished. Agreed. This is

Re: [PATCHES] plperl features

2004-09-30 Thread Sergej Sergeev
Sergej Sergeev [EMAIL PROTECTED] writes: What happens if you feed other pseudotypes, like cstring or language_handler? Shouldn't that be disallowed or something? Other pseudo-types are disallowed (no-change) No, because you diked out the check at lines 1452ff, rather than

Re: [PATCHES] plperl features

2004-09-29 Thread Alvaro Herrera
On Wed, Sep 29, 2004 at 07:13:47PM +0300, Sergej Sergeev wrote: Patch provide support for array type and pseudo type (anyelement, anyarray) for function parameters and result. for example: CREATE FUNCTION add_three_values(anyelement, anyelement, anyelement) RETURNS anyelement AS ' return

Re: [PATCHES] plperl features

2004-09-29 Thread Sergej Sergeev
Alvaro Herrera wrote: On Wed, Sep 29, 2004 at 07:13:47PM +0300, Sergej Sergeev wrote: Patch provide support for array type and pseudo type (anyelement, anyarray) for function parameters and result. for example: CREATE FUNCTION add_three_values(anyelement, anyelement, anyelement) RETURNS

Re: [PATCHES] plperl features

2004-09-29 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: What happens if you feed other pseudotypes, like cstring or language_handler? Shouldn't that be disallowed or something? Indeed. This patch breaks those defenses... regards, tom lane ---(end of

Re: [PATCHES] plperl features

2004-09-29 Thread Tom Lane
Sergej Sergeev [EMAIL PROTECTED] writes: What happens if you feed other pseudotypes, like cstring or language_handler? Shouldn't that be disallowed or something? Other pseudo-types are disallowed (no-change) No, because you diked out the check at lines 1452ff, rather than upgrading it to