On Mon, May 06, 2024 at 06:34:16PM +0200, Alvaro Herrera wrote:
> On 2024-May-06, Justin Pryzby wrote:
>
> > > (Do you really want the partition to be
> > > created without the primary key already there?)
> >
> > Why not ? The PK will be added when I attach it one moment later.
> >
> > CREATE T
On 2024-May-06, Justin Pryzby wrote:
> > (Do you really want the partition to be
> > created without the primary key already there?)
>
> Why not ? The PK will be added when I attach it one moment later.
>
> CREATE TABLE part (LIKE parent);
> ALTER TABLE parent ATTACH PARTITION part ...
Well, i
On Mon, May 06, 2024 at 05:56:54PM +0200, Alvaro Herrera wrote:
> On 2024-May-04, Alvaro Herrera wrote:
> > On 2024-May-03, Justin Pryzby wrote:
> >
> > > But if it's created with LIKE:
> > > postgres=# CREATE TABLE t1 (LIKE t);
> > > postgres=# ALTER TABLE t ATTACH PARTITION t1 DEFAULT ;
> > >
>
On 2024-May-04, Alvaro Herrera wrote:
> On 2024-May-03, Justin Pryzby wrote:
>
> > But if it's created with LIKE:
> > postgres=# CREATE TABLE t1 (LIKE t);
> > postgres=# ALTER TABLE t ATTACH PARTITION t1 DEFAULT ;
> >
> > ..one also sees:
> >
> > Not-null constraints:
> > "t1_i_not_null" NO
On 2024-May-03, Justin Pryzby wrote:
> But if it's created with LIKE:
> postgres=# CREATE TABLE t1 (LIKE t);
> postgres=# ALTER TABLE t ATTACH PARTITION t1 DEFAULT ;
>
> ..one also sees:
>
> Not-null constraints:
> "t1_i_not_null" NOT NULL "i"
Hmm, I think the problem here is not ATTACH; th
On another thread [0], Alexander Lakhin pointed out, indirectly, that
partitions created using LIKE+ATTACH now have different not-null constraints
from partitions created using PARTITION OF.
postgres=# CREATE TABLE t (i int PRIMARY KEY) PARTITION BY RANGE (i);
postgres=# CREATE TABLE t1 PARTITION
On Tue, Apr 30, 2024 at 01:52:02PM -0400, Robert Haas wrote:
> On Thu, Apr 18, 2024 at 12:52 PM Justin Pryzby wrote:
> > I'm not totally clear on what's intended in v17 - maybe it'd be dead
> > code, and maybe it shouldn't even be applied to master branch. But I do
> > think it's worth patching e
On Thu, Apr 18, 2024 at 12:52 PM Justin Pryzby wrote:
> I'm not totally clear on what's intended in v17 - maybe it'd be dead
> code, and maybe it shouldn't even be applied to master branch. But I do
> think it's worth patching earlier versions (even though it'll be less
> useful than having done
On Thu, Apr 18, 2024 at 06:23:30PM +0200, Alvaro Herrera wrote:
> On 2024-Apr-18, Justin Pryzby wrote:
>
> > BTW, this works up to v16 (although maybe it should not):
> >
> > | CREATE TABLE ip(id int PRIMARY KEY); CREATE TABLE ic(id int) INHERITS
> > (ip); ALTER TABLE ic ALTER id DROP NOT NULL;
On 2024-Apr-18, Justin Pryzby wrote:
> That seems like it could be important. I considered but never actually
> test your patch by pg_upgrading across major versions.
It would be a welcome contribution for sure. I've been doing it rather
haphazardly, which is not great.
> BTW, this works up to
On Tue, Apr 16, 2024 at 08:11:49PM +0200, Alvaro Herrera wrote:
> This is still missing some cleanup and additional tests, of course.
> Speaking of which, I wonder if I should modify pg16's tests so that they
> leave behind tables set up in this way, to immortalize pg_upgrade
> testing.
That seems
On 2024-Apr-15, Justin Pryzby wrote:
> Here's a couple more issues affecting upgrades from v16 to v17.
>
> postgres=# CREATE TABLE a(i int NOT NULL); CREATE TABLE b(i int PRIMARY KEY)
> INHERITS (a);
> pg_restore: error: could not execute query: ERROR: constraint
> "pgdump_throwaway_notnull_0"
On 2024-Apr-16, Justin Pryzby wrote:
> Yes, this fixes the issue I reported.
Excellent, thanks for confirming.
> BTW, that seems to be the same issue Andrew reported in January.
> https://www.postgresql.org/message-id/CAJnzarwkfRu76_yi3dqVF_WL-MpvT54zMwAxFwJceXdHB76bOA%40mail.gmail.com
That's r
On Tue, Apr 16, 2024 at 08:11:49PM +0200, Alvaro Herrera wrote:
> On 2024-Apr-15, Alvaro Herrera wrote:
>
> > - Fourth thought: we do as in the third thought, except we also allow
> > DROP CONSTRAINT a constraint that's marked "local, inherited" to be
> > simply an inherited constraint (remove its
On 2024-Apr-15, Justin Pryzby wrote:
> Here's a couple more issues affecting upgrades from v16 to v17.
>
> postgres=# CREATE TABLE a(i int NOT NULL); CREATE TABLE b(i int PRIMARY KEY)
> INHERITS (a);
> pg_restore: error: could not execute query: ERROR: constraint
> "pgdump_throwaway_notnull_0"
On 2024-Apr-15, Alvaro Herrera wrote:
> - Fourth thought: we do as in the third thought, except we also allow
> DROP CONSTRAINT a constraint that's marked "local, inherited" to be
> simply an inherited constraint (remove its "local" marker).
Here is an initial implementation of what I was thinkin
On Mon, Apr 15, 2024 at 03:47:38PM +0200, Alvaro Herrera wrote:
> On 2024-Apr-15, Justin Pryzby wrote:
>
> > I think there are other issues related to b0e96f3119 (Catalog not-null
> > constraints) - if I dump a v16 server using v17 tools, the backup can't
> > be restored into the v16 server. I'm
On 2024-Apr-15, Alvaro Herrera wrote:
> On 2024-Apr-15, Justin Pryzby wrote:
> > postgres=# CREATE TABLE iparent(id serial PRIMARY KEY); CREATE TABLE child
> > (id int) INHERITS (iparent); ALTER TABLE child ALTER id DROP NOT NULL;
> > ALTER TABLE child ADD CONSTRAINT p PRIMARY KEY (id);
> >
>
On 2024-Apr-15, Justin Pryzby wrote:
> 9b581c5341 can break dump/restore from old versions, including
> pgupgrade.
>
> postgres=# CREATE TABLE iparent(id serial PRIMARY KEY); CREATE TABLE child
> (id int) INHERITS (iparent); ALTER TABLE child ALTER id DROP NOT NULL; ALTER
> TABLE child ADD CONS
Forking: <20230829172828.5qi2pfbladvfgvsg@alvherre.pgsql>
Subject: Re: Strange presentaion related to inheritance in \d+
On Tue, Aug 29, 2023 at 07:28:28PM +0200, Alvaro Herrera wrote:
> On 2023-Aug-29, Kyotaro Horiguchi wrote:
>
> > Attached is the initial version of the patch. It prevents "CREA
20 matches
Mail list logo
