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 CAFj8pRB94jRM6GgqbEqYbadsG8=9E2wHLXEiUW5GkOvSiGuf0g@mail.gmail.com
Whole thread Raw
In response to Re: proposal: possibility to read dumped table's name from file  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
Hi

út 5. 10. 2021 v 14:30 odesílatel Daniel Gustafsson <daniel@yesql.se> napsal:
> On 1 Oct 2021, at 15:19, Daniel Gustafsson <daniel@yesql.se> wrote:

> I'm still not happy with the docs, I need to take another look there and see if
> I make them more readable but otherwise I don't think there are any open issues
> with this.

Attached is a rebased version which has rewritten docs which I think are more
in line with the pg_dump documentation.  I've also added tests for
--strict-names operation, as well subjected it to pgindent and pgperltidy.

Unless there are objections, I think this is pretty much ready to go in.

I am sending a rebased version of patch pg_dump-filteropt-20211005.patch with fixed regress tests and fixed documentation (reported by Erik).
I found another issue - the stringinfo line used in filter_get_pattern was released too early - the line (memory) was used later in check of unexpected
chars after pattern string. I fixed it by moving this stringinfo buffer to fstate structure. It can be shared by all routines, and it can be safely released at
an end of filter processing, where we are sure, so these data can be free.

Regards

Pavel




--
Daniel Gustafsson               https://vmware.com/

Attachment

pgsql-hackers by date:

Previous
From: Greg Nancarrow
Date:
Subject: Re: row filtering for logical replication
Next
From: Amit Kapila
Date:
Subject: Re: Skipping logical replication transactions on subscriber side