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-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
