On 09.04.24 10:44, jian he wrote:
After studying this a bit more, I think moving forward in this direction
is the best way. Attached is a new patch version, mainly with a more
elaborate commit message. This patch makes the not-null constraint
syntax consistent between CREATE DOMAIN and ALTER DO
On 21.03.24 12:23, Peter Eisentraut wrote:
All the examples in the tests append "value" to this, presumably by
analogy with CHECK constraints, but it looks as though anything works,
and is simply ignored:
ALTER DOMAIN d ADD CONSTRAINT nn NOT NULL xxx; -- works
That doesn't seem particularly sat
On Tue, Mar 26, 2024 at 2:28 AM Dean Rasheed wrote:
>
> On Fri, 22 Mar 2024 at 08:28, jian he wrote:
> >
> > On Thu, Mar 21, 2024 at 7:23 PM Peter Eisentraut
> > wrote:
> > >
> > > Hmm. CREATE DOMAIN uses column constraint syntax, but ALTER DOMAIN uses
> > > table constraint syntax. Attached
On Tue, 26 Mar 2024 at 07:30, Alvaro Herrera wrote:
>
> On 2024-Mar-25, Dean Rasheed wrote:
>
> > Also (not this patch's fault), psql doesn't seem to offer a way to
> > display domain constraint names -- something you need to know to drop
> > or alter them. Perhaps \dD+ could be made to do that?
>
On 2024-Mar-25, Dean Rasheed wrote:
> Also (not this patch's fault), psql doesn't seem to offer a way to
> display domain constraint names -- something you need to know to drop
> or alter them. Perhaps \dD+ could be made to do that?
Ooh, I remember we had offered a patch for \d++ to display these
On Fri, 22 Mar 2024 at 08:28, jian he wrote:
>
> On Thu, Mar 21, 2024 at 7:23 PM Peter Eisentraut wrote:
> >
> > Hmm. CREATE DOMAIN uses column constraint syntax, but ALTER DOMAIN uses
> > table constraint syntax. Attached is a patch to try to sort this out.
>
> also you should also change src/
On Thu, Mar 21, 2024 at 7:23 PM Peter Eisentraut wrote:
>
> On 20.03.24 12:22, Dean Rasheed wrote:
> > Hmm, for CHECK constraints, the ALTER DOMAIN syntax for adding a
> > constraint is the same as for CREATE DOMAIN, but that's not the case
> > for NOT NULL constraints. So, for example, these both
On 3/22/24 01:46, Tom Lane wrote:
Vik Fearing writes:
Anyway, I will bring this up with the committee and report back. My
proposed solution will be for CAST to check domain constraints even if
the input is NULL.
Please do not claim that that is the position of the Postgres project.
Everyt
Vik Fearing writes:
> On 3/22/24 00:17, Tom Lane wrote:
>> Vik Fearing writes:
>>> As also said somewhere in that thread, I think that
>>> short-cutting a NULL input value without considering the constraints of
>>> a domain is a bug that needs to be fixed in the standard.
>> I think it's probab
On 3/22/24 00:17, Tom Lane wrote:
Vik Fearing writes:
On 3/21/24 15:30, Tom Lane wrote:
The SQL spec's answer to that conundrum appears to be "NULL is
a valid value of every domain, and if you don't like it, tough".
I don't see how you can infer this from the standard at all.
I believe wh
Vik Fearing writes:
> On 3/21/24 15:30, Tom Lane wrote:
>> The SQL spec's answer to that conundrum appears to be "NULL is
>> a valid value of every domain, and if you don't like it, tough".
> I don't see how you can infer this from the standard at all.
I believe where we got that from is 6.13 ,
On 3/21/24 15:30, Tom Lane wrote:
Peter Eisentraut writes:
A quick reading of the SQL standard suggests to me that the way we are
doing null handling in domain constraints is all wrong. The standard
says that domain constraints are only checked on values that are not
null. So both the handli
On Thu, 21 Mar 2024 at 10:30, Tom Lane wrote:
> The SQL spec's answer to that conundrum appears to be "NULL is
> a valid value of every domain, and if you don't like it, tough".
>
To be fair, NULL is a valid value of every type. Even VOID has NULL.
In this context, it’s a bit weird to be able
Peter Eisentraut writes:
>
> A quick reading of the SQL standard suggests to me that the way we are
> doing null handling in domain constraints is all wrong. The standard
> says that domain constraints are only checked on values that are not
> null. So both the handling of constraints using
On 20.03.24 12:22, Dean Rasheed wrote:
Hmm, for CHECK constraints, the ALTER DOMAIN syntax for adding a
constraint is the same as for CREATE DOMAIN, but that's not the case
for NOT NULL constraints. So, for example, these both work:
CREATE DOMAIN d AS int CONSTRAINT c1 CHECK (value > 0);
ALTER
On Wed, 20 Mar 2024 at 09:43, Peter Eisentraut wrote:
>
> On 19.03.24 10:57, jian he wrote:
> > this new syntax need to be added into the alter_domain.sgml's synopsis and
> > also
> > need an explanation varlistentry?
>
> The ALTER DOMAIN reference page refers to CREATE DOMAIN about the
> details
On 19.03.24 10:57, jian he wrote:
this new syntax need to be added into the alter_domain.sgml's synopsis and also
need an explanation varlistentry?
The ALTER DOMAIN reference page refers to CREATE DOMAIN about the
details of the constraint syntax. I believe this is still accurate. We
could
On 18.03.24 11:02, Aleksander Alekseev wrote:
Hi,
Anyway, in order to move this forward, here is an updated patch where
the ADD CONSTRAINT ... NOT NULL behavior for domains matches the
idempotent behavior of tables. This uses the patch that Jian He posted.
I tested the patch on Raspberry Pi
create domain connotnull integer;
create table domconnotnulltest
( col1 connotnull
, col2 connotnull
);
alter domain connotnull add not null value;
---
the above query does not work in pg16.
ERROR: syntax error at or near "not".
after applying the patch, now this works.
thi
Hi,
> Anyway, in order to move this forward, here is an updated patch where
> the ADD CONSTRAINT ... NOT NULL behavior for domains matches the
> idempotent behavior of tables. This uses the patch that Jian He posted.
I tested the patch on Raspberry Pi 5 and Intel MacBook and also
experimented wi
traints
+WHERE domain_name IN ('con', 'dom', 'pos_int', 'things'))
+ ORDER BY constraint_name;
base-commit: ca108be72e7abf1f801c8e49dcfff412c0d9
--
2.44.0
From c7e10d25851fa90fe87be84b0d4798fbb110e8fb Mon Sep 17 00:00:00 2001
From: Peter Ei
On 14.03.24 15:03, Alvaro Herrera wrote:
On 2024-Mar-14, Peter Eisentraut wrote:
Perhaps it would make sense if we change the ALTER TABLE command to be like
ALTER TABLE t1 ADD IF NOT EXISTS NOT NULL c1
Then the behavior is like one would expect.
For ALTER TABLE, we would reject this com
On 2024-Mar-14, Peter Eisentraut wrote:
> Perhaps it would make sense if we change the ALTER TABLE command to be like
>
> ALTER TABLE t1 ADD IF NOT EXISTS NOT NULL c1
>
> Then the behavior is like one would expect.
>
> For ALTER TABLE, we would reject this command if IF NOT EXISTS is not
>
On 12.02.24 11:24, Alvaro Herrera wrote:
On 2024-Feb-11, Peter Eisentraut wrote:
But I see that table constraints do not work that way. A command like ALTER
TABLE t1 ADD NOT NULL c1 does nothing if the column already has a NOT NULL
constraint. I'm not sure this is correct. At least it's not d
wandering around the function AlterDomainNotNull,
the following code can fix the previous undesired behavior.
seems pretty simple, am I missing something?
based on v3-0001-Add-tests-for-domain-related-information-schema-v.patch
and v3-0002-Catalog-domain-not-null-constraints.patch
diff --git a/src
On 2024-Feb-11, Peter Eisentraut wrote:
> But I see that table constraints do not work that way. A command like ALTER
> TABLE t1 ADD NOT NULL c1 does nothing if the column already has a NOT NULL
> constraint. I'm not sure this is correct. At least it's not documented.
> We should probably make
Peter Eisentraut writes:
> But I see that table constraints do not work that way. A command like
> ALTER TABLE t1 ADD NOT NULL c1 does nothing if the column already has a
> NOT NULL constraint. I'm not sure this is correct. At least it's not
> documented. We should probably make the domains
On 08.02.24 13:17, jian he wrote:
I think I found a bug.
connotnull already set to not null.
every execution of `alter domain connotnull add not null value ;`
would concatenate 'NOT NULL VALUE' for the "Check" column,
I would have expected that. Each invocation adds a new constraint.
But I s
On Wed, Feb 7, 2024 at 4:11 PM Peter Eisentraut wrote:
>
> >
> > Interesting. I couldn't reproduce this locally, even across different
> > operating systems. The cfbot failures appear to be sporadic, but also
> > happening across multiple systems, so it's clearly not just a local
> > environment
ain_name;
+
+SELECT * FROM information_schema.check_constraints
+ WHERE (constraint_schema, constraint_name)
+IN (SELECT constraint_schema, constraint_name
+ FROM information_schema.domain_constraints
+WHERE domain_name IN ('con', 'dom', '
On 17.01.24 13:15, vignesh C wrote:
One of the test has failed in CFBot at [1] with:
diff -U3 /tmp/cirrus-ci-build/src/test/regress/expected/domain.out
/tmp/cirrus-ci-build/src/test/regress/results/domain.out
--- /tmp/cirrus-ci-build/src/test/regress/expected/domain.out
2024-01-14 15:40:01.793434
On Wed, 29 Nov 2023 at 01:14, Peter Eisentraut wrote:
>
> On 23.11.23 14:13, Aleksander Alekseev wrote:
> > =# create domain connotnull1 integer;
> > =# create domain connotnull2 integer;
> > =# alter domain connotnull1 add not null value;
> > =# alter domain connotnull2 set not null;
> > =# \dD
>
c297c458766a0e1ee65408d3ced469f32cf5e7d8 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 28 Nov 2023 20:38:16 +0100
Subject: [PATCH v2 2/2] Catalog domain not-null constraints
This applies the explicit catalog representation of not-null
constraints introduced by b0e96f3119 for table
On 23.11.23 17:38, Alvaro Herrera wrote:
If you create a table with column of domain that has a NOT NULL
constraint, what happens? I mean, is the table column marked
attnotnull, and how does it behave?
No, the domain does not affect the catalog entry for the column. This
is the same way it b
On 2023-Nov-23, Peter Eisentraut wrote:
> This patch set applies the explicit catalog representation of not-null
> constraints introduced by b0e96f3119 for table constraints also to domain
> not-null constraints.
I like the idea of having domain not-null constraints appear in
pg_constraint.
> Si
On 2023-Nov-23, Aleksander Alekseev wrote:
> Interestingly enough according to the documentation this syntax is
> already supported [1][2], but the actual query will fail on `master`:
>
> ```
> =# create domain connotnull integer;
> CREATE DOMAIN
> =# alter domain connotnull add not null value;
>
Hi,
> This patch set applies the explicit catalog representation of not-null
> constraints introduced by b0e96f3119 for table constraints also to
> domain not-null constraints.
Interestingly enough according to the documentation this syntax is
already supported [1][2], but the actual query will f
+SELECT * FROM information_schema.check_constraints
+ WHERE (constraint_schema, constraint_name)
+IN (SELECT constraint_schema, constraint_name
+FROM information_schema.domain_constraints
+WHERE domain_name IN ('con', 'dom', 'pos_int', 'things
38 matches
Mail list logo
