Re: [HACKERS] Some questions about the array.

2015-11-09 Thread Vitaly Burovoy
={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

[HACKERS] Returning 'Infinity'::TIMESTAMPTZ from "to_timestamp" function

2015-11-08 Thread Vitaly Burovoy
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

[HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

2015-11-07 Thread Vitaly Burovoy
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

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

2015-11-17 Thread Vitaly Burovoy
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

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

2016-01-05 Thread Vitaly Burovoy
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

Re: [HACKERS] New feature "... ALTER CONSTRAINT ... VERIFY USING INDEX"

2016-01-08 Thread Vitaly Burovoy
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

Re: [HACKERS][PROPOSAL] New feature "... VALIDATE CONSTRAINT ... USING INDEX ..."

2016-01-08 Thread Vitaly Burovoy
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

[HACKERS] Feature or bug: getting "Inf"::timestamp[tz] by "regular" value

2015-11-18 Thread Vitaly Burovoy
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

[HACKERS] New feature "... ALTER CONSTRAINT ... VERIFY USING INDEX"

2016-01-08 Thread Vitaly Burovoy
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

Re: [HACKERS] New feature "... ALTER CONSTRAINT ... VERIFY USING INDEX"

2016-01-08 Thread Vitaly Burovoy
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

Re: [HACKERS] New feature "... ALTER CONSTRAINT ... VERIFY USING INDEX"

2016-01-08 Thread Vitaly Burovoy
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

Re: [HACKERS] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

2016-06-15 Thread Vitaly Burovoy
On 6/15/16, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Jun 16, 2016 at 12:10 PM, Vitaly Burovoy > <vitaly.buro...@gmail.com> wrote: >> In the initial letter[1] I posted a digest from the SQL-2011 standard >> and a conclusion as a design of a new

Re: [HACKERS] Need help on pgcrypto

2016-01-11 Thread Vitaly Burovoy
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

Re: [HACKERS] SET syntax in INSERT

2016-01-14 Thread Vitaly Burovoy
, 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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-01-18 Thread Vitaly Burovoy
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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-01-18 Thread Vitaly Burovoy
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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-01-18 Thread Vitaly Burovoy
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

Re: [HACKERS] SET syntax in INSERT

2016-01-14 Thread Vitaly Burovoy
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

Re: [HACKERS] jsonb - jsonb operators

2016-01-18 Thread Vitaly Burovoy
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,

Re: [HACKERS] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

2016-06-15 Thread Vitaly Burovoy
t'll be ready to be shown in a month (may be two). But it already forbids dropping NOT NULLs if they were set as result of inheritance. [1] https://www.postgresql.org/message-id/flat/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA%40mail.gmail.com [2] https://www.postgresql.org/message-id/attachme

Re: [HACKERS] Make PG's "NOT NULL"s and attnotnull ("is_nullable") conform to SQL-2011

2016-02-08 Thread Vitaly Burovoy
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]

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-02-10 Thread Vitaly Burovoy
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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-02-11 Thread Vitaly Burovoy
//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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-01-25 Thread Vitaly Burovoy
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

[HACKERS] Patch: make behavior of all versions of the "isinf" function be similar

2016-01-31 Thread Vitaly Burovoy
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

Re: [HACKERS] Patch: make behavior of all versions of the "isinf" function be similar

2016-02-01 Thread Vitaly Burovoy
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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-01-30 Thread Vitaly Burovoy
"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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-01-30 Thread Vitaly Burovoy
, > 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

[HACKERS]

2016-01-30 Thread Vitaly Burovoy
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

Re: [HACKERS] Integer overflow in timestamp_part()

2016-02-02 Thread Vitaly Burovoy
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

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

2016-02-28 Thread Vitaly Burovoy
> 0001-06-01 BC > (1 row) Also because of: postgres=# SELECT EXTRACT(year FROM to_date('-3', '')); date_part --- -4 (1 row) Note that the documentation[1] says "Keep in mind there is no 0 AD". More examples by the link[2]. > -- > R

Re: [HACKERS][PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

2016-02-24 Thread Vitaly Burovoy
On 2/24/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > On 2/2/16, Jim Nasby <jim.na...@bluetreble.com> wrote: >> On 2/2/16 6:39 PM, Tom Lane wrote: >>> I'm inclined to think that a good solution would be to create an >>> artificial restriction to

Re: [HACKERS][PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

2016-02-25 Thread Vitaly Burovoy
> Added to the commitfest 2016-03. [CF] https://commitfest.postgresql.org/9/540/ -- 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

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

2016-02-26 Thread Vitaly Burovoy
extract options "year"/"isoyear", but I think getting decision of the community before modifying the patch is a better idea. [1]http://www.postgresql.org/docs/devel/static/functions-formatting.html [2]http://www.postgresql.org/docs/devel/static/functions-datetime.html [3]http://www.postgresql.org/message-id/CAEepm=0aznvy+frtyni04imdw4tlgzaelljqmhmcjbre+ln...@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

Re: [HACKERS][PATCH] Supporting +-Infinity values by to_timestamp(float8)

2016-02-26 Thread Vitaly Burovoy
Added to the CF 2016-03: https://commitfest.postgresql.org/9/546/ -- 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

[HACKERS][PATCH] Supporting +-Infinity values by to_timestamp(float8)

2016-02-26 Thread Vitaly Burovoy
3]https://commitfest.postgresql.org/9/540/ [4]http://www.postgresql.org/docs/devel/static/datatype-datetime.html -- Best regards, Vitaly Burovoy to_timestamp_infs.v001.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

[HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

2016-02-22 Thread Vitaly Burovoy
*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

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

2016-02-22 Thread Vitaly Burovoy
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

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

2016-02-22 Thread Vitaly Burovoy
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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-01-21 Thread Vitaly Burovoy
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

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

2016-01-21 Thread Vitaly Burovoy
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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-01-21 Thread Vitaly Burovoy
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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-01-26 Thread Vitaly Burovoy
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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-02-15 Thread Vitaly Burovoy
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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-02-15 Thread Vitaly Burovoy
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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-02-16 Thread Vitaly Burovoy
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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-02-16 Thread Vitaly Burovoy
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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-02-16 Thread Vitaly Burovoy
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

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-02-17 Thread Vitaly Burovoy
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

Re: [HACKERS] [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

2016-03-14 Thread Vitaly Burovoy
_DAY are one of them. I would leave it as is. > The #defines would be less brittle in > the event, for example, that the postgres epoch were ever changed. I don't think it is real, and even in such case all constants are collected together in the file and will be found and changed at once. &

[HACKERS] Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

2016-03-14 Thread Vitaly Burovoy
On 3/14/16, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote: > 14.03.2016 16:23, David Steele: >> On 2/25/16 4:44 PM, Vitaly Burovoy wrote: >> >>> Added to the commitfest 2016-03. >>> >>> [CF] https://commitfest.postgresql.org/9/540/ >

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

2016-03-11 Thread Vitaly Burovoy
uch of the actual problem could be addressed by teaching make_date() > and friends to accept negative year values as meaning BC. > > regards, tom lane Thank Thomas, Robert and Tom very much for an interesting (but short) discussion. -- 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

Re: [HACKERS] [PATCH] Supporting +-Infinity values by to_timestamp(float8)

2016-03-19 Thread Vitaly Burovoy
On 2016-03-15, David Steele <da...@pgmasters.net> wrote: > On 3/4/16 2:56 PM, Vitaly Burovoy wrote: >> On 3/4/16, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote: >> >>> I think that you should update documentation. At least description

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

2016-03-11 Thread Vitaly Burovoy
On 3/11/16, Robert Haas <robertmh...@gmail.com> wrote: > On Sun, Feb 28, 2016 at 9:38 PM, Vitaly Burovoy > <vitaly.buro...@gmail.com> wrote: >>> However, I'm not sure we ought to tinker with the behavior in this >>> area. If -MM-DD is going to accept things

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

2016-03-30 Thread Vitaly Burovoy
ect, so I have no idea why "before ? JB_PATH_INSERT_BEFORE : JB_PATH_INSERT_AFTER" works. I think either proper comment should be added or lack in the code must be found. Anyway the variable's name must reflect the SQL argument's name. -- 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

Re: [HACKERS] [PATCH] Supporting +-Infinity values by to_timestamp(float8)

2016-03-30 Thread Vitaly Burovoy
On 3/29/16, Tom Lane <t...@sss.pgh.pa.us> wrote: > Pushed with minor adjustments. > > regards, tom lane > Thank you very much! -- Best regards, Vitaly Burovoy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

2016-03-19 Thread Vitaly Burovoy
e JULIAN_MINDAY and JULIAN_MAXDAY which are not used now? Also why JULIAN_MAXMONTH is set to "6" whereas {DATE|TIMESTAMP}_END_JULIAN use "1" as month? -- 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

Re: [HACKERS] Bug in searching path in jsonb_set when walking through JSONB array

2016-03-23 Thread Vitaly Burovoy
On 2016-03-23, Oleg Bartunov <obartu...@gmail.com> wrote: > On Wed, Mar 23, 2016 at 6:37 AM, Vitaly Burovoy <vitaly.buro...@gmail.com> > wrote: > >> Hello, Hackers! >> >> While I was reviewed a patch with "json_insert" function I found a bug >&g

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

2016-03-22 Thread Vitaly Burovoy
te about importance of existing intermediate keys. Try to reword it since the function doesn't have a "create_missing" parameter support. > All the items of the path parameter of jsonb_set must be present in the > target, > ... in which case all but the last item must be present. Currently I can't break the code, so I think it is close to the final state. ;-) -- 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

[HACKERS] Bug in searching path in jsonb_set when walking through JSONB array

2016-03-22 Thread Vitaly Burovoy
posed patch in an attachment fixes it. There is a magic number "20" as a length of an array for copying key from a path before passing it to strtol. It is a maximal length of a value which can be parsed by the function. I could not find a proper constant for it. Also I found similar dire

Re: [HACKERS] [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

2016-03-19 Thread Vitaly Burovoy
On 2016-03-15, Mark Dilger <hornschnor...@gmail.com> wrote: > >> On Mar 14, 2016, at 5:12 PM, Vitaly Burovoy <vitaly.buro...@gmail.com> >> wrote: >> >> On 3/14/16, Mark Dilger <hornschnor...@gmail.com> wrote: >>> The first thing I no

Re: [HACKERS] [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

2016-03-19 Thread Vitaly Burovoy
rect if checks for IS_VALID_DATE is added in date.c to places marked as "IS_VALID_JULIAN is enough for checking..." All other places are (I'm sure) covered by IS_VALID_DATE/IS_VALID_TIMESTAMP. What about the question: On 2016-02-24, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > A

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

2016-03-07 Thread Vitaly Burovoy
column threshold... The same rules for the documentation. 9. And finally... it does not work as expected in case of: postgres=# select jsonb_insert('{"a":[0,1,2,3]}', '{"a", 10}', '"4"'); jsonb_insert - {"a": [0, 1, 2, 3]} (1 row) wheras jsonb_set

Re: [HACKERS][PATCH] Supporting +-Infinity values by to_timestamp(float8)

2016-03-04 Thread Vitaly Burovoy
On 3/4/16, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote: > 27.02.2016 09:57, Vitaly Burovoy: >> Hello, Hackers! >> >> I worked on a patch[1] allows "EXTRACT(epoch FROM >> +-Inf::timestamp[tz])" to return "+-Inf::float8". >>

Re: [HACKERS] jsonb array-style subscription

2016-03-02 Thread Vitaly Burovoy
committers, it can end up as "Rejected with feedback" (since the patch is already in the CF[1])? [1]https://commitfest.postgresql.org/9/485/ -- 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

Re: [HACKERS][PATCH] Supporting +-Infinity values by to_timestamp(float8)

2016-03-03 Thread Vitaly Burovoy
On 2/26/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > Proposed patch implements it. I'm sorry, I forgot to leave a note for reviewers and committers: This patch requires CATALOG_VERSION_NO be bumped. Since pg_proc.h entry has changed, it is important to check and run regr

[HACKERS] Re: [PATH] Jsonb, insert a new value into an array at arbitrary position

2016-03-31 Thread Vitaly Burovoy
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 I have reviewed this patch. It applies cleanly at the top of

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

2016-03-31 Thread Vitaly Burovoy
On 3/30/16, Dmitry Dolgov <9erthali...@gmail.com> wrote: > On 31 March 2016 at 05:04, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: >> The documentation changes still has to be fixed. > Thanks for help. Looks like I'm not so good at text formulation. Fixed. Never mi

Re: [HACKERS] 10.0

2016-05-13 Thread Vitaly Burovoy
mjian <br...@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com I'd vote for 9.6 up to 9.9 then 10.0… -- 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

Re: [HACKERS] 10.0

2016-05-13 Thread Vitaly Burovoy
.X 15.X ... 10.6.X 19.X 10.7.X 20.X 10.8.X 21.X 10.9.X 22.X 11.0.X 23.X 11.1.X 24.X Etc. > -- > 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

Re: [HACKERS] Make PG's "NOT NULL"s and attnotnull ("is_nullable") conform to SQL-2011

2016-05-03 Thread Vitaly Burovoy
I'm sorry for the late answer. On 4/27/16, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Vitaly Burovoy wrote: > > Hi, > >> But before starting working on it I had a look at the SQL-2011 >> standard (ISO/IEC 9075-2)[3] and found that: >> >> 1. A name

Re: [HACKERS] Initial release notes created for 9.6

2016-05-05 Thread Vitaly Burovoy
sage-id/2723429.ZaCixaFn1x@dinodell [2] http://www.postgresql.org/message-id/dd701b62-008d-4048-882e-20df0e4b5...@postgrespro.ru [3] http://www.postgresql.org/message-id/caezatcxhz5ggfrfcf9_yw5h6wdxr68qdfiwhvmgfr3ascnq...@mail.gmail.com -- Best regards, Vitaly Burovoy -- Sent via pgsql-hacke

Re: [HACKERS] Make PG's "NOT NULL"s and attnotnull ("is_nullable") conform to SQL-2011

2016-05-04 Thread Vitaly Burovoy
On 5/3/16, Tom Lane <t...@sss.pgh.pa.us> wrote: > Vitaly Burovoy <vitaly.buro...@gmail.com> writes: >> On 4/27/16, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: >>> Point 2 is where things differ from what I remember; my (possibly >>> flawed) underst

Re: [HACKERS] Why we lost Uber as a user

2016-07-28 Thread Vitaly Burovoy
ERE id = 4; This query would return *TWO* records: ... And it affected slaves, not master. Slaves are for decreasing loading to master, if you run all queries (even) RO at master, why would you (or someone) have so many slaves? -- Best regards, Vitaly Burovoy -- Sent via pgsql-hac

[HACKERS][REVIEW] macaddr 64 bit (EUI-64) datatype support

2017-01-31 Thread Vitaly Burovoy
hould bump catversion. It is not bumped in the patch because it is unclear when it is committed. [1]https://postgr.es/m/CAJrrPGeT8zrGPMcRVk_wRvYD-ETcgUz6WRrc2C=inubmrkr...@mail.gmail.com [2]http://standards.ieee.org/develop/regauth/tut/eui64.pdf -- Best regards, Vitaly Burovoy -- Sent via pgsql-hacke

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-24 Thread Vitaly Burovoy
ac->h); In this case the left-hand side argument for the "*=" operator is computed at the compile time as a single constant. The second line can be written as "res *= 256. * 256 * 256 * 256;" (pay attention to a dot in the first multiplier), but it is not readable at all (a

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-30 Thread Vitaly Burovoy
/backend/utils/adt/network.c pg_indent makes it uglier. I've just found how to write the line for it: res *= ((double) 256) * 256 * 256 * 256; -- 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

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-26 Thread Vitaly Burovoy
On 1/25/17, Haribabu Kommi <kommi.harib...@gmail.com> wrote: > On Wed, Jan 25, 2017 at 6:43 PM, Vitaly Burovoy <vitaly.buro...@gmail.com> > wrote: > >> On 1/23/17, Haribabu Kommi <kommi.harib...@gmail.com> wrote: >> > The patch is split into two parts

Re: [HACKERS] identity columns

2016-09-07 Thread Vitaly Burovoy
uot;)? 6. In ATExecDropIdentity: is it a good idea to do nothing if the column is already not a identity (the same behavior as DROP NOT NULL/DROP DEFAULT)? 7. Is there any reason to insert CREATE_TABLE_LIKE_IDENTITY before CREATE_TABLE_LIKE_INDEXES, not at the end? Why do you change catversio

Re: [HACKERS][REVIEW] Tab Completion for CREATE DATABASE ... TEMPLATE ...

2016-09-11 Thread Vitaly Burovoy
On 9/11/16, Kevin Grittner <kgri...@gmail.com> wrote: > On Sat, Sep 10, 2016 at 12:26 AM, Vitaly Burovoy >> Mark it as "Ready for committer". >> >> P.S.: While I was reviewing I simplified SQL query: improved version >> only 2 seqscans instead of 3 seqsca

Re: [HACKERS][REVIEW] Tab Completion for CREATE DATABASE ... TEMPLATE ...

2016-09-11 Thread Vitaly Burovoy
On 9/11/16, Tom Lane <t...@sss.pgh.pa.us> wrote: > Vitaly Burovoy <vitaly.buro...@gmail.com> writes: >> On 9/11/16, Kevin Grittner <kgri...@gmail.com> wrote: >>> I was able to find cases during test which were not handled >>> correctly with either versi

Re: [HACKERS][REVIEW] Tab Completion for CREATE DATABASE ... TEMPLATE ...

2016-09-12 Thread Vitaly Burovoy
| en_US.UTF-8 | en_US.UTF-8 | db2 | bob | UTF8 | en_US.UTF-8 | en_US.UTF-8 | (2 rows) postgres=# set role bob; SET postgres=> CREATE DATABASE ss TEMPLATE db -- shows both db1 db2 postgres=> CREATE DATABASE ss TEMPLATE db2; ERROR: permission denied to create database postgres=> So a check for the CREATEDB privilege should be done at the point whether to show CREATE DATABASE or not. But if a user has privileges, Tom's version works fine. -- 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

Re: [HACKERS] sequence data type

2016-09-10 Thread Vitaly Burovoy
ect, Blue Treble Consulting, Austin TX Hex or base64 are not data types. They are just different representation types of binary sequences. Even for bigints these representations are done after writing numbers as byte sequences. -- Best regards, Vitaly Burovoy -- Sent via pgsql-hackers

Re: [HACKERS] identity columns

2016-09-12 Thread Vitaly Burovoy
On 9/12/16, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > Thank you for this extensive testing. I will work on getting the bugs > fixed. Just a couple of comments on some of your points: > > On 9/9/16 11:45 PM, Vitaly Burovoy wrote: >> It compiles and p

Re: [HACKERS] identity columns

2016-09-09 Thread Vitaly Burovoy
/create_table.sgml (5th chunk) has "TODO". Why? --- 14. It would be fine if psql has support of new clauses. === Also several notes: 15. Initializing attidentity in most places is ' ' but makefuncs.c has "n->identity = 0;". Is it correct? --- 16. I think it is a good idea to

Re: [HACKERS][REVIEW] Tab Completion for CREATE DATABASE ... TEMPLATE ...

2016-09-09 Thread Vitaly Burovoy
to all supported versions. No documentation needed. Mark it as "Ready for committer". P.S.: While I was reviewing I simplified SQL query: improved version only 2 seqscans instead of 3 seqscans with an inner loop in an original one. Please find a file "tab-complete-create-database-

[HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-26 Thread Vitaly Burovoy
For restoring to stdout (or dumping to a plain SQL file) I left current behavior: all options in the SET block are written. Also I left "SET row_security = on;" if "enable_row_security" is set to break restoring to a DB non-supported version. -- Best regards, Vitaly Burovoy d

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

2016-10-05 Thread Vitaly Burovoy
On 10/5/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > On 10/5/16, Andres Freund <and...@anarazel.de> wrote: >> On 2016-10-05 15:23:05 -0700, Vitaly Burovoy wrote: >>> On 10/5/16, Andres Freund <and...@anarazel.de> wrote: >>> > On 2016-10-05

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

2016-10-05 Thread Vitaly Burovoy
gt;> the >> default in effect at the time the column was added can never change, no >> matter what you do to the default later on. > > DROP DEFAULT pretty much does that, because it allows multiple (set of) > rows with no value (or a NULL) for a specific column, but with differing

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

2016-10-05 Thread Vitaly Burovoy
table (pg_attribute) as default column values of the "pre-alter" era. It solves changing of the default expression of the same column later. -- 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

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

2016-10-05 Thread Vitaly Burovoy
; SELECT * FROM t ORDER BY pk; ALTER TABLE t ADD COLUMN c2 serial; SELECT * FROM t ORDER BY pk; INSERT INTO t(pk) VALUES (4); SELECT * FROM t ORDER BY pk; P.S.: I really think it is a good idea, just some research is necessary and covering corner cases... -- Best regards, Vitaly Burovoy -- Sent vi

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

2016-10-05 Thread Vitaly Burovoy
On 10/5/16, Andres Freund <and...@anarazel.de> wrote: > On 2016-10-05 15:23:05 -0700, Vitaly Burovoy wrote: >> On 10/5/16, Andres Freund <and...@anarazel.de> wrote: >> > On 2016-10-05 11:58:33 -0700, Serge Rielau wrote: >> >> Dear Hackers, >> >

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

2016-10-05 Thread Vitaly Burovoy
is recommended), but for a separate table it is 11 columns with two indexes now... -- 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

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

2016-10-05 Thread Vitaly Burovoy
On 10/5/16, Serge Rielau <se...@rielau.com> wrote: >On Wed, Oct 5, 2016 at 4:19 PM, Vitaly Burovoy <vitaly.buro...@gmail.com> >wrote: >> But what I discover for myself is that we have pg_attrdef separately >> from the pg_attribute. Why? >> Is it time to j

Re: [HACKERS] Proposal: ON UPDATE REMOVE foreign key action

2016-10-04 Thread Vitaly Burovoy
onnected to the referenced row (by referencing column list). Also your proposal is not consistent: ON UPDATE REMOVE (DELETE?), but ON DELETE - what? again remove/delete? [1] https://wiki.postgresql.org/wiki/Mailing_Lists#Using_the_discussion_lists -- 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

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

2016-10-06 Thread Vitaly Burovoy
up with a NULL. As for me the best phrase is "pre-add-column-default", but it is impossible to use it as a column name. :-( It is still an open question. (I remember funny versions in a discussion[1] when people tried to choose a name for a function reversed to pg_size_pretty...) [1

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

2016-10-06 Thread Vitaly Burovoy
On 10/6/16, Serge Rielau <se...@rielau.com> wrote: >> On Oct 6, 2016, at 9:20 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Vitaly Burovoy <vitaly.buro...@gmail.com> writes: >>> But what I discover for myself is that we have pg_attrdef separately >>> f

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

2016-10-06 Thread Vitaly Burovoy
for > itself once I have the WIP patch ready so we have something concrete to > discuss -- 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

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

2016-10-06 Thread Vitaly Burovoy
On 10/6/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > Ough. I made a mistake about pg_attribute because I forgot about the > pg_attrdef. > If we do not merge these tables, the pg_attrdef is the best place to > store evaluated expression as a constant the same way def

[HACKERS] Small doc fix

2016-10-05 Thread Vitaly Burovoy
Hello, hackers, I've just noticed an extra word in a sentence in the docs in the "parallel.sgml". It seems the sentence was constructed one way and changed later with the extra word left. Please, find the fix attached. -- Best regards, Vitaly Burovoy pg-docs-fix.patch Descripti

  1   2   >