RE: Planned changes to pg_am catalog - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject RE: Planned changes to pg_am catalog
Date
Msg-id ECEHIKNFIMMECLEBJFIGGEEHCBAA.chriskl@familyhealth.com.au
Whole thread Raw
In response to Planned changes to pg_am catalog  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Note that this doesn't address Oleg's concerns about haskeytype,
> lossiness, etc.  AFAICS those issues are not related to the contents
> of pg_am.  Later on, I am going to have some proposals for altering
> pg_opclass and related tables to deal with those issues...
>
> Comments?  Any other festering problems in this immediate area?

As part of my DROP CONSTRAINT stuff I've been fiddling with, I've found it
necessary to write an 'IsIndex' function.  At the moment, all it does is
return true if the named index exists on the named relation and is unique
(or primary, or neither, or any).

I think it would be very nice to have an all-purpose function with a
definition something like this:

bool IsIndex(Relation rel, const char *indname, int type, List attrs);

Where type could be:

0 - any
1 - normal
2 - unique
3 - primary

And attrs, if not null, indicates that true should only be returned if the
index is over the given list of attributes (in the given order).

I guess the function would assume that the necessary lock is acquired on the
relation from outside the function.

I think there's _lots_ of places in the code where index existence checks
are performed and this could prevent vast code-duplication...

Chris



pgsql-hackers by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: iconv?
Next
From: Bruce Momjian
Date:
Subject: pg_depend