pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feednpgsql - Npgsql2: Give type to NULL literals.
7+ messages / 2 participants
[nested] [flat]
* npgsql - Npgsql2: Give type to NULL literals.
@ 2009-07-02 01:52 User Jbcooley <jbcooley@pgfoundry.org>
0 siblings, 0 replies; 7+ messages in thread
From: jbcooley@pgfoundry.org @ 2009-07-02 01:52 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Give type to NULL literals. See message 1005019. Bug reported by Eric Adv.
Modified Files:
--------------
Npgsql2/src/Npgsql/SqlGenerators:
SqlBaseGenerator.cs (r1.23 -> r1.24)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql/SqlGenerators/SqlBaseGenerator...)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix deparsing of Consts in postgres_fdw ORDER BY
@ 2024-03-10 23:27 David Rowley <drowley@postgresql.org>
0 siblings, 0 replies; 7+ messages in thread
From: David Rowley @ 2024-03-10 23:27 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix deparsing of Consts in postgres_fdw ORDER BY
For UNION ALL queries where a union child query contained a foreign
table, if the targetlist of that query contained a constant, and the
top-level query performed an ORDER BY which contained the column for the
constant value, then postgres_fdw would find the EquivalenceMember with
the Const and then try to produce an ORDER BY containing that Const.
This caused problems with INT typed Consts as these could appear to be
requests to order by an ordinal column position rather than the constant
value. This could lead to either an error such as:
ERROR: ORDER BY position <int const> is not in select list
or worse, if the constant value is a valid column, then we could just
sort by the wrong column altogether.
Here we fix this issue by just not including these Consts in the ORDER
BY clause.
In passing, add a new section for testing ORDER BY in the postgres_fdw
tests and move two existing tests which were misplaced in the WHERE
clause testing section into it.
Reported-by: Michał Kłeczek
Reviewed-by: Ashutosh Bapat, Richard Guo
Bug: #18381
Discussion: https://postgr.es/m/0714C8B8-8D82-4ABB-9F8D-A0C3657E7B6E%40kleczek.org
Discussion: https://postgr.es/m/18381-137456acd168bf93%40postgresql.org
Backpatch-through: 12, oldest supported version
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/c399248b3b44bd6cece1ada47eee346b67a88a0a
Modified Files
--------------
contrib/postgres_fdw/deparse.c | 25 +++++--
contrib/postgres_fdw/expected/postgres_fdw.out | 93 +++++++++++++++++++-------
contrib/postgres_fdw/sql/postgres_fdw.sql | 32 +++++++--
3 files changed, 114 insertions(+), 36 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix deparsing of Consts in postgres_fdw ORDER BY
@ 2024-03-10 23:28 David Rowley <drowley@postgresql.org>
0 siblings, 0 replies; 7+ messages in thread
From: David Rowley @ 2024-03-10 23:28 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix deparsing of Consts in postgres_fdw ORDER BY
For UNION ALL queries where a union child query contained a foreign
table, if the targetlist of that query contained a constant, and the
top-level query performed an ORDER BY which contained the column for the
constant value, then postgres_fdw would find the EquivalenceMember with
the Const and then try to produce an ORDER BY containing that Const.
This caused problems with INT typed Consts as these could appear to be
requests to order by an ordinal column position rather than the constant
value. This could lead to either an error such as:
ERROR: ORDER BY position <int const> is not in select list
or worse, if the constant value is a valid column, then we could just
sort by the wrong column altogether.
Here we fix this issue by just not including these Consts in the ORDER
BY clause.
In passing, add a new section for testing ORDER BY in the postgres_fdw
tests and move two existing tests which were misplaced in the WHERE
clause testing section into it.
Reported-by: Michał Kłeczek
Reviewed-by: Ashutosh Bapat, Richard Guo
Bug: #18381
Discussion: https://postgr.es/m/0714C8B8-8D82-4ABB-9F8D-A0C3657E7B6E%40kleczek.org
Discussion: https://postgr.es/m/18381-137456acd168bf93%40postgresql.org
Backpatch-through: 12, oldest supported version
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/6a9e2cb2b457d962bc3952931a05ad7d5b5be252
Modified Files
--------------
contrib/postgres_fdw/deparse.c | 25 +++++--
contrib/postgres_fdw/expected/postgres_fdw.out | 93 +++++++++++++++++++-------
contrib/postgres_fdw/sql/postgres_fdw.sql | 32 +++++++--
3 files changed, 114 insertions(+), 36 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix deparsing of Consts in postgres_fdw ORDER BY
@ 2024-03-10 23:28 David Rowley <drowley@postgresql.org>
0 siblings, 0 replies; 7+ messages in thread
From: David Rowley @ 2024-03-10 23:28 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix deparsing of Consts in postgres_fdw ORDER BY
For UNION ALL queries where a union child query contained a foreign
table, if the targetlist of that query contained a constant, and the
top-level query performed an ORDER BY which contained the column for the
constant value, then postgres_fdw would find the EquivalenceMember with
the Const and then try to produce an ORDER BY containing that Const.
This caused problems with INT typed Consts as these could appear to be
requests to order by an ordinal column position rather than the constant
value. This could lead to either an error such as:
ERROR: ORDER BY position <int const> is not in select list
or worse, if the constant value is a valid column, then we could just
sort by the wrong column altogether.
Here we fix this issue by just not including these Consts in the ORDER
BY clause.
In passing, add a new section for testing ORDER BY in the postgres_fdw
tests and move two existing tests which were misplaced in the WHERE
clause testing section into it.
Reported-by: Michał Kłeczek
Reviewed-by: Ashutosh Bapat, Richard Guo
Bug: #18381
Discussion: https://postgr.es/m/0714C8B8-8D82-4ABB-9F8D-A0C3657E7B6E%40kleczek.org
Discussion: https://postgr.es/m/18381-137456acd168bf93%40postgresql.org
Backpatch-through: 12, oldest supported version
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/ab64b275ad8f3bd15a3aa77308620fad80e07b62
Modified Files
--------------
contrib/postgres_fdw/deparse.c | 25 +++++--
contrib/postgres_fdw/expected/postgres_fdw.out | 93 +++++++++++++++++++-------
contrib/postgres_fdw/sql/postgres_fdw.sql | 32 +++++++--
3 files changed, 114 insertions(+), 36 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix deparsing of Consts in postgres_fdw ORDER BY
@ 2024-03-10 23:28 David Rowley <drowley@postgresql.org>
0 siblings, 0 replies; 7+ messages in thread
From: David Rowley @ 2024-03-10 23:28 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix deparsing of Consts in postgres_fdw ORDER BY
For UNION ALL queries where a union child query contained a foreign
table, if the targetlist of that query contained a constant, and the
top-level query performed an ORDER BY which contained the column for the
constant value, then postgres_fdw would find the EquivalenceMember with
the Const and then try to produce an ORDER BY containing that Const.
This caused problems with INT typed Consts as these could appear to be
requests to order by an ordinal column position rather than the constant
value. This could lead to either an error such as:
ERROR: ORDER BY position <int const> is not in select list
or worse, if the constant value is a valid column, then we could just
sort by the wrong column altogether.
Here we fix this issue by just not including these Consts in the ORDER
BY clause.
In passing, add a new section for testing ORDER BY in the postgres_fdw
tests and move two existing tests which were misplaced in the WHERE
clause testing section into it.
Reported-by: Michał Kłeczek
Reviewed-by: Ashutosh Bapat, Richard Guo
Bug: #18381
Discussion: https://postgr.es/m/0714C8B8-8D82-4ABB-9F8D-A0C3657E7B6E%40kleczek.org
Discussion: https://postgr.es/m/18381-137456acd168bf93%40postgresql.org
Backpatch-through: 12, oldest supported version
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/628c3f2e17fef9cee9329f8d142db6a69105c681
Modified Files
--------------
contrib/postgres_fdw/deparse.c | 25 +++++--
contrib/postgres_fdw/expected/postgres_fdw.out | 93 +++++++++++++++++++-------
contrib/postgres_fdw/sql/postgres_fdw.sql | 32 +++++++--
3 files changed, 114 insertions(+), 36 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix deparsing of Consts in postgres_fdw ORDER BY
@ 2024-03-10 23:29 David Rowley <drowley@postgresql.org>
0 siblings, 0 replies; 7+ messages in thread
From: David Rowley @ 2024-03-10 23:29 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix deparsing of Consts in postgres_fdw ORDER BY
For UNION ALL queries where a union child query contained a foreign
table, if the targetlist of that query contained a constant, and the
top-level query performed an ORDER BY which contained the column for the
constant value, then postgres_fdw would find the EquivalenceMember with
the Const and then try to produce an ORDER BY containing that Const.
This caused problems with INT typed Consts as these could appear to be
requests to order by an ordinal column position rather than the constant
value. This could lead to either an error such as:
ERROR: ORDER BY position <int const> is not in select list
or worse, if the constant value is a valid column, then we could just
sort by the wrong column altogether.
Here we fix this issue by just not including these Consts in the ORDER
BY clause.
In passing, add a new section for testing ORDER BY in the postgres_fdw
tests and move two existing tests which were misplaced in the WHERE
clause testing section into it.
Reported-by: Michał Kłeczek
Reviewed-by: Ashutosh Bapat, Richard Guo
Bug: #18381
Discussion: https://postgr.es/m/0714C8B8-8D82-4ABB-9F8D-A0C3657E7B6E%40kleczek.org
Discussion: https://postgr.es/m/18381-137456acd168bf93%40postgresql.org
Backpatch-through: 12, oldest supported version
Branch
------
REL_13_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/20b85b3da6f8d885a980a6d7003fe5535686a5cb
Modified Files
--------------
contrib/postgres_fdw/deparse.c | 25 +++++--
contrib/postgres_fdw/expected/postgres_fdw.out | 93 +++++++++++++++++++-------
contrib/postgres_fdw/sql/postgres_fdw.sql | 32 +++++++--
3 files changed, 114 insertions(+), 36 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix deparsing of Consts in postgres_fdw ORDER BY
@ 2024-03-10 23:29 David Rowley <drowley@postgresql.org>
0 siblings, 0 replies; 7+ messages in thread
From: David Rowley @ 2024-03-10 23:29 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix deparsing of Consts in postgres_fdw ORDER BY
For UNION ALL queries where a union child query contained a foreign
table, if the targetlist of that query contained a constant, and the
top-level query performed an ORDER BY which contained the column for the
constant value, then postgres_fdw would find the EquivalenceMember with
the Const and then try to produce an ORDER BY containing that Const.
This caused problems with INT typed Consts as these could appear to be
requests to order by an ordinal column position rather than the constant
value. This could lead to either an error such as:
ERROR: ORDER BY position <int const> is not in select list
or worse, if the constant value is a valid column, then we could just
sort by the wrong column altogether.
Here we fix this issue by just not including these Consts in the ORDER
BY clause.
In passing, add a new section for testing ORDER BY in the postgres_fdw
tests and move two existing tests which were misplaced in the WHERE
clause testing section into it.
Reported-by: Michał Kłeczek
Reviewed-by: Ashutosh Bapat, Richard Guo
Bug: #18381
Discussion: https://postgr.es/m/0714C8B8-8D82-4ABB-9F8D-A0C3657E7B6E%40kleczek.org
Discussion: https://postgr.es/m/18381-137456acd168bf93%40postgresql.org
Backpatch-through: 12, oldest supported version
Branch
------
REL_12_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/9301e0f416d1b92299d06786ac28d14885884dd3
Modified Files
--------------
contrib/postgres_fdw/deparse.c | 25 +++++--
contrib/postgres_fdw/expected/postgres_fdw.out | 93 +++++++++++++++++++-------
contrib/postgres_fdw/sql/postgres_fdw.sql | 32 +++++++--
3 files changed, 114 insertions(+), 36 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2024-03-10 23:29 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-07-02 01:52 npgsql - Npgsql2: Give type to NULL literals. User Jbcooley <jbcooley@pgfoundry.org>
2024-03-10 23:27 pgsql: Fix deparsing of Consts in postgres_fdw ORDER BY David Rowley <drowley@postgresql.org>
2024-03-10 23:28 pgsql: Fix deparsing of Consts in postgres_fdw ORDER BY David Rowley <drowley@postgresql.org>
2024-03-10 23:28 pgsql: Fix deparsing of Consts in postgres_fdw ORDER BY David Rowley <drowley@postgresql.org>
2024-03-10 23:28 pgsql: Fix deparsing of Consts in postgres_fdw ORDER BY David Rowley <drowley@postgresql.org>
2024-03-10 23:29 pgsql: Fix deparsing of Consts in postgres_fdw ORDER BY David Rowley <drowley@postgresql.org>
2024-03-10 23:29 pgsql: Fix deparsing of Consts in postgres_fdw ORDER BY David Rowley <drowley@postgresql.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox