collin.peters wrote
> Wow, an amazing 'feature' for sure. Is there any use case where it
> actually
> makes sense? I'm just wondering if this is a case where it is better to
> stray from the spec? Would almost prefer a 'NOTICE' if you use an
> unqualified column reference in a sub-query.
Correlated subqueries must be able to see values in the outer relation to
function. Those are quite useful. Since not everything needs or wants to be
table qualified it becomes difficult to selectively enforce such a
requirement.
Two possible solutions...
1. All correlated subqueries need to have external-able columns explicitly
prefixed
2. All normal subquery columns with two possible name resolutions need to be
prefixed
The first option causes your post-rename to fail but the original query
works.
The second option causes the original query to fail but the post-rename one
works.
You can require both and both queries fail.
I'm not saying I support these...though the option would be nice to prevent
just this sort of thing.
David J.
--
View this message in context:
http://postgresql.nabble.com/BUG-12276-Using-old-name-of-a-renamed-or-dropped-column-in-a-sub-query-does-not-throw-error-tp5831401p5831501.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
