Jean-Christophe Deschamps wrote:
> At 23:36 18/03/2018, you wrote:
>> In other words, aliases in the SELECT clause are evaluated _after_ the
>> FROM and WHERE clauses are done.
>
> I must be misinterpreting:
I was talking about the SQL standard. (I might have mentioned that somewhere
...)
> sel
Compared to PostgreSQL, SQLite does a better job here when there is no
input column collision.
The column collision case below returns no rows in both SQLite and
PostgreSQL:
WITH t(a) AS (VALUES ('foo')) SELECT a||'!' AS a FROM t WHERE a='foo!';
But the following edit with intermediating alias c
On 3/18/2018 5:31 AM, Moritz Bruder wrote:
I just came across a strange behaviour in sqlite3 (3.22.0 2018-01-22 18:45:57
0c55d179733b46d8d0ba4d88e01a25e10677046ee3da1d5b1581e86726f2171d). Consider the
following test case:
CREATE TABLE test (name varchar);
INSERT INTO test VALUES ("fo
At 23:36 18/03/2018, you wrote:
In other words, aliases in the SELECT clause are evaluated _after_ the
FROM and WHERE clauses are done.
The order of the SELECT/WHERE clauses in the SQL syntax is misleading;
the actual behaviour would be better represented by something like this:
( FROM test
Simon Slavin wrote:
> As best I can find, SQL92 does not specify what happens when you choose
> an AS clause giving a value name the same as a column.
| 7.3
|
| Function
|
|Specify a table or a grouped table.
|
| Format
|
| ::=
|
| [ ]
| [ ]
| [ ]
|
On 18 Mar 2018, at 9:31am, Moritz Bruder wrote:
> I'm not exactly sure what the SQL standard says
As best I can find, SQL92 does not specify what happens when you choose an AS
clause giving a value name the same as a column. It doesn't go into much
detail at all about applying "AS" to a valu
Hi,
I just came across a strange behaviour in sqlite3 (3.22.0 2018-01-22
18:45:57
0c55d179733b46d8d0ba4d88e01a25e10677046ee3da1d5b1581e86726f2171d).
Consider the following test case:
CREATE TABLE test (name varchar);
INSERT INTO test VALUES ("foo"),("bar");
-- Returns a single row w
7 matches
Mail list logo
