Good afternoon, Indeed, the functionality that I started to implement in the patch is very similar to what is included in the program you proposed. Many of the use cases are the same. Thanks for giving me a hint about it. I have been working on implementing referential integrity, but have not been able to find simple solutions for a complex structure. And I am not sure if it can be done in the dump process. Although it is obvious that without this functionality, the usefulness of the function is insignificant. When I worked with another database management system, the partial offer feature was available from the dump program. It was useful for me. But I understand why it might not be worth extending pg_dump with a non-essential feature. However, I will try to work again to solve the problem with the guaranteed recovery of the database. Thanks for the comments, they were really helpful to me.
вт, 4 окт. 2022 г. в 19:24, Julien Rouhaud <rjuju...@gmail.com>: > Hi, > > On Tue, Oct 04, 2022 at 02:15:16PM +0200, Pavel Stehule wrote: > > > > út 4. 10. 2022 v 12:48 odesílatel Никита Старовойтов < > nikstar...@gmail.com> > > napsal: > > > > > Hello, > > > with a view to meeting with postgres code and to get some practice with > > > it, I am making a small patch that adds the possibility of partial > tables > > > dump. > > > A rule of filtering is specified with standard SQL where clause > (without > > > "where" keyword) > > > > What is benefit and use case? For this case I don't see any benefit > against > > simple > > > > \copy (select * from xx where ...) to file CSV > > > > or how hard is it to write trivial application that does export of what > you > > want in the format that you want? > > Also, such approach probably requires a lot of effort to get a valid backup > (with regards to foreign keys and such). > > There's already a project dedicated to generate such partial (and > consistent) > backups: https://github.com/mla/pg_sample. Maybe that would address your > needs? >