Re: [HACKERS] dump / restore functionality
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] 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 [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] dump / restore functionality
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 TrackingTracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] 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. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] dump / restore functionality
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/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] dump / restore functionality
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? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] dump / restore functionality
Naz Gassiep [EMAIL PROTECTED] 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 ---(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
Re: [HACKERS] dump / restore functionality
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/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] dump / restore functionality
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 ? ---(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
Re: [HACKERS] dump / restore functionality
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 Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] dump / restore functionality
Alvaro Herrera [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
