| 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: | Whole Thread | Raw Message | 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 |