public inbox for [email protected]
help / color / mirror / Atom feedRe: information_schema and not-null constraints
3+ messages / 3 participants
[nested] [flat]
* Re: information_schema and not-null constraints
@ 2023-09-06 00:53 Tom Lane <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2023-09-06 00:53 UTC (permalink / raw)
To: Vik Fearing <[email protected]>; +Cc: David G. Johnston <[email protected]>; Alvaro Herrera <[email protected]>; Pg Hackers <[email protected]>; Peter Eisentraut <[email protected]>; Peter Eisentraut <[email protected]>
Vik Fearing <[email protected]> writes:
> On 9/6/23 00:14, David G. Johnston wrote:
>> I'm not all that for either A or B since the status quo seems workable.
> Pray tell, how is it workable? The view does not identify a specific
> constraint because we don't obey the rules on one side and we do obey
> the rules on the other side. It is completely useless and unworkable.
What solution do you propose? Starting to enforce the spec's rather
arbitrary requirement that constraint names be unique per-schema is
a complete nonstarter. Changing the set of columns in a spec-defined
view is also a nonstarter, or at least we've always taken it as such.
If you'd like to see some forward progress in this area, maybe you
could lobby the SQL committee to make constraint names unique per-table
not per-schema, and then make the information_schema changes that would
be required to support that.
In general though, the fact that we have any DDL extensions at all
compared to the standard means that there will be Postgres databases
that are not adequately represented by the information_schema views.
I'm not sure it's worth being more outraged about constraint names
than anything else. Or do you also want us to rip out (for starters)
unique indexes on expressions, or unique partial indexes?
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: information_schema and not-null constraints
@ 2023-09-06 02:31 Vik Fearing <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Vik Fearing @ 2023-09-06 02:31 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; Alvaro Herrera <[email protected]>; Pg Hackers <[email protected]>; Peter Eisentraut <[email protected]>; Peter Eisentraut <[email protected]>
On 9/6/23 02:53, Tom Lane wrote:
> Vik Fearing <[email protected]> writes:
>> On 9/6/23 00:14, David G. Johnston wrote:
>>> I'm not all that for either A or B since the status quo seems workable.
>
>> Pray tell, how is it workable? The view does not identify a specific
>> constraint because we don't obey the rules on one side and we do obey
>> the rules on the other side. It is completely useless and unworkable.
>
> What solution do you propose? Starting to enforce the spec's rather
> arbitrary requirement that constraint names be unique per-schema is
> a complete nonstarter. Changing the set of columns in a spec-defined
> view is also a nonstarter, or at least we've always taken it as such.
I both semi-agree and semi-disagree that these are nonstarters. One of
them has to give.
> If you'd like to see some forward progress in this area, maybe you
> could lobby the SQL committee to make constraint names unique per-table
> not per-schema, and then make the information_schema changes that would
> be required to support that.
I could easily do that; but now you are asking to denormalize the
standard, because the constraints could be from tables, domains, or
assertions.
I don't think that will go over well, starting with my own opinion.
And for this reason, I do not believe that this is a "rather arbitrary
requirement".
> In general though, the fact that we have any DDL extensions at all
> compared to the standard means that there will be Postgres databases
> that are not adequately represented by the information_schema views.
Sure.
> I'm not sure it's worth being more outraged about constraint names
> than anything else. Or do you also want us to rip out (for starters)
> unique indexes on expressions, or unique partial indexes?
Indexes of any kind are not part of the standard so these examples are
basically invalid.
SQL:2023-11 Schemata is not the part I am most familiar with, but I
don't even see where regular multi-column unique constraints are listed
out, so that is both a lack in the standard and a knockdown of this
argument. I am happy to be shown wrong about this.
--
Vik Fearing
^ permalink raw reply [nested|flat] 3+ messages in thread
* [PATCH] Cover get_json_table_plan() with tests
@ 2026-07-10 13:44 Aleksander Alekseev <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Aleksander Alekseev @ 2026-07-10 13:44 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
Hi,
I noticed that get_json_table_plan() is never executed by the existing
tests. The proposed patch fixes this.
--
Best regards,
Aleksander Alekseev
Attachments:
[text/x-patch] v1-0001-Cover-get_json_table_plan-with-tests.patch (3.8K, ../../CAJ7c6TP0kgaN1Hjtj1PYtQVF0vyr+ce01oAx9Li_UpGDG2NMmA@mail.gmail.com/2-v1-0001-Cover-get_json_table_plan-with-tests.patch)
download | inline diff:
From a99b5e95dd095a04886b81f4ae3a7de94664fb70 Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev <[email protected]>
Date: Fri, 10 Jul 2026 16:27:54 +0300
Subject: [PATCH v1] Cover get_json_table_plan() with tests
Function get_json_table() executes get_json_table_plan() only when
json_table_plan_is_default() == false. For this reason the existing tests
didn't cover get_json_table_plan() before.
Author: Aleksander Alekseev <[email protected]>
Reviewed-by: TODO FIXME
Discussion: TODO FIXME
---
.../regress/expected/sqljson_jsontable.out | 55 +++++++++++++++++++
src/test/regress/sql/sqljson_jsontable.sql | 22 ++++++++
2 files changed, 77 insertions(+)
diff --git a/src/test/regress/expected/sqljson_jsontable.out b/src/test/regress/expected/sqljson_jsontable.out
index 1530ef8afe0..fc8e8d7e1a7 100644
--- a/src/test/regress/expected/sqljson_jsontable.out
+++ b/src/test/regress/expected/sqljson_jsontable.out
@@ -1847,3 +1847,58 @@ CREATE OR REPLACE VIEW public.json_table_view9 AS
)
)
DROP VIEW json_table_view8, json_table_view9;
+-- Test get_json_table_plan()
+-- covers the INNER branch and the UNION branch
+CREATE VIEW jt_plan_inner_union AS
+SELECT * FROM JSON_TABLE(
+ jsonb 'null', '$' AS p
+ COLUMNS (NESTED PATH '$[*]' AS p1 COLUMNS (a int),
+ NESTED PATH '$[*]' AS p2 COLUMNS (b int))
+ PLAN (p INNER (p1 UNION p2))
+);
+\sv jt_plan_inner_union
+CREATE OR REPLACE VIEW public.jt_plan_inner_union AS
+ SELECT a,
+ b
+ FROM JSON_TABLE(
+ 'null'::jsonb, '$' AS p
+ COLUMNS (
+ NESTED PATH '$[*]' AS p1
+ COLUMNS (
+ a integer PATH '$."a"'
+ ),
+ NESTED PATH '$[*]' AS p2
+ COLUMNS (
+ b integer PATH '$."b"'
+ )
+ )
+ PLAN (p INNER (p1 UNION p2))
+ )
+DROP VIEW jt_plan_inner_union;
+-- covers the OUTER branch and the CROSS branch
+CREATE VIEW jt_plan_outer_cross AS
+SELECT * FROM JSON_TABLE(
+ jsonb 'null', '$' AS p
+ COLUMNS (NESTED PATH '$[*]' AS p1 COLUMNS (a int),
+ NESTED PATH '$[*]' AS p2 COLUMNS (b int))
+ PLAN (p OUTER (p1 CROSS p2))
+);
+\sv jt_plan_outer_cross
+CREATE OR REPLACE VIEW public.jt_plan_outer_cross AS
+ SELECT a,
+ b
+ FROM JSON_TABLE(
+ 'null'::jsonb, '$' AS p
+ COLUMNS (
+ NESTED PATH '$[*]' AS p1
+ COLUMNS (
+ a integer PATH '$."a"'
+ ),
+ NESTED PATH '$[*]' AS p2
+ COLUMNS (
+ b integer PATH '$."b"'
+ )
+ )
+ PLAN (p OUTER (p1 CROSS p2))
+ )
+DROP VIEW jt_plan_outer_cross;
diff --git a/src/test/regress/sql/sqljson_jsontable.sql b/src/test/regress/sql/sqljson_jsontable.sql
index d71d57e99b2..74903a75fc8 100644
--- a/src/test/regress/sql/sqljson_jsontable.sql
+++ b/src/test/regress/sql/sqljson_jsontable.sql
@@ -1004,3 +1004,25 @@ CREATE VIEW json_table_view9 AS SELECT * from JSON_TABLE('"a"', '$' COLUMNS (a t
\sv json_table_view9;
DROP VIEW json_table_view8, json_table_view9;
+
+-- Test get_json_table_plan()
+-- covers the INNER branch and the UNION branch
+CREATE VIEW jt_plan_inner_union AS
+SELECT * FROM JSON_TABLE(
+ jsonb 'null', '$' AS p
+ COLUMNS (NESTED PATH '$[*]' AS p1 COLUMNS (a int),
+ NESTED PATH '$[*]' AS p2 COLUMNS (b int))
+ PLAN (p INNER (p1 UNION p2))
+);
+\sv jt_plan_inner_union
+DROP VIEW jt_plan_inner_union;
+-- covers the OUTER branch and the CROSS branch
+CREATE VIEW jt_plan_outer_cross AS
+SELECT * FROM JSON_TABLE(
+ jsonb 'null', '$' AS p
+ COLUMNS (NESTED PATH '$[*]' AS p1 COLUMNS (a int),
+ NESTED PATH '$[*]' AS p2 COLUMNS (b int))
+ PLAN (p OUTER (p1 CROSS p2))
+);
+\sv jt_plan_outer_cross
+DROP VIEW jt_plan_outer_cross;
--
2.43.0
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-07-10 13:44 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-09-06 00:53 Re: information_schema and not-null constraints Tom Lane <[email protected]>
2023-09-06 02:31 ` Vik Fearing <[email protected]>
2026-07-10 13:44 [PATCH] Cover get_json_table_plan() with tests Aleksander Alekseev <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox