On Fri, 2011-07-08 at 23:39 -0700, Darren Duncan wrote:
> What if you used the context of the calling code and resolve in favor of
> whatever match is closest to it? The problem is related to general-purpose
> programming languages.
>
> Basically start looking in the lexical context for an "x" and if you find one
> use that; otherwise, assuming we're talking about referencing code that lives
> in
> the database such as a function, look at the innermost schema containing the
> referencing code and see if it has a direct child named "x"; otherwise go up
> one
> level to a parent schema, and so on until you get to the top, and finding
> none
> by then say it doesn't exist.
This is an example of where data languages and normal programming
languages have a crucial difference.
With a data language, you have this problem:
1. An application uses a query referencing 'y.z.foo' that resolves to
internal object with fully-qualified name 'x.y.z'.
2. An administrator creates object 'y.z.foo'.
Now, the application breaks all of a sudden.
In a normal prgramming language, if the schema of the two "foo"s are
different, the compiler could probably catch the error. SQL really has
no hope of catching it though.
PostgreSQL has this problem now in a couple ways, but it's much easier
to grasp what you might be conflicting with. If you have multiple nested
levels to traverse and different queries using different levels of
qualification, it gets a little more messy and I think a mistake is more
likely.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
