Le jeu. 7 avr. 2022, 07:43, Michael Paquier a écrit :
>
> Looks clear to me that a different design is wanted here, and that
> this won't make it for v15, so I have marked the patch as returned
> with feedback in the CF app.
>
> Hello,
I agree with Michael, this won't be ready for PG15. I had
On Sat, Mar 26, 2022 at 09:53:19AM +0100, Laetitia Avrot wrote:
> I think it's time to sum up what we want to do:
>
> - We'd like to use switches to export objects according to a pattern.
> - For each object type we will have an --object=PATTERN flag and a
> --exclude-object=PATTERN
> - Having a
On Sat, Mar 26, 2022 at 1:53 AM Laetitia Avrot
wrote:
> Hello all,
>
> Le sam. 26 mars 2022 à 01:13, Michael Paquier a
> écrit :
>
>> On Fri, Mar 25, 2022 at 10:09:33PM +0100, Daniel Gustafsson wrote:
>> > Agreed. In this case it seems that adding --exclude-extension would
>> make sense
>> >
Hello all,
Le sam. 26 mars 2022 à 01:13, Michael Paquier a
écrit :
> On Fri, Mar 25, 2022 at 10:09:33PM +0100, Daniel Gustafsson wrote:
> > Agreed. In this case it seems that adding --exclude-extension would
> make sense
> > to keep conistency. I took a quick stab at doing so with the
On Fri, Mar 25, 2022 at 10:09:33PM +0100, Daniel Gustafsson wrote:
> Agreed. In this case it seems that adding --exclude-extension would make
> sense
> to keep conistency. I took a quick stab at doing so with the attached while
> we're here.
src/test/modules/test_pg_dump would be the best
"David G. Johnston" writes:
> If we want to choose the other position I would just go with
> "--[no]-system-objects" options to toggle whether pattern matching grabs
> them by default (defaulting to no) and if someone wants to enable them for
> only specific object types they can --system-objects
On Fri, Mar 25, 2022 at 2:55 PM Tom Lane wrote:
> Daniel Gustafsson writes:
> >> On 25 Mar 2022, at 19:37, Tom Lane wrote:
> >> I'd vote for changing the behavior of --table rather than trying to
> >> be bug-compatible with this decision.
>
> > Agreed. Question is what to do for "-t
Daniel Gustafsson writes:
>> On 25 Mar 2022, at 19:37, Tom Lane wrote:
>> I'd vote for changing the behavior of --table rather than trying to
>> be bug-compatible with this decision.
> Agreed. Question is what to do for "-t pg_class", should we still forbid
> dumping system catalogs when they
> On 25 Mar 2022, at 19:37, Tom Lane wrote:
> I'd vote for changing the behavior of --table rather than trying to
> be bug-compatible with this decision.
Agreed. Question is what to do for "-t pg_class", should we still forbid
dumping system catalogs when they are pattern matched without
> On 25 Mar 2022, at 01:40, Tom Lane wrote:
>
> "David G. Johnston" writes:
>> The extension object type does not seem to have gotten the
>> --exclude-extension capability that it would need to conform to the general
>> design exemplified by --table and hopefully extended out to the routine
>>
On Friday, March 25, 2022, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Fri, Mar 25, 2022 at 10:57 AM Tom Lane wrote:
> >> pg_dump never dumps system objects, so I don't see a need for
> >> a switch to tell it not to.
>
> > I considered pg_class to be a system object, which was dumped
"David G. Johnston" writes:
> On Fri, Mar 25, 2022 at 10:57 AM Tom Lane wrote:
>> pg_dump never dumps system objects, so I don't see a need for
>> a switch to tell it not to.
> I considered pg_class to be a system object, which was dumped under -t '*'
Oh! You're right, the --table switches
On Fri, Mar 25, 2022 at 10:57 AM Tom Lane wrote:
> "David G. Johnston" writes:
>
> > Except succinctly
> > omitting system objects which should get its own general option.
>
pg_dump never dumps system objects, so I don't see a need for
> a switch to tell it not to.
>
>
I considered pg_class to
"David G. Johnston" writes:
> I don't find the --objectype-only option to be desirable. psql
> --tables-only --functions-only just seems odd, no longer are they "only".
> I would go with --function-all (and maybe --function-system and
> --function-user) if going down this path but the wildcard
Laetitia Avrot writes:
> Thank you so much for your suggestion. I was really excited to find a
> generic term for Functions and Procedures, but "routine" also includes
> aggregation functions which I had excluded from my feature (see Postgres
> Glossary here:
>
On Fri, Mar 25, 2022 at 9:44 AM Laetitia Avrot
wrote:
>
> Actually, I thought of it after the --schema-only flag (which is kind of
> confusing, because it won't export only schema creation DDL).
>
--schema-only is talking about the different sections of the dump file, not
namespace schema
Hello David,
thank you for your interest in that patch.
Le ven. 25 mars 2022 à 01:17, David G. Johnston
a écrit :
> On Thu, Mar 24, 2022 at 4:42 PM Chapman Flack
> wrote:
>
>> On 03/27/21 08:57, Andrew Dunstan wrote:
>> > We can bikeshed the name of the flag at some stage. --procedures-only
Hello Chapman,
Le ven. 25 mars 2022 à 00:42, Chapman Flack a
écrit :
> On 03/27/21 08:57, Andrew Dunstan wrote:
> > We can bikeshed the name of the flag at some stage. --procedures-only
> > might also make sense
>
> Any takers for --routines-only ?
>
> "Routine" is the genuine, ISO SQL umbrella
Hello Tom,
Le ven. 25 mars 2022 à 00:18, Tom Lane a écrit :
> Daniel Gustafsson writes:
> >> On 24 Mar 2022, at 23:38, Greg Stark wrote:
> >> It looks like this discussion has reached a bit of an impasse with Tom
> >> being against this approach and Michael and Daniel being for it. It
> >>
Hello Michael,
Le mar. 25 janv. 2022 à 06:49, Michael Paquier a
écrit :
> On Tue, Nov 09, 2021 at 03:23:07PM +0100, Daniel Gustafsson wrote:
> > Looking at this thread I think it makes sense to go ahead with this
> patch. The
> > filter functionality worked on in another thread is dealing with
On Thu, Mar 24, 2022 at 5:40 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > The extension object type does not seem to have gotten the
> > --exclude-extension capability that it would need to conform to the
> general
> > design exemplified by --table and hopefully extended out to the
"David G. Johnston" writes:
> The extension object type does not seem to have gotten the
> --exclude-extension capability that it would need to conform to the general
> design exemplified by --table and hopefully extended out to the routine
> object types.
We're not going to instantly build out
On Mon, Jan 24, 2022 at 10:49 PM Michael Paquier
wrote:
> What about patterns? Switches like --table or
> --extension are able to digest a psql-like pattern to decide which
> objects to dump.
>
The extension object type does not seem to have gotten the
--exclude-extension capability that it
On Thu, Mar 24, 2022 at 4:42 PM Chapman Flack wrote:
> On 03/27/21 08:57, Andrew Dunstan wrote:
> > We can bikeshed the name of the flag at some stage. --procedures-only
> > might also make sense
>
> Any takers for --routines-only ?
>
> "Routine" is the genuine, ISO SQL umbrella term for a
On 03/27/21 08:57, Andrew Dunstan wrote:
> We can bikeshed the name of the flag at some stage. --procedures-only
> might also make sense
Any takers for --routines-only ?
"Routine" is the genuine, ISO SQL umbrella term for a function or
procedure, and we have used it that way in our docs and
Daniel Gustafsson writes:
>> On 24 Mar 2022, at 23:38, Greg Stark wrote:
>> It looks like this discussion has reached a bit of an impasse with Tom
>> being against this approach and Michael and Daniel being for it. It
>> doesn't look like it's going to get committed this commitfest, shall
>> we
> On 24 Mar 2022, at 23:38, Greg Stark wrote:
> It looks like this discussion has reached a bit of an impasse with Tom
> being against this approach and Michael and Daniel being for it. It
> doesn't look like it's going to get committed this commitfest, shall
> we move it forward or mark it
It looks like this discussion has reached a bit of an impasse with Tom
being against this approach and Michael and Daniel being for it. It
doesn't look like it's going to get committed this commitfest, shall
we move it forward or mark it returned with feedback?
On Tue, Nov 09, 2021 at 03:23:07PM +0100, Daniel Gustafsson wrote:
> Looking at this thread I think it makes sense to go ahead with this patch.
> The
> filter functionality worked on in another thread is dealing with
> cherry-picking
> certain objects where this is an all-or-nothing switch, so
> On 30 Jul 2021, at 12:55, Lætitia Avrot wrote:
>
> > On Fri, Jul 9, 2021 at 4:43 PM Tomas Vondra
> > wrote:
> >
> > The main question I have is whether this should include procedures. I'd
> > probably argue procedures should be considered different from functions
> > (i.e. requiring a
>
>
> > On Fri, Jul 9, 2021 at 4:43 PM Tomas Vondra <
> tomas.von...@enterprisedb.com> wrote:
> >
> > The main question I have is whether this should include procedures. I'd
> > probably argue procedures should be considered different from functions
> > (i.e. requiring a separate --procedures-only
> On Sat, Jul 10, 2021 at 5:06 AM Tomas Vondra <
tomas.von...@enterprisedb.com> wrote:
> On 7/10/21 1:43 AM, Tom Lane wrote:
>> Tomas Vondra writes:
>>> The main question I have is whether this should include procedures.
>>
>> I feel a bit uncomfortable about sticking this sort of limited-purpose
On 7/10/21 1:43 AM, Tom Lane wrote:
Tomas Vondra writes:
The main question I have is whether this should include procedures.
I feel a bit uncomfortable about sticking this sort of limited-purpose
selectivity mechanism into pg_dump. I'd rather see a general filter
method that can select
On Fri, Jul 09, 2021 at 07:43:02PM -0400, Tom Lane wrote:
> Tomas Vondra writes:
> > The main question I have is whether this should include procedures.
>
> I feel a bit uncomfortable about sticking this sort of limited-purpose
> selectivity mechanism into pg_dump. I'd rather see a general
Tomas Vondra writes:
> The main question I have is whether this should include procedures.
I feel a bit uncomfortable about sticking this sort of limited-purpose
selectivity mechanism into pg_dump. I'd rather see a general filter
method that can select object(s) of any type. Pavel was doing
Hi,
I took a quick look at the patch today. There was some minor bitrot
requiring a rebase, so I attach the rebased patch as v3.
The separate 0002 part contains some minor fixes - a couple
typos/rewording in the docs (would be good if a native speaker looked at
it, thought), and a slightly
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Few minor comments :
- The latest patch has some hunk failures
>
>
>> Using --functions-only along with --table= does not error out and
> warn the user, instead it creates a dump containing only the SET commands.
> An error similar to using --functions-only along with --data-only seems
> like a good idea.
>
>
Thank you for giving my patch a try.
I added the
On Sat, Mar 27, 2021 at 6:23 AM Lætitia Avrot
wrote:
> Hello,
>
> You'll find enclosed the first version of my patch.
>
I tested a couple simple use cases. This is great, Thank you!
> I did not include the possibility of using a file to list tables to be
> exported as Tom suggested because I
On 3/27/21 8:22 AM, Lætitia Avrot wrote:
> Hello,
>
> You'll find enclosed the first version of my patch. I did not include
> the possibility of using a file to list tables to be exported as Tom
> suggested because I genuinely think it is a totally different matter.
> It does not mean I'm not
Hello,
You'll find enclosed the first version of my patch. I did not include the
possibility of using a file to list tables to be exported as Tom suggested
because I genuinely think it is a totally different matter. It does not
mean I'm not open to the possibility, it just felt weird.
The patch
Vik Fearing writes:
> On 3/17/21 6:00 PM, Lætitia Avrot wrote:
>> However, when I finally got the time to look at it in detail, I found out
>> there was no way to solve the dependencies in the functions and procedures,
>> so that the exported file, when re-played could lead to invalid objects.
>>
On Wed, Mar 17, 2021 at 2:00 PM Lætitia Avrot
wrote:
>
> Hey hackers,
>
> I had this idea, that I raised and cherished like my baby to add a switch
in `pg_dump` to allow exporting stored functions (and procedures) only.
>
> However, when I finally got the time to look at it in detail, I found out
On 3/17/21 6:00 PM, Lætitia Avrot wrote:
> Hey hackers,
>
> I had this idea, that I raised and cherished like my baby to add a switch
> in `pg_dump` to allow exporting stored functions (and procedures) only.
>
> However, when I finally got the time to look at it in detail, I found out
> there
Hey hackers,
I had this idea, that I raised and cherished like my baby to add a switch
in `pg_dump` to allow exporting stored functions (and procedures) only.
However, when I finally got the time to look at it in detail, I found out
there was no way to solve the dependencies in the functions and
45 matches
Mail list logo
