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
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
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
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
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
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.
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
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
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
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
>
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.
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
18 Mar 2024 08:42:12 +0100
Subject: [PATCH v4 2/2] Catalog domain not-null constraints
This applies the explicit catalog representation of not-null
constraints introduced by b0e96f3119 for table constraints also to
domain not-null constraints.
TODO: catversion
Discussion:
https://www.postgresql
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
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
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
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
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
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
> >
b83033c3cff556d520281aaec399e47b4f11edbe
--
2.43.0
From d34881a605d43241686816aa00603aa1b4a55179 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 6 Feb 2024 14:55:54 +0100
Subject: [PATCH v3 2/2] Catalog domain not-null constraints
This applies the explicit catalog representati
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
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
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.
>
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
'))
+ ORDER BY constraint_name;
base-commit: 414e75540f058b23377219586abb3008507f7099
--
2.42.1
From 778fd05ba7fde5062e64addc98eda5505ef475ca Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 23 Nov 2023 07:35:32 +0100
Subject: [PATCH v1 2/2] Catalog domain not-null constraints
This applies the expl
38 matches
Mail list logo
