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; 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?
> BTW I see few references to *catalog*. Would the concept
> of catalog be introduced together. If so what would be
> contained in the current database.
My thought is that we will consider catalog == database. As far as
I can tell, that is a legitimate implementation-defined way of
interpreting the spec. (It's not clear to me what the value is of
having more than one level of schema hierarchy; or at least, if you want
hierarchical namespaces, there's no argument for stopping at depth two.
But I digress.) To satisfy the spec we must allow a (purely decorative)
specification of the current database name as the catalog level of a
qualified name, but that's as far as I want to go. In this round,
anyway. Cross-database access is not something to tackle for 7.3.
regards, tom lane
