dump / restore functionality
At risk of being chastised for reviving old issues, I was wondering,
what are the chances were of getting the dump / restore selectivity into
8.2 ? I am referring to the idea that, instead of the current 2 parts, a
dump could be broken up into 3 parts, namely tables, data and everything
else, so that data from one dump could be mixed and matched with schema
defs from another dump easily and scriptably.
I think the previous discussion concluded that the functionality would
be best implemented as a selective restore, rather than a breakable dump
due to the risk of inconsistent restores, so you could restore just the
tables, data or "everything else" components from a given dump.
Did this item make it onto the to-do list? If so, did anyone pick this
up or will I be waiting until a future as-yet-undefined date?
More generally, is there a publicly accessible place one can see the
to-do items, who has adopted which ones and what the status is on them?
Sorry for asking this, but I am still a rather new participant in here.
Am Dienstag, 12. September 2006 15:22 schrieb Naz Gassiep:
At risk of being chastised for reviving old issues, I was wondering,
what are the chances were of getting the dump / restore selectivity into
8.2 ?
Zero, because feature freeze is over.
Did this item make it onto the to-do list? If so, did anyone pick this
up or will I be waiting until a future as-yet-undefined date?
If you find this feature interesting, you are free to drive the development
yourself, independent of it appearing on any list. To avoid tears later on,
look for a consensus about the merit of the feature first, though.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Zero, because feature freeze is over.
Aah yes, fair enough
If you find this feature interesting, you are free to drive the development
yourself, independent of it appearing on any list. To avoid tears later on,
look for a consensus about the merit of the feature first, though
This has been discussed already, and there was a not insignificant
amount of support from it, IIRC Tom Lane agreed that such functionality
would be useful.
Tom, are you aware if this item made it onto the to-do list?
Naz Gassiep <naz@mira.net> writes:
At risk of being chastised for reviving old issues, I was wondering,
what are the chances were of getting the dump / restore selectivity into
8.2 ?
None, but feel free to start coding for 8.3.
I am referring to the idea that, instead of the current 2 parts, a
dump could be broken up into 3 parts, namely tables, data and everything
else, so that data from one dump could be mixed and matched with schema
defs from another dump easily and scriptably.
That seems like a rather spectacular overstatement of the likely
benefits, not to mention a misdescription of what was discussed.
AFAIR what was discussed was separating
- schema stuff needed before loading data
- table data
- schema stuff needed after loading data
where the last category boils down to "indexes and then foreign keys".
All the "other stuff" such as functions really needs to be in the
first part ... or at least there's no visible benefit to delaying
loading it.
regards, tom lane
That seems like a rather spectacular overstatement of the likely
benefits, not to mention a misdescription of what was discussed.AFAIR what was discussed was separating
Yes, that is what was discussed.
- schema stuff needed before loading data
- table data
- schema stuff needed after loading data
where the last category boils down to "indexes and then foreign keys".
All the "other stuff" such as functions really needs to be in the
first part ... or at least there's no visible benefit to delaying
loading it.
Right. This breakdown I still think would be useful. An additional item
that would be useful is to allow pg_restore to restore plain text dumps.
Sincerely,
Joshua D. Drake
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
None, but feel free to start coding for 8.3.My coding skills are still nascent, but I shall do my best.
My coding skills are still pretty nascent, but I shall do my best.
That seems like a rather spectacular overstatement of the likely
benefits, not to mention a misdescription of what was discussed.
Once again I get pulled over by the semantics police :) Yes, you are
right, that's what was discussed, and that is the functionality I am
hoping for, as it would allow scripting the merging of a schema from one
database with the table data from another.
Did this make it into the to-do list for 8.3 ?
Naz Gassiep wrote:
None, but feel free to start coding for 8.3.My coding skills are still
nascent, but I shall do my best.My coding skills are still pretty nascent, but I shall do my best.
That seems like a rather spectacular overstatement of the likely
benefits, not to mention a misdescription of what was discussed.Once again I get pulled over by the semantics police :) Yes, you are
right, that's what was discussed, and that is the functionality I am
hoping for, as it would allow scripting the merging of a schema from one
database with the table data from another.Did this make it into the to-do list for 8.3 ?
Don't worry about the to-do list too much. If you care about it, post a
patch; if you keep a link to the archives pointing at this discussion,
you can later bang us over our heads if we reject the patch.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
Naz Gassiep wrote:
Did this make it into the to-do list for 8.3 ?
Don't worry about the to-do list too much.
In particular, if you're imagining that being in the TODO list will
in itself cause anyone to work on it, you're much mistaken about this
community operates. Scratching your own itch is the general rule.
regards, tom lane
Hi, Tom,
Tom Lane wrote:
AFAIR what was discussed was separating
- schema stuff needed before loading data
- table data
- schema stuff needed after loading data
where the last category boils down to "indexes and then foreign keys".
All the "other stuff" such as functions really needs to be in the
first part ... or at least there's no visible benefit to delaying
loading it.
I agree, it has to be in the first part, especially as data types and
input functions needed for the table definitions and table data may be
defined therein.
HTH,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org
Tom Lane wrote:
Alvaro Herrera <alvherre@commandprompt.com> writes:
Naz Gassiep wrote:
Did this make it into the to-do list for 8.3 ?
Don't worry about the to-do list too much.
In particular, if you're imagining that being in the TODO list will
in itself cause anyone to work on it, you're much mistaken about this
community operates. Scratching your own itch is the general rule.
I can add it to the TODO list if people want it. The original
discussion seemed rather unfocused for me to add it to TODO.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +