Thats a good idea!
I'll have a go and try it out.
However the 7 field limitation still needs resolving.
Regards
John
-----Original Message-----
From: David Warnock <david@sundayta.co.uk>
To: John Huttley <john@mwk.co.nz>
Cc: pgsql-general <pgsql-general@postgreSQL.org>
Date: Friday, 25 June 1999 10:33
Subject: 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
>