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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-sql by date

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