Re: Patch for SQL-standard negative valued year-month literals
От | Tom Lane |
---|---|
Тема | Re: Patch for SQL-standard negative valued year-month literals |
Дата | |
Msg-id | 18956.1221604587@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Patch for SQL-standard negative valued year-month literals (Ron Mayer <rm_pg@cheapcomplexdevices.com>) |
Ответы |
Re: Patch for SQL-standard negative valued year-month literals
Re: Patch for SQL-standard negative valued year-month literals |
Список | pgsql-hackers |
Ron Mayer <rm_pg@cheapcomplexdevices.com> writes: > Tom Lane wrote: >> Hmm. I'm a bit concerned about possible side-effects on other cases: >> what had been seen as two separate tokens will now become one token >> for *all* datetime types, not just interval. However, I can't > If it's a concern, I could make interval_in first look for the > SQL-standard patterns before even parsing the string into fields. I don't think it's worth the trouble unless someone points out a real-world format that would be broken by the change. We certainly don't document anything that would be. I've applied a patch along these lines and we'll see if anyone complains. > If I read SQL 200N's spec correctly > select interval '-1 1:00:00'; > should mean "-1 days -1 hours", > yet 8.3 sees it as "-1 days +1 hours". I think we are kind of stuck on this one. If we change it, then how would one represent -1 days +1 hours? The spec's format is only sane if you assume all the fields must have the same sign, which is not the case for PG. > Scary to touch that one, but since a standard's a standard, I think > eventually we should get there. The SQL spec's date/time handling is, and always has been, broken enough that I feel no great compulsion to follow every last detail. Especially details that make it impossible to support our extensions... regards, tom lane
В списке pgsql-hackers по дате отправления: