Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle
От | Ron Mayer |
---|---|
Тема | Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle |
Дата | |
Msg-id | 4915AC0A.9070608@cheapcomplexdevices.com обсуждение исходный текст |
Ответ на | Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Ron Mayer <rm_pg@cheapcomplexdevices.com> writes: >> Rather than forcing Postgres mode; couldn't it put a >> "set intervalstyle = [whatever the current interval style is]" >> in the dump file? > > This would work for loading into a PG >= 8.4 server, and fail miserably > for loading into pre-8.4 servers. Even though we don't guarantee > backwards compatibility of dump files, I'm loath to adopt a solution > that will successfully load wrong data into an older server. How is the case different from standard_conforming_strings; where ISTM depending on postgresql.conf 8.4 will happily dump either SET standard_conforming_strings = off; ... INSERT INTO dumptest VALUES ('\\\\'); or SET standard_conforming_strings = on; ... INSERT INTO dumptest VALUES ('\\'); and AFAICT the latter will happily load wrong data into 8.1 with only the error message ERROR: parameter "standard_conforming_strings" cannot be changed I imagine the use-case for "standard_conforming_strings = 0 " and "intervalstyle = sql_standard" are petty similar as well. I wonder if the best solution is that any dump file with standard_conforming_strings=on include some SQL that will refuse to load in pre-8.2 systems; and that any dump file with intervalstyle=sql_standard refuse to load in pre-8.4 systems. It seems pretty easy to add a sql fragment that checks version() and put that in the beginning of a dump file that uses these GUCs to enforce this.
В списке pgsql-hackers по дате отправления: