On Thu, May 11, 2017 at 9:33 AM, Tom Lane wrote:
> Uh ... what in that is creating the already-extant parent?
/me looks embarrassed.
Never mind. I didn't read what you wrote carefully enough.
>> I think one answer to the original complaint might be to add a new
>> flag to pg_dump, something li
Robert Haas writes:
> On Thu, May 11, 2017 at 9:02 AM, Tom Lane wrote:
>> You could argue that it would be better for pg_dump to emit something
>> like
>>
>> CREATE TABLE c (...);
>> ALTER TABLE c INHERIT p;
>>
>> so that if p isn't around, at least c gets created. And I think it
>> *would* be
On Thu, May 11, 2017 at 9:02 AM, Tom Lane wrote:
> Jeevan Ladhe writes:
>> On Thu, May 11, 2017 at 4:47 PM, Ashutosh Bapat <
>>> We add PARTITION OF clause for a table which is partition, so if the
>>> parent is not present while restoring, the restore is going to fail.
>
>> +1
>> But, similarly
Jeevan Ladhe writes:
> On Thu, May 11, 2017 at 4:47 PM, Ashutosh Bapat <
>> We add PARTITION OF clause for a table which is partition, so if the
>> parent is not present while restoring, the restore is going to fail.
> +1
> But, similarly for inheritance if we dump a child table, it's dump is
> b
On Thu, May 11, 2017 at 4:47 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
> We add PARTITION OF clause for a table which is partition, so if the
> parent is not present while restoring, the restore is going to fail.
+1
But, similarly for inheritance if we dump a child table, it
On Thu, May 11, 2017 at 3:05 AM, Tom Lane wrote:
>
> We should make sure that pg_dump behaves sanely when dumping just
> some elements of a partition tree, of course. And for that matter,
> pg_restore ought to be able to successfully restore just some elements
> out of a an archive containing mo
On Thu, May 11, 2017 at 2:06 AM, Robert Haas wrote:
> On Tue, May 9, 2017 at 4:21 AM, Jeevan Ladhe
> wrote:
>>> Current pg_dump --exclude-table option excludes partitioned relation
>>> and dumps all its child relations and vice versa for --table option, which
>>> I think is incorrect.
>>>
>>> In
Robert Haas writes:
> On Tue, May 9, 2017 at 4:21 AM, Jeevan Ladhe
> wrote:
>> Also, I can see similar issue exists with inheritance.
> That's a pretty insightful comment which makes me think that this
> isn't properly categorized as a bug. Table partitioning is based on
> inheritance and is in
On Tue, May 9, 2017 at 4:21 AM, Jeevan Ladhe
wrote:
>> Current pg_dump --exclude-table option excludes partitioned relation
>> and dumps all its child relations and vice versa for --table option, which
>> I think is incorrect.
>>
>> In this case we might need to explore all partitions and exclude
On Tue, May 9, 2017 at 3:51 PM, Ashutosh Bapat
wrote:
> On Tue, May 9, 2017 at 2:59 PM, Amit Langote
> wrote:
>> Hi Amul,
>>
>> On 2017/05/09 16:13, amul sul wrote:
>>> Hi,
>>>
>>> Current pg_dump --exclude-table option excludes partitioned relation
>>> and dumps all its child relations and vice
On Tue, May 9, 2017 at 2:59 PM, Amit Langote
wrote:
> Hi Amul,
>
> On 2017/05/09 16:13, amul sul wrote:
>> Hi,
>>
>> Current pg_dump --exclude-table option excludes partitioned relation
>> and dumps all its child relations and vice versa for --table option, which
>> I think is incorrect.
>
> I agr
Hi Amit, Ashutosh,
On Tue, May 9, 2017 at 3:29 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Tue, May 9, 2017 at 3:13 PM, Amit Langote
> wrote:
> > On 2017/05/09 17:21, Jeevan Ladhe wrote:
> >> On Tue, May 9, 2017 at 12:43 PM, amul sul wrote:
> >>> Current pg_dump --exclude-
On Tue, May 9, 2017 at 3:13 PM, Amit Langote
wrote:
> On 2017/05/09 17:21, Jeevan Ladhe wrote:
>> On Tue, May 9, 2017 at 12:43 PM, amul sul wrote:
>>> Current pg_dump --exclude-table option excludes partitioned relation
>>> and dumps all its child relations and vice versa for --table option, whic
On 2017/05/09 17:21, Jeevan Ladhe wrote:
> On Tue, May 9, 2017 at 12:43 PM, amul sul wrote:
>> Current pg_dump --exclude-table option excludes partitioned relation
>> and dumps all its child relations and vice versa for --table option, which
>> I think is incorrect.
>>
>> In this case we might nee
On Tue, May 9, 2017 at 12:43 PM, amul sul wrote:
> Hi,
>
> Current pg_dump --exclude-table option excludes partitioned relation
> and dumps all its child relations and vice versa for --table option, which
> I think is incorrect.
>
> In this case we might need to explore all partitions and exclude
Hi Amul,
On 2017/05/09 16:13, amul sul wrote:
> Hi,
>
> Current pg_dump --exclude-table option excludes partitioned relation
> and dumps all its child relations and vice versa for --table option, which
> I think is incorrect.
I agree that `pg_dump -t partitioned_table` should dump all of its
par
In my last email by mistake I attached Amul's patch itself.
Please find attached patch extending the fix to inheritance relations.
Regards,
Jeevan Ladhe
On Tue, May 9, 2017 at 1:51 PM, Jeevan Ladhe
wrote:
> Hi,
>
> On Tue, May 9, 2017 at 12:43 PM, amul sul wrote:
>
>> Hi,
>>
>> Current pg_dump
Hi,
On Tue, May 9, 2017 at 12:43 PM, amul sul wrote:
> Hi,
>
> Current pg_dump --exclude-table option excludes partitioned relation
> and dumps all its child relations and vice versa for --table option, which
> I think is incorrect.
>
> In this case we might need to explore all partitions and ex
On Wed, Mar 4, 2015 at 2:03 PM, Michael Paquier
wrote:
> On Wed, Mar 4, 2015 at 6:48 AM, Peter Eisentraut wrote:
>> - set up basic scaffolding for TAP tests in src/bin/pg_dump
>
> Agreed.
>
>> - write a Perl function that can create an extension on the fly, given
>> name, C code, SQL code
>
> I a
On Wed, Mar 4, 2015 at 6:48 AM, Peter Eisentraut wrote:
> - set up basic scaffolding for TAP tests in src/bin/pg_dump
Agreed.
> - write a Perl function that can create an extension on the fly, given
> name, C code, SQL code
I am perplex about that. Where would the SQL code or C code be stored?
On 3/1/15 2:17 PM, Stephen Frost wrote:
> Peter, if you have a minute, could you take a look at this thread and
> discussion of having TAP tests under src/test/modules which need to
> install an extension? I think it's something we certainly want to
> support but I'm not sure it's a good idea to j
On Tue, Mar 3, 2015 at 4:57 AM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Mon, Mar 2, 2015 at 6:27 AM, Stephen Frost wrote:
>> > Please see the latest version of this, attached. I've removed the left
>> > join, re-used the 'query' buffer (instead of destro
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Mon, Mar 2, 2015 at 6:27 AM, Stephen Frost wrote:
> > Please see the latest version of this, attached. I've removed the left
> > join, re-used the 'query' buffer (instead of destroying and recreating
> > it), and added a bit of documentati
On Mon, Mar 2, 2015 at 6:27 AM, Stephen Frost wrote:
> Please see the latest version of this, attached. I've removed the left
> join, re-used the 'query' buffer (instead of destroying and recreating
> it), and added a bit of documentation, along with a note in the commit
> message for the release
Michael,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
> > The thing is that we must absolutely wait for *all* the TableInfoData
> > of all the extensions to be created because we need to mark the
> > dependencies between them, and even my last
Michael,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
> > >> Subject: [PATCH 2/3] Make prove_check install contents of current
> > >> directory as well
> > >
> > > This is really an independent thing, no? I don't see any particular
> > > prob
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> >> Subject: [PATCH 2/3] Make prove_check install contents of current
> >> directory as well
> >
> > This is really an independent thing, no? I don't see any particular
> > problem with it, for my part.
>
> Yes, that's an independen
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> The thing is that we must absolutely wait for *all* the TableInfoData
> of all the extensions to be created because we need to mark the
> dependencies between them, and even my last patch, or even with what
> you are proposing we may
On Sun, Mar 1, 2015 at 1:09 AM, Stephen Frost wrote:
> Michael,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> + /*
>> + * Query all the foreign key dependencies for all the
>> extension
>> + * tables found previously. Onl
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> + /*
> + * Query all the foreign key dependencies for all the
> extension
> + * tables found previously. Only tables whose data need
> to be
> + * ha
Michael, all,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold
> wrote:
> > This is a far better patch and the test to export/import of the
> > postgis_topology extension works great for me.
> >
> > Thanks for the work.
>
> Attached is a patc
On Sat, Feb 28, 2015 at 12:29 AM, Gilles Darold
wrote:
> Le 26/02/2015 12:41, Michael Paquier a écrit :
>> On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold
>> wrote:
>>> This is a far better patch and the test to export/import of the
>>> postgis_topology extension works great for me.
>>>
>>> Thank
On Thu, Feb 26, 2015 at 08:41:46PM +0900, Michael Paquier wrote:
> On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold
> wrote:
> > This is a far better patch and the test to export/import of the
> > postgis_topology extension works great for me.
> >
> > Thanks for the work.
>
> Attached is a patch t
Le 26/02/2015 12:41, Michael Paquier a écrit :
> On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold
> wrote:
>> This is a far better patch and the test to export/import of the
>> postgis_topology extension works great for me.
>>
>> Thanks for the work.
> Attached is a patch that uses an even better a
On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold wrote:
> This is a far better patch and the test to export/import of the
> postgis_topology extension works great for me.
>
> Thanks for the work.
Attached is a patch that uses an even better approach by querying only
once all the FK dependencies of
Le 24/02/2015 05:40, Michael Paquier a écrit :
>
>
> On Tue, Feb 24, 2015 at 2:17 AM, Gilles Darold
> mailto:gilles.dar...@dalibo.com>> wrote:
>
> Looks great to me, I have tested with the postgis_topology extension
> everything works fine.
>
>
> Actually, after looking more in depth at the
On Tue, Feb 24, 2015 at 2:17 AM, Gilles Darold
wrote:
> Looks great to me, I have tested with the postgis_topology extension
> everything works fine.
>
Actually, after looking more in depth at the internals of pg_dump I think
that both patches are wrong (did that yesterday night for another patc
Le 17/02/2015 14:44, Michael Paquier a écrit :
> On Tue, Jan 20, 2015 at 8:06 PM, Gilles Darold
> wrote:
>> Le 19/01/2015 14:41, Robert Haas a écrit :
>>> On Thu, Jan 15, 2015 at 6:26 AM, Gilles Darold
>>> wrote:
I attach a patch that solves the issue in pg_dump, let me know if it might
>>
On Tue, Jan 20, 2015 at 8:06 PM, Gilles Darold wrote:
> Le 19/01/2015 14:41, Robert Haas a écrit :
>> On Thu, Jan 15, 2015 at 6:26 AM, Gilles Darold
>> wrote:
>>> I attach a patch that solves the issue in pg_dump, let me know if it might
>>> be included in Commit Fest or if the three other solut
Le 19/01/2015 14:41, Robert Haas a écrit :
> On Thu, Jan 15, 2015 at 6:26 AM, Gilles Darold
> wrote:
>> I attach a patch that solves the issue in pg_dump, let me know if it might
>> be included in Commit Fest or if the three other solutions are a better
>> choice.
> I think a fix in pg_dump is ap
On Thu, Jan 15, 2015 at 6:26 AM, Gilles Darold wrote:
> I attach a patch that solves the issue in pg_dump, let me know if it might
> be included in Commit Fest or if the three other solutions are a better
> choice.
I think a fix in pg_dump is appropriate, so I'd encourage you to add
this to the n
On 16/01/2015 01:06, Jim Nasby wrote:
> On 1/15/15 5:26 AM, Gilles Darold wrote:
>> Hello,
>>
>> There's a long pending issue with pg_dump and extensions that have
>> table members with foreign keys. This was previously reported in this
>> thread
>> http://www.postgresql.org/message-id/ca+tgmoyvzka
On 1/15/15 5:26 AM, Gilles Darold wrote:
Hello,
There's a long pending issue with pg_dump and extensions that have table
members with foreign keys. This was previously reported in this thread
http://www.postgresql.org/message-id/ca+tgmoyvzkadmgh_8el7uvm472geru0b4pnnfjqye6ss1k9...@mail.gmail.co
Alvaro Herrera writes:
> Excerpts from Joel Jacobson's message of jue ene 13 06:31:06 -0300 2011:
>> The example from Tom Lane below results in a database which is not
>> possible to correctly dump using pg_dump.
> I wouldn't care too much about that particular case -- you can't query
> any of th
Excerpts from Joel Jacobson's message of jue ene 13 06:31:06 -0300 2011:
> The example from Tom Lane below results in a database which is not
> possible to correctly dump using pg_dump.
I wouldn't care too much about that particular case -- you can't query
any of the views either.
--
Álvaro Herr
* Joel Jacobson wrote:
The example from Tom Lane below results in a database which is not
possible to correctly dump using pg_dump.
The view v1 strangely becomes a table in the dump output?!
This is no bug, it's a feature (tm).
pg_dump is clever enough to detect the circular dependency and b
On 2011-01-13 11:31 AM +0200, Joel Jacobson wrote:
The example from Tom Lane below results in a database which is not
possible to correctly dump using pg_dump.
The view v1 strangely becomes a table in the dump output?!
CREATE RULE "_RETURN" AS ON SELECT TO v1 DO INSTEAD SELECT v2.f1, v2.f2 FR
Actually, scratch that - I'm wrong... It appeared separately from the
other DROP commands...
Chris
Christopher Kings-Lynne wrote:
Hi,
Playing around with this MySQL compatibility library, I noticed that
pg_dump -c does not emit DROP commands for casts. Seems like a bug...?
Chris
---
So what are we going to do about this problem?
The pg_settings view does not have enough information to determine it
generically. (It only says 'string', not 'list'...)
I propose that we modify pg_dumpall to hard-code the set of list-type
GUC variables for each backend version.
The current (CV
As part of my testing, I noticed this bug. My database has a
search_path set in the database vars. It dumps lik ethis:
DROP DATABASE usa;
CREATE DATABASE usa WITH TEMPLATE = template0 OWNER = usadmin ENCODING =
'LATIN1';
ALTER DATABASE usa SET search_path TO 'public, contrib';
Notice the sing
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Is a fix for this required for only search_path, or is it a more general
> problem?
I think this has to be driven off the GUC_LIST_INPUT and/or
GUC_LIST_QUOTE flag bits (too late at night to remember just what those
two flags do, but one or bo
ssage -
From: "Bruno Wolff III" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>
Cc: "Darko Prenosil" <[EMAIL PROTECTED]>; "PostgreSQL Development"
<[EMAIL PROTECTED]>
Sent: Thursday, May 06, 2004 6:41 PM
Subject: Re: [H
On Thu, May 06, 2004 at 10:17:31 -0400,
Rod Taylor <[EMAIL PROTECTED]> wrote:
> > CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT
> > nextval('doc.seq_doc_id'::text)
> > CONSTRAINT cnst_chk_doc_id CHECK ( fn_chk_doc_id(VALUE) ) ;
> >
> > I did not notice any similar error report on the
Rod Taylor <[EMAIL PROTECTED]> writes:
>> CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT
>> nextval('doc.seq_doc_id'::text)
>> CONSTRAINT cnst_chk_doc_id CHECK ( fn_chk_doc_id(VALUE) ) ;
> It comes out right for me in 7.4.2.
AFAICT the relevant fix was well before 7.4 release:
2003-10-04 1
> CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT
> nextval('doc.seq_doc_id'::text)
> CONSTRAINT cnst_chk_doc_id CHECK ( fn_chk_doc_id(VALUE) ) ;
>
> I did not notice any similar error report on the list, so I believe that this
> is not fixed yet ?
It comes out right for me in 7.4.2.
55 matches
Mail list logo
