Tom Lane wrote:
>
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > I have no objection to the point it makes sense to use
> > such *path*s internally but I think it also has a siginificance
> > for SQL-path to not look up _tables_like objects.
> > I think they are different from the first and we should(need)
> > not manage the system with one *path*.
>
> I'm unconvinced. We must search for datatypes and tables on the same
> path because tables have associated datatypes;
Isn't the table definition a part of the datatype in
such a case ?
> it will definitely not
> do to look for a table's datatype and get the wrong type. And I think
> that functions and operators should be looked for on the same path
> as datatypes, because a type should be pretty closely associated with
> the functions/operators for it. So it seems to me that the apparent
> flexibility of having more than one path is just a way to shoot yourself
> in the foot. Why are you concerned that we keep them separate?
For example, doesn't 'DROP table a_table' drop the
a_table table in a schema in the *path* if there's
no a_table table in the current schema ?
If we would never introduce SQL-paths (in the future)
there would be problem.
regards,
Hiroshi Inoue