Thread: 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
loadingdata
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 solutionssince 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. +