Re: [GENERAL] Limitation

John,

Can't you do this check in a trigger?  Have a select count(*) with a
where so that all columns are checked against the row being
edited/inserted.  If the count is not zero then rejectr the
update/insert.

If you have one index which is for 7 fields (I guess the ones that
differ most often) then the select should be quite fast.

NB I have not written any postgresql triggers so I am not certain of
what is possible in them. But you could definately do this in the
various dbms I have written triggers for.

I realise this will be slow to write the code for so it would probably
be best to script the trigger definitions.

I came to sql from a background in DataFlex and Btrieve so I understand
many of the problems. We had similar indexes in some db's and it took a
while to get people used to designing without indexes and then add them
for speed.

Dave

John Huttley wrote:
>
> The answer is that you are thinking as indexes in the context of fast lookup
> on fields.
>
> However my requirement comes from a need to ensure that every single field
> in the
> table forms a unique combination. (not my design, I might add)
>
> Now you know why, can you append it to the TODO list?
>
> On thinking about it, I wonder if the same field can appear more than
> once in an index. Now that would be weird!
>
> >> 1.  Have more than 7 fields on a btree index
> >
> >We have never understood why someone would want an index with more than
> >seven columns.
> >
> >--
> >  Bruce Momjian                        |  http://www.op.net/~candle

--
David Warnock
Sundayta Ltd