Re: Proposed patch: make SQL interval-literal syntax work per spec
От | Ron Mayer |
---|---|
Тема | Re: Proposed patch: make SQL interval-literal syntax work per spec |
Дата | |
Msg-id | 48C9AE52.1020000@cheapcomplexdevices.com обсуждение исходный текст |
Ответ на | Re: Proposed patch: make SQL interval-literal syntax work per spec (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proposed patch: make SQL interval-literal syntax work per spec
|
Список | pgsql-hackers |
Tom Lane wrote: > Ron Mayer <rm_pg@cheapcomplexdevices.com> writes: >> Back a while ago (2003) there was some talk about replacing >> some of the non-standard extensions with shorthand forms of >> intervals with ISO 8601 intervals that have a similar but >> not-the-same shorthand. > > I think *replacement* would be a hard sell, as that would tick off all > the existing users ;-). Now it seems like being able to accept either I originally submitted a patch that supported both, and I think you suggested replacing on the grounds that the old one was never documented, http://archives.postgresql.org/pgsql-patches/2003-09/msg00134.php "If we're going to support the real ISO spec, I'd suggestripping out any not-quite-there variant. http://archives.postgresql.org/pgsql-patches/2003-09/msg00121.php "I doubt anyone is using it, because it's completely undocumented." On the other hand, the company I was at was indeed originally using it, so I prefer that it stay in as well. Perhaps if there's a way to mark them as deprecated and post warnings in the log file if they're used. I think they should be removed eventually in a few releases, because they're quite confusing as they stand: Interval ISO Postgres 8601 shorthand ----------------------------------------------------- '1 year 1 minute' 'P1YT1M' '1Y1M' '1 year 1 month' 'P1Y1M' N/A > the 8601 syntax or the existing syntaxes on input wouldn't be tough > at all, if you insist on the P prefix to distinguish; so that end of ISO 8601 seems to me to require the P, so I think we would. > it should be easy enough. On the output side, seems like a GUC variable > is the standard precedent here. I'd still vote against overloading > DateStyle --- it does too much already --- but a separate variable for > interval style wouldn't bother me. In fact, given that we are now > somewhat SQL-compliant on interval input, a GUC that selected > PG traditional, SQL-standard, or ISO 8601 interval output format seems > like it could be a good idea. Great. I'm bringing my patch up-to-date with CVS now and adding the separate GUC.
В списке pgsql-hackers по дате отправления: