Re: [HACKERS] Disabling function validation
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Should we add a variable that is set from the dump filew that identifies the version of PostgreSQL that generated the dump? SET dumped_version = 7.3 Is that identifying the backend version, or the pg_dump version? Without a solid rationale for this, I'd rather not do it. Why not both? I would also think this info could be used in pg_restore in some way at some point. Even if if can't, wouldn't it be worth it just for debugging purposes. Knowing for sure what the backend and pg_dump versions were could be helpful. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Disabling function validation
Matthew T. O'Connor wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Should we add a variable that is set from the dump filew that identifies the version of PostgreSQL that generated the dump? SET dumped_version = 7.3 Is that identifying the backend version, or the pg_dump version? Without a solid rationale for this, I'd rather not do it. Why not both? I would also think this info could be used in pg_restore in some way at some point. Even if if can't, wouldn't it be worth it just for debugging purposes. Knowing for sure what the backend and pg_dump versions were could be helpful. My guess was that this information would allow us to change the behavior of PostgreSQL in the future but allow older dumps to still load. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Disabling function validation
Bruce Momjian writes: I think we should change the check_function_bodies to something more general. I like restore_validation_mode because it could also be used to disable foreign key checks which we are discussing. An even more general idea would be to have something like restore_mode, and perhaps could handle cases like allowing a larger sort_mem or other optimizations during restore. I also like this approach (independent of whether foreign keys should be one of its applications). It gives us more freedom to open and close these types of holes when new issues arise or pg_dump improves. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Disabling function validation
Peter Eisentraut wrote: Bruce Momjian writes: I think we should change the check_function_bodies to something more general. I like restore_validation_mode because it could also be used to disable foreign key checks which we are discussing. An even more general idea would be to have something like restore_mode, and perhaps could handle cases like allowing a larger sort_mem or other optimizations during restore. I also like this approach (independent of whether foreign keys should be one of its applications). It gives us more freedom to open and close these types of holes when new issues arise or pg_dump improves. Should we add a variable that is set from the dump filew that identifies the version of PostgreSQL that generated the dump? SET dumped_version = 7.3 or something like that. We could test it in the PostgreSQL backend code in case we have to handle something differently. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Disabling function validation
Should we add a variable that is set from the dump filew that identifies the version of PostgreSQL that generated the dump? SET dumped_version = 7.3 With something like that, does it have to be reissued after every \connect in the dump? Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Disabling function validation
On Tue, 2003-10-07 at 21:31, Christopher Kings-Lynne wrote: Should we add a variable that is set from the dump filew that identifies the version of PostgreSQL that generated the dump? SET dumped_version = 7.3 With something like that, does it have to be reissued after every \connect in the dump? Heh.. what \connect ;) I believe those have been replaced with SET SESSION_AUTHORIZATION... signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Disabling function validation
Bruce Momjian [EMAIL PROTECTED] writes: Should we add a variable that is set from the dump filew that identifies the version of PostgreSQL that generated the dump? SET dumped_version = 7.3 Is that identifying the backend version, or the pg_dump version? Without a solid rationale for this, I'd rather not do it. regards, tom lane ---(end of broadcast)--- TIP 3: 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
Re: [HACKERS] Disabling function validation
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Should we add a variable that is set from the dump filew that identifies the version of PostgreSQL that generated the dump? SET dumped_version = 7.3 Is that identifying the backend version, or the pg_dump version? Without a solid rationale for this, I'd rather not do it. Uh, not sure --- whichever one is more useful, I guess. Just an idea. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Disabling function validation
Bruce Momjian [EMAIL PROTECTED] writes: I think we should change the check_function_bodies to something more general. I like restore_validation_mode because it could also be used to disable foreign key checks which we are discussing. I think I'd prefer to keep foreign key check disabling separate. Or at least make it separately selectable. Maybe validation_mode could have multiple levels (off, safe, risky)? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Disabling function validation
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I think we should change the check_function_bodies to something more general. I like restore_validation_mode because it could also be used to disable foreign key checks which we are discussing. I think I'd prefer to keep foreign key check disabling separate. Or at least make it separately selectable. Maybe validation_mode could have multiple levels (off, safe, risky)? Makes sense. Function bodies will be validated anyway when they are run, while foreign keys would not. Shame we can't disable fsync per backend. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
