Hiroshi Inoue wrote:
>
> Tom Lane wrote:
> >
> > Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > > I don't object to use a search path to resolve unqualified
> > > function, type etc names. But it is very siginificant for
> > > users to be able to be sure what tables they are handling.
> >
> > I really don't buy this argument; it seems exactly comparable to
> > arguing that the notion of current directory in Unix is evil, and
> > that users should be forced to specify absolute paths to every
> > file that they reference.
> >
> > There is nothing to stop you from writing qualified names (schema.table)
> > if you are concerned about being sure that you get the table you intend.
>
> Probably I can do it in many cases but I couldn't force others
> to do it. I don't object if PostgreSQL doesn't allow unqualified
> table name other than in public/temporary/catalog schema.
> There's no ambiguity and there's no need for the CURRENT schema.
>
We can't do that. Accordingly to the SQL if you are user HIROSHI
and write "SELECT * FROM a;" the table is actually "HIROSHI.a".
This must work for people who are using SQL-schemas in their databases
or we would have a non-conforming implementation of SCHEMAS (would make
the whole exercise pointless IMO).
The path proposed by Tom (discussed in the list some time ago) actually
does magic:
1) It allows SQL_schema compliant code and database to work as the
standard expects;
2) It allows backward compatibility as someone will be able to use the
same schema-unaware code and create their databases without schemas as
before.
3) If the DBA is careful enough, she/he can convert his/her database to
use schemas incrementally.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
