Обсуждение: suggested warning about perl nested named subroutines

Поиск
Список
Период
Сортировка

suggested warning about perl nested named subroutines

От
Andrew Dunstan
Дата:
I propose to add the following to the plperl docs, following recent
problems.

comments?

cheers

andrew


Index: plperl.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v
retrieving revision 2.45
diff -c -r2.45 plperl.sgml
*** plperl.sgml 24 Aug 2005 19:16:49 -0000      2.45
--- plperl.sgml 12 Oct 2005 00:36:33 -0000
***************
*** 53,64 ****
      # PL/Perl function body
  $$ LANGUAGE plperl;
  </programlisting>
!    The body of the function is ordinary Perl code. A PL/Perl function must
     always return a scalar value.  You can return more complex structures
     (arrays, records, and sets) by returning a reference, as discussed
below.
     Never return a list.
    </para>

     <para>
      The syntax of the <command>CREATE FUNCTION</command> command requires
      the function body to be written as a string constant.  It is usually
--- 53,76 ----
      # PL/Perl function body
  $$ LANGUAGE plperl;
  </programlisting>
!    The body of the function is ordinary Perl code. In fact, the PL/Perl
!    glue code wraps it inside a Perl subroutine. A PL/Perl function must
     always return a scalar value.  You can return more complex structures
     (arrays, records, and sets) by returning a reference, as discussed
below.
     Never return a list.
    </para>

+    <note>
+       <para>
+        The use of named nested subroutines is dangerous in Perl,
especially if
+        they refer to lexical variables in the enclosing scope. Because
a PL/Perl
+        function is wrapped in a subroutine, any named subroutine you
create will
+        be nested. In general, it is far safer to create anonymous
subroutines
+        which you call via a coderef. See the <literal>perldiag</literal>
+        man page for more details.
+       </para>
+    </note>
+
     <para>
      The syntax of the <command>CREATE FUNCTION</command> command requires
      the function body to be written as a string constant.  It is usually


Re: suggested warning about perl nested named subroutines

От
David Fetter
Дата:
On Tue, Oct 11, 2005 at 08:40:21PM -0400, Andrew Dunstan wrote:
>
> I propose to add the following to the plperl docs, following recent
> problems.
>
> comments?

Examples of each and how they'd break would be good.

Cheers,
D
>
> cheers
>
> andrew
>
>
> Index: plperl.sgml
> ===================================================================
> RCS file: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v
> retrieving revision 2.45
> diff -c -r2.45 plperl.sgml
> *** plperl.sgml 24 Aug 2005 19:16:49 -0000      2.45
> --- plperl.sgml 12 Oct 2005 00:36:33 -0000
> ***************
> *** 53,64 ****
>      # PL/Perl function body
>  $$ LANGUAGE plperl;
>  </programlisting>
> !    The body of the function is ordinary Perl code. A PL/Perl function must
>     always return a scalar value.  You can return more complex structures
>     (arrays, records, and sets) by returning a reference, as discussed
> below.
>     Never return a list.
>    </para>
>
>     <para>
>      The syntax of the <command>CREATE FUNCTION</command> command requires
>      the function body to be written as a string constant.  It is usually
> --- 53,76 ----
>      # PL/Perl function body
>  $$ LANGUAGE plperl;
>  </programlisting>
> !    The body of the function is ordinary Perl code. In fact, the PL/Perl
> !    glue code wraps it inside a Perl subroutine. A PL/Perl function must
>     always return a scalar value.  You can return more complex structures
>     (arrays, records, and sets) by returning a reference, as discussed
> below.
>     Never return a list.
>    </para>
>
> +    <note>
> +       <para>
> +        The use of named nested subroutines is dangerous in Perl,
> especially if
> +        they refer to lexical variables in the enclosing scope. Because
> a PL/Perl
> +        function is wrapped in a subroutine, any named subroutine you
> create will
> +        be nested. In general, it is far safer to create anonymous
> subroutines
> +        which you call via a coderef. See the <literal>perldiag</literal>
> +        man page for more details.
> +       </para>
> +    </note>
> +
>     <para>
>      The syntax of the <command>CREATE FUNCTION</command> command requires
>      the function body to be written as a string constant.  It is usually
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>               http://www.postgresql.org/docs/faq

--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!

Re: suggested warning about perl nested named subroutines

От
Neil Conway
Дата:
On Tue, 2005-11-10 at 18:36 -0700, David Fetter wrote:
> Examples of each and how they'd break would be good.

Is that needed? Seems like overkill to me.

