Hello,
# Let's consider a table defined as follows :
CREATE TABLE weather_stations(
id integer,
name varchar(30),
elev integer
) ;
# After loading, the content :
id | name | elev
--+--+--
31069001 | TOULOUSE-BLAGNAC | 151
31006001 | ALBIAC AGGLOMERATION
This is what happens:
WITH elev_Tlse_Blagnac AS (
SELECT elev FROM weather_stations WHERE id=31069001
)
SELECT w.id, w.name, w.elev
FROM weather_stations AS w
WHERE elev > (SELECT x.elev
FROM elev_Tlse_Blagnac AS x
WHERE w.id BETWEEN 3100 and 3199);
id
Hi,
Le mar. 22 mars 2022 à 10:46, PALAYRET Jacques
a écrit :
> Hello,
>
> # Let's consider a table defined as follows :
> CREATE TABLE weather_stations(
> id integer,
> name varchar(30),
> elev integer
> ) ;
>
> # After loading, the content :
> id| name | elev
> -
On Tuesday, March 22, 2022, Torsten Förtsch wrote:
>
>
> Note the use of aliases, w and x. You are using a correlated subquery.
>
Yep. There is an FAQ entry if you’d like a bit more exposition.
https://wiki.postgresql.org/wiki/FAQ#Why_doesn.27t_PostgreSQL_report_a_column_not_found_error_when_us
Thanks a lot.
Visibly, you are right.
It's a correlated statement, OK, right.
But in the subquery :
(
SELECT x.elev
FROM elev_Tlse_Blagnac AS x
WHERE w.id BETWEEN 3100 and 3199
)
the WHERE clause (= w.id BETWEEN 3100 and 3199) is for the SELECT
x.elev FROM elev_Tlse_Blagn
On Tuesday, March 22, 2022, PALAYRET Jacques
wrote:
>
> According to me, there is only one condition in the main statement (SELECT
> w.id, 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_statio
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
On Wed, 23 Mar 2022 at 04:03, PALAYRET Jacques
wrote:
> 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.
But if your original complaint, the column was not ambiguous
On Mon, Mar 21, 2022 at 06:33:29PM -0400, Tom Lane wrote:
> It sounds like something thinks that scram-sha-256 encryption is
> disallowed by FIPS. That may or may not be accurate. If it's
> supposed to be allowed, you'd need to poke a little harder to
> narrow down where the problem is.
>
> (Dig
