Uh, were are we in fixing/reviewing this?


Andrew Dunstan wrote:
> I wrote:
> > Pavel Stehule wrote:
> >> Hello,
> >>
> >> I send two small patches. First does conversion from perl to 
> >> postgresql array in OUT parameters. Second patch allow hash form 
> >> output from procedures with one OUT argument.
> >>
> >
> > I will try to review these in the next 2 weeks unless someone beats me 
> > to it.
> >
> >
> I have reviewed this lightly, as committed by Bruce, and have some 
> concerns. Unfortunately, the deathof my main workstation has cost me 
> much of the time I intended to use for a more thorough review, so there 
> may well be more issues than are outlined here.
> First, it is completely undocumented.
> Second, this comment is at best confusing:
>   /* if value is ref on array do to pg string array conversion */
> Third, it appears to assume that we will have names for all OUT params. But 
> names are optional, as I understand it. Arguably, we should be treating the 
> returns positionally, and thus return an arrayref when there are OYT params, 
> not a hashref, and ignore the names - after all, all perl function args are 
> nameless, in fact, even if you use a naming convention to refer to them.
> Fourth, I don't understand the change: "allow hash form output from 
> procedures with one OUT argument." That seems very non-orthogonal, and I 
> can't see any good reason for it.
> Lastly, if you look at the expected output as committed,it appears to have 
> been prepared without being actually examined, for example:
> CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
>          return {a=>'ahoj'};
>        $$ LANGUAGE plperl;
> SELECT '05' AS i,a FROM test05();
>   i  |        a        
>  ----+-----------------
>   05 | HASH(0x8558f9c)
>  (1 row)
> what???
> And now that I look I see every buildfarm box broken on PLCheck. That's no 
> surprise at all.
> The conversation regarding these features appears only to have started on 
> July 28th, which was probably much too late given some of the issues. Unless 
> we can solve these issues very fast I would be inclined to say this should be 
> tabled for 8.3. I think this is a fairly good illustration of the danger of 
> springing a feature, largely undiscussed, on the community just about freeze 
> time.
> cheers
> andrew

  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to