-Neil



Re: suggested warning about perl nested named subroutines

От
David Fetter
Дата:
On Tue, Oct 11, 2005 at 09:58:22PM -0400, Neil Conway wrote:
> On Tue, 2005-11-10 at 18:36 -0700, David Fetter wrote:
> > Examples of each and how they'd break would be good.
>
> Is that needed? Seems like overkill to me.

IMHO, yes, and no, respectively.  If there's an example, there's fewer
frustrated people pestering lists about it.

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!

Re: suggested warning about perl nested named subroutines

От
Andrew Dunstan
Дата:

David Fetter wrote:

>On Tue, Oct 11, 2005 at 09:58:22PM -0400, Neil Conway wrote:
>
>
>>On Tue, 2005-11-10 at 18:36 -0700, David Fetter wrote:
>>
>>
>>>Examples of each and how they'd break would be good.
>>>
>>>
>>Is that needed? Seems like overkill to me.
>>
>>
>
>IMHO, yes, and no, respectively.  If there's an example, there's fewer
>frustrated people pestering lists about it.
>
>
>
>

If this were a Postgres problem I'd agree with you. But it isn't, really
- it's a Perl problem, which is properly documented in the Perl docs, to
which this note refers.

I don't think we'll get flooded with problems - Greg is the first person
who has complained about it in the 9 months or so since version 8.0 was
released.

cheers

andrew

Re: suggested warning about perl nested named subroutines

От
Neil Conway
Дата:
On Tue, 2005-11-10 at 18:55 -0700, David Fetter wrote:
> IMHO, yes, and no, respectively.  If there's an example, there's fewer
> frustrated people pestering lists about it.

There is something to be said for brevity: spending a lot of prose on an
example of an obscure problem means the documentation is more difficult
to understand and less useful to most users.

Of course, that's not to say this particular problem is sufficiently
obscure that an example isn't worthwhile (I don't really know) -- but
the attitude that examples are always good is misguided IMHO.

-Neil



Re: suggested warning about perl nested named subroutines

От
David Fetter
Дата:
On Tue, Oct 11, 2005 at 10:01:02PM -0400, Andrew Dunstan wrote:
>
>
> David Fetter wrote:
>
> >On Tue, Oct 11, 2005 at 09:58:22PM -0400, Neil Conway wrote:
> >
> >>On Tue, 2005-11-10 at 18:36 -0700, David Fetter wrote:
> >>
> >>>Examples of each and how they'd break would be good.
> >>>
> >>Is that needed? Seems like overkill to me.
> >
> >IMHO, yes, and no, respectively.  If there's an example, there's
> >fewer frustrated people pestering lists about it.
>
> If this were a Postgres problem I'd agree with you. But it isn't,
> really - it's a Perl problem, which is properly documented in the
> Perl docs, to which this note refers.
>
> I don't think we'll get flooded with problems - Greg is the first
> person who has complained about it in the 9 months or so since
> version 8.0 was released.

Fair enough :)

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!

Re: suggested warning about perl nested named subroutines

От
Bruce Momjian
Дата:
Patch applied.  Thanks.

---------------------------------------------------------------------------


Andrew Dunstan wrote:
>
> I propose to add the following to the plperl docs, following recent
> problems.
>
> comments?
>
> cheers
>
> andrew
>
>
> Index: plperl.sgml
> ===================================================================
> RCS file: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v
> retrieving revision 2.45
> diff -c -r2.45 plperl.sgml
> *** plperl.sgml 24 Aug 2005 19:16:49 -0000      2.45
> --- plperl.sgml 12 Oct 2005 00:36:33 -0000
> ***************
> *** 53,64 ****
>       # PL/Perl function body
>   $$ LANGUAGE plperl;
>   </programlisting>
> !    The body of the function is ordinary Perl code. A PL/Perl function must
>      always return a scalar value.  You can return more complex structures
>      (arrays, records, and sets) by returning a reference, as discussed
> below.
>      Never return a list.
>     </para>
>
>      <para>
>       The syntax of the <command>CREATE FUNCTION</command> command requires
>       the function body to be written as a string constant.  It is usually
> --- 53,76 ----
>       # PL/Perl function body
>   $$ LANGUAGE plperl;
>   </programlisting>
> !    The body of the function is ordinary Perl code. In fact, the PL/Perl
> !    glue code wraps it inside a Perl subroutine. A PL/Perl function must
>      always return a scalar value.  You can return more complex structures
>      (arrays, records, and sets) by returning a reference, as discussed
> below.
>      Never return a list.
>     </para>
>
> +    <note>
> +       <para>
> +        The use of named nested subroutines is dangerous in Perl,
> especially if
> +        they refer to lexical variables in the enclosing scope. Because
> a PL/Perl
> +        function is wrapped in a subroutine, any named subroutine you
> create will
> +        be nested. In general, it is far safer to create anonymous
> subroutines
> +        which you call via a coderef. See the <literal>perldiag</literal>
> +        man page for more details.
> +       </para>
> +    </note>
> +
>      <para>
>       The syntax of the <command>CREATE FUNCTION</command> command requires
>       the function body to be written as a string constant.  It is usually
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: suggested warning about perl nested named subroutines

