Ask a Question related to PostgreSQL / PGSQL, Design and Development.

  1. #1

    Default pl/pgsql oddity

    Hello everyone,

    When writing some serverside code I ran into an oddity that I
    managed to boil down to this:

    -------------------------------------------------------
    create or replace function fubar() returns varchar as '
    declare
    l integer;
    begin
    l = 38;
    if l < 38 then
    return ''< 38'';
    elseif l >= 38 then
    return ''>= 38'';
    else
    return ''this is not possible'';
    end if;
    end;'
    language 'plpgsql';
    -------------------------------------------------------

    But I can't understand or solve it. The function always returns
    'this is not possible'. Can someone tell me what I'm overlooking?
    Thanks!


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

    [url]http://www.postgresql.org/docs/faqs/FAQ.html[/url]

    Joolz Guest

  2. Similar Questions and Discussions

    1. Date oddity in Acrobat, default page size oddity
      Got two things driving me nuts. One, when I go to Save As a file, the file dats come up in the form like this: Saturday, July -2147483642, 41221,...
    2. child object oddity
      I have a parent script and in it I noticed that a SendAllSprites call to a handler in a script attached to a sprite on the stage wasn't getting to...
    3. Toolbox oddity
      Greetings All. Does anyone know why the toolbox icons and all the tool options along the top are solid black on some machines and not others, i've...
    4. CSS & Template Oddity
      I have created an entire website based on a template. In the beginning, I linked the CSS into the template and created pages. As I was building...
    5. OE oddity
      Greetings, I recently let a friend use my computer for a few minutes to send some e-mail and somehow they managed to mess things up somewhat. ...
  3. #2

    Default Re: pl/pgsql oddity

    Hi,
    > l = 38;
    This should be:

    l := 38;

    otherwise l would remain uninitialized (NULL).


    Ciao ciao
    --
    Matteo Beccati
    [url]http://phpadsnew.com[/url]
    [url]http://phppgads.com[/url]


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

    [url]http://www.postgresql.org/docs/faqs/FAQ.html[/url]

    Matteo Beccati Guest

  4. #3

    Default Re: pl/pgsql oddity

    On Thu, 16 Dec 2004 10:06:19 +0100 (CET), Joolz
    <joolz@arbodienst-limburg.nl> wrote:
    > Hello everyone,
    >
    > When writing some serverside code I ran into an oddity that I
    > managed to boil down to this:
    >
    > -------------------------------------------------------
    > create or replace function fubar() returns varchar as '
    > declare
    > l integer;
    > begin
    > l = 38;
    > if l < 38 then
    > return ''< 38'';
    > elseif l >= 38 then
    Try "elsif" here.
    (No, I don't know what the problem with "elseif" is).

    Ian Barwick

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

    Ian Barwick Guest

  5. #4

    Default Re: pl/pgsql oddity

    Joolz wrote:
    > Hello everyone,
    >
    > When writing some serverside code I ran into an oddity that I
    > managed to boil down to this:
    > elseif l >= 38 then
    You want "elsif" - plpgsql isn't a hugely sophisticated language and its
    parser is having trouble there. I'm guessing the parser is somehow
    putting the "elseif" branch under the initial "then" so it never gets
    executed. If you rewrite the function like so:

    create or replace function fubar() returns varchar as '
    declare
    l integer;
    begin
    l = 34;
    if l < 38 then
    raise notice ''< 38: %'',l;
    elseif l >= 38
    then raise notice ''>= 38: %'',l;
    else
    raise notice ''this is not possible: %'',l;
    end if;

    return 0;
    end;'
    language 'plpgsql';

    Now, try different values for "l" and you'll see what is happening.
    Congratulations - I think you've found a bug. You can report it formally
    via the bugs mailing list or [url]http://www.postgresql.org/bugform.html[/url]

    --
    Richard Huxton
    Archonet Ltd

    ---------------------------(end of broadcast)---------------------------
    TIP 1: subscribe and unsubscribe commands go to [email]majordomo@postgresql.org[/email]

    Richard Huxton Guest

  6. #5

    Default Re: pl/pgsql oddity

    Ian Barwick zei:
    > On Thu, 16 Dec 2004 10:06:19 +0100 (CET), Joolz
    > <joolz@arbodienst-limburg.nl> wrote:
    >> Hello everyone,
    >>
    >> When writing some serverside code I ran into an oddity that I
    >> managed to boil down to this:
    >>
    >> -------------------------------------------------------
    >> create or replace function fubar() returns varchar as '
    >> declare
    >> l integer;
    >> begin
    >> l = 38;
    >> if l < 38 then
    >> return ''< 38'';
    >> elseif l >= 38 then
    >
    > Try "elsif" here.
    > (No, I don't know what the problem with "elseif" is).
    Thanks Ian, but I don't understand... I _am_ already using elseif...


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

    Joolz Guest

  7. #6

    Default Re: pl/pgsql oddity

    > When writing some serverside code I ran into an oddity that I
    > managed to boil down to this:
    >
    > -------------------------------------------------------
    > create or replace function fubar() returns varchar as '
    > declare
    > l integer;
    > begin
    > l = 38;
    > if l < 38 then
    > return ''< 38'';
    > elseif l >= 38 then
    > return ''>= 38'';
    > else
    > return ''this is not possible'';
    > end if;
    > end;'
    > language 'plpgsql';
    > -------------------------------------------------------
    >
    > But I can't understand or solve it. The function always returns
    > 'this is not possible'. Can someone tell me what I'm overlooking?
    > Thanks!
    Documentation says you should use "elsif" rather than "elseif". In your
    case everything between "return <38" and "else" is discarded as
    unreachable code. The same sense will have function below:

    create or replace function fubar() returns varchar as '
    declare
    l integer;
    begin
    l = 38;
    if l < 38 then
    return ''< 38'';
    bleblbebleblebe sfdsdf;
    nothing special;
    else
    return ''this is not possible'';
    end if;
    end;'
    language 'plpgsql';
    select fubar();

    Regards,
    Tomasz Myrta
    Tomasz Myrta Guest

  8. #7

    Default Re: pl/pgsql oddity


    Tomasz Myrta zei:
    >> When writing some serverside code I ran into an oddity that I
    >> managed to boil down to this:
    >>
    >> -------------------------------------------------------
    >> create or replace function fubar() returns varchar as '
    >> declare
    >> l integer;
    >> begin
    >> l = 38;
    >> if l < 38 then
    >> return ''< 38'';
    >> elseif l >= 38 then
    >> return ''>= 38'';
    >> else
    >> return ''this is not possible'';
    >> end if;
    >> end;'
    >> language 'plpgsql';
    >> -------------------------------------------------------
    >>
    >> But I can't understand or solve it. The function always returns
    >> 'this is not possible'. Can someone tell me what I'm overlooking?
    >> Thanks!
    >
    > Documentation says you should use "elsif" rather than "elseif". In
    > your
    > case everything between "return <38" and "else" is discarded as
    > unreachable code.
    That's it, thanks!



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

    Joolz Guest

  9. #8

    Default Re: pl/pgsql oddity

    Richard Huxton zei:

    Hi Richard,

    See the other posting,

    elseif l >= 38

    Apparently this is parsed as

    elseif l >= 38
    ^ ^
    | |
    code|
    |
    comment from here on

    It should be "elsif", not "elseif" :-\

    Thanks everyone!


    ---------------------------(end of broadcast)---------------------------
    TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [email]majordomo@postgresql.org[/email])

    Joolz Guest

  10. #9

    Default Re: pl/pgsql oddity

    Richard Huxton wrote:
    > You want "elsif" - plpgsql isn't a hugely sophisticated language and its
    > parser is having trouble there. I'm guessing the parser is somehow
    > putting the "elseif" branch under the initial "then" so it never gets
    > executed.
    Indeed; the parser thinks an unrecognized keyword indicates the
    beginning of a SQL statement: since the PL/PgSQL parser and the SQL
    parser are completely separate, we need to do some guessing about what
    constitutes a legal SQL statement. See the more detailed diagnose of the
    problem here:

    [url]http://archives.postgresql.org/pgsql-bugs/2004-11/msg00297.php[/url]

    There's a patch in that thread that provides better PL/PgSQL error
    checking (which results in flagging this kind of code as invalid at
    compile time). Some form of that patch will be in 8.1, as well as other
    nice stuff like warning for unreachable code.

    Tom also suggested just adding 'elseif' as an alternative for 'elsif'.
    That sounds like it would be worth doing.
    > Congratulations - I think you've found a bug. You can report it formally
    > via the bugs mailing list
    No need, this is a known issue.

    -Neil

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

    Neil Conway Guest

  11. #10

    Default Re: pl/pgsql oddity

    Matteo Beccati wrote:
    > Hi,
    >
    >> l = 38;
    >
    >
    > This should be:
    >
    > l := 38;
    >
    > otherwise l would remain uninitialized (NULL).
    Actually, either work. You are right that the docs suggest the second
    form though.

    --
    Richard Huxton
    Archonet Ltd

    ---------------------------(end of broadcast)---------------------------
    TIP 1: subscribe and unsubscribe commands go to [email]majordomo@postgresql.org[/email]

    Richard Huxton Guest

  12. #11

    Default Re: pl/pgsql oddity

    Neil Conway <neilc@samurai.com> writes:
    > Tom also suggested just adding 'elseif' as an alternative for 'elsif'.
    > That sounds like it would be worth doing.
    I think we should go ahead and do that for 8.0. I'm getting tired of
    reading reports that stem from this mistake (I think this is the third
    one in the past month ...). I can't see any real downside to accepting
    both spellings, can you?

    regards, tom lane

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

    [url]http://www.postgresql.org/docs/faqs/FAQ.html[/url]

    Tom Lane Guest

  13. #12

    Default Re: pl/pgsql oddity

    Tom Lane wrote:
    > Neil Conway <neilc@samurai.com> writes:
    >
    >>Tom also suggested just adding 'elseif' as an alternative for 'elsif'.
    >>That sounds like it would be worth doing.
    >
    >
    > I think we should go ahead and do that for 8.0. I'm getting tired of
    > reading reports that stem from this mistake (I think this is the third
    > one in the past month ...). I can't see any real downside to accepting
    > both spellings, can you?
    Well, you end up with the opposite problem. Someone has a issue and is
    focusing on the spelling of elseif (elsif), because the google searches
    they've done happen to come up with a different spelling then what
    they're using. So, they're looking for a solution in the wrong place.

    I don't know of any other language that permits multiple spellings for
    the same construct. I'd be concerned with starting such a precedent.

    Now I'm sure someone will post back with some valid examples from other
    languages. :(

    --
    Until later, Geoffrey

    ---------------------------(end of broadcast)---------------------------
    TIP 6: Have you searched our list archives?

    [url]http://archives.postgresql.org[/url]

    Geoffrey Guest

  14. #13

    Default Re: pl/pgsql oddity

    On Thu, Dec 16, 2004 at 12:27:53PM -0500, Geoffrey wrote:
    > I don't know of any other language that permits multiple spellings for
    > the same construct. I'd be concerned with starting such a precedent.
    I'd be in favor of making it a bloody law that every bloody language
    use the same bloody spelling. I'm forever forgetting whether a
    particular language uses ELSE IF, ELSEIF, ELSIF, or ELIF. Grumble,
    grumble, grumble....

    --
    Michael Fuhr
    [url]http://www.fuhr.org/~mfuhr/[/url]

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

    Michael Fuhr Guest

  15. #14

    Default Re: pl/pgsql oddity

    Geoffrey <esoteric@3times25.net> writes:
    > I don't know of any other language that permits multiple spellings for
    > the same construct. I'd be concerned with starting such a precedent.
    Well, we have plenty of precedent already at the SQL language level:
    ANALYZE vs ANALYSE, NOTNULL vs IS NOT NULL, and so on.

    regards, tom lane

    ---------------------------(end of broadcast)---------------------------
    TIP 6: Have you searched our list archives?

    [url]http://archives.postgresql.org[/url]

    Tom Lane Guest

  16. #15

    Default Re: pl/pgsql oddity

    Tom Lane wrote:
    > Geoffrey <esoteric@3times25.net> writes:
    >
    >>I don't know of any other language that permits multiple spellings for
    >>the same construct. I'd be concerned with starting such a precedent.
    >
    >
    > Well, we have plenty of precedent already at the SQL language level:
    > ANALYZE vs ANALYSE, NOTNULL vs IS NOT NULL, and so on.
    Like I said, someone would come up with some real world examples. :) I
    personally wouldn't lose too much sleep over it.

    --
    Until later, Geoffrey

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

    Geoffrey Guest

  17. #16

    Default Re: pl/pgsql oddity

    Michael Fuhr wrote:
    > On Thu, Dec 16, 2004 at 12:27:53PM -0500, Geoffrey wrote:
    >
    >> I don't know of any other language that permits multiple spellings
    >> for the same construct. I'd be concerned with starting such a
    >> precedent.
    >
    > I'd be in favor of making it a bloody law that every bloody language
    > use the same bloody spelling. I'm forever forgetting whether a
    > particular language uses ELSE IF, ELSEIF, ELSIF, or ELIF. Grumble,
    > grumble, grumble....
    As a relative newbie to PostgreSQL (but an old-timer to programming
    languages and other DMBSs) I would certainly vote for allowing elseif.
    This is my first encounter of "else" without the terminating "e", and
    that would not be a natural omission for me.

    --
    Guy Rouillier


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

    Guy Rouillier Guest

  18. #17

    Default Re: pl/pgsql oddity

    "elsif" is the spelling used by Ada. I'm getting rather used to it,
    myself.

    I'm really starting to like Ada. So "elsif" is fine with me.

    As far as alternate spellings being accepted within a language, look at
    the Transcript language used by Runtime Revolution ([url]www.runrev.com[/url]),
    which is a so-called "Xtalk" language (based on HyperTalk, which was
    used by HyperCard; and yes, HyperTalk was like this too...)

    -- and # are synonyms (comment delimiters)

    abbreviated can be abbreviated as abbr or abbrev ;-)

    audioClip can be abbreviated as ac

    accelKey and acceleratorKey

    acceleratorModifiers and accelMods

    arm and armed

    autoHilite and autoHighlight

    recentNames and backList

    group, background, bg, and bkgnd


    The list goes on and On and ON...


    On Dec 16, 2004, at 2:12 PM, Guy Rouillier wrote:
    > Michael Fuhr wrote:
    >> On Thu, Dec 16, 2004 at 12:27:53PM -0500, Geoffrey wrote:
    >>
    >>> I don't know of any other language that permits multiple spellings
    >>> for the same construct. I'd be concerned with starting such a
    >>> precedent.
    >>
    >> I'd be in favor of making it a bloody law that every bloody language
    >> use the same bloody spelling. I'm forever forgetting whether a
    >> particular language uses ELSE IF, ELSEIF, ELSIF, or ELIF. Grumble,
    >> grumble, grumble....
    >
    > As a relative newbie to PostgreSQL (but an old-timer to programming
    > languages and other DMBSs) I would certainly vote for allowing elseif.
    > This is my first encounter of "else" without the terminating "e", and
    > that would not be a natural omission for me.
    >
    > --
    > Guy Rouillier
    >
    >
    > ---------------------------(end of
    > broadcast)---------------------------
    > TIP 9: the planner will ignore your desire to choose an index scan if
    > your
    > joining column's datatypes do not match
    >
    >
    -----------------------------------------------------------
    Frank D. Engel, Jr. <fde101@fjrhome.net>

    $ ln -s /usr/share/kjvbible /usr/manual
    $ true | cat /usr/manual | grep "John 3:16"
    John 3:16 For God so loved the world, that he gave his only begotten
    Son, that whosoever believeth in him should not perish, but have
    everlasting life.
    $



    __________________________________________________ _________
    $0 Web Hosting with up to 120MB web space, 1000 MB Transfer
    10 Personalized POP and Web E-mail Accounts, and much more.
    Signup at [url]www.doteasy.com[/url]


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

    Frank D. Engel, Jr. Guest

  19. #18

    Default Re: pl/pgsql oddity

    --- Tom Lane <tgl@sss.pgh.pa.us> escreveu:
    > Neil Conway <neilc@samurai.com> writes:
    > > Tom also suggested just adding 'elseif' as an alternative for 'elsif'.
    > > That sounds like it would be worth doing.
    >
    > I think we should go ahead and do that for 8.0. I'm getting tired of
    > reading reports that stem from this mistake (I think this is the third
    > one in the past month ...). I can't see any real downside to accepting
    > both spellings, can you?
    >
    > regards, tom lane
    I made the exact same mistake and it took me a good chunk of energy to figure
    it out. I didn't report it to the list. When one look at the manual it is very
    easy to read elseif in instead of elsif.

    Regards,
    Clodoaldo Pinto





    __________________________________________________ _____
    Yahoo! Mail - Agora com 250MB de espaço gratuito. Abra
    uma conta agora! [url]http://br.info.mail.yahoo.com/[/url]

    ---------------------------(end of broadcast)---------------------------
    TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [email]majordomo@postgresql.org[/email])

    Clodoaldo Pinto Guest

  20. #19

    Default Re: pl/pgsql oddity

    On Thu, Dec 16, 2004 at 05:14:42PM -0300, Clodoaldo Pinto wrote:
    > --- Tom Lane <tgl@sss.pgh.pa.us> escreveu:
    > > Neil Conway <neilc@samurai.com> writes:
    > > > Tom also suggested just adding 'elseif' as an alternative for 'elsif'..
    > > > That sounds like it would be worth doing.
    > >
    > > I think we should go ahead and do that for 8.0. I'm getting tired of
    > > reading reports that stem from this mistake (I think this is the third
    > > one in the past month ...). I can't see any real downside to accepting
    > > both spellings, can you?
    > >
    > > regards, tom lane
    >
    > I made the exact same mistake and it took me a good chunk of energy to figure
    > it out. I didn't report it to the list. When one look at the manual it isvery
    > easy to read elseif in instead of elsif.
    I'd vote for one of two options:

    1. Accept both elseif and elsif as equivalent or
    2. Add some parsing magic to give a meaningful error message so people
    see it immediatly.

    Maybe just match in "elseif" at beginning of a line and error out with
    "maybe you meant elsif".
    --
    Martijn van Oosterhout <kleptog@svana.org> [url]http://svana.org/kleptog/[/url]
    > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
    > tool for doing 5% of the work and then sitting around waiting for someone
    > else to do the other 95% so you can sue them.
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.0.6 (GNU/Linux)
    Comment: For info see [url]http://www.gnupg.org[/url]

    iD8DBQFBwe8yY5Twig3Ge+YRAnvSAKCElzx0Jt/sE5YO7MqqFr7jSGR/FgCghrmu
    8YO9rHg/eiEKvZHTZeYkYW4=
    =FZ0F
    -----END PGP SIGNATURE-----

    Martijn van Oosterhout Guest

  21. #20

    Default Re: pl/pgsql oddity

    I prefer the FORTRAN66 construct

    IF <condition> <label1> <label2> <label3>

    where it jumps to label1 if <condition> is negative, label2 if zero, and
    label3 if positive. No else ifs about it.

    I hope you realize I'm as kidding as I am obviously too old.



    Michael Fuhr
    <mike@fuhr.org> To: Geoffrey <esoteric@3times25.net>
    Sent by: cc: [email]pgsql-general@postgresql.org[/email]
    pgsql-general-owner@pos Subject: Re: [GENERAL] pl/pgsql oddity
    tgresql.org


    12/16/2004 01:16 PM






    On Thu, Dec 16, 2004 at 12:27:53PM -0500, Geoffrey wrote:
    > I don't know of any other language that permits multiple spellings for
    > the same construct. I'd be concerned with starting such a precedent.
    I'd be in favor of making it a bloody law that every bloody language
    use the same bloody spelling. I'm forever forgetting whether a
    particular language uses ELSE IF, ELSEIF, ELSIF, or ELIF. Grumble,
    grumble, grumble....

    --
    Michael Fuhr
    [url]http://www.fuhr.org/~mfuhr/[/url]

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




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

    Richard_D_Levine@raytheon.com Guest

Posting Permissions

  • You may not post new threads
  • You may post replies
  • You may not post attachments
  • You may not edit your posts

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139