On 10/10/23 15:12, Robert Haas wrote:
On Mon, Oct 9, 2023 at 5:07 PM David G. Johnston
wrote:
2. I don't think it's a good idea for the same patch to try to solve
two problems unless they are so closely related that solving one
without solving the other is not sensible.
A NOT NULL constraint
On Mon, Oct 9, 2023 at 5:07 PM David G. Johnston
wrote:
>> 2. I don't think it's a good idea for the same patch to try to solve
>> two problems unless they are so closely related that solving one
>> without solving the other is not sensible.
>
> A NOT NULL constraint apparently is just a special
On Mon, Oct 9, 2023 at 1:27 PM Robert Haas wrote:
> On Tue, Oct 3, 2023 at 10:05 AM David G. Johnston
> wrote:
> >> The real-world use case, at least for me, is when using an ORM. For
> large object-graphs ORMs have a tendency to INSERT first with NULLs then
> UPDATE the “NOT NULLs” later.
> >>
On Tue, Oct 3, 2023 at 10:05 AM David G. Johnston
wrote:
>> The real-world use case, at least for me, is when using an ORM. For large
>> object-graphs ORMs have a tendency to INSERT first with NULLs then UPDATE
>> the “NOT NULLs” later.
>>
>> “Rewrite the ORM” is not an option for most of us…
>
On Mon, Oct 2, 2023 at 10:25 PM Tom Lane wrote:
> But here we have a
> feature whose only possible use is with constraints that *aren't*
> immutable; else we might as well just check them immediately.
I'm a little bit confused by this whole discussion because surely this
statement is just
On Monday, October 2, 2023, Andreas Joseph Krogh wrote:
> På fredag 07. juli 2023 kl. 13:50:44, skrev Dilip Kumar <
> dilipbal...@gmail.com>:
>
> On Wed, Jul 5, 2023 at 3:08 PM Himanshu Upadhyaya
> wrote:
> >
> > Hi,
> >
> > Currently, there
On Tue, Sep 19, 2023 at 4:14 PM Dean Rasheed
wrote:
> > I think we should be able to defer one constraint like in the case of
> > foreign key constraint
> >
>
> Agreed. It should be possible to have a mix of deferred and immediate
> constraint checks. In the example, the tbl_chk_1 is set
On Thu, Sep 14, 2023 at 9:57 AM vignesh C wrote:
> 2) I was not sure, if the error message change was intentional:
> 2a)
> In Head:
> CREATE FOREIGN TABLE t9(a int CHECK(a<>0) DEFERRABLE) SERVER s1;
> ERROR: misplaced DEFERRABLE clause
> LINE 1: CREATE FOREIGN TABLE t9(a int CHECK(a<>0)
Vik Fearing writes:
> On 10/2/23 21:25, Tom Lane wrote:
>> Sorry for not weighing in on this before, but ... is this a feature
>> we want at all?
> For standards conformance, I vote yes.
Only if we can actually implement it in a defensible way, which this
patch is far short of accomplishing.
På fredag 07. juli 2023 kl. 13:50:44, skrev Dilip Kumar mailto:dilipbal...@gmail.com>>:
On Wed, Jul 5, 2023 at 3:08 PM Himanshu Upadhyaya
wrote:
>
> Hi,
>
> Currently, there is no support for CHECK constraint DEFERRABLE in a create
table statement.
> SQL standard
On 10/2/23 21:25, Tom Lane wrote:
Himanshu Upadhyaya writes:
V3 patch attached.
Sorry for not weighing in on this before, but ... is this a feature
we want at all?
For standards conformance, I vote yes.
We are very clear in the existing docs that CHECK
conditions must be immutable [1],
On Mon, Oct 2, 2023 at 12:25 PM Tom Lane wrote:
> Himanshu Upadhyaya writes:
> > V3 patch attached.
>
> Sorry for not weighing in on this before, but ... is this a feature
> we want at all? We are very clear in the existing docs that CHECK
> conditions must be immutable [1], and that's not
Himanshu Upadhyaya writes:
> V3 patch attached.
Sorry for not weighing in on this before, but ... is this a feature
we want at all? We are very clear in the existing docs that CHECK
conditions must be immutable [1], and that's not something we can
easily relax because if they are not then it's
On Mon, Oct 2, 2023 at 8:31 PM Himanshu Upadhyaya <
upadhyaya.himan...@gmail.com> wrote:
V3 patch attached.
>
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
v3-0001-Implementation-of-CHECK-Constraint-to-make-it.patch
Description: Binary data
e symbolizer.
>
> The details of CFBot failure can be seen at [1]
>
> I have tried it with my latest patch on windows environment and not
getting any crash with the above statement, will do further analysis if
this patch also has the same issue.
> 2) Alter of check constraint deferrab
On Fri, 15 Sept 2023 at 08:00, vignesh C wrote:
>
> On Thu, 14 Sept 2023 at 15:33, Himanshu Upadhyaya
> wrote:
> >
> > On Thu, Sep 14, 2023 at 9:57 AM vignesh C wrote:
> >>
> >> postgres=*# SET CONSTRAINTS tbl_chk_1 DEFERRED;
> >> SET CONSTRAINTS
> >> postgres=*# INSERT INTO tbl values (1);
>
On Thu, 14 Sept 2023 at 15:33, Himanshu Upadhyaya
wrote:
>
>
>
> On Thu, Sep 14, 2023 at 9:57 AM vignesh C wrote:
>>
>> 3) Insert check is not deferred to commit:
>> This insert check here is deferred to commit:
>> postgres=# CREATE TABLE tbl (i int ) partition by range (i);
>> CREATE TABLE
On Thu, Sep 14, 2023 at 9:57 AM vignesh C wrote:
> 3) Insert check is not deferred to commit:
> This insert check here is deferred to commit:
> postgres=# CREATE TABLE tbl (i int ) partition by range (i);
> CREATE TABLE tbl_1 PARTITION OF tbl FOR VALUES FROM (0) TO (10);
> CREATE TABLE tbl_2
t'
> ==58563==Using libbacktrace symbolizer.
>
> Will Fix this in my next patch.
> The details of CFBot failure can be seen at [1]
>
> 2) Alter of check constraint deferrable is not handled, is this
> intentional?
> CREATE TABLE check_constr_tbl (i int CHECK(i<>0) DEF
On Thu, 7 Sept 2023 at 17:26, Himanshu Upadhyaya
wrote:
>
> Attached is v2 of the patch, rebased against the latest HEAD.
Few issues:
1) Create domain fails but alter domain is successful, I feel we
should support create domain too:
postgres=# create domain d1 as int check(value<>0) deferrable;
ement: drop table c1;
../src/backend/commands/trigger.c:220:26: runtime error: member access
within null pointer of type 'struct CreateTrigStmt'
==58563==Using libbacktrace symbolizer.
The details of CFBot failure can be seen at [1]
2) Alter of check constraint deferrable is not handled, is th
On Fri, Sep 8, 2023 at 1:23 PM Dilip Kumar wrote:
> 2.
> - if ((failed = ExecRelCheck(resultRelInfo, slot, estate)) != NULL)
> + if ((failed = ExecRelCheck(resultRelInfo, slot, estate,
> checkConstraint, )) != NULL && !recheckConstraints)
>
>
> Why recheckConstraints need to get as output from
On Thu, Sep 7, 2023 at 1:25 PM Himanshu Upadhyaya
wrote:
>
> Attached is v2 of the patch, rebased against the latest HEAD.
I have done some initial reviews, and here are my comments. More
detailed review later. Meanwhile, you can work on these comments and
fix all the cosmetics especially 80
e.
@@ -2113,8 +2119,10 @@ StoreRelCheck(Relation rel, const char *ccname, Node *expr,
CreateConstraintEntry(ccname, /* Constraint Name */
RelationGetNamespace(rel), /* namespace */
CONSTRAINT_CHECK, /* Constraint Type */
- false, /* Is Deferrable */
- false, /* Is Def
On Friday, July 7, 2023, Himanshu Upadhyaya
wrote:
> I can think of one scenario, as below
>
> 1) any department should have an employee
> 2)any employee should be assigned to a department
> so, the employee table has a FK to the department table, and another check
> constraint should be added
--+--+
1001 | test | 1
(1 row)
Thanks,
Himanshu
On Fri, Jul 7, 2023 at 5:21 PM Dilip Kumar wrote:
> On Wed, Jul 5, 2023 at 3:08 PM Himanshu Upadhyaya
> wrote:
> >
> > Hi,
> >
> > Currently, there is no supp
On Wed, Jul 5, 2023 at 3:08 PM Himanshu Upadhyaya
wrote:
>
> Hi,
>
> Currently, there is no support for CHECK constraint DEFERRABLE in a create
> table statement.
> SQL standard specifies that CHECK constraint can be defined as DEFERRABLE.
I think this is a valid argument
Hi,
Currently, there is no support for CHECK constraint DEFERRABLE in a create
table statement.
SQL standard specifies that CHECK constraint can be defined as DEFERRABLE.
The attached patch is having implementation for CHECK constraint Deferrable
as below:
‘postgres[579453]=#’CREATE TABLE t1 (i
28 matches
Mail list logo
