Re: proposal: possibility to read dumped table's name from file

po 13. 11. 2023 v 14:39 odesílatel Daniel Gustafsson <daniel(at)yesql(dot)se>
napsal:

> > On 13 Nov 2023, at 14:15, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> >
> > Hi
> >
> > ne 12. 11. 2023 v 14:17 odesílatel Pavel Stehule <
> pavel(dot)stehule(at)gmail(dot)com <mailto:pavel(dot)stehule(at)gmail(dot)com>> napsal:
> > Hi
> >
> >
> > What are your thoughts on this version? It's not in a committable state
> as it
> > needs a bit more comments here and there and a triplecheck that nothing
> was
> > missed in changing this, but I prefer to get your thoughts before
> spending the
> > extra time.
> >
> > I think using pointer to exit function is an elegant solution. I checked
> the code and I found only one issue. I fixed warning
> >
> > [13:57:22.578] time make -s -j${BUILD_JOBS} world-bin
> > [13:58:20.858] filter.c: In function ‘pg_log_filter_error’:
> > [13:58:20.858] filter.c:161:2: error: function ‘pg_log_filter_error’
> might be a candidate for ‘gnu_printf’ format attribute
> [-Werror=suggest-attribute=format]
> > [13:58:20.858] 161 | vsnprintf(buf, sizeof(buf), fmt, argp);
> > [13:58:20.858] | ^~~~~~~~~
> > [13:58:20.858] cc1: all warnings being treated as errors
> >
> > and probably copy/paste bug
> >
> > diff --git a/src/bin/pg_dump/pg_restore.c b/src/bin/pg_dump/pg_restore.c
> > index f647bde28d..ab2abedf5f 100644
> > --- a/src/bin/pg_dump/pg_restore.c
> > +++ b/src/bin/pg_dump/pg_restore.c
> > @@ -535,7 +535,7 @@ read_restore_filters(const char *filename,
> RestoreOptions *opts)
> > case FILTER_OBJECT_TYPE_EXTENSION:
> > case FILTER_OBJECT_TYPE_FOREIGN_DATA:
> > pg_log_filter_error(&fstate, _("%s filter for \"%s\"
> is not allowed."),
> > - "exclude",
> > + "include",
> >
> filter_object_type_name(objtype));
> > exit_nicely(1);
> >
> > Regards
> >
> > Pavel
> >
> > next update - fix used, but uninitialized "is_include" variable, when
> filter is of FILTER_OBJECT_TYPE_NONE
>
> Thanks, the posted patchset was indeed a bit of a sketch, thanks for
> fixing up
> these. I'll go over it again too to clean it up and try to make into
> something
> committable.
>
> I was pondering replacing the is_include handling with returning an enum
> for
> the operation, to keep things more future proof in case we add more
> operations
> (and also a bit less magic IMHO).
>

+1

Pavel

> --
> Daniel Gustafsson
>
>