On Wed, Mar 14, 2018 at 1:29 PM Paul Jungwirth <p...@illuminatedcomputing.com> wrote:
> On 03/14/2018 06:19 AM, Jeremy Finzel wrote: > > Hello! From all that I can tell, it is not possible using a btree_gist > > index as a primary key. If so, why not? I have a table with this gist > > index which truly ought to be its primary key. as_of_date is of range > > date type: > > > > EXCLUDE USING gist (id WITH =, as_of_date WITH &&) > > I'm curious why you need a primary key on this table, especially if the > exclusion constraint is already preventing duplicate/overlapping records? > > Technically I think an exclusion constraint (or at least this one) > fulfills the formal requirements of a primary key (is unique, isn't > null), but maybe there are other primary-key duties it doesn't meet, > like defining foreign keys that reference it. I've been on-and-off > building an extension for temporal foreign keys at [1]. That is pretty > new, but perhaps it will be useful/interesting to you. And if you have > any feedback, I'd love to hear it! > > But anyway, maybe if you shared why the table needs a real PRIMARY KEY, > people here can suggest something. > > [1] https://github.com/pjungwir/time_for_keys > > Yours, > > -- > Paul ~{:-) > pj@ <p...@illuminatedcomputing.com> Because many extensions require primary keys. I also infer primary keys for various purposes. illuminatedcomputing.com <p...@illuminatedcomputing.com> > >
