On 30 August 2011 16:40, Robert Haas wrote:
> OK, committed.
Thanks.
I'm fine with not back-patching it, on the grounds given.
Cheers,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
Robert Haas writes:
> Well, I'm fine with not back-patching it, but think the existing
> behavior is flat wrong.
I'm not arguing that this way isn't better, just that it's different.
There have been zero user complaints about this behavior since Tom
Lockhart put it in, more than ten years ago. T
On Tue, Aug 30, 2011 at 11:52 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Aug 28, 2011 at 5:39 AM, Dean Rasheed
>> wrote:
>>> The attached patch makes "today", "tomorrow" and "yesterday" only set
>>> the year, month and day fields. All the other fields are already
>>> initialised to 0
Robert Haas writes:
> On Sun, Aug 28, 2011 at 5:39 AM, Dean Rasheed
> wrote:
>> The attached patch makes "today", "tomorrow" and "yesterday" only set
>> the year, month and day fields. All the other fields are already
>> initialised to 0 at the start, and may be set non-zero before or after
>> e
On Sun, Aug 28, 2011 at 5:39 AM, Dean Rasheed wrote:
> On 28 August 2011 00:39, Robert Haas wrote:
>> On Sat, Aug 27, 2011 at 7:43 AM, Dean Rasheed
>> wrote:
>>> On 27 August 2011 12:29, Dean Rasheed wrote:
... if nothing else it has been a
fun exercise figuring out how the datetime
On 28 August 2011 00:00, Jeff MacDonald wrote:
> Greetings,
>
> On Saturday, August 27, 2011 11:36:13 AM Dean Rasheed wrote:
>>
>> I'm not sure how best to handle timezones though, since it's
>> hard-coded list probably won't match the timezones PostgreSQL knows
>> about. Maybe that doesn't matter
On 28 August 2011 00:39, Robert Haas wrote:
> On Sat, Aug 27, 2011 at 7:43 AM, Dean Rasheed
> wrote:
>> On 27 August 2011 12:29, Dean Rasheed wrote:
>>> ... if nothing else it has been a
>>> fun exercise figuring out how the datetime string parsing code works.
>>
>> While looking through the cu
On Sat, Aug 27, 2011 at 7:43 AM, Dean Rasheed wrote:
> On 27 August 2011 12:29, Dean Rasheed wrote:
>> ... if nothing else it has been a
>> fun exercise figuring out how the datetime string parsing code works.
>
> While looking through the current code, I spotted the following oddity:
>
> select
Greetings,
On Saturday, August 27, 2011 11:36:13 AM Dean Rasheed wrote:
>
> I'm not sure how best to handle timezones though, since it's
> hard-coded list probably won't match the timezones PostgreSQL knows
> about. Maybe that doesn't matter, I'm not sure.
>
It'll matter when the expression has
On 27 August 2011 14:29, Jeff MacDonald wrote:
> Greetings,
>
> On Thursday, August 25, 2011 05:39:09 AM Dean Rasheed wrote:
>> As background, I have an app that accepts user text input and casts it
>> to a timestamp in order to produce reports. I use PostgreSQL's
>> timestamp input conversion for
On 27 August 2011 14:14, Peter Eisentraut wrote:
> On lör, 2011-08-27 at 12:29 +0100, Dean Rasheed wrote:
>> So Robert and Merlin both expressed concerns that the existing
>> datetime string parsing code is so complicated that adding to it would
>> likely just introduce more bugs.
>>
>> My first t
Greetings,
On Thursday, August 25, 2011 05:39:09 AM Dean Rasheed wrote:
> As background, I have an app that accepts user text input and casts it
> to a timestamp in order to produce reports. I use PostgreSQL's
> timestamp input conversion for this, since it gives a lot of
> flexibility, and can pa
On lör, 2011-08-27 at 12:29 +0100, Dean Rasheed wrote:
> So Robert and Merlin both expressed concerns that the existing
> datetime string parsing code is so complicated that adding to it would
> likely just introduce more bugs.
>
> My first thought was 'how hard can it be?' - famous last words :-)
On 27 August 2011 12:29, Dean Rasheed wrote:
> ... if nothing else it has been a
> fun exercise figuring out how the datetime string parsing code works.
>
While looking through the current code, I spotted the following oddity:
select timestamp 'yesterday 10:30';
timestamp
-
On 27 August 2011 02:32, Robert Haas wrote:
> Frankly, our current date parsing code is pretty darn strange and
> flaky...
So Robert and Merlin both expressed concerns that the existing
datetime string parsing code is so complicated that adding to it would
likely just introduce more bugs.
My fir
On Fri, Aug 26, 2011 at 4:32 PM, Jim Nasby wrote:
> On Aug 25, 2011, at 5:08 AM, Dean Rasheed wrote:
>>> Funny you should mention intervals...
>>>
>>> timestamptz 'today' - interval '5 days'
>>> timestamptz 'now' + interval '2 hours'
>>>
>>
>> Yes, but what I am trying to achieve is a way of enter
On Aug 25, 2011, at 5:08 AM, Dean Rasheed wrote:
>> Funny you should mention intervals...
>>
>> timestamptz 'today' - interval '5 days'
>> timestamptz 'now' + interval '2 hours'
>>
>
> Yes, but what I am trying to achieve is a way of entering such
> relative timestamps using a single input value
> Yes, but what I am trying to achieve is a way of entering such
> relative timestamps using a single input value, so that absolute and
> relative timestamps can both be bound to a SQL query using just one
> variable.
I think adding a function would be the way to go then. Maybe extending
to_time
On Thu, Aug 25, 2011 at 5:08 AM, Dean Rasheed wrote:
> On 25 August 2011 10:43, Vik Reykja wrote:
>> On Thu, Aug 25, 2011 at 11:39, Dean Rasheed
>> wrote:
>>>
>>> My first thought was to have some general way of adding or subtracting
>>> an interval at the end of an input timestamp, eg. by addin
On 25 August 2011 10:43, Vik Reykja wrote:
> On Thu, Aug 25, 2011 at 11:39, Dean Rasheed
> wrote:
>>
>> My first thought was to have some general way of adding or subtracting
>> an interval at the end of an input timestamp, eg. by adding another
>> couple of special values - "plus " and "minus ".
On Thu, Aug 25, 2011 at 11:39, Dean Rasheed wrote:
> My first thought was to have some general way of adding or subtracting
> an interval at the end of an input timestamp, eg. by adding another
> couple of special values - "plus " and "minus ".
> This would allow things like:
>
> TIMESTAMPTZ 'toda
As background, I have an app that accepts user text input and casts it
to a timestamp in order to produce reports. I use PostgreSQL's
timestamp input conversion for this, since it gives a lot of
flexibility, and can parse pretty much anything the users throw at it.
It is also handy that it recogni
22 matches
Mail list logo
