Re: SQL99, CREATE CAST, and initdb - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: SQL99, CREATE CAST, and initdb
Date
Msg-id 3D188C95.80A889B4@fourpalms.org
Whole thread Raw
In response to Re: SQL99, CREATE CAST, and initdb  (Thomas Lockhart <lockhart@fourpalms.org>)
List pgsql-hackers
> Well, let's see an alternate proposal.

OK. Proposal:

Schemas should be able to contain extensions to any and all features
available in the database. Features are resolved by searching the path,
choosing the first exact-match in the path. Under-specified cases should
be resolved from within the entire set of schemas, using the match
closest to the front of the schema list as a tie-breaker.

> If we just look for "anything named int4() in the current search path"
> then I think we will have some unpleasantnesses of a different sort,
> namely unexpected conflicts between similarly-named types in different
> schemas.

Yup. Schemas are a larger gun and can be loaded with larger bullets, and
feet should beware. We should get the expected behavior if they are not
being explicitly used, and we should get the most powerful behavior if
they are imho.

> > btw, how *do* I control the default schema? Is it always the schema at
> > the front of the search list,
> If you mean the default schema for creating things, yes, it's whatever
> is at the front of the search list.  Should it be different?

We should at least have some ability to incrementally add and subtract
from the search list. Something like SET SCHEMA = 'foo' would be
helpful. Since we don't currently have the search list as a queryable
(sp?) entity, it is difficult to manipulate on the fly afaict.
                  - Thomas




pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: Suggestions for implementing IS DISTINCT FROM?
Next
From: Andrew Sullivan
Date:
Subject: Re: Democracy and organisation : let's make a revolution