On Wed, Sep 16, 2020 at 3:06 PM Michael Paquier wrote:
>
> On Tue, Sep 15, 2020 at 10:46:56AM +0200, Julien Rouhaud wrote:
> > FWIW I'm fine with those news comments!
>
> Okay, I got again on this one today and finished by committing the
> patch as of 5423853.
Thanks Michael!
On Tue, Sep 15, 2020 at 10:46:56AM +0200, Julien Rouhaud wrote:
> FWIW I'm fine with those news comments!
Okay, I got again on this one today and finished by committing the
patch as of 5423853.
--
Michael
signature.asc
Description: PGP signature
On Tue, Sep 15, 2020 at 4:48 AM Michael Paquier wrote:
>
> On Thu, Sep 10, 2020 at 02:31:32PM +0200, Daniel Gustafsson wrote:
> > Given how unintrusive this optimization is, +1 from me to go ahead with this
> > patch. pg_dump tests pass. Personally I would've updated the nearby
> > comments
> >
On Mon, Sep 14, 2020 at 10:56:01PM -0400, Tom Lane wrote:
> (Note that we disallow sub-queries in CHECK constraints, and also
> disclaim responsibility for what happens if you cheat by hiding
> the subquery in a function. So while it's certainly possible to
> build CHECK constraints that only work
Michael Paquier writes:
> On Tue, Jul 14, 2020 at 11:14:50AM +0200, Julien Rouhaud wrote:
>> Note that those extraneous queries were found while trying to dump
>> data out of a corrupted database. The issue wasn't an excessive
>> runtime but corrupted catalog entries, so bypassing this code (sinc
On Thu, Sep 10, 2020 at 02:31:32PM +0200, Daniel Gustafsson wrote:
> Given how unintrusive this optimization is, +1 from me to go ahead with this
> patch. pg_dump tests pass. Personally I would've updated the nearby comments
> to reflect why the check for dataOnly is there, but MMV there. I'm mo
On Tue, Jul 14, 2020 at 11:14:50AM +0200, Julien Rouhaud wrote:
> Note that those extraneous queries were found while trying to dump
> data out of a corrupted database. The issue wasn't an excessive
> runtime but corrupted catalog entries, so bypassing this code (since I
> was only interested in t
> On 12 Jul 2020, at 07:48, Julien Rouhaud wrote:
> Currently, getTableAttrs() always retrieves info about columns defaults and
> check constraints, while this will never be used if --data-only option if
> used.
> This seems like a waste of resources, so here's a patch to skip those parts
> when
On Sun, Jul 12, 2020 at 4:29 PM Justin Pryzby wrote:
>
> On Sun, Jul 12, 2020 at 07:48:50AM +0200, Julien Rouhaud wrote:
> > Currently, getTableAttrs() always retrieves info about columns defaults and
> > check constraints, while this will never be used if --data-only option if
> > used.
> > This
On Sun, Jul 12, 2020 at 07:48:50AM +0200, Julien Rouhaud wrote:
> Currently, getTableAttrs() always retrieves info about columns defaults and
> check constraints, while this will never be used if --data-only option if
> used.
> This seems like a waste of resources, so here's a patch to skip those
Hi,
Currently, getTableAttrs() always retrieves info about columns defaults and
check constraints, while this will never be used if --data-only option if used.
This seems like a waste of resources, so here's a patch to skip those parts
when the DDL won't be generated.
diff --git a/src/bin/pg_dump/
11 matches
Mail list logo
