On 2020-Mar-19, Daniel Gustafsson wrote:
> Moving this patch to Ready for Committer.
Thanks, pushed.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> On 15 Jan 2020, at 00:04, Alvaro Herrera wrote:
>
> On 2020-Jan-14, Tom Lane wrote:
>
>> I can't get terribly excited about persuading that test to cover this
>> trivial little bit of logic, but if you are, I won't stand in the way.
>
> Hmm, that's a good point actually: the patch changed
On 2020-Jan-14, Tom Lane wrote:
> I can't get terribly excited about persuading that test to cover this
> trivial little bit of logic, but if you are, I won't stand in the way.
Hmm, that's a good point actually: the patch changed several places to
inject the FOREIGN keyword, so in order to cover
Alvaro Herrera writes:
>> On Mon, Jan 13, 2020 at 7:52 PM Tom Lane wrote:
>>> Isn't the change in the TAP test output sufficient?
> Yeah, I think there should be at least one regexp in t/002_pg_dump.pl to
> verify ALTER FOREIGN TABLE is being produced.
> I wonder if Tom is thinking about Luis'
On 2020-Jan-14, vignesh C wrote:
> On Mon, Jan 13, 2020 at 7:52 PM Tom Lane wrote:
> >
> > vignesh C writes:
> > > On Thu, Sep 26, 2019 at 7:17 PM Luis Carril
> > > wrote:
> > >>> Your patch is failing the pg_dump TAP tests. Please use
> > >>> configure --enable-tap-tests, fix the problems,
On Mon, Jan 13, 2020 at 7:52 PM Tom Lane wrote:
>
> vignesh C writes:
> > On Thu, Sep 26, 2019 at 7:17 PM Luis Carril wrote:
> >>> Your patch is failing the pg_dump TAP tests. Please use
> >>> configure --enable-tap-tests, fix the problems, then resubmit.
>
> >> Fixed, I've attached a new
On 2020-Jan-11, Tomas Vondra wrote:
> Hi,
>
> On Thu, Sep 26, 2019 at 01:47:28PM +, Luis Carril wrote:
> >
> > I don't disagree with adding FOREIGN, though.
> >
> > Your patch is failing the pg_dump TAP tests. Please use
> > configure --enable-tap-tests, fix the problems, then resubmit.
>
vignesh C writes:
> On Thu, Sep 26, 2019 at 7:17 PM Luis Carril wrote:
>>> Your patch is failing the pg_dump TAP tests. Please use
>>> configure --enable-tap-tests, fix the problems, then resubmit.
>> Fixed, I've attached a new version.
> Will it be possible to add a test case for this, can
On Thu, Sep 26, 2019 at 7:17 PM Luis Carril wrote:
>
>
> I don't disagree with adding FOREIGN, though.
>
> Your patch is failing the pg_dump TAP tests. Please use
> configure --enable-tap-tests, fix the problems, then resubmit.
>
> Fixed, I've attached a new version.
Will it be possible to add
Hi,
On Thu, Sep 26, 2019 at 01:47:28PM +, Luis Carril wrote:
I don't disagree with adding FOREIGN, though.
Your patch is failing the pg_dump TAP tests. Please use
configure --enable-tap-tests, fix the problems, then resubmit.
Fixed, I've attached a new version.
This seems like a
I don't disagree with adding FOREIGN, though.
Your patch is failing the pg_dump TAP tests. Please use
configure --enable-tap-tests, fix the problems, then resubmit.
Fixed, I've attached a new version.
Cheers
Luis M Carril
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
On 2019-Jul-12, Luis Carril wrote:
> Hello,
> pg_dump creates plain ALTER TABLE statements even if the table is a
> foreign table, which for someone reading the dump is confusing.
> This also made a difference when applying the dump if there is any plugin
> installed that hooks on
Hello,
pg_dump creates plain ALTER TABLE statements even if the table is a foreign
table, which for someone reading the dump is confusing.
This also made a difference when applying the dump if there is any plugin
installed that hooks on ProcessUtility, because the plugin could react
13 matches
Mail list logo
