Skip site navigation (1) Skip section navigation (2)

Re: feature request ?

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: sad <sad(at)bankir(dot)ru>
Cc: "Gregory S(dot) Williamson" <gsw(at)globexplorer(dot)com>,pgsql-sql(at)postgresql(dot)org
Subject: Re: feature request ?
Date: 2004-06-24 14:00:32
Message-ID: 20040624065015.Y87012@megazone.bigpanda.com (view raw or flat)
Thread:
Lists: pgsql-sql
On Thu, 24 Jun 2004, sad wrote:

> >  If you were to add a NULL block you'd have to deal with things
> > like, if you only have a then and else, do you run the else on NULL or do
> > you do nothing?  If you do nothing, what if you want the null and else to
> > be the same, do you add another way to specify that?  If you do the else,
> > then the else stops making sense since it's sometimes false and sometimes
> > not true.
>
> it is only syntax problem.
> really we have more than one way to continue execution if one block is skipped
> so your are free to define IF's behavior any way, particularly the way it is
> defined now.

So you want to syntactically allow both ELSE and something like
FALSE/NULL? Or perhaps a different structure from IF entirely?

If you don't then you still run into questions like is
 IF booleanval THEN
  ... 1
 ELSE
  ... 2
 NULL
  ... 2
 ENDIF
different from
 IF booleanval THEN
  ... 1
 ELSE
  ... 2
 ENDIF
because, if they're different, then lots of currently perfectly correct
programs break.  If they're the same, then ELSE has different meanings
depending on whether NULL is specified, and that's generally bad from an
understanding the language standpoint.

In addition, either adding a FALSE and NULL or just a NULL still involves
looking at the rest of the IF semantics to make sure they make sense.  How
do those interact with ELSIF blocks?


In response to

Responses

pgsql-sql by date

Next:From: Stephan SzaboDate: 2004-06-24 14:34:18
Subject: Re: feature request ?
Previous:From: Stephan SzaboDate: 2004-06-24 13:25:05
Subject: Re: feature request ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group