SEO

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

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!

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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!

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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!

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-----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=2529DF...9B906714964AC8

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

iD8DBQFDTT+1vJuQZxSWSsgRApbmAKCTQWMS3RQIY4R0Bby0Xj 8hMZ9mqgCfdskt
q5J6e0AaIOFaVI+pXnGGWCo=



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match