Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 26, 2018 at 11:56 AM, Stephen Frost wrote:
> >> I think you've chosen a terrible design and ought to throw the whole
> >> thing away and start over.
> >
> > I'll all for throwing away the existing test once we've got something
> >
On Fri, Jan 26, 2018 at 11:56 AM, Stephen Frost wrote:
>> I think you've chosen a terrible design and ought to throw the whole
>> thing away and start over.
>
> I'll all for throwing away the existing test once we've got something
> that covers at least what it does (ideally more, of course).
I'm
Robert Haas writes:
> I figured you would, but it's still my opinion. I guess my basic
> objection here is to the idea that we somehow know that the 6000+ line
> test case file actually contains only correct tests. That vastly
> exceeds the ability of any normal human being to verify correctness
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 26, 2018 at 11:09 AM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Thu, Jan 25, 2018 at 4:52 PM, Alvaro Herrera
> >> wrote:
> >> > My proposal is that instead of looking at three hundred lines, y
On Fri, Jan 26, 2018 at 11:09 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Jan 25, 2018 at 4:52 PM, Alvaro Herrera
>> wrote:
>> > My proposal is that instead of looking at three hundred lines, you'd
>> > look for 50 lines of `pg_restore -l` output -- is elem
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jan 25, 2018 at 4:52 PM, Alvaro Herrera
> wrote:
> > My proposal is that instead of looking at three hundred lines, you'd
> > look for 50 lines of `pg_restore -l` output -- is element XYZ in there
> > or not. Quite a bit simpler for
On Thu, Jan 25, 2018 at 4:52 PM, Alvaro Herrera wrote:
> My proposal is that instead of looking at three hundred lines, you'd
> look for 50 lines of `pg_restore -l` output -- is element XYZ in there
> or not. Quite a bit simpler for the guy adding a new test. This tests
> combinations of pg_dump
Alvaro,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> Stephen Frost wrote:
> > Alvaro, Tom,
> >
> > * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
>
> > > Crazy idea: maybe a large fraction of that test could be replaced with
> > > comparisons of the "pg_restore -l" output file rather t
Alvaro Herrera writes:
> Well, the current implementation compares a dozen of pg_dump output text
> files, three hundred lines apiece, against a thousand of regexes (give
> or take). Whenever there is a mismatch, what you get is "this regexp
> failed to match " (or sometimes "matched when it
> sh
Stephen Frost wrote:
> Alvaro, Tom,
>
> * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> > Crazy idea: maybe a large fraction of that test could be replaced with
> > comparisons of the "pg_restore -l" output file rather than pg_dump's
> > text output (i.e. the TOC entry for each object, rather
Alvaro, Tom,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> Tom Lane wrote:
>
> > The changes in t/002_pg_dump.pl largely failed to apply, which is
> > partially due to the age of the patch but IMO speaks more to the
> > unmaintainability of that TAP test. It still didn't run after I'd
> >
Tom Lane wrote:
> The changes in t/002_pg_dump.pl largely failed to apply, which is
> partially due to the age of the patch but IMO speaks more to the
> unmaintainability of that TAP test. It still didn't run after I'd
> manually fixed the merge failures, so I gave up in disgust and
> did not pus
Robins Tharakan writes:
> Attached is an updated patch (v4) with basic tests for pg_dump / pg_dumpall.
I've reviewed and pushed this, after making some changes so that the
switch works in pg_restore as well, and minor cosmetic adjustments.
The changes in t/002_pg_dump.pl largely failed to apply,
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> So are we at a consensus yet?
> You had me at "make public less special", I was just trying to make sure
> we all understand what that means.
> +1 from me for moving forward.
Applying this patch will leave us with the original pg_
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Fair point, but doesn't it apply equally to non-default ACLs on any
> >> other system objects? If you tweaked the permissions on say pg_ls_dir(),
> >> then dump, then tweak them so
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Fair point, but doesn't it apply equally to non-default ACLs on any
>> other system objects? If you tweaked the permissions on say pg_ls_dir(),
>> then dump, then tweak them some more, you're going to get uncertain
>> results if yo
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> No, if you have a nondefault ACL, that will still get applied. This
> >> arrangement would drop comment changes, but I can't get excited about
> >> that; it's certainly far less of
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> No, if you have a nondefault ACL, that will still get applied. This
>> arrangement would drop comment changes, but I can't get excited about
>> that; it's certainly far less of an inconvenience in that scenario
>> than dumping the
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm afraid we may still get some push-back from existing users of
> > --clean since, with the change you're proposing, we wouldn't be cleaning
> > up anything that's been done to the public schema when it comes to
> > comment
Stephen Frost writes:
> I'm afraid we may still get some push-back from existing users of
> --clean since, with the change you're proposing, we wouldn't be cleaning
> up anything that's been done to the public schema when it comes to
> comment changes or ACL changes, right?
No, if you have a nond
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> In further testing of that, I noticed that it made the behavior of our
> >> other bugaboo, the public schema, rather inconsistent. With this
> >> builtin-extensions hack, the plpgs
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> In further testing of that, I noticed that it made the behavior of our
>> other bugaboo, the public schema, rather inconsistent. With this
>> builtin-extensions hack, the plpgsql extension doesn't get dumped,
>> whether or not you
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > I went looking and realized that actually what we're interested in here
> > is the plpgsql extension, not the plpgsql language ... and in fact the
> > behavior I was thinking of is already there, except for some reason it's
> > only applie
I wrote:
> I went looking and realized that actually what we're interested in here
> is the plpgsql extension, not the plpgsql language ... and in fact the
> behavior I was thinking of is already there, except for some reason it's
> only applied during binary upgrade. So I think we should give ser
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> The most obvious hack is just to exclude PL objects with OIDs below 16384
>> from the dump. An issue with that is that it'd lose any nondefault
>> changes to the ACL for plpgsql, which seems like a problem. On the
>> other hand, I
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> > On Monday, January 22, 2018, Stephen Frost wrote:
> >> In the end, I feel like this patch has actually been through the ringer
> >> and back because it was brought up in the context of solving a problem
> >> that we'd all like to fix in a better way
> On Monday, January 22, 2018, Stephen Frost wrote:
>> In the end, I feel like this patch has actually been through the ringer
>> and back because it was brought up in the context of solving a problem
>> that we'd all like to fix in a better way. Had it been simply dropped
>> on us as a "I'd like
Robert, all,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Aug 7, 2017 at 11:14 AM, Fabrízio de Royes Mello
> wrote:
> > I also test against all current supported versions (9.2 ... 9.6) and didn't
> > find any issue.
> >
> > Changed status to "ready for commiter".
>
> On a very fast rea
On Wed, Nov 29, 2017 at 5:50 AM, Robert Haas wrote:
> On Mon, Aug 7, 2017 at 11:14 AM, Fabrízio de Royes Mello
> wrote:
>> I also test against all current supported versions (9.2 ... 9.6) and didn't
>> find any issue.
>>
>> Changed status to "ready for commiter".
>
> On a very fast read this patc
On Mon, Aug 7, 2017 at 11:14 AM, Fabrízio de Royes Mello
wrote:
> I also test against all current supported versions (9.2 ... 9.6) and didn't
> find any issue.
>
> Changed status to "ready for commiter".
On a very fast read this patch looks OK to me, but I'm a bit concerned
about whether we have
30 matches
Mail list logo
