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 CAFj8pRAgvWbJnRD7+t9e_P+aQdUhO3JVJqznNUoBY7B-r6RiOA@mail.gmail.com
Whole thread Raw
In response to Re: proposal: possibility to read dumped table's name from file  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: proposal: possibility to read dumped table's name from file
List pgsql-hackers


st 10. 6. 2020 v 0:30 odesílatel Justin Pryzby <pryzby@telsasoft.com> napsal:
On Tue, Jun 09, 2020 at 11:46:24AM +0200, Pavel Stehule wrote:
> po 8. 6. 2020 v 23:30 odesílatel Justin Pryzby <pryzby@telsasoft.com> napsal:

> I still wonder if a better syntax would use a unified --filter option, whose
> > argument would allow including/excluding any type of object:
> I tried to implement simple format "[+-][tndf] objectname"

I had another idea about format - instead using +-, we can use case sensitive options  same to pg_dump command line (with extending Df - because these options doesn't exists in short form)

So format can looks like

[tTnNDf] {objectname}

What do you think about this? This format is simpler, and it can work. What do you think about it?

> Did you "reduce" this from another implementation?  Where?
> What is its license ?

The code is 100% mine. It is not copy from gnulib and everybody can simply check it


Reduced in functionality sense. There is no full argument check that is necessary for glibc functions. There are no memory checks because pg_malloc, pg_realloc are used.

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: FailedAssertion at ReorderBufferCheckMemoryLimit()
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.