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


From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: BETWEEN Help
Date: 2002-04-15 01:36:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
> We could make that restriction directly (just resolve the operators,
> and then complain if the resolver chooses different types for A),
> but it might make more sense to first coerce B and C to be the same
> datatype, eg using the same rules that UNION/CASE do.  If we did that
> then BETWEEN would only need to keep track of two comparison operators
> not four (the asymmetric case requires four distinct comparison ops
> if B and C are not the same datatype).
> Comments anyone?

*sigh* This is getting a bit out of my league...  I seem to have a habit of
picking things to work on that turn out to really need a total rethink ;)

> BTW, would you go screaming off into the night if I pointed out that
> SQL92 expects BETWEEN to support row-wise comparisons?  Really this
> project should include upgrading our support of row-wise comparisons
> to be spec-compliant.  Right now, gram.y transforms them into something
> (see makeRowExpr) that looks plausible but does not actually implement
> the spec-required semantics.  I suspect we need RowComparison nodes to
> go along with Between nodes.

I don't quite understand the exact issue, but I'll try to read up on it.
However, expect delays in implementation.

OK, how about I firstly submit a patch that adds support for SYMMETRIC and
ASYMMETRIC using the old style hack.  Actually - I think I've already
submitted that patch.  Then, once that's in, I/we can hack on the new style
one at our leisure.


In response to

pgsql-patches by date

Next:From: Peter EisentrautDate: 2002-04-15 01:47:22
Subject: Re: Commands/ directory reorganisation
Previous:From: Christopher Kings-LynneDate: 2002-04-15 01:23:21
Subject: Re: Commands/ directory reorganisation

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