Re: Integer input functions for date and timestamp
От | Peter Geoghegan |
---|---|
Тема | Re: Integer input functions for date and timestamp |
Дата | |
Msg-id | AANLkTimRjEQH+RpVqNy2c=wjjH8Gt_JyKaf-N39v2xkk@mail.gmail.com обсуждение исходный текст |
Ответ на | Integer input functions for date and timestamp (Brendan Jurd <direvus@gmail.com>) |
Ответы |
Re: Integer input functions for date and timestamp
|
Список | pgsql-hackers |
On 22 October 2010 19:45, Brendan Jurd <direvus@gmail.com> wrote: > Hi folks, > > In my own databases, I've been using a couple of C functions that > might be useful to the wider community. > > They are very simple date/timestamp constructors that take integers as > their arguments. Nothing fancy, but very convenient and *much* faster > than using a SQL or PL/pgSQL workaround. > > The offering is analogous to mktime() in C/PHP, the standard datetime > constructors in Python, and Perl's Time::Local. The function > signatures pretty much speak for themselves: > > date(year int, month int, day int) returns date > datetime(year int, month int, day int, hour int, minute int, second > int) returns timestamp > > Without these functions (or some variation), a user wishing to > construct a date from integers can only assemble the date into a > string and then put that string through postgres' datetime parser, > which is totally perverse. > > Is there any interest in adding this to core, or failing that, > contrib? If so I'd be happy to provide a patch including the > functions themselves and some attendant documentation. > > I'm not wedded to the function names or argument order, and I realise > a fully realised offering would need to include a variant for > 'timestamp with time zone'. What's wrong with to_timestamp() and to_date()? Sure, your functions might be marginally faster, but I don't think that it's likely to be a very performance sensitive area. -- Regards, Peter Geoghegan
В списке pgsql-hackers по дате отправления: