Re: BETWEEN [SYMMETRIC | ASYMMETRIC]

From: "Robert B(dot) Easter" <reaster(at)comptechnews(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: BETWEEN [SYMMETRIC | ASYMMETRIC]
Date: 2001-01-10 00:35:09
Message-ID: 01010919350901.15894@comptechnews
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> I don't really see this as important enough to justify introducing a
> nonstandard syntax for it...
>
> regards, tom lane

Sorry to quote like this, it makes me feel like a real nerd. :)

This quote from the SQL standard (1999) has it:

8.3 <between predicate>

Function

Specify a range comparison.

Format

<between predicate> ::=
<row value expression> [ NOT ] BETWEEN
[ ASYMMETRIC | SYMMETRIC ]
<row value expression> AND <row value expression>


Syntax Rules

1) If neither SYMMETRIC nor ASYMMETRIC is specified, then
ASYMMETRIC is implicit.

2) Let X, Y, and Z be the first, second, and third <row value
expression>s, respectively.

3) "X NOT BETWEEN SYMMETRIC Y AND Z" is equivalent to "NOT ( X
BETWEEN SYMMETRIC Y AND Z )".

4) "X BETWEEN SYMMETRIC Y AND Z" is equivalent to "((X BETWEEN
ASYMMETRIC Y AND Z) OR (X BETWEEN ASYMMETRIC Z AND Y))".

5) "X NOT BETWEEN ASYMMETRIC Y AND Z" is equivalent to "NOT ( X
BETWEEN ASYMMETRIC Y AND Z )".

6) "X BETWEEN ASYMMETRIC Y AND Z" is equivalent to "X>=Y AND X<=Z".

Access Rules

None.

General Rules

None.

Conformance Rules

1) Without Feature T461, "Symmetric <between predicate>",
conforming SQL language shall not specify SYMMETRIC or
ASYMMETRIC.

2) Without Feature S024, "Enhanced structured types", no subfield
of the declared type of a <row value expression> that is simply
contained in a <between predicate> shall be of a structured
type.

--
-------- Robert B. Easter reaster(at)comptechnews(dot)com ---------
-- CompTechNews Message Board http://www.comptechnews.com/ --
-- CompTechServ Tech Services http://www.comptechserv.com/ --
---------- http://www.comptechnews.com/~reaster/ ------------

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-01-10 00:37:46 Re: Well, we seem to be proof against cache-inval problems now
Previous Message Nathan Myers 2001-01-10 00:30:58 Re: AW: Re: tinterval - operator problems on AIX