От
"Greg Sabino Mullane"
Дата:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> If this were a Postgres problem I'd agree with you. But it isn't, really
> - it's a Perl problem, which is properly documented in the Perl docs, to
> which this note refers.

Well, it's really a problem with our implementation of pl/perl. I don't think
it's entirely fair to simply say it's a perl problem and point people at a
perldoc page. An example would definitely be nice - it is not as if the pl/perl
docs are growing out of control or anything. :)

> I don't think we'll get flooded with problems - Greg is the first person
> who has complained about it in the 9 months or so since version 8.0 was
> released.

Call me cutting edge. :) I ran into this when creating an article about
how wonderful pl/perl is. I just don't think many people are using it yet.
Hopefully that will change after my article comes out and I convince all
those perl hackers out there that procedural languages don't need to be
painful anymore.

+1 on the 5.6 dependency: it came out in early 2000. By way of comparison,
PostgreSQL was at version 6.5.3 when perl 5.6 came out.

One more annoyance, while I'm here: what's with "spi_exec_query()"? Is that
the best name we could come up with? How about something short and simple,
in the same vein as "elog()", such as "sql()" ? :)

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200510121205
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFDTT+1vJuQZxSWSsgRApbmAKCTQWMS3RQIY4R0Bby0Xj8hMZ9mqgCfdskt
q5J6e0AaIOFaVI+pXnGGWCo=



Re: suggested warning about perl nested named subroutines

От
Andrew Dunstan
Дата:

Greg Sabino Mullane wrote:

>>If this were a Postgres problem I'd agree with you. But it isn't, really
>>- it's a Perl problem, which is properly documented in the Perl docs, to
>>which this note refers.
>>
>>
>
>Well, it's really a problem with our implementation of pl/perl. I don't think
>it's entirely fair to simply say it's a perl problem and point people at a
>perldoc page. An example would definitely be nice - it is not as if the pl/perl
>docs are growing out of control or anything. :)
>
>

Submit a patch then.

>+1 on the 5.6 dependency: it came out in early 2000. By way of comparison,
>PostgreSQL was at version 6.5.3 when perl 5.6 came out.
>
>

Sure. But there is an older, slightly more klunky, mechanism should work
just as well in this case (see my script).

>One more annoyance, while I'm here: what's with "spi_exec_query()"? Is that
>the best name we could come up with? How about something short and simple,
>in the same vein as "elog()", such as "sql()" ? :)
>
>
>
>

I don't much like it either. But it's there from 8.0, so we really
shouldn't change it now. OTOH I don't like also having spi_query, but
nobody has kicked up much. If we're going to change that we need to
change it real fast.

cheers

andrew

Re: suggested warning about perl nested named subroutines

От
"Greg Sabino Mullane"
Дата:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>One more annoyance, while I'm here: what's with "spi_exec_query()"? Is that
>>the best name we could come up with? How about something short and simple,
>>in the same vein as "elog()", such as "sql()" ? :)

> I don't much like it either. But it's there from 8.0, so we really
> shouldn't change it now. OTOH I don't like also having spi_query, but
> nobody has kicked up much. If we're going to change that we need to
> change it real fast.

We don't need to change it and break backwards-compatibilty, but we could
easily add in a synonym and deprecate spi_*. I prefer sql() or exec(),
although the latter is a little to close to "EXECUTE". Maybe do() in
the spirit of DBI (although it returns result sets, so that could be
potentially confusing). Other ideas? I'm assuming this is a 8.2 thing,
so we have plenty of time. :)

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200510231734
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFDXAJBvJuQZxSWSsgRAs5qAJ9xcw/lcEcOsD3gBcc6o6xQcC4HTgCeNhKQ
aofyqUREbX0jYJD+CVY3FQI=
=1XDK
-----END PGP SIGNATURE-----