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
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
Andrew Dunstan wrote:
>
>
> 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
Added to TODO:
o Pass arrays nat
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 broadcast)--
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 doi
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
an
Sergej, are you going to repost this patch?
---
Tom Lane wrote:
> Bruce Momjian 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?
>
> T
Bruce Momjian 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
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)
> >>
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.
> >>
> >>
> >
>
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
Bruce Momjian wrote:
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 g
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Sergej Sergeev wrote:
>
> >Sergej Sergeev <[EMAIL PROTECTED]> writes:
> >
> >
> >>>What happens if you feed other pseud
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
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, there will always be one mor
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
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
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.
--
Sergej Sergeev wrote:
any comments on my last patch?
Speaking for myself, I am not really thinking much about new plperl
stuff until we get closer to branching the code, which as I understand
the current processes would be at the time we release an RC - that seems
a little way off yet.
cheers
any comments on my last patch?
--
g.gRay: PL/perl, PL/PHP ;)
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
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
upgr
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
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 broad
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 anyel
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 '
>
25 matches
Mail list logo
