Re: Schema search for default operator classes (was: [ADMIN] Cross schema Primary Key Indexes problem with datatype in the public schema)

On Wed, Feb 08, 2006 at 09:04:46PM -0500, Tom Lane wrote:
> http://archives.postgresql.org/pgsql-admin/2006-02/msg00084.php
> reports a problem with default btree operator classes that are
> not in pg_catalog: you can create a UNIQUE or PRIMARY KEY constraint
> that depends on such an opclass, but then when you pg_dump and
> try to reload, you get something like

<snip>

> The only other solution I can see is to extend the ADD CONSTRAINT syntax
> to allow explicit specification of an opclass for each column. This
> might be a good thing to do in itself, but it looks like a new feature
> to me, rather than something we could reasonably apply as a bug fix.
> It would certainly be a much larger code change (affecting both pg_dump
> and the backend) than changing the behavior of GetDefaultOpClass. And
> it'd not fix the problem for existing dump files, either.
>
> So I'm leaning towards removing the search-path dependency of
> GetDefaultOpClass. Comments?

I'm for. IMHO, if you give someone has access to the type they should
have access to the supporting machinary. Whoever created the type
probably also created the operator class and intended it to be used.
For a comparison, we don't check the schema on looking up type
input/output functions (well, we don't need to because we have the oid,
but the idea is important).

W.R.T. the other option (per column opclass specification), if we ever
do COLLATE users will be allowed to specify it on a per-column basis
anyway. Then specifying opclasses becomes redundant. I've been
seriously neglecting this patch but hope to get back to it soon...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.