On 2/22/16, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
> On Tue, Feb 23, 2016 at 11:58 AM, Vitaly Burovoy
> <vitaly.buro...@gmail.com> wrote:
>> Hello, Hackers!
>>
>> I'm writing another patch and while I was trying to cover corner cases
>> I foun
On 2/22/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> Testings, complains, advice, comment improvements are very appreciated.
The patch seems simple, but it can lead to a discussion, so I've added it to CF.
[CF]https://commitfest.postgresql.org/9/533/
--
Best regards,
Vital
*MM*DD BC');
to_timestamp| to_timestamp
---+---
0010-01-01 00:00:00+00 BC | 0010-01-01 00:00:00+00 BC
(1 row)
Testings, complains, advice, comment improvements are very appreciated.
--
Best regards,
Vitaly Burovoy
negative_years_in_to_dat
On 2/17/16, Dean Rasheed <dean.a.rash...@gmail.com> wrote:
> On 17 February 2016 at 00:39, Vitaly Burovoy <vitaly.buro...@gmail.com>
> wrote:
>> Now parse_memory_unit returns -1024 for bytes as divider, constant
>> "bytes" has moved there.
>> Add
On 2/16/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> On 2/16/16, Dean Rasheed <dean.a.rash...@gmail.com> wrote:
>> Fixing that in parse_memory_unit() would be messy because it assumes a
>> base unit of kB, so it would require a negative multiplier, and
&g
On 2/16/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> On 2/16/16, Dean Rasheed <dean.a.rash...@gmail.com> wrote:
>> On 16 February 2016 at 05:01, Pavel Stehule <pavel.steh...@gmail.com>
>> wrote:
>>> 2016-02-15 10:16 GMT+01:00 Dean Ras
more
> readable to just parse the supported units directly in
> pg_size_bytes(), rather than trying to share code with guc.c, when the
> supported units are actually different and may well diverge further in
> the future.
>
> I'll try to hack something up, and see what it looks like.
>
> Regards,
> Dean
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/15/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> P.S.: "bytes" size unit was added just for consistency: each group
> should have a name, even with an exponent of 1.
Oops... Of course, "even with an exponent of 0".
--
Best regards,
Vitaly Buro
d6a57e1a61d5bf756349e8
[3]http://www.postgresql.org/docs/devel/static/functions-admin.html#FUNCTIONS-ADMIN-BACKUP-TABLE
[4]https://en.wikipedia.org/wiki/Binary_prefix#Adoption_by_IEC.2C_NIST_and_ISO
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
//www.postgresql.org/message-id/ca+tgmozfomg4eyorzzgf7pzotg9pxpuhtqvxlfskim4izh8...@mail.gmail.com
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
free is removed (it is easier than removing all other allocated resources).
I still think my changes are little and they are based on your work
(and research).
[1]http://www.postgresql.org/message-id/cakoswnk13wvdem06lro-hucr0pr6et29+dvqy6j5skxzaru...@mail.gmail.com
--
Best regards,
Vitaly Buro
On 2/7/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> Hello, Hackers!
>
> TODO list has an entry "Move NOT NULL constraint information to
> pg_constraint" with four links and without two with the newest
> work[1][2].
>
> I rebased the patch from [2]
On 2/2/16, Tom Lane <t...@sss.pgh.pa.us> wrote:
> [ Please use a useful Subject: line in your posts. ]
I'm so sorry, it was the first time I had forgotten to look at the
"Subject" field before I pressed the "Send" button.
> Vitaly Burovoy <vitaly.buro...@gm
regards, tom lane
Ok, then I'll use "is_infinite" from "float.c".
But why functions' (in "src/port/isinf.c") behavior are different? It
is a bit confusing…
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list
Proposed patch makes that behavior.
P.S.: Should the patch be added to the next CF?
[1]https://docs.oracle.com/cd/E36784_01/html/E36874/fpclass-3c.html
--
Best regards,
Vitaly Burovoy
isinf_v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"str" and "buffer".
But if you do so, clean up also buffers from numeric_in, numeric_mul
and int8_numeric. If you insist it should be left as is, I leave that
decision to a committer.
P.S.: Have you thought to wrap the call "numeric_in" by a
PG_TRY/PG_CATCH instead of checkin
,
> false, "error message" instead raising a exception.
I know. It is a common style in C programs.
> I would not to refactor numeric_in function in this style.
No doubt. It is not necessary.
> This function is in critical path of COPY
> FROM, and any more calls can decreas
8721654.78
infinity| Infinity
(4 rows)
--
Best regards,
Vitaly Burovoy
fix_extract_overflow_v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello, Pavel!
That letter was not a complain against you. I'm sorry if it seems like
that for you.
It was an intermediate review with several points to be clear for _me_
from experienced hackers, mostly about a code design.
26.01.2016 07:05, Pavel Stehule пишет:
>> pg_proc.h has changed, so the
Hello!
I have reviewed this patch. It applies and compiles cleanly at the
current master 1129c2b0ad2732f301f696ae2cf98fb063a4c1f8 and implements
the behavior reached by a consensus.
All size units (the same as used in the GUC) are supported.
The documentation is present and describes behavior
On 1/20/16, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> ...
> New version is attached
>
> Regards
> Pavel
I'm sorry I'll do a review only tonight.
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
adjustments, mainly to make sure that the
> erroneous-units errors exactly match those that would be thrown in
> the main code line.
>
> regards, tom lane
Thank you! I didn't pay enough attention to it at that time.
--
Best regards,
Vitaly Burovoy
--
Sent
ed by
text_to_cstring) and copying into it. I don't think it gives a big
improvement, but nevertheless.
===
[1] http://www.postgresql.org/message-id/29618.1451882...@sss.pgh.pa.us
[2]
http://www.postgresql.org/message-id/CAB7nPqS6Wob4WnZb=dhb3o0pc-nx1v3xjszkn3z9kbexgcq...@mail.gmail.com
--
Best
input values at app-level.
> ...
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e numeric: "+"
---
+ while (isspace((unsigned char) *strptr))
...
+ while (isspace(*strptr))
...
+ while (*strptr && !isspace(*strptr))
...
+ while (isspace(*strptr))
The first occurece of isspace's parameter is casting to "unsigned
char" wher
On 1/18/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> <>
> ---
> + if (*strptr != '\0')
> ...
> + while (*strptr && !isspace(*strptr))
> Sometimes it explicitly compares to '\0', sometimes implicitly.
> Common use is explicit compar
ct in some way?
>
> Thanks
> Glyn
I thing the operator 'jsonb-jsonb' behavior in such case is not obvious.
How to understand the result is not like that:
# select '{"a":1, "b":2}'::jsonb - '{"b":2, "a":4}'::jsonb;
?column?
--
{"a": -3,
, but there is certainly
> more here than meets the eye; and therefore there's a nonzero chance of
> being blindsided if the SQL committee someday standardizes this syntax
> and makes some different decisions about what it means.
>
> regards, tom lane
Be honest I
On 1/14/16, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Vitaly Burovoy <vitaly.buro...@gmail.com> writes:
>> On 1/14/16, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> It's more than syntactic sugar; you are going to have to invent
>>> semantics,
>>> as
of SELECT and UPDATE:
http://www.postgresql.org/docs/devel/static/pgcrypto.html#AEN170716
... but recommend to change just "gen_salt('md5')" to "gen_salt('bf', 8))"
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/8/16, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> Simon Riggs wrote:
>> On 8 January 2016 at 14:14, Vitaly Burovoy <vitaly.buro...@gmail.com>
>> wrote:
>>
>> > What about SET NOT NULL constraints? There is no VALIDATE CONSTRAINT
>> &g
On 1/8/16, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 8 January 2016 at 13:13, Vitaly Burovoy <vitaly.buro...@gmail.com>
> wrote:
>
>> On 1/8/16, Simon Riggs <si...@2ndquadrant.com> wrote:
>> > On 8 January 2016 at 12:49, Vitaly Bur
USING
INDEX tablename_chk;
DROP INDEX CONCURRENTLY tablename_chk; -- if the command above succeed
ALTER TABLE tablename DROP CONSTRAINT tablename_nonnull_chk; --optional
[1] http://www.postgresql.org/docs/9.1/static/release-9-1.html#AEN110279
[2] http://www.postgresql.org/docs/9.5/static/sql-createt
On 1/8/16, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 8 January 2016 at 12:49, Vitaly Burovoy <vitaly.buro...@gmail.com>
> wrote:
>
>
>> In Postgres9.1 a new feature was implemented [1] for adding PK and
>> UNIQUE constraints using indexes created concu
On 1/8/16, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 8 January 2016 at 13:13, Vitaly Burovoy <vitaly.buro...@gmail.com>
> wrote:
>
>> On 1/8/16, Simon Riggs <si...@2ndquadrant.com> wrote:
>> > On 8 January 2016 at 12:49, Vitaly Bur
On 1/4/16, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> Vitaly Burovoy wrote:
>
>> Majority of the votes for NULL for "other things" except epoch.
>> Nobody answers about differences between monotonic and oscillating
>> values.
>>
>> I s
t a check for that
special case to raise an exception "timestamp out of range"?
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/9/15, Robert Haas <robertmh...@gmail.com> wrote:
> On Sat, Nov 7, 2015 at 9:47 AM, Vitaly Burovoy <vitaly.buro...@gmail.com>
> wrote:
>> I'd like to raise a topic about extracting fields from infinite
>> timestamps, so much more that it is mentioned in th
={1,2,3,4,5,6,7}'::int[], 2, NULL) ==
{3,4,5,6,7} -- omitting boundaries
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
siest way, because it allows to avoid
usage of INTERVAL as a helper (of course, there is still possible to
use intervals as shown above in user's scripts, but without "Infinity"
support).
2. Add support of infinite intervals. It is harder, because it touches
a lot of functions. I can ad
on 9.1 proposed test fails because "SELECT
EXTRACT(EPOCH FROM DATE '1970-01-01')" gives "28800" instead of "0".
Before 9.2 it was time zone-related.
--
Best regards,
Vitaly Burovoy.
extract_from_infinite_timestamp-v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
101 - 141 of 141 matches
Mail list logo
