On 2025-Jun-26, Fujii Masao wrote:
> I noticed a small inconsistency in the output of pg_dump when handling
> comments for COMMENT commands on not-null constraints. [...]
> You can see that only comments for the not-null constraint includes
> the schema-qualified table name (hoge.t) after "ON". T
On 2025/06/26 0:45, Álvaro Herrera wrote:
On 2025-Jun-26, Fujii Masao wrote:
CREATE TABLE ctlt1_inh (LIKE ctlt1 INCLUDING CONSTRAINTS INCLUDING COMMENTS)
INHERITS (ctlt1);
\d+ ctlt1_inh
-SELECT description FROM pg_description, pg_constraint c WHERE classoid =
'pg_constraint'::regclass
On 2025/06/26 3:45, Álvaro Herrera wrote:
On 2025-Jun-25, Álvaro Herrera wrote:
Ah, thanks for the test case. Yeah, I removed one 'if' condition too
many from Jian's patch. We just need to test the constraint name for
nullness and then things seem to work:
One more thing was missing, whi
On 2025-Jun-25, Álvaro Herrera wrote:
> Ah, thanks for the test case. Yeah, I removed one 'if' condition too
> many from Jian's patch. We just need to test the constraint name for
> nullness and then things seem to work:
One more thing was missing, which I noticed as I added the tests.
Apparent
On Wed, Jun 25, 2025 at 11:04 PM Fujii Masao
wrote:
> >>
> >> This commit corrects the behavior by ensuring CREATE TABLE LIKE to also
> >> copy
> >> the comments on NOT NULL constraints when INCLUDING COMMENTS is specified.
> >
> > LGTM. I'd add a line in the test showing that these comments are
On 2025-Jun-26, Fujii Masao wrote:
> However, with the patch applied, I encountered a segmentation fault in pg_dump
> as follows:
Ah, thanks for the test case. Yeah, I removed one 'if' condition too
many from Jian's patch. We just need to test the constraint name for
nullness and then things se
On 2025-Jun-26, Fujii Masao wrote:
> CREATE TABLE ctlt1_inh (LIKE ctlt1 INCLUDING CONSTRAINTS INCLUDING COMMENTS)
> INHERITS (ctlt1);
> \d+ ctlt1_inh
> -SELECT description FROM pg_description, pg_constraint c WHERE classoid =
> 'pg_constraint'::regclass AND objoid = c.oid AND c.conrelid =
> '
On 2025/06/25 22:36, Álvaro Herrera wrote:
On 2025-Jun-25, Álvaro Herrera wrote:
Yeah, I think in this case we need to extract the constraint name so
that we have it available to print the COMMENT command, rather than
making any assumptions about it. In fact I suspect this would fail if
the
On 2025/06/25 20:46, Álvaro Herrera wrote:
On 2025-Jun-25, Fujii Masao wrote:
From 516e647e7d1fdafc64dba092389963f32cd688e5 Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Wed, 25 Jun 2025 10:02:56 +0900
Subject: [PATCH v2] Make CREATE TABLE LIKE copy comments on NOT NULL
constraints wh
On 2025-Jun-25, Álvaro Herrera wrote:
> Yeah, I think in this case we need to extract the constraint name so
> that we have it available to print the COMMENT command, rather than
> making any assumptions about it. In fact I suspect this would fail if
> the table or column names are very long. Fo
On 2025-Jun-25, Fujii Masao wrote:
> > however, in determineNotNullFlags we have:
> >
> > char *default_name;
> > /* XXX should match ChooseConstraintName better */
> > default_name = psprintf("%s_%s_not_null",
> > tbinfo->dobj.name,
> >
On 2025-Jun-25, Fujii Masao wrote:
> From 516e647e7d1fdafc64dba092389963f32cd688e5 Mon Sep 17 00:00:00 2001
> From: Fujii Masao
> Date: Wed, 25 Jun 2025 10:02:56 +0900
> Subject: [PATCH v2] Make CREATE TABLE LIKE copy comments on NOT NULL
> constraints when requested.
>
> Commit 14e87ffa5c5 int
On 2025/06/19 20:53, Fujii Masao wrote:
On 2025/06/19 14:42, jian he wrote:
On Wed, Jun 18, 2025 at 10:21 AM Fujii Masao
wrote:
I ran into another issue related to comments on NOT NULL constraints.
When using CREATE TABLE ... (LIKE ... INCLUDING ALL), the NOT NULL constraints
are copied,
On 2025/06/19 11:38, jian he wrote:
On Wed, Jun 18, 2025 at 11:05 PM Álvaro Herrera wrote:
I agree that this is roughly the right approach, but I think you're
doing it harder than it needs to be -- it might be easier to add a JOIN
to pg_description to the big query in getTableAttrs(), and a
On 2025/06/19 14:42, jian he wrote:
On Wed, Jun 18, 2025 at 10:21 AM Fujii Masao
wrote:
I ran into another issue related to comments on NOT NULL constraints.
When using CREATE TABLE ... (LIKE ... INCLUDING ALL), the NOT NULL constraints
are copied, but their comments are not. For example:
On Wed, Jun 18, 2025 at 10:21 AM Fujii Masao
wrote:
>
> I ran into another issue related to comments on NOT NULL constraints.
> When using CREATE TABLE ... (LIKE ... INCLUDING ALL), the NOT NULL constraints
> are copied, but their comments are not. For example:
>
>
On Wed, Jun 18, 2025 at 11:05 PM Álvaro Herrera wrote:
>
> I agree that this is roughly the right approach, but I think you're
> doing it harder than it needs to be -- it might be easier to add a JOIN
> to pg_description to the big query in getTableAttrs(), and add a pointer
> to the returned stri
On 2025-Jun-18, jian he wrote:
> Similarly we don't need to worry about not-null constraints that are
> dumped separately.
> dumpConstraint, dumpTableConstraintComment will do the job.
Right.
> dumpTableSchema handles dumping of table column definitions, and tells us
> which
> column print_notn
On Wed, Jun 18, 2025 at 8:13 AM Fujii Masao wrote:
>
> I'm aware of a related open item [1] affecting both v17 and v18,
> but this seems like a separate issue, since it relates to a new v18 feature...
> Or we should treat them the same?
>
I think they are separate issues.
for check constraint tha
On 2025-Jun-18, Fujii Masao wrote:
> On 2025/06/18 9:13, Fujii Masao wrote:
> > In v18, we can now add comments on NOT NULL constraints. However, I noticed
> > that pg_dump doesn't include those comments in its output. For example:
This is definitely a bug, thanks for reporting.
> I ran into an
On 2025/06/18 9:13, Fujii Masao wrote:
Hi,
In v18, we can now add comments on NOT NULL constraints. However, I noticed
that pg_dump doesn't include those comments in its output. For example:
--
$ psql < 0);
COMMENT ON CONSTRAINT my_not_null ON t IS 'my not null';
COMM
21 matches
Mail list logo
