On 2024-Apr-19, Tender Wang wrote:
> The new patch looks good to me.
Thanks for looking once more. I have pushed it now. I didn't try
pg_upgrade other than running the tests, so maybe buildfarm member crake
will have more to complain about -- we'll see.
--
Álvaro Herrera
Alvaro Herrera 于2024年4月19日周五 02:49写道：
> On 2024-Apr-13, jian he wrote:
>
> > I wonder is there any incompatibility issue, or do we need to say
> something
> > about the new behavior when dropping a key column?
>
> Umm, yeah, maybe we should document it in ALTER TABLE DROP PRIMARY KEY
> and in
On 2024-Apr-13, jian he wrote:
> I wonder is there any incompatibility issue, or do we need to say something
> about the new behavior when dropping a key column?
Umm, yeah, maybe we should document it in ALTER TABLE DROP PRIMARY KEY
and in the release notes to note the different behavior.
>
On Fri, Apr 12, 2024 at 3:52 PM Alvaro Herrera wrote:
>
> On 2024-Apr-12, jian he wrote:
>
> > Now I am more confused...
>
> > +CREATE TABLE notnull_tbl1 (c0 int, c1 int, PRIMARY KEY (c0, c1));
> > +ALTER TABLE notnull_tbl1 DROP c1;
>
> > same query, mysql make let "c0" be not null
>
> Yes, that
On 2024-Apr-12, jian he wrote:
> Now I am more confused...
> +CREATE TABLE notnull_tbl1 (c0 int, c1 int, PRIMARY KEY (c0, c1));
> +ALTER TABLE notnull_tbl1 DROP c1;
> same query, mysql make let "c0" be not null
Yes, that was Postgres' old model. But the way we think of it now, is
that a
Alvaro Herrera 于2024年4月11日周四 22:48写道：
> On 2024-Apr-11, Alvaro Herrera wrote:
>
> > Well, I think you were right that we should try to handle the situation
> > of unmarking attnotnull as much as possible, to decrease the chances
> > that the problematic situation occurs. That means, we can use
jian he 于2024年4月12日周五 10:12写道：
> On Thu, Apr 11, 2024 at 10:48 PM Alvaro Herrera
> wrote:
> >
> >
> > I'm still not ready with this -- still not convinced about the new AT
> > pass. Also, I want to add a test for the pg_dump behavior, and there's
> > an XXX comment.
> >
> Now I am more
On Thu, Apr 11, 2024 at 10:48 PM Alvaro Herrera wrote:
>
>
> I'm still not ready with this -- still not convinced about the new AT
> pass. Also, I want to add a test for the pg_dump behavior, and there's
> an XXX comment.
>
Now I am more confused...
+-- make sure attnotnull is reset correctly
On 2024-Apr-11, Alvaro Herrera wrote:
> Well, I think you were right that we should try to handle the situation
> of unmarking attnotnull as much as possible, to decrease the chances
> that the problematic situation occurs. That means, we can use the
> earlier code to handle DROP COLUMN when it
On 2024-Apr-11, jian he wrote:
> now I figured out that
> dropping a column of primary key columns will not change other key
> columns' "not null" property.
> dropping the primary key associated constraint will make all key
> columns "not null" property disappear.
Well, I think you were right
On Thu, Apr 11, 2024 at 3:19 PM Tender Wang wrote:
>
>> +DROP TABLE notnull_tbl1;
>> +-- make sure attnotnull is reset correctly when a PK is dropped indirectly
>> +CREATE TABLE notnull_tbl1 (c0 int, c1 int, PRIMARY KEY (c0, c1));
>> +ALTER TABLE notnull_tbl1 DROP c1;
>> +\d+ notnull_tbl1
>> +
jian he 于2024年4月11日周四 14:40写道：
> On Wed, Apr 10, 2024 at 2:10 PM jian he
> wrote:
> >
> > DROP TABLE if exists notnull_tbl2;
> > CREATE TABLE notnull_tbl2 (c0 int generated by default as IDENTITY, c1
> int);
> > ALTER TABLE notnull_tbl2 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > ALTER TABLE
On Wed, Apr 10, 2024 at 2:10 PM jian he wrote:
>
> DROP TABLE if exists notnull_tbl2;
> CREATE TABLE notnull_tbl2 (c0 int generated by default as IDENTITY, c1 int);
> ALTER TABLE notnull_tbl2 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> ALTER TABLE notnull_tbl2 DROP CONSTRAINT
Alvaro Herrera 于2024年4月10日周三 21:58写道：
> It turns out that trying to close all holes that lead to columns marked
> not-null without a pg_constraint row is not possible within the ALTER
> TABLE framework, because it can happen outside it also. Consider this
>
> CREATE DOMAIN dom1 AS integer;
>
On 2024-Apr-10, Alvaro Herrera wrote:
> One thing missing here is pg_dump support. If you just dump this table,
> it'll end up with no constraint at all. That's obviously bad, so I
> propose we have pg_dump add a regular NOT NULL constraint for those, to
> avoid perpetuating the weird situation
On Wed, Apr 10, 2024 at 7:01 PM Alvaro Herrera wrote:
>
> On 2024-Apr-10, jian he wrote:
>
> > another related bug, in master.
> >
> > drop table if exists notnull_tbl1;
> > CREATE TABLE notnull_tbl1 (c0 int not null, c1 int);
> > ALTER TABLE notnull_tbl1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> >
It turns out that trying to close all holes that lead to columns marked
not-null without a pg_constraint row is not possible within the ALTER
TABLE framework, because it can happen outside it also. Consider this
CREATE DOMAIN dom1 AS integer;
CREATE TABLE notnull_tbl (a dom1, b int, PRIMARY KEY
On 2024-Apr-10, jian he wrote:
> another related bug, in master.
>
> drop table if exists notnull_tbl1;
> CREATE TABLE notnull_tbl1 (c0 int not null, c1 int);
> ALTER TABLE notnull_tbl1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> \d+ notnull_tbl1
> ALTER TABLE notnull_tbl1 ALTER c0 DROP NOT NULL;
>
On 2024-Apr-10, Tender Wang wrote:
> Yeah, it should fail as before, because c0 is primary key.
> In master, although c0's pg_attribute.attnotnull is still true, but its
> not-null constraint has been deleted
> in dropconstraint_internal().
Yeah, the problem here is that we need to do the checks
jian he 于2024年4月10日周三 17:34写道：
>
> another related bug, in master.
>
> drop table if exists notnull_tbl1;
> CREATE TABLE notnull_tbl1 (c0 int not null, c1 int);
> ALTER TABLE notnull_tbl1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> \d+ notnull_tbl1
> ALTER TABLE notnull_tbl1 ALTER c0 DROP NOT NULL;
another related bug, in master.
drop table if exists notnull_tbl1;
CREATE TABLE notnull_tbl1 (c0 int not null, c1 int);
ALTER TABLE notnull_tbl1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
\d+ notnull_tbl1
ALTER TABLE notnull_tbl1 ALTER c0 DROP NOT NULL;
ALTER TABLE notnull_tbl1 ALTER c1 DROP NOT NULL;
jian he 于2024年4月10日周三 14:10写道：
> On Wed, Apr 10, 2024 at 1:29 AM Alvaro Herrera
> wrote:
> >
> > On 2024-Mar-29, Tender Wang wrote:
> >
> > > I think aboved case can explain what's meaning about comments in
> > > dropconstraint_internal.
> > > But here, in RemoveConstraintById() , we only care
On Wed, Apr 10, 2024 at 1:29 AM Alvaro Herrera wrote:
>
> On 2024-Mar-29, Tender Wang wrote:
>
> > I think aboved case can explain what's meaning about comments in
> > dropconstraint_internal.
> > But here, in RemoveConstraintById() , we only care about primary key case,
> > so NOT NULL is better
On 2024-Mar-29, Tender Wang wrote:
> I think aboved case can explain what's meaning about comments in
> dropconstraint_internal.
> But here, in RemoveConstraintById() , we only care about primary key case,
> so NOT NULL is better to removed from comments.
Actually, I think it's better if all the
It has been several days since the last email. Do you have any
suggestions, please?
What I'm concerned about is that adding a new AT_PASS is good fix? Is it
a big try?
More concerned is that it can cover all ALTER TABLE cases?
Any thoughts.
--
Tender Wang
OpenPie: https://en.openpie.com/
jian he 于2024年3月29日周五 14:56写道：
> hi.
> about v4, i think, i understand the changes you made.
> RemoveConstraintById(Oid conId)
> will drop a single constraint record.
> if the constraint is primary key, then primary key associated
> attnotnull should set to false.
> but sometimes it shouldn't.
>
hi.
about v4, i think, i understand the changes you made.
RemoveConstraintById(Oid conId)
will drop a single constraint record.
if the constraint is primary key, then primary key associated
attnotnull should set to false.
but sometimes it shouldn't.
for example:
drop table if exists t2;
CREATE
Alvaro Herrera 于2024年3月28日周四 17:18写道：
> On 2024-Mar-28, Tender Wang wrote:
>
> > RemoveConstraintById() should think recurse(e.g. partition table)? I'm
> not
> > sure now.
> > If we should think process recurse in RemoveConstraintById(), the
> > function will look complicated than before.
>
>
On 2024-Mar-28, Tender Wang wrote:
> RemoveConstraintById() should think recurse(e.g. partition table)? I'm not
> sure now.
> If we should think process recurse in RemoveConstraintById(), the
> function will look complicated than before.
No -- this function handles just a single constraint,
Alvaro Herrera 于2024年3月26日周二 23:25写道：
> On 2024-Mar-26, Tender Wang wrote:
>
> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > postgres=# ALTER TABLE t1 DROP c1;
> >
> > postgres=# ALTER TABLE t1 ALTER c0 DROP NOT NULL;
>
jian he 于2024年3月28日周四 13:18写道：
> On Wed, Mar 27, 2024 at 10:26 PM Tender Wang wrote:
> >
> > Alvaro Herrera 于2024年3月26日周二 23:25写道：
> >>
> >> On 2024-Mar-26, Tender Wang wrote:
> >>
> >> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> >> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY
On Wed, Mar 27, 2024 at 10:26 PM Tender Wang wrote:
>
> Alvaro Herrera 于2024年3月26日周二 23:25写道：
>>
>> On 2024-Mar-26, Tender Wang wrote:
>>
>> > postgres=# CREATE TABLE t1(c0 int, c1 int);
>> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
>> > postgres=# ALTER TABLE t1 DROP
Alvaro Herrera 于2024年3月26日周二 23:25写道：
> On 2024-Mar-26, Tender Wang wrote:
>
> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > postgres=# ALTER TABLE t1 DROP c1;
> >
> > postgres=# ALTER TABLE t1 ALTER c0 DROP NOT NULL;
>
Alvaro Herrera 于2024年3月26日周二 23:25写道：
> On 2024-Mar-26, Tender Wang wrote:
>
> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > postgres=# ALTER TABLE t1 DROP c1;
> >
> > postgres=# ALTER TABLE t1 ALTER c0 DROP NOT NULL;
>
Alvaro Herrera 于2024年3月26日周二 23:25写道：
> On 2024-Mar-26, Tender Wang wrote:
>
> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > postgres=# ALTER TABLE t1 DROP c1;
> >
> > postgres=# ALTER TABLE t1 ALTER c0 DROP NOT NULL;
>
On 2024-Mar-26, Tender Wang wrote:
> postgres=# CREATE TABLE t1(c0 int, c1 int);
> postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> postgres=# ALTER TABLE t1 DROP c1;
>
> postgres=# ALTER TABLE t1 ALTER c0 DROP NOT NULL;
> ERROR: could not find not-null constraint on column
Hi Alvaro,
I met an issue related to Catalog not-null commit on HEAD.
postgres=# CREATE TABLE t1(c0 int, c1 int);
CREATE TABLE
postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
ALTER TABLE
postgres=# \d+ t1
Table "public.t1"
Column |
37 matches
Mail list logo
