| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
| Cc: | vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Review items for EXCEPT TABLE publication |
| Date: | 2026-09-11 08:03:08 |
| Message-ID: | CAA4eK1LvZWTgHCZKPWY53n+rEiVc9hegY2b6M2gENBcBi_ExFg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Sep 11, 2026 at 1:13 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> On Fri, Sep 11, 2026 at 5:22 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> >
> > Yes, but how does that matter? We just don't want the operation to
> > proceed when the table is part of publication, users anyway need to
> > fix it before proceeding.
> >
>
> OTOH it doesn't matter because they are both problems the user must
> fix. But won't it be better to get a consistent/deterministic error
> message for the same problem?
>
Sure, but to distinguish ERROR-type, extra scan on catalog seems
costly. If you can avoid extra scans and or more cycles on scanning
catalog and still be able to manage this difference, then it is worth
considering.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nisha Moond | 2026-09-11 08:06:02 | Re: Crashes on a partition whose concurrent detach never finished |
| Previous Message | Daniel Gustafsson | 2026-09-11 07:59:37 | Re: Do we reduce autovacuum_naptime max values |