[GENERAL] pl/pgsql oddity

2004-12-16 Thread Joolz
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'';

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Matteo Beccati
Hi, l = 38; This should be: l := 38; otherwise l would remain uninitialized (NULL). Ciao ciao -- Matteo Beccati http://phpadsnew.com http://phppgads.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.pos

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Richard Huxton
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 "

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Tomasz Myrta
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 the

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Joolz
Ian Barwick zei: > On Thu, 16 Dec 2004 10:06:19 +0100 (CET), Joolz > <[EMAIL PROTECTED]> wrote: >> Hello everyone, >> >> When writing some serverside code I ran into an oddity that I >> managed to boil down to this: >> >> --- >> create or replace

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Ian Barwick
On Thu, 16 Dec 2004 10:06:19 +0100 (CET), Joolz <[EMAIL PROTECTED]> 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 v

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Joolz
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)

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Neil Conway
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 indi

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> 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

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Geoffrey
Tom Lane wrote: Neil Conway <[EMAIL PROTECTED]> 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

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Geoffrey
Tom Lane wrote: Geoffrey <[EMAIL PROTECTED]> 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

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Guy Rouillier
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

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Frank D. Engel, Jr.
"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 (www.runrev.com), which is a so-c

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Richard_D_Levine
MAIL PROTECTED]> Sent by: cc: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: [GENERAL]

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Clodoaldo Pinto
--- Tom Lane <[EMAIL PROTECTED]> escreveu: > Neil Conway <[EMAIL PROTECTED]> 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 repor

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Bruno Wolff III
On Thu, Dec 16, 2004 at 15:34:03 -0500, [EMAIL PROTECTED] wrote: > I prefer the FORTRAN66 construct > > IF My memory is that those labels were separated by commas. > > where it jumps to label1 if is negative, label2 if zero, and > label3 if positive. No else ifs about it. > > I hope yo

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Frank D. Engel, Jr.
"Frank D. Engel, Jr." <[EMAIL PROTECTED]> To: pgsql-general <[EMAIL PROTECTED]> Sent by: cc: [EMAIL PROTECTED]Subject: Re: [GENERAL] pl/pgsql oddity

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Neil Conway
On Thu, 2004-12-16 at 11:09 -0500, Tom Lane wrote: > 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? I

Re: [GENERAL] pl/pgsql oddity

2004-12-17 Thread Richard_D_Levine
I blew the parenthesis around the conditional expression also. Hence the *old* comment. (Embedded image moved to file: pic14771.jpg) Bru

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Joolz
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 <

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Richard Huxton
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)-

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Tom Lane
Geoffrey <[EMAIL PROTECTED]> 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, an

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Michael Fuhr
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 spel

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Martijn van Oosterhout
On Thu, Dec 16, 2004 at 05:14:42PM -0300, Clodoaldo Pinto wrote: > --- Tom Lane <[EMAIL PROTECTED]> escreveu: > > Neil Conway <[EMAIL PROTECTED]> writes: > > > Tom also suggested just adding 'elseif' as an alternative for 'elsif'. > > > That sounds like it would be worth doing. > > > > I think

Re: [GENERAL] pl/pgsql oddity

2004-12-16 Thread Richard_D_Levine
Sent by: cc: [EMAIL PROTECTED] Subject: Re: [GENERAL] pl/pgsql oddity