Re: proposal: possibility to read dumped table's name from file - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: possibility to read dumped table's name from file
Date
Msg-id CAFj8pRCGX_9YtMDXwaVXA6qKBJVziyHj662jmRuei1CPvy=Sqw@mail.gmail.com
Whole thread Raw
In response to Re: proposal: possibility to read dumped table's name from file  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: proposal: possibility to read dumped table's name from file  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
Hi


út 18. 10. 2022 v 11:33 odesílatel Julien Rouhaud <rjuju123@gmail.com> napsal:
On Thu, Oct 13, 2022 at 11:46:34AM -0700, Andres Freund wrote:
> Hi,
>
> On 2022-10-07 07:26:08 +0200, Pavel Stehule wrote:
> > I am sending version with handy written parser and meson support
>
> Given this is a new approach it seems inaccurate to have the CF entry marked
> ready-for-committer. I've updated it to needs-review.

I just had a quick look at the rest of the patch.

For the parser, it seems that filter_get_pattern is reimplementing an
identifier parsing function but isn't entirely correct.  It can correctly parse
quoted non-qualified identifiers and non-quoted qualified identifiers, but not
quoted and qualified ones.  For instance:

$ echo 'include table nsp.tbl' | pg_dump --filter - >/dev/null
$echo $?
0

$ echo 'include table "TBL"' | pg_dump --filter - >/dev/null
$echo $?
0

$ echo 'include table "NSP"."TBL"' | pg_dump --filter - >/dev/null
pg_dump: error: invalid format of filter on line 1: unexpected extra data after pattern

fixed
 

This should also be covered in the regression tests.

done
 

I'm wondering if psql's parse_identifier() could be exported and reused here
rather than creating yet another version. 

I looked there, and I don't think this parser is usable for this purpose. It is  very sensitive on white spaces, and doesn't support multi-lines. It is designed for support readline tab complete, it is designed for simplicity not for correctness.



Nitpicking: the comments needs some improvements:

+ /*
+  * Simple routines - just don't repeat same code
+  *
+  * Returns true, when filter's file is opened
+  */
+ bool
+ filter_init(FilterStateData *fstate, const char *filename)

done
 

also, is there any reason why this function doesn't call exit_nicely in case of
error rather than letting each caller do it without any other cleanup?

It is commented few lines up

/*
 * Following routines are called from pg_dump, pg_dumpall and pg_restore.
 * Unfortunatelly, implementation of exit_nicely in pg_dump and pg_restore
 * is different from implementation of this rutine in pg_dumpall. So instead
 * direct calling exit_nicely we have to return some error flag (in this
 * case NULL), and exit_nicelly will be executed from caller's routine.
 */
 

+ /*
+  * Release allocated sources for filter
+  */
+ void
+ filter_free_sources(FilterStateData *fstate)

I'm assuming "ressources" not "sources"?

changed
 

+ /*
+  * log_format_error - Emit error message
+  *
+  * This is mostly a convenience routine to avoid duplicating file closing code
+  * in multiple callsites.
+  */
+ void
+ log_invalid_filter_format(FilterStateData *fstate, char *message)

mismatch between comment and function name (same for filter_read_item)

fixes
 

+ static const char *
+ filter_object_type_name(FilterObjectType fot)

No description.


fixed
 
/*
 * Helper routine to reduce duplicated code
 */
void
log_unsupported_filter_object_type(FilterStateData *fstate,
                                                                        const char *appname,
                                                                        FilterObjectType fot)

Need more helpful comment.

fixed

Thank you for comments

attached updated patch

Regards

Pavel
 
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Allow file inclusion in pg_hba and pg_ident files
Next
From: Bharath Rupireddy
Date:
Subject: Re: Some regression tests for the pg_control_*() functions