Обсуждение: Disabling function validation
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Peter Eisentraut wrote:
> >> Given that new languages don't tend to appear out of the blue, I think
> >> it's reasonable to design the feature considering the languages currently
> >> available.
>
> I think that position is sufficiently rebutted by Bruce's observation:
>
> > Once we put a GUC value in a dump, we have to keep that parameter valid
> > almost forever.
>
> Since we are inventing this thing specifically to put it in dump files,
> we had better take a very long-term view of its purposes.
>
> >> None of these languages except the
> >> first two have anything to gain, but everything to lose, if they were
> >> asked not to check the function body during a dump restore.
>
> That's why the code leaves it up to the individual validator routine how
> much to check or not check depending on the flag setting. I have no
> problem with an individual language deciding that it should or shouldn't
> do a particular check. I do think that we'd be foolish to make advance
> judgements about what those decisions will be.
>
> Bottom line is that I wouldn't object to changing the switch name to
> something more general ("restore_validation_mode", maybe?) but I think
> that changing it to something more specific would be a mistake in the
> long run.
[ Moved to hackers.]
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.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> 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
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> 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 pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
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 peter_e@gmx.net
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> 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
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...
Bruce Momjian <pgman@candle.pha.pa.us> 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
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> 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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: >Bruce Momjian <pgman@candle.pha.pa.us> 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.
Matthew T. O'Connor wrote: > Tom Lane wrote: > > >Bruce Momjian <pgman@candle.pha.pa.us> 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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073