Constrained and forced, I am obliged to accept the behavior which is a means of using useful functionalities (standard SQL a priori). It's instructive for me.
I don't know if it's the same behavior (more or less strict SQL standard) in other DBMS. For example, in Oracle it is not possible to have a SELECT statement without a FROM clause (using DUAL table), so maybe " ambiguous " columns are not handled in the same way. Anyway, thank you very much for the explanation. Regards De: "David G. Johnston" <david.g.johns...@gmail.com> À: "PALAYRET Jacques" <jacques.palay...@meteo.fr> Cc: "PostgreSQL mailing lists" <pgsql-gene...@postgresql.org> Envoyé: Mardi 22 Mars 2022 14:04:32 Objet: Re: PostgreSQL : bug (ou not) in CTE Common Table Expressions or Subqueries in the FROM Clause On Tuesday, March 22, 2022, PALAYRET Jacques < [ mailto:jacques.palay...@meteo.fr | jacques.palay...@meteo.fr ] > wrote: According to me, there is only one condition in the main statement (SELECT [ http://w.id/ | w.id ] , [ http://w.name/ | w.name ] , w.elev FROM weather_stations ...) and it is : elev > 151 (correlation ou not correlation). In others words : for each line of table weather_stations), the only condition is : is the elev superior than the elev returned by the subquery, 151 ? Visibly, the correlated statement adds one condition ( [ http://w.id/ | w.id ] BETWEEN 31000000 and 31999999) in the main statement, but it's not logical for me, because of the parentheses. I agree your example query is written poorly and thus is confusing. But it is not possible for the system to distinguish a poorly written query from a goodly written one that uses the same functionality. As the functionality is useful, and the parentheses simply don’t isolate the subquery in the manner you ascribe to them, you’ll just need to adapt to reality. Its doesn’t have to seem logical to you, but this is how it is defined to work and thus the observed behavior is not a bug. David J.
