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 | 4915079F.8070006@cheapcomplexdevices.com обсуждение исходный текст |
Ответ на | Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle
Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle |
Список | 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. 'k. So the options seem to be: (1) Don't output a SQL-standard interval literal for the value "negative one days and negative one hours"; perhaps by sticking an extra '+' sign in there? (2) Force pg_dump to a non-standard mode, at least until 8.3's deprecated in many years? After that, pg_dump can useany intervalstyle so long as it says which one it uses. (3) Put something into the dump file that will make the old server reject the file rather than successfully loading wrong data? (Some "if intervalstyle==std and version<8.3 abort loading the restore" logic?) I don't much like the first one, because it seems we're oh-so-close to meeting the standard. I don't know how to do the third one; but if pg_dump had an "assert(version>=8.4)" feature it might be useful if we ever had other non-backward-compatible changes. pg_dump would only put that assert-like-thing in the dump file if the sql_standard mode (or iso mode, if that gets approved) was chosen. The second one doesn't really seem that scary to me; since the uglyness can go away when we eventually stop restoring into 83.
В списке pgsql-hackers по дате отправления: