From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: sad <sad@bankir.ru>
Cc: Gregory S. Williamson <gsw@globexplorer.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: feature request ?
Date: Thu, 24 Jun 2004 07:00:32 -0700 (PDT)
Message-ID: <20040624065015.Y87012@megazone.bigpanda.com> (raw)
In-Reply-To: <200406241655.26065.sad@bankir.ru>
References: <71E37EF6B7DCC1499CEA0316A256832801057B7C@loki.wc.globexplorer.net>
<200406241104.15265.sad@bankir.ru>
<20040624062119.Q87012@megazone.bigpanda.com>
<200406241655.26065.sad@bankir.ru>
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?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: sszabo@megazone.bigpanda.com, sad@bankir.ru, gsw@globexplorer.com
Subject: Re: feature request ?
In-Reply-To: <20040624065015.Y87012@megazone.bigpanda.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox