| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18558: ALTER PUBLICATION fails with unhelpful error on attempt to use system column |
| Date: | 2024-07-29 14:06:02 |
| Message-ID: | 2580482.1722261962@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On the whole, I think the API of these functions could be improved as
> it's made the fix for this bug more convoluted than it needs to be.
+1
> I'm on the fence if this should be done as part of this bug fix. The
> reason I think it might is that you're changing
> publication_translate_columns() to be non-static, and if the above API
> change gets done later, that's then changing the API of an existing
> external function. The reason against is that it's more risky to do in
> the back branches as it's changing more code. What do others think?
If we are going to export a formerly-static function, we should make
its API as clean as we can. I doubt that that adds meaningful risk,
and it avoids people possibly getting bit by cross-branch differences.
> Is it worth adding an ALTER PUBLICATION test with a duplicate column too?
Probably, just to prove that the non-duplicative representation does
what we want.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-07-29 14:08:19 | Re: BUG #18558: ALTER PUBLICATION fails with unhelpful error on attempt to use system column |
| Previous Message | Bertrand Drouvot | 2024-07-29 13:52:10 | Re: 回复: [External]Re: BUG #18540: Does PG16 standby database support function pg_replication_origin_advance? |