Hello,

We were asked by Enova Financial to improve the documentation of PL/Perl database access functions.
Alvaro and me worked on that and we produced the patch that is attached. It splits initial block of functions
into the groups with the description directly following each of the group, corrects couple of mistakes and
adds an example.

One of the existing mistakes was confusion in definitions of spi_exec_prepared and spi_query_prepared.
Another one is usage of INTEGER type to return the result of spi_prepare in the example for prepared queries.
When trying to execute that function I've got the following error:

postgres=# CREATE OR REPLACE FUNCTION init() RETURNS INTEGER AS $#
$_SHARED{my_plan} = spi_prepare( 'SELECT (now() + $1)::date AS now', 'INTERVAL');
$$ LANGUAGE plperl;

CREATE FUNCTION

postgres=# select init();
ERROR: invalid input syntax for integer: "0x1007d6f40"
CONTEXT: PL/Perl function "init"

Since the return value is not used anyway, I've changed the return type of the function declaration in the example to VOID.

I think this is a good reason to suggest backpatching these changes down to 8.2.

Search Discussions

  • Bruce Momjian at Feb 5, 2010 at 7:40 pm
    Patch applied for 9.0. We don't normally backpatch such documentation
    improvements unless we receive multiple reports of confusion.

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

    Alexey Klyukin wrote:
    Hello,

    We were asked by Enova Financial to improve the documentation of PL/Perl database access functions.
    Alvaro and me worked on that and we produced the patch that is attached. It splits initial block of functions
    into the groups with the description directly following each of the group, corrects couple of mistakes and
    adds an example.

    One of the existing mistakes was confusion in definitions of spi_exec_prepared and spi_query_prepared.
    Another one is usage of INTEGER type to return the result of spi_prepare in the example for prepared queries.
    When trying to execute that function I've got the following error:

    postgres=# CREATE OR REPLACE FUNCTION init() RETURNS INTEGER AS $#
    $_SHARED{my_plan} = spi_prepare( 'SELECT (now() + $1)::date AS now', 'INTERVAL');
    $$ LANGUAGE plperl;

    CREATE FUNCTION

    postgres=# select init();
    ERROR: invalid input syntax for integer: "0x1007d6f40"
    CONTEXT: PL/Perl function "init"

    Since the return value is not used anyway, I've changed the return type of the function declaration in the example to VOID.

    I think this is a good reason to suggest backpatching these changes down to 8.2.

    [ Attachment, skipping... ]

    --
    Alexey Klyukin http://www.CommandPrompt.com/
    The PostgreSQL Company - Command Prompt, Inc


    --
    Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
    To make changes to your subscription:
    http://www.postgresql.org/mailpref/pgsql-hackers
    --
    Bruce Momjian <bruce@momjian.us> http://momjian.us
    EnterpriseDB http://enterprisedb.com

    + If your life is a hard drive, Christ can be your backup. +
  • Alvaro Herrera at Feb 5, 2010 at 8:18 pm

    Bruce Momjian wrote:

    Patch applied for 9.0. We don't normally backpatch such documentation
    improvements unless we receive multiple reports of confusion.
    I think that's a mistake in this case. The documentation wasn't
    confusing -- it was bogus. (Actually, the bug fixing is a smaller
    change than the whole of this patch, so we could provide the smaller
    patch if desired to apply to 8.4. To be honest I think it is better to
    just apply the larger patch verbatim.)

    I could do the backpatch if you want. I just wanted some more peer
    review on the changes.

    --
    Alvaro Herrera http://www.CommandPrompt.com/
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support
  • Bruce Momjian at Feb 5, 2010 at 11:10 pm

    Alvaro Herrera wrote:
    Bruce Momjian wrote:
    Patch applied for 9.0. We don't normally backpatch such documentation
    improvements unless we receive multiple reports of confusion.
    I think that's a mistake in this case. The documentation wasn't
    confusing -- it was bogus. (Actually, the bug fixing is a smaller
    change than the whole of this patch, so we could provide the smaller
    patch if desired to apply to 8.4. To be honest I think it is better to
    just apply the larger patch verbatim.)

    I could do the backpatch if you want. I just wanted some more peer
    review on the changes.
    Sure, go ahead if you are sure. I wasn't clear enough to risk it, and
    documentation churn in back branches has its own downsides, which is why
    I avoid it, especially for larger patches.

    --
    Bruce Momjian <bruce@momjian.us> http://momjian.us
    EnterpriseDB http://enterprisedb.com

    + If your life is a hard drive, Christ can be your backup. +
  • Alvaro Herrera at Mar 11, 2010 at 10:05 pm

    Bruce Momjian wrote:
    Alvaro Herrera wrote:
    Bruce Momjian wrote:
    Patch applied for 9.0. We don't normally backpatch such documentation
    improvements unless we receive multiple reports of confusion.
    I think that's a mistake in this case. The documentation wasn't
    confusing -- it was bogus. (Actually, the bug fixing is a smaller
    change than the whole of this patch, so we could provide the smaller
    patch if desired to apply to 8.4. To be honest I think it is better to
    just apply the larger patch verbatim.)

    I could do the backpatch if you want. I just wanted some more peer
    review on the changes.
    Sure, go ahead if you are sure. I wasn't clear enough to risk it, and
    documentation churn in back branches has its own downsides, which is why
    I avoid it, especially for larger patches.
    Just applied it.

    --
    Alvaro Herrera http://www.CommandPrompt.com/
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJan 29, '10 at 10:11a
activeMar 11, '10 at 10:05p
posts5
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase