Обсуждение: RE: [HACKERS] tuple return from function

> >     there  is  a targetlist in the func node of a C function (for
> >     ExecMake...  there is no  difference  between  C,  PL/TCL  or
> >     PL/pgSQL),  it  knows  that  the  return  value is a tuple or
> >     tupletable or temp relation or whatever and it can manage for
> >     the  requested  projection and for the iteration (if function
> >     isset).
> >
> >     But should we do that all (and the rule stuff) before 6.4?
>
> Sorry to say this, but I think we need the rewrite stuff done for 6.4.
>
> Too many bugs and limited features.
>
> The PL/pgSQL perhaps can be started now, but not ready until 6.5?  I
> don't think we should delay 6.4 for PL/pgSQL, do you?
>
I personally am willing to wait another month for PL/pgSQL w/returned
tuples if it means I don't have to wait another 6 months for it.  I
would also be willing to do work toward that end, if anyone needs the
help (nobody's taken me up on the offer for help yet).
And I agree about the rewrite stuff.  If it's a choice between rewrite
and PL/pgSQL I say rewrite.  But, I'd like to have my cake and eat it
too.
        -DEJ

P.S. And while your at it, Jan, if you could drop in syntax for GROUP
creation/removal I'd be ecstatic.  But I do understand the need to eat.

> I personally am willing to wait another month for PL/pgSQL w/returned
> tuples if it means I don't have to wait another 6 months for it.  I
> would also be willing to do work toward that end, if anyone needs the
> help (nobody's taken me up on the offer for help yet).

    I  just  sent the initial version to Bruce to be added to the
    source tree. It is without tuple return (except for triggers)
    since  this  requires  changes  to PostgreSQL itself, which I
    think would be better for  6.5.  Also  the  changes  recently
    discussed  about  the  extended syntax for CREATE TRIGGER and
    the ()'s on CREATE FUNCTION should be delayed for 6.5.

    As soon as it's in the CVS, I  don't  call  it  my  baby  any
    longer.  It's  my child then and children go out to the world
    to  learn  things  I  cannot  teach  them.  But   I'm   still
    responsible for my child.

    There  is  currently  a  point  where  your  offered  help is
    appreciated.  It lacks a CASE ... WHEN ...  END  CASE;  which
    would  be  very  useful.   I  have  some ideas already how to
    implement it but it would be nice if others get familiar with
    the code too.

> And I agree about the rewrite stuff.  If it's a choice between rewrite
> and PL/pgSQL I say rewrite.  But, I'd like to have my cake and eat it
> too.
>         -DEJ

    I  think  there  is  no  choice  any  longer.  I'll start now
    removing all the non-instead rule  stuff  to  make  the  rule
    system as reliable as can.

    For  6.5  I  want  to  have  the suggested uid/euid model for
    views, functions and triggers and maybe  ACL's  on  functions
    too.  And  the tuples for functions fixed. When this is done,
    PL/pgSQL is  absolutely  safe  and  can  be  a  real  trusted
    language.  This  is  IMHO required to incorporate it into the
    backend itself and install it in the template1 database while
    bootstrapping.

>
> P.S. And while your at it, Jan, if you could drop in syntax for GROUP
> creation/removal I'd be ecstatic.  But I do understand the need to eat.
>

    No  priority  for  me  for 6.4. But will get priority for 6.5
    when doing the ACL and uid/euid stuff.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #

> > I personally am willing to wait another month for PL/pgSQL w/returned
> > tuples if it means I don't have to wait another 6 months for it.  I
> > would also be willing to do work toward that end, if anyone needs the
> > help (nobody's taken me up on the offer for help yet).
>
>     I  just  sent the initial version to Bruce to be added to the
>     source tree. It is without tuple return (except for triggers)
>     since  this  requires  changes  to PostgreSQL itself, which I
>     think would be better for  6.5.  Also  the  changes  recently
>     discussed  about  the  extended syntax for CREATE TRIGGER and
>     the ()'s on CREATE FUNCTION should be delayed for 6.5.
>
>     As soon as it's in the CVS, I  don't  call  it  my  baby  any
>     longer.  It's  my child then and children go out to the world
>     to  learn  things  I  cannot  teach  them.  But   I'm   still
>     responsible for my child.
>
>     There  is  currently  a  point  where  your  offered  help is
>     appreciated.  It lacks a CASE ... WHEN ...  END  CASE;  which
>     would  be  very  useful.   I  have  some ideas already how to
>     implement it but it would be nice if others get familiar with
>     the code too.
>

Added to /contrib.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)