On 2/27/17 4:19 AM, Artur Zakirov wrote:
> On 15.02.2017 15:26, Amul Sul wrote:
>>
>> The new status of this patch is: Ready for Committer
>>
>
> Thank you for your review!
This submission has been moved to CF 2017-07.
--
-David
da...@pgmasters.net
--
Sent via pgsql-hackers mailing list
On 15.02.2017 15:26, Amul Sul wrote:
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Review of v7 patch:
- Patch
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Review of v7 patch:
- Patch applies to the top of master HEAD
On Mon, Dec 5, 2016 at 11:35 AM, Haribabu Kommi
wrote:
> Moved to next CF with "needs review" status.
Same, this time to CF 2017-03.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mon, Nov 7, 2016 at 2:26 AM, Artur Zakirov
wrote:
>
> Hm, truly. Fixed it.
>
> I've attached the fixed patch.
>
Moved to next CF with "needs review" status.
Regards,
Hari Babu
Fujitsu Australia
Thank you for your comments,
2016-11-04 20:36 GMT+02:00 Tom Lane :
>
> Artur Zakirov writes:
> > I attached new version of the patch, which fix is_char_separator()
> > declaration too.
>
> I did some experimenting using
>
Artur Zakirov writes:
> I attached new version of the patch, which fix is_char_separator()
> declaration too.
I did some experimenting using
http://rextester.com/l/oracle_online_compiler
It appears that Oracle will consider a single space in the pattern
to match zero
On Fri, Sep 30, 2016 at 12:34 PM, Amul Sul wrote:
> The new status of this patch is: Ready for Committer
And moved to next CF with same status.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Appreciate your support.
I've tested v6 patch again, looks good
Robert Haas writes:
> On Thu, Sep 29, 2016 at 4:54 AM, amul sul wrote:
>> Commitfest status left untouched, I am not sure how to deal with
>> "Returned With Feedback" patch. Is there any chance that, this can be
>> considered again for committer review?
On Thu, Sep 29, 2016 at 4:54 AM, amul sul wrote:
> On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote:
>> Artur Zakirov writes:
>>> - now DCH_cache_getnew() is called after parse_format(). Because now
>>> parse_format() can raise an
2016-09-29 13:54 GMT+05:00 amul sul :
>
> On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote:
> >
> > I started looking at your 0001-to-timestamp-format-checking-v4.patch
> > and this point immediately jumped out at me. Currently the code relies
> > ...
On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote:
> Artur Zakirov writes:
>> - now DCH_cache_getnew() is called after parse_format(). Because now
>> parse_format() can raise an error and in the next attempt
>> DCH_cache_search() could return broken
Artur Zakirov writes:
> - now DCH_cache_getnew() is called after parse_format(). Because now
> parse_format() can raise an error and in the next attempt
> DCH_cache_search() could return broken cache entry.
I started looking at your
On Fri, Sep 16, 2016 at 10:01 PM, Artur Zakirov
wrote:
> On 25.08.2016 13:26, amul sul wrote:
>>>
>>> Thanks. I've created the entry in
>>> https://commitfest.postgresql.org/10/713/
>>> . You can add yourself as a reviewer.
>>>
>>
>> Done, added myself as reviewer &
On 25.08.2016 13:26, amul sul wrote:
Thanks. I've created the entry in https://commitfest.postgresql.org/10/713/
. You can add yourself as a reviewer.
Done, added myself as reviewer & changed status to "Ready for
Committer". Thanks !
Regards,
Amul Sul
It seems there is no need to rebase
On Thu, Aug 25, 2016 at 3:41 PM, Artur Zakirov wrote:
>>> You are right. I assigned to prev_type NODE_TYPE_SPACE to be able to
>>> execute such query:
>>>
>>>
>>> SELECT to_timestamp('---2000JUN', ' MON');
>>>
>>>
>>> Will be it a proper behaviour?
>>
>>
>>
>>
You are right. I assigned to prev_type NODE_TYPE_SPACE to be able to
execute such query:
SELECT to_timestamp('---2000JUN', ' MON');
Will be it a proper behaviour?
Looks good to me, no one will complain if something working on PG but not on
Oracle.
Thanks. I've created the entry
On Thursday, August 25, 2016 1:56 PM, Artur Zakirov
wrote:
>> #2. Warning at compilation;
>>
>> formatting.c: In function ‘do_to_timestamp’:
>> formatting.c:3049:37: warning: ‘prev_type’ may be used uninitialized in this
>> function [-Wmaybe-uninitialized]
>> if
Hi,
#1.
Whitespace @ line # 317.
Sorry, fixed.
#2. Warning at compilation;
formatting.c: In function ‘do_to_timestamp’:
formatting.c:3049:37: warning: ‘prev_type’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
if (prev_type == NODE_TYPE_SPACE || prev_type ==
Hi Artur Zakirov,
0001-to-timestamp-format-checking-v3.patch looks pretty reasonable to me, other
than following concern:
#1.
Whitespace @ line # 317.
#2. Warning at compilation;
formatting.c: In function ‘do_to_timestamp’:
formatting.c:3049:37: warning: ‘prev_type’ may be used uninitialized
Sorry. I did not get last two mails from Amul. Don't know why. So I
reply to another mail.
Documented as working case, but unfortunatly it does not :
postgres=# SELECT to_timestamp('2000JUN', ' MON');
ERROR: invalid value "---" for "MON"
DETAIL: The given value did not match any of
Hi Artur Zakirov,
Please see following review comment for
"0001-to-timestamp-format-checking-v2.patch" & share your thought:
#1.
15 + to_timestamp('2000JUN', ' MON')
Documented as working case, but unfortunatly it does not :
postgres=# SELECT to_timestamp('2000JUN', '
On Friday, August 19, 2016 12:42 AM, Robert Haas wrote:
>On Wed, Aug 17, 2016 at 10:35 AM, amul sul wrote:
>
>
>> Hmm. I haven't really looked into the code, but with applying both patches
>> it looks precisely imitate Oracle's behaviour. Thanks.
>
On Wed, Aug 17, 2016 at 10:35 AM, amul sul wrote:
> Hmm. I haven't really looked into the code, but with applying both patches it
> looks precisely imitate Oracle's behaviour. Thanks.
This is good to hear, but for us to consider applying something like
this, somebody would
On Wednesday, August 17, 2016 5:15 PM, Artur Zakirov
wrote:
>I attached new patch "0001-to-timestamp-format-checking-v2.patch". It
>fixes behaviour for Amul's scenarious:
>
Great.
>
>> Following are few scenarios where we break existing behaviour:
>>
>> SELECT
I attached new patch "0001-to-timestamp-format-checking-v2.patch". It
fixes behaviour for Amul's scenarious:
Following are few scenarios where we break existing behaviour:
SELECT TO_TIMESTAMP('2015-12-31 13:43:36', ' MM DD HH24 MI SS');
SELECT TO_TIMESTAMP('2011$03!18 23_38_15',
On 15.08.2016 19:28, Robert Haas wrote:
Well, what's the Oracle behavior in any of these cases? I don't think
we can decide to change any of this behavior without knowing that. If
a proposed behavior change is incompatible with our previous releases,
I think it'd better at least be more
Monday, 15 August 2016 9:58 PM, Robert Haas wrote:
>On Mon, Aug 15, 2016 at 10:56 AM, amul sul wrote:
>> On Thursday, 11 August 2016 3:18 PM, Artur Zakirov
>> wrote:
[Skipped..]
>Well, what's the Oracle behavior in any of
On Mon, Aug 15, 2016 at 10:56 AM, amul sul wrote:
> On Thursday, 11 August 2016 3:18 PM, Artur Zakirov
> wrote:
>
>>Here is my patch. It is a proof of concept.
>>Date/Time Formatting
>>
>>There are changes in date/time
On Thursday, 11 August 2016 3:18 PM, Artur Zakirov
wrote:
>Here is my patch. It is a proof of concept.>Date/Time
>Formatting>>There are changes in date/time formatting
>rules:-> now to_timestamp() and to_date() skip spaces in the input string and
Hello,
On 14.07.2016 12:16, Pavel Stehule wrote:
last point was discussed in thread related to to_date_valid function.
Regards
Pavel
Thank you.
Here is my patch. It is a proof of concept.
Date/Time Formatting
There are changes in date/time formatting rules:
- now
2016-07-14 11:05 GMT+02:00 Artur Zakirov :
> On 23.06.2016 21:02, Tom Lane wrote:
>
>> Robert Haas writes:
>>
>>> On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane wrote:
>>>
At the very least I'd want to see a thought-through
On 23.06.2016 21:02, Tom Lane wrote:
Robert Haas writes:
On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane wrote:
At the very least I'd want to see a thought-through proposal that
addresses all three of these interrelated points:
* what should a space in
On Thu, Jun 23, 2016 at 02:00:49PM -0400, Robert Haas wrote:
> > Ok. I'm having trouble seeing this justified as a bug fix - the docs
> > clearly state our behavior is intentional. Improved behavior, yes, but
> > that's a feature and we're in beta2. Please be specific if you believe I've
> >
On Fri, Jun 24, 2016 at 5:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
>> wrote:
>>> To me, 2016-02-30 is an invalid date that should generate an error.
>
>> I don't
On Fri, Jun 24, 2016 at 3:43 PM, Joshua D. Drake
wrote:
> On 06/24/2016 02:16 PM, Tom Lane wrote:
>
>> Robert Haas writes:
>>
>>> On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
>>> wrote:
>>>
To me,
On 06/24/2016 02:16 PM, Tom Lane wrote:
Robert Haas writes:
On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
wrote:
To me, 2016-02-30 is an invalid date that should generate an error.
I don't particularly disagree with that, but on
On 25/06/16 08:33, Robert Haas wrote:
On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
wrote:
My observation has been that the PostgreSQL development group aims for
correctness and the elimination of surprising results. This was part of the
reason to eliminate a
Robert Haas writes:
> On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
> wrote:
>> To me, 2016-02-30 is an invalid date that should generate an error.
> I don't particularly disagree with that, but on the other hand, as
> mentioned earlier,
On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
wrote:
> My observation has been that the PostgreSQL development group aims for
> correctness and the elimination of surprising results. This was part of the
> reason to eliminate a number of automatic casts to dates
On 06/24/2016 09:26 AM, Steve Crawford wrote:
My observation has been that the PostgreSQL development group aims for
correctness and the elimination of surprising results. This was part of
the reason to eliminate a number of automatic casts to dates in earlier
versions.
To me, 2016-02-30 is an
My observation has been that the PostgreSQL development group aims for
correctness and the elimination of surprising results. This was part of the
reason to eliminate a number of automatic casts to dates in earlier
versions.
To me, 2016-02-30 is an invalid date that should generate an error.
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 20.06.2016 17:09, Albe Laurenz wrote:
Tom Lane wrote:
I don't necessarily have an opinion yet. I would like to see more than
just an unsupported assertion about what Oracle's behavior is. Also,
On 23.06.2016 20:40, Tom Lane wrote:
Robert Haas writes:
On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston
wrote:
My understanding is that is not going to change for 9.6.
That's exactly what is under discussion here.
I would definitely
On Thu, Jun 23, 2016 at 2:00 PM, Robert Haas wrote:
> On Thu, Jun 23, 2016 at 1:46 PM, David G. Johnston
> wrote:
> >> Sheesh. Who put you in charge of this? You basically seem like you
> >> are trying to shut up anyone who supports this
On 6/23/16 12:29 PM, Alvaro Herrera wrote:
David G. Johnston wrote:
On Thursday, June 23, 2016, Alex Ignatov wrote:
Arguing just like that one can say that we don't even need exception like
"division by zero". Just use well-formed numbers in denominator...
Input
Robert Haas writes:
> On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane wrote:
>> At the very least I'd want to see a thought-through proposal that
>> addresses all three of these interrelated points:
>>
>> * what should a space in the format match
>> * what
On Thu, Jun 23, 2016 at 1:46 PM, David G. Johnston
wrote:
>> Sheesh. Who put you in charge of this? You basically seem like you
>> are trying to shut up anyone who supports this change, and I don't
>> think that's right.
>
> I'm all for a change in this area - though
On Thursday, June 23, 2016, Robert Haas wrote:
> On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston
> > wrote:
> > to_timestamp with its present behavior is, IMO, a poorly designed
> function
> > that would never be accepted today.
On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston
>> wrote:
>>> My understanding is that is not going to change for 9.6.
>
>> That's exactly what is
Robert Haas writes:
> On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston
> wrote:
>> My understanding is that is not going to change for 9.6.
> That's exactly what is under discussion here.
I would definitely agree with David on that point.
David G. Johnston wrote:
> On Thursday, June 23, 2016, Alex Ignatov wrote:
>
> > Arguing just like that one can say that we don't even need exception like
> > "division by zero". Just use well-formed numbers in denominator...
> > Input data sometimes can be generated
On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston
wrote:
> to_timestamp with its present behavior is, IMO, a poorly designed function
> that would never be accepted today. Concrete proposals for either fixing or
> deprecating (or both) are welcome. Fixing it should
On Thu, Jun 23, 2016 at 12:37 PM, David G. Johnston
wrote
> To be honest I don't see how this is relevant to quoted content. And you've
> already made this point quite clearly - repeating it isn't constructive.
> This behavior has existed for a long time and I don't
On Thursday, June 23, 2016, Alex Ignatov wrote:
> Arguing just like that one can say that we don't even need exception like
> "division by zero". Just use well-formed numbers in denominator...
> Input data sometimes can be generated automagically. Without exception
>
On 23.06.2016 19:37, David G. Johnston wrote:
On Thu, Jun 23, 2016 at 12:16 PM, Alex Ignatov
>wrote:
On 23.06.2016 16:30, Bruce Momjian wrote:
On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote:
On
On Thu, Jun 23, 2016 at 12:16 PM, Alex Ignatov
wrote:
>
> On 23.06.2016 16:30, Bruce Momjian wrote:
>
>> On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote:
>>
>>> On Monday, 20 June 2016 8:53 PM, Alex Ignatov
>>> wrote:
>>>
>>>
>>> On
On 23.06.2016 16:30, Bruce Momjian wrote:
On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote:
On Monday, 20 June 2016 8:53 PM, Alex Ignatov wrote:
On 13.06.2016 18:52, amul sul wrote:
And it wont stop on some simple whitespace. By using to_timestamp you
can
On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote:
> On Monday, 20 June 2016 8:53 PM, Alex Ignatov
> wrote:
>
>
> >>On 13.06.2016 18:52, amul sul wrote:
> >And it wont stop on some simple whitespace. By using to_timestamp you
> >can get any output results by
On Monday, 20 June 2016 8:53 PM, Alex Ignatov wrote:
>>On 13.06.2016 18:52, amul sul wrote:
>And it wont stop on some simple whitespace. By using to_timestamp you
>can get any output results by providing illegal input parameters values:
>postgres=# SELECT
On 13.06.2016 18:52, amul sul wrote:
Hi,
It's look like bug in to_timestamp() function when format string has more
whitespaces compare to input string, see below:
Ex.1: Two white spaces before HH24 whereas one before input time string
postgres=# SELECT TO_TIMESTAMP('2016-06-13 15:43:36',
On 20.06.2016 16:36, Tom Lane wrote:
Robert Haas writes:
On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas wrote:
I think a space in the format string should skip a whitespace
character in the input string, but not a non-whitespace character.
It's
Tom Lane wrote:
> I don't necessarily have an opinion yet. I would like to see more than
> just an unsupported assertion about what Oracle's behavior is. Also,
> how should FM mode affect this?
I can supply what Oracle 12.1 does:
SQL> SELECT to_timestamp('2016-06-13 15:43:36', ' /MM/DD
Robert Haas writes:
> On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas wrote:
>> I think a space in the format string should skip a whitespace
>> character in the input string, but not a non-whitespace character.
>> It's my understanding that these
On Mon, Jun 20, 2016 at 8:19 AM, Robert Haas wrote:
> On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas
> wrote:
> > On Mon, Jun 13, 2016 at 12:12 PM, Tom Lane wrote:
> >> amul sul writes:
> >>> It's look like
On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas wrote:
> On Mon, Jun 13, 2016 at 12:12 PM, Tom Lane wrote:
>> amul sul writes:
>>> It's look like bug in to_timestamp() function when format string has more
>>> whitespaces compare to
On Monday, 13 June 2016 9:57 PM, Robert Haas wrote:
>I think a space in the format string should skip a whitespace
>character in the input string, but not a non-whitespace character.
+1, enough the benefit is we are giving correct output.
PFA patch proposing this fix.
On Mon, Jun 13, 2016 at 12:12 PM, Tom Lane wrote:
> amul sul writes:
>> It's look like bug in to_timestamp() function when format string has more
>> whitespaces compare to input string, see below:
>
> No, I think this is a case of "input doesn't match
amul sul writes:
> It's look like bug in to_timestamp() function when format string has more
> whitespaces compare to input string, see below:
No, I think this is a case of "input doesn't match the format string".
As a rule of thumb, using to_timestamp() for input that
Hi,
It's look like bug in to_timestamp() function when format string has more
whitespaces compare to input string, see below:
Ex.1: Two white spaces before HH24 whereas one before input time string
postgres=# SELECT TO_TIMESTAMP('2016-06-13 15:43:36', '/MM/DD HH24:MI:SS');
to_timestamp
71 matches
Mail list logo