From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
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:04:32 |
Message-ID: | 2765.976647872@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
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?
In any case, it's certainly a bad idea that the system accepted an
FK constraint relating int[] to int.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-12-12 19:09:18 | Re: case with distinct |
Previous Message | Merrill Oveson | 2000-12-12 18:39:05 | case with distinct |