On Wed, May 15, 2024 at 09:50:36AM +0200, Álvaro Herrera wrote:
> On 2024-May-14, Bruce Momjian wrote:
>
> > Turns out these commits generated a single release note item, which I
> > have now removed with the attached committed patch.
>
> Hmm, but the commits about not-null constraints for
On 15.05.24 09:50, Alvaro Herrera wrote:
On 2024-May-14, Bruce Momjian wrote:
Turns out these commits generated a single release note item, which I
have now removed with the attached committed patch.
Hmm, but the commits about not-null constraints for domains were not
reverted, only the ones
On 2024-May-14, Bruce Momjian wrote:
> Turns out these commits generated a single release note item, which I
> have now removed with the attached committed patch.
Hmm, but the commits about not-null constraints for domains were not
reverted, only the ones for constraints on relations. I think
On Mon, May 13, 2024 at 09:00:28AM -0400, Robert Haas wrote:
> > Specifically, the problem is that I mentioned that we could restrict the
> > NOT NULL NO INHERIT addition in pg_dump for primary keys to occur only
> > in pg_upgrade; but it turns this is not correct. In normal
> > dump/restore,
On Sun, May 12, 2024 at 04:56:09PM +0200, Álvaro Herrera wrote:
> On 2024-May-11, Alvaro Herrera wrote:
>
> > I have found two more problems that [] require some more work to fix,
> > so I've decided to cut my losses now and revert the whole.
>
> Here's the revert patch, which I intend to push
On 2024-May-13, Robert Haas wrote:
> It seems to me that the practical thing to do about this problem is
> just decide not to solve it. I mean, it's currently the case that if
> you establish a PRIMARY KEY when you create a table, the columns of
> that key are marked NOT NULL and remain NOT NULL
On Mon, May 13, 2024 at 12:45 PM Alvaro Herrera wrote:
> The point is that a column can be in a primary key and not have an
> explicit not-null constraint. This is different from having a column be
> NOT NULL and having a primary key on top. In both cases the attnotnull
> flag is set; the
On 2024-May-13, Robert Haas wrote:
> On Mon, May 13, 2024 at 9:44 AM Alvaro Herrera
> wrote:
> > The problematic point is the need to add NOT NULL constraints during
> > table creation that don't exist in the table being dumped, for
> > performance of primary key creation -- I called this a
On Mon, May 13, 2024 at 9:44 AM Alvaro Herrera wrote:
> The problematic point is the need to add NOT NULL constraints during
> table creation that don't exist in the table being dumped, for
> performance of primary key creation -- I called this a throwaway
> constraint. We needed to be able to
On 2024-May-13, Robert Haas wrote:
> On Sat, May 11, 2024 at 5:40 AM Alvaro Herrera
> wrote:
> > Specifically, the problem is that I mentioned that we could restrict the
> > NOT NULL NO INHERIT addition in pg_dump for primary keys to occur only
> > in pg_upgrade; but it turns this is not
On Sat, May 11, 2024 at 5:40 AM Alvaro Herrera wrote:
> I have found two more problems that I think are going to require some
> more work to fix, so I've decided to cut my losses now and revert the
> whole. I'll come back again in 18 with these problems fixed.
Bummer, but makes sense.
>
On 2024-May-09, Robert Haas wrote:
> Yeah, I have to admit that the ongoing bug fixing here has started to
> make me a bit nervous, but I also can't totally follow everything
> that's under discussion, so I don't want to rush to judgement.
I have found two more problems that I think are going to
On Wed, May 8, 2024 at 4:42 PM Alvaro Herrera wrote:
> I spent a long time trying to think how to fix this, and I had despaired
> wanting to write that I would need to revert the whole NOT NULL business
> for pg17 -- but that was until I realized that we don't actually need
> this NOT NULL NO
On 2024-May-07, Kyotaro Horiguchi wrote:
> Hello,
>
> At Wed, 1 May 2024 19:49:35 +0200, Alvaro Herrera
> wrote in
> > Here are two patches that I intend to push soon (hopefully tomorrow).
>
> This commit added and edited two error messages, resulting in using
> slightly different wordings
Hello,
At Wed, 1 May 2024 19:49:35 +0200, Alvaro Herrera
wrote in
> Here are two patches that I intend to push soon (hopefully tomorrow).
This commit added and edited two error messages, resulting in using
slightly different wordings "in" and "on" for relation constraints.
+ errmsg("cannot
02.05.2024 19:21, Alvaro Herrera wrote:
Now, you could claim that the standard doesn't mention
INCLUDING/EXCLUDING CONSTRAINTS, therefore since we have come up with
its definition then we should make it affect not-null constraints.
However, there's also this note:
NOTE 520 — s, except for
Hello Alexander
On 2024-May-02, Alexander Lakhin wrote:
> Could you also clarify, please, how CREATE TABLE ... LIKE is expected to
> work with NOT NULL constraints?
It should behave identically to 16. If in 16 you end up with a
not-nullable column, then in 17 you should get a not-null
Hello Alvaro,
01.05.2024 20:49, Alvaro Herrera wrote:
Here are two patches that I intend to push soon (hopefully tomorrow).
Thank you for fixing those issues!
Could you also clarify, please, how CREATE TABLE ... LIKE is expected to
work with NOT NULL constraints?
I wonder whether EXCLUDING
On 2024-Apr-25, Alvaro Herrera wrote:
> > Also, I've found a weird behaviour with a non-inherited NOT NULL
> > constraint for a partitioned table:
> > CREATE TABLE pt(a int NOT NULL NO INHERIT) PARTITION BY LIST (a);
> Ugh. Maybe a way to handle this is to disallow NO INHERIT in
> constraints
On 2024-Apr-25, Alexander Lakhin wrote:
> While studying the NO INHERIT option, I've noticed that the documentation
> probably misses it's specification for NOT NULL:
> https://www.postgresql.org/docs/devel/sql-createtable.html
>
> where column_constraint is:
> ...
> [ CONSTRAINT constraint_name
24.04.2024 20:36, Alvaro Herrera wrote:
So I added a restriction that we only accept such a change when
recursively adding a constraint, or during binary upgrade. This should
limit the damage: you're no longer able to change an existing constraint
from NO INHERIT to YES INHERIT merely by doing
On 2024-Apr-22, Alvaro Herrera wrote:
> > On d9f686a72~1 this script results in:
> > ERROR: cannot change NO INHERIT status of inherited NOT NULL constraint
> > "t_a_not_null" on relation "t"
>
> Right. Now I'm beginning to wonder if allowing ADD CONSTRAINT to mutate
> a pre-existing NO
Hi Alexander,
On 2024-Apr-18, Alexander Lakhin wrote:
> 18.04.2024 16:39, Alvaro Herrera wrote:
> > I have pushed a fix which should hopefully fix this problem
> > (d9f686a72e). Please give this a look. Thanks for reporting the issue.
>
> Please look at an assertion failure, introduced with
Hello Alvaro,
18.04.2024 16:39, Alvaro Herrera wrote:
I have pushed a fix which should hopefully fix this problem
(d9f686a72e). Please give this a look. Thanks for reporting the issue.
Please look at an assertion failure, introduced with d9f686a72:
CREATE TABLE t(a int, NOT NULL a NO
On 2024-Jan-25, Andrew Bille wrote:
> Starting from b0e96f31, pg_upgrade fails with inherited NOT NULL constraint:
> For example upgrade from 9c13b6814a (or REL_12_STABLE .. REL_16_STABLE) to
> b0e96f31 (or master) with following two tables (excerpt from
> src/test/regress/sql/rules.sql)
>
>
(I think I had already argued this point, but I don't see it in the
archives, so here it is again).
On 2024-Feb-07, jian he wrote:
> if you place CommandCounterIncrement inside the `if (recurse)` branch,
> then the regression test will be ok.
Yeah, but don't you think this is too magical? I
On Mon, Feb 5, 2024 at 5:51 PM Alvaro Herrera wrote:
>
> On 2024-Feb-05, Alvaro Herrera wrote:
>
> > Hmm, let me have a look, I can probably get this one fixed today before
> > embarking on a larger fix elsewhere in the same feature.
>
> You know what -- this missing CCI has a much more visible
On 2024-Feb-05, Alvaro Herrera wrote:
> While playing with it I noticed this other behavior change from 16,
>
> create table pa (a int primary key) partition by list (a);
> create table pe (a int unique);
> alter table pa attach partition pe for values in (1, null);
>
> In 16, we get the error:
On 2024-Feb-05, Alvaro Herrera wrote:
> So this regression test no longer fails:
>
> create table cnn2_parted(a int primary key) partition by list (a);
> create table cnn2_part1(a int);
> alter table cnn2_parted attach partition cnn2_part1 for values in (1);
> Here, in the existing code the
On 2024-Feb-05, Alvaro Herrera wrote:
> Subject: [PATCH v1] Fix failure to merge NOT NULL constraints in inheritance
>
> set_attnotnull() was not careful to CommandCounterIncrement() in cases
> of multiple recursion. Omission in b0e96f311985.
Eh, this needs to read "multiple inheritance"
On 2024-Feb-05, Alvaro Herrera wrote:
> Hmm, let me have a look, I can probably get this one fixed today before
> embarking on a larger fix elsewhere in the same feature.
You know what -- this missing CCI has a much more visible impact, which
is that the attnotnull marker that a primary key
On 2024-Feb-05, Michael Paquier wrote:
> On Fri, Feb 02, 2024 at 07:00:01PM +0300, Alexander Lakhin wrote:
> > results in:
> > NOTICE: merging definition of column "i" for child "b"
> > NOTICE: merging definition of column "i" for child "c"
> > ERROR: tuple already updated by self
> >
> >
On Fri, Feb 02, 2024 at 07:00:01PM +0300, Alexander Lakhin wrote:
> results in:
> NOTICE: merging definition of column "i" for child "b"
> NOTICE: merging definition of column "i" for child "c"
> ERROR: tuple already updated by self
>
> (This is similar to bug #18297, but ATExecAddColumn()
Hello Alvaro,
Please look at an anomaly introduced with b0e96f311.
The following script:
CREATE TABLE a ();
CREATE TABLE b (i int) INHERITS (a);
CREATE TABLE c () INHERITS (a, b);
ALTER TABLE a ADD COLUMN i int NOT NULL;
results in:
NOTICE: merging definition of column "i" for child "b"
Hi Alvaro,
25.08.2023 14:38, Alvaro Herrera wrote:
> I have now pushed this again. Hopefully it'll stick this time.
Starting from b0e96f31, pg_upgrade fails with inherited NOT NULL constraint:
For example upgrade from 9c13b6814a (or REL_12_STABLE .. REL_16_STABLE) to
b0e96f31 (or master) with
On 2023-Oct-12, Alexander Lakhin wrote:
Hello,
> I've discovered that that commit added several recursive functions, and
> some of them are not protected from stack overflow.
True. I reproduced the first two, but didn't attempt to reproduce the
third one -- patching all these to check for
Hi Alvaro,
25.08.2023 14:38, Alvaro Herrera wrote:
I have now pushed this again. Hopefully it'll stick this time.
I've discovered that that commit added several recursive functions, and
some of them are not protected from stack overflow.
Namely, with "max_locks_per_transaction = 600" and
On 2023-Sep-05, Peter Eisentraut wrote:
> The following information schema views are affected by the not-null
> constraint catalog entries:
>
> 1. CHECK_CONSTRAINTS
> 2. CONSTRAINT_COLUMN_USAGE
> 3. DOMAIN_CONSTRAINTS
> 4. TABLE_CONSTRAINTS
>
> Note that 1 and 3 also contain domain constraints.
On 31.08.23 12:02, Alvaro Herrera wrote:
In constraint_column_usage, you're adding a relkind to the catalog scan
that goes through pg_depend for CHECK constraints. Here we can rely on
a simple conkey[1] check and a separate UNION ALL arm[q5]; this is also
faster when there are many tables.
The
Looking at your 0001 patch, which adds tests for some of the
information_schema views, I think it's a bad idea to put them in
whatever other regression .sql files; they would be subject to
concurrent changes depending on what other tests are being executed in
the same parallel test. I suggest to
On 2023-Aug-31, Alvaro Herrera wrote:
> Hmm, that's some weird code I left there all right. Can you please try
> this patch? (Not final; I'll review it more completely later,
> particularly to add this test case.)
The change in MergeAttributesIntoExisting turned out to be close but not
quite
31.08.2023 13:26, Alvaro Herrera wrote:
Hmm, that's some weird code I left there all right. Can you please try
this patch? (Not final; I'll review it more completely later,
particularly to add this test case.)
Yes, your patch fixes the issue. I get the same error now:
ERROR: column "a" in
Hello Alexander,
Thanks for testing.
On 2023-Aug-31, Alexander Lakhin wrote:
> 25.08.2023 14:38, Alvaro Herrera wrote:
> > I have now pushed this again. Hopefully it'll stick this time.
>
> I've found that after that commit the following query:
> CREATE TABLE t(a int PRIMARY KEY) PARTITION BY
On 2023-Mar-29, Peter Eisentraut wrote:
> On 27.03.23 15:55, Peter Eisentraut wrote:
> > The information schema should be updated. I think the following views:
> >
> > - CHECK_CONSTRAINTS
> > - CONSTRAINT_COLUMN_USAGE
> > - DOMAIN_CONSTRAINTS
> > - TABLE_CONSTRAINTS
> >
> > It looks like these
Hi Alvaro,
25.08.2023 14:38, Alvaro Herrera wrote:
I have now pushed this again. Hopefully it'll stick this time.
I've found that after that commit the following query:
CREATE TABLE t(a int PRIMARY KEY) PARTITION BY RANGE (a);
CREATE TABLE tp1(a int);
ALTER TABLE t ATTACH PARTITION tp1 FOR
On 2023-Aug-28, Peter Eisentraut wrote:
> It looks like we forgot about domain constraints? For example,
>
> create domain testdomain as int not null;
>
> should create a row in pg_constraint?
Well, at some point I purposefully left them out; they were sufficiently
different from the ones in
On 25.08.23 13:38, Alvaro Herrera wrote:
I have now pushed this again. Hopefully it'll stick this time.
We may want to make some further tweaks to the behavior in some cases --
for example, don't disallow ALTER TABLE DROP NOT NULL when the
constraint is both inherited and has a local
On 2023-Aug-25, Alvaro Herrera wrote:
> I have now pushed this again. Hopefully it'll stick this time.
Hmm, failed under the Czech locale[1]; apparently "inh_grandchld" sorts
earlier than "inh_child1" there. I think I'll rename inh_grandchld to
inh_child3 or something like that.
[1]
I have now pushed this again. Hopefully it'll stick this time.
We may want to make some further tweaks to the behavior in some cases --
for example, don't disallow ALTER TABLE DROP NOT NULL when the
constraint is both inherited and has a local definition; the other
option is to mark the
I have two small patches that you can integrate into your patch set:
The first just changes the punctuation of "Not-null constraints" in the
psql output to match what the documentation mostly uses.
The second has some changes to ddl.sgml to reflect that not-null
constraints are now named and
On 15.08.23 11:57, Dean Rasheed wrote:
Something else I noticed when reading the SQL standard is that a
user-defined CHECK (col IS NOT NULL) constraint should be recognised
by the system as also making the column not null (setting its
"nullability characteristic" to "known not nullable"). I
On 2023-Aug-15, Dean Rasheed wrote:
> I think perhaps for ALTER TABLE INHERIT, it should check that the
> child has a NOT NULL constraint, and error out if not. That's the
> current behaviour, and also matches other constraints types (e.g.,
> CHECK constraints).
Yeah, I reached the same
On Fri, 11 Aug 2023 at 14:54, Alvaro Herrera wrote:
>
> Right, in the end I got around to that point of view. I abandoned the
> idea of adding these dependency links, and I'm back at relying on the
> coninhcount/conislocal markers. But there were a couple of bugs in the
> accounting for that,
On 2023-Aug-09, Peter Eisentraut wrote:
> I wonder whether the root of these problems is that we mix together primary
> key constraints and not-null constraints. I understand that right now, with
> the proposed patch, when a table inherits from a parent table with a primary
> key constraint, we
On 05.08.23 21:50, Dean Rasheed wrote:
Anyway, I was at the same time fixing the other problem you reported
with inheritance (namely, adding a PK ends up with the child column
being marked NOT NULL but no corresponding constraint).
At some point I wondered if the easy way out wouldn't be to
On Sat, 5 Aug 2023 at 18:37, Alvaro Herrera wrote:
>
> Yeah, something like that. However, if the child had a NOT NULL
> constraint of its own, then it should not be deleted when the
> PK-on-parent is, but merely marked as no longer inherited. (This is
> also what happens with a straight NOT
On 2023-Aug-05, Dean Rasheed wrote:
> Hmm, thinking about this some more, I think this might be the wrong
> approach to fixing the original problem. I think it was probably OK
> that the NOT NULL constraint on the child was marked as inherited, but
> I think what should have happened is that
On Fri, 4 Aug 2023 at 19:10, Alvaro Herrera wrote:
>
> On 2023-Jul-28, Alvaro Herrera wrote:
>
> > To avoid that, one option would be to make this NN constraint
> > undroppable ... but I don't see how. One option might be to add a
> > pg_depend row that links the NOT NULL constraint to its PK
On 2023-Jul-28, Alvaro Herrera wrote:
> To avoid that, one option would be to make this NN constraint
> undroppable ... but I don't see how. One option might be to add a
> pg_depend row that links the NOT NULL constraint to its PK constraint.
> But this will be a strange case that occurs
On 24.07.23 12:32, Alvaro Herrera wrote:
However, 11.16 ( as part of 11.12 ), says that DROP NOT NULL causes the indication of
the column as NOT NULL to be removed. This, to me, says that if you do
have multiple such constraints, you'd better remove them all with that
command. All in all, I
> > Given the following sequence:
> >
> > drop table if exists p,c;
> > create table p(a int primary key);
> > create table c() inherits (p);
> > alter table p drop constraint p_pkey;
> > However, c.a remains non-nullable, with a NOT NULL constraint that
> > claims to be inherited:
> >
> > \d+
On 2023-Jul-26, Alvaro Herrera wrote:
> On 2023-Jul-26, Dean Rasheed wrote:
>
> > The new \d+ output certainly makes testing and reviewing easier,
> > though I do understand people's concerns that this may make the output
> > significantly longer in many real-world cases.
>
> Yeah, at this
Thanks for spending so much time with this patch -- really appreciated.
On 2023-Jul-26, Dean Rasheed wrote:
> On Tue, 25 Jul 2023 at 13:36, Alvaro Herrera wrote:
> >
> > Okay then, I've made these show up in the footer of \d+. This is in
> > patch 0003 here. Please let me know what do you
On Tue, 25 Jul 2023 at 13:36, Alvaro Herrera wrote:
>
> Okay then, I've made these show up in the footer of \d+. This is in
> patch 0003 here. Please let me know what do you think of the regression
> changes.
>
The new \d+ output certainly makes testing and reviewing easier,
though I do
On Tue, Jul 25, 2023 at 3:07 PM Isaac Morland wrote:
> OK, I suppose ALTER CONSTRAINT to change the deferrable status and validity
> (that is why we're doing this, right?) needs the constraint name. But the
> constraint name is formulaic by default, and my proposal is to suppress it
> only
On Tue, 25 Jul 2023 at 14:59, Robert Haas wrote:
> On Tue, Jul 25, 2023 at 1:33 PM Isaac Morland
> wrote:
> > My suggestion is for \d+ to show NOT NULL constraints only if there is
> something weird going on (wrong name, duplicate constraints, …). If there
> is nothing weird about the
On Tue, Jul 25, 2023 at 1:33 PM Isaac Morland wrote:
> My suggestion is for \d+ to show NOT NULL constraints only if there is
> something weird going on (wrong name, duplicate constraints, …). If there is
> nothing weird about the constraint then explicitly listing it provides
> absolutely no
On Tue, 25 Jul 2023 at 12:24, Alvaro Herrera
wrote:
> On 2023-Jul-25, Isaac Morland wrote:
>
> > I agree. I definitely do *not* want a bunch of NOT NULL constraint names
> > cluttering up displays. Can we legislate that all NOT NULL implementing
> > constraints are named by mashing together the
On 2023-Jul-25, Isaac Morland wrote:
> I agree. I definitely do *not* want a bunch of NOT NULL constraint names
> cluttering up displays. Can we legislate that all NOT NULL implementing
> constraints are named by mashing together the table name, column name, and
> something to identify it as a
On Tue, 25 Jul 2023 at 11:39, Robert Haas wrote:
>
> I'm not really thrilled with the idea of every not-null constraint
> having a name, to be honest. Of all the kinds of constraints that we
> have in the system, NOT NULL constraints are probably the ones where
> naming them is least likely to
On Tue, Jul 25, 2023 at 8:36 AM Alvaro Herrera wrote:
> Okay then, I've made these show up in the footer of \d+. This is in
> patch 0003 here. Please let me know what do you think of the regression
> changes.
Seems OK.
I'm not really thrilled with the idea of every not-null constraint
having
On Mon, Jul 24, 2023 at 6:33 AM Alvaro Herrera wrote:
> That's the first thing I proposed actually. I got one vote down from
> Robert Haas[1], but while the idea seems to have had support from Justin
> Pryzby (in \dt++) [2] and definitely did from Peter Eisentraut [3], I do
> not like it too
On Mon, 24 Jul 2023 at 17:42, Alvaro Herrera wrote:
>
> On 2023-Jul-24, Dean Rasheed wrote:
>
> > Something else I noticed: the error message from ALTER TABLE ... ADD
> > CONSTRAINT in the case of a duplicate constraint name is not very
> > friendly:
> >
> > ERROR: duplicate key value violates
On 7/24/23 18:42, Alvaro Herrera wrote:
55490 17devel 3166154=# create table foo (a int constraint nn not null);
CREATE TABLE
55490 17devel 3166154=# alter table foo add constraint nn not null a;
ERROR: column "a" of table "foo" is already NOT NULL
Surely this should be a WARNING or INFO? I
Hello,
While discussing the matter of multiple constraints with Vik Fearing, I
noticed that we were throwing an unnecessary error if you used
CREATE TABLE foo (a int NOT NULL NOT NULL);
That would die with "redundant NOT NULL declarations", but current
master doesn't do that; and we don't do it
On 2023-Jul-24, Dean Rasheed wrote:
> Something else I noticed: the error message from ALTER TABLE ... ADD
> CONSTRAINT in the case of a duplicate constraint name is not very
> friendly:
>
> ERROR: duplicate key value violates unique constraint
> "pg_constraint_conrelid_contypid_conname_index"
On 2023-Jul-24, Dean Rasheed wrote:
> Hmm, I'm not so sure. I think perhaps multiple NOT NULL constraints on
> the same column should just be allowed, otherwise things might get
> confusing. For example:
>
create table p1 (a int not null check (a > 0));
create table p2 (a int not null check (a
On 2023-Jul-24, Dean Rasheed wrote:
> Hmm, I don't particularly like that approach, because I think it will
> be difficult to cram any additional details into the table, and also I
> don't know whether having multiple not null constraints for a
> particular column can be entirely ruled out.
>
>
Something else I noticed: the error message from ALTER TABLE ... ADD
CONSTRAINT in the case of a duplicate constraint name is not very
friendly:
ERROR: duplicate key value violates unique constraint
"pg_constraint_conrelid_contypid_conname_index"
DETAIL: Key (conrelid, contypid,
On Thu, 20 Jul 2023 at 16:31, Alvaro Herrera wrote:
>
> On 2023-Jul-13, Dean Rasheed wrote:
>
> > Something else I noticed is that the result from "ALTER TABLE ...
> > ALTER COLUMN ... DROP NOT NULL" is no longer easily predictable -- if
> > there are multiple NOT NULL constraints on the column,
On Thu, 20 Jul 2023 at 16:31, Alvaro Herrera wrote:
>
> On 2023-Jul-13, Dean Rasheed wrote:
>
> > I see that it's already been discussed, but I don't like the fact that
> > there is no way to get hold of the new constraint names in psql. I
> > think for the purposes of dropping named constraints,
On Wed, 12 Jul 2023 at 18:11, Alvaro Herrera wrote:
>
> v13, because a conflict was just committed to alter_table.sql.
>
> Here I also call out the relcache.c change by making it a separate
> commit. I'm likely to commit it that way, too. To recap: the change is
> to have a partitioned table's
On 30.06.23 13:44, Alvaro Herrera wrote:
OK, so here's a new attempt to get this working correctly.
Attached is a small fixup patch for the documentation.
Furthermore, there are a few outdated comments that are probably left
over from previous versions of this patch set.
*
On 2023-Jun-30, Andres Freund wrote:
> On 2023-06-30 13:44:03 +0200, Alvaro Herrera wrote:
>
> > The main novelty in this version of the patch, is that we now emit
> > "throwaway" NOT NULL constraints when a column is part of the primary
> > key. Then, after the PK is created, we run a DROP for
Hi,
On 2023-06-30 13:44:03 +0200, Alvaro Herrera wrote:
> OK, so here's a new attempt to get this working correctly.
Thanks for continuing to work on this!
> The main novelty in this version of the patch, is that we now emit
> "throwaway" NOT NULL constraints when a column is part of the
Alvaro Herrera writes:
>> I'm inclined to think that this idea of suppressing the implied
>> NOT NULL from PRIMARY KEY is a nonstarter and we should just
>> go ahead and make such a constraint. Another idea could be for
>> pg_dump to emit the NOT NULL, load data, do the ALTER ADD PRIMARY
>> KEY,
On 2023-Apr-09, Tom Lane wrote:
> In the new dispensation, pg_dump omits the NOT NULL clauses.
> Great, you say, that makes the output more like what the user wrote.
> I'm not so sure. This means that the ALTER TABLE will be compelled
> to perform a full-table scan to verify that there are no
Andres Freund writes:
> I think
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo=2023-04-07%2021%3A16%3A04
> might point out a problem with the pg_dump or pg_upgrade backward compat
> paths:
Yeah, this patch has broken every single upgrade-from-back-branch test.
I think there's
Hi,
On 2023-04-07 17:19:42 -0700, Andres Freund wrote:
> I think
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo=2023-04-07%2021%3A16%3A04
> might point out a problem with the pg_dump or pg_upgrade backward compat
> paths:
>
> ---
Hi,
On 2023-04-07 18:26:28 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-04-07 17:46:33 -0400, Tom Lane wrote:
> >> After quickly eyeing the diffs, I'm just going to take the new output
> >> as good. I'm not surprised that there are additional output messages
> >> given the
... BTW, shouldn't
https://commitfest.postgresql.org/42/3869/
now get closed as committed?
regards, tom lane
Andres Freund writes:
> On 2023-04-07 17:46:33 -0400, Tom Lane wrote:
>> After quickly eyeing the diffs, I'm just going to take the new output
>> as good. I'm not surprised that there are additional output messages
>> given the additional catalog entries this made. I *am* a bit surprised
>>
Hi,
On 2023-04-07 17:46:33 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-04-07 23:11:55 +0200, Alvaro Herrera wrote:
> >> Ah, cool, no worries. I would have stopped indeed, but I had to stay
> >> around in case of any test failures.
>
> > Looks like there's work for you if you
Andres Freund writes:
> On 2023-04-07 23:11:55 +0200, Alvaro Herrera wrote:
>> Ah, cool, no worries. I would have stopped indeed, but I had to stay
>> around in case of any test failures.
> Looks like there's work for you if you want ;)
>
Hi,
On 2023-04-07 23:11:55 +0200, Alvaro Herrera wrote:
> On 2023-Apr-07, Andres Freund wrote:
>
> > I just pushed a fix - sorry, I thought you might have stopped working for
> > the
> > day and CI finished with the modification a few seconds before your email
> > arrived...
>
> Ah, cool, no
On 2023-Apr-07, Andres Freund wrote:
> I just pushed a fix - sorry, I thought you might have stopped working for the
> day and CI finished with the modification a few seconds before your email
> arrived...
Ah, cool, no worries. I would have stopped indeed, but I had to stay
around in case of
Hi,
On 2023-04-07 23:00:01 +0200, Alvaro Herrera wrote:
> On 2023-Apr-07, Andres Freund wrote:
>
> > src/test/regress/sql/triggers.sql
> > 2127:create table child partition of parent for values in ('AAA');
> > 2266:create table child () inherits (parent);
> > 2759:create table child () inherits
On 2023-Apr-07, Andres Freund wrote:
> src/test/regress/sql/triggers.sql
> 2127:create table child partition of parent for values in ('AAA');
> 2266:create table child () inherits (parent);
> 2759:create table child () inherits (parent);
>
> The inherit.sql part is new.
Yeah.
> I'll see how
Hi,
On 2023-04-07 13:38:43 -0700, Andres Freund wrote:
> I suspect there's a naming conflict between tests in different groups.
Yep:
test: create_aggregate create_function_sql create_cast constraints triggers
select inherit typed_table vacuum drop_if_exists updatable_views roleattributes
Hi,
I think there's some test instability:
Fail:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=parula=2023-04-07%2018%3A43%3A02
Subsequent success, without relevant changes:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=parula=2023-04-07%2020%3A22%3A01
Followed by a failure:
1 - 100 of 133 matches
Mail list logo
