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

Re: constrains of array

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alexander Klimov <ask(at)wisdom(dot)weizmann(dot)ac(dot)il>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: constrains of array
Date: 2000-12-12 19:40:35
Message-ID: Pine.BSF.4.21.0012121127270.32695-100000@megazone23.bigpanda.com (view raw or flat)
Thread:
Lists: pgsql-bugs
On Tue, 12 Dec 2000, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> >> 2) It should be error in *creation* of table if there is no comparasion
> >> operator for constrain check
> 
> > Possibly, although it currently doesn't to allow you to add the operator
> > after you do the references.  The benefits of that might be outweighed by
> > the problems if you don't add the operator.
> 
> I can't see any good reason not to require the operator to pre-exist.

The only case I could see would be if there was some case where you had
equality operators that needed to be defined after the table that had
the references constraint (not sure if that could ever happen).  You
could use alter table in these cases though.

> In fact, there's a good argument that we should require the two columns
> to have the exact same datatype.  Otherwise, equality may be a pretty
> fuzzy concept.  Think about varchar vs bpchar comparison, for example
> --- shall we consider trailing blanks significant?  Which column will
> drive the choice?
I think the spec only requires them to be comparable I believe (I'd
assume that the match predicate rules would apply), so would an equality
operator be sufficient to tell that?


In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2000-12-12 20:25:47
Subject: Re: select cash_out('2'); crashes backend on 7.0.2
Previous:From: Tom LaneDate: 2000-12-12 19:09:18
Subject: Re: case with distinct

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