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 (pgs
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 ap
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 cleanl
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:
http://www.postgresql.org/mailpref/pgsql-
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
> http://rextester.com/l/oracle_online_compiler
>
>
> which makes it look a
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 or more spaces in the input,
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:
http://www.postgresql.org/mail
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?
> You may be able to set the status back t
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 error and in the next attempt
>>> DCH_cache_search() could return
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
> > ... without any documentation ... on no elog being
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 cache entry.
>
> I started looking at your 0001-t
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 0001-to-timestamp-format-checking-v4.patch
and this point imme
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 & changed status to "Ready for
>>
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 p
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?
>>
>>
>>
>> Looks good to me, no one will
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 i
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 (prev_type == NODE_TYPE_SPACE ||
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 == NODE_TYPE_S
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 i
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 t
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.
>
>
>This is good to hear, but for us to conside
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 need to look into the
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 TO_TIMESTAMP('2015-12-31 13:43:36'
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', '-MM-D
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 compat
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 these cases? I don't think
>we can decide to change any of this behavi
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 formatting rules:
> -> now to_timestamp() and to_date() sk
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
>>in the formatting string
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 to
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 proposal that
addresses all three of these interrelated points:
>>>
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 the format match
* what should a non-space, n
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
> > mis
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 particularly disagree with that, but on the other hand, as
>> mentioned earlie
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, 2016-02-30 is an invalid date that should generate an error.
>>>
>> I don't particul
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 the other hand, as
mentioned earlier, to_timestamp() is he
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 number of automatic casts to dat
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, to_timestamp() is here for Oracle compatibility,
> and
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 in earlier
> versions.
>
> To me
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 i
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.
Autom
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,
how
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 agree with David on that point. Making to_timestamp
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 change, and I don't
> >> think that's right.
> >
> > I'm
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 data sometimes can be generat
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 should a non-space, non-format-code character
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 I'm not impacted enough to
>
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. Concrete proposals for either
> fixing or
> > deprecating (or bo
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 under discussion here.
>
> I would definitely agree with David on that p
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. Making to_timestamp
noticeably better on this score s
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 automagically. Without excep
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 not cause unnecessary
> error
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 see that changing it
> is a wo
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
> throwing debugging stored fu
On 23.06.2016 19:37, David G. Johnston wrote:
On Thu, Jun 23, 2016 at 12:16 PM, Alex Ignatov
mailto:a.igna...@postgrespro.ru>>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, A
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 13.06.2016 18:52, amul sul wrote:
>
And it wo
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 get any output results by
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 providing illegal input para
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 TO_TIMESTAMP('2016-06-13 99:99:99', 'Y
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', 'YY
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 my understanding that these functions exist in n
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 HH24
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 functions exist in no small part for
>> compatibili
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 bug in to_timestamp() function when format string has
> more whitespaces compare to inpu
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 input string, see below:
>>
>> No, I think this is a case of "inp
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.
Regards,
Amul Sul.
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 the format string".
>
> As a rule of thumb,
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 could be parsed
just fin
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
