Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function

On Sat, Jun 3, 2023 at 2:28 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Kirk Wolak <wolakk(at)gmail(dot)com> writes:
> > On Fri, Jun 2, 2023 at 8:16 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > If I comprehend the suggestion, it will label each line with a warning.
> > Which implies I have 6 Warnings.
>
> Right, I'd forgotten that pg_log_warning() will interpose "warning:".
> Attached are two more-carefully-thought-out suggestions. The easy
> way is to use pg_log_warning_detail(), which produces output like
>
> pg_dump: warning: could not resolve dependency loop among these items:
> pg_dump: detail: FUNCTION a_f (ID 216 OID 40532)
> pg_dump: detail: CONSTRAINT a_pkey (ID 3466 OID 40531)
> pg_dump: detail: POST-DATA BOUNDARY (ID 3612)
> pg_dump: detail: TABLE DATA a (ID 3610 OID 40525)
> pg_dump: detail: PRE-DATA BOUNDARY (ID 3611)
>
> Alternatively, we could assemble the details by hand, as in the
> second patch, producing
>
> pg_dump: warning: could not resolve dependency loop among these items:
> FUNCTION a_f (ID 216 OID 40532)
> CONSTRAINT a_pkey (ID 3466 OID 40531)
> POST-DATA BOUNDARY (ID 3612)
> TABLE DATA a (ID 3610 OID 40525)
> PRE-DATA BOUNDARY (ID 3611)
>
> I'm not really sure which of these I like better. The first one
> is a much simpler code change, and there is some value in labeling
> the output like that. The second patch's output seems less cluttered,
> but it's committing a modularity sin by embedding formatting knowledge
> at the caller level. Thoughts?
>

Honestly the double space in front of the strings with either the Original
version,
or the "detail:" version is great.

While I get the "Less Cluttered" version.. It "detaches" it a bit too much
from the lead in, for me.

Kirk...