Re: [HACKERS] Fix dumping pre-10 DBs by pg_dump10 if table "name" exists

2017-10-31 Thread Vitaly Burovoy
t along with your fix. > > regards, tom lane > Oops. I missed it in "describe.c" because I grepped for exact "::name" string. Thank you very much! -- Best regards, Vitaly Burovoy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgres

Re: [HACKERS] Fix dumping pre-10 DBs by pg_dump10 if table "name" exists

2017-10-31 Thread Vitaly Burovoy
On 10/31/17, Tom Lane <t...@sss.pgh.pa.us> wrote: > Vitaly Burovoy <vitaly.buro...@gmail.com> writes: >> Recently my colleagues found a bug. > >> - "SELECT 'bigint'::name AS >> sequence_type, " >> +

[HACKERS] Fix dumping pre-10 DBs by pg_dump10 if table "name" exists

2017-10-31 Thread Vitaly Burovoy
ery was: SELECT 'bigint'::name AS sequence_type, start_value, increment_by, max_value, min_value, cache_value, is_cycled FROM name_id_seq I've implemented a little fix (attached), don't think there is something to be written to docs and tests. -- Best regards, Vitaly Burovoy 0001-Fix-dumping-schema

Re: [HACKERS] identity columns

2017-04-23 Thread Vitaly Burovoy
On 4/23/17, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Apr 20, 2017 at 12:05 AM, Vitaly Burovoy > <vitaly.buro...@gmail.com> wrote: >> OK. Let's go through it again. >> IDENTITY is a property of a column. There are no syntax to change any >> property o

Re: [HACKERS] identity columns

2017-04-19 Thread Vitaly Burovoy
On 4/18/17, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 4/7/17 01:26, Vitaly Burovoy wrote: >> I've implement SET GENERATED ... IF NOT EXISTS. It must be placed >> before other SET options but fortunately it conforms with the >> standard. >&g

Re: [HACKERS] sequence data type

2017-04-13 Thread Vitaly Burovoy
On 4/4/17, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 3/30/17 22:47, Vitaly Burovoy wrote: >> It seemed not very hard to fix it. >> Please find attached patch to be applied on top of your one. >> >> I've added more tests to cover different case

Re: [HACKERS] identity columns

2017-04-13 Thread Vitaly Burovoy
On 4/6/17, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > On 4/6/17, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: >> As I tried to mention earlier, it is very difficult to implement the IF >> NOT EXISTS behavior here, because we need to run the commands

Re: [HACKERS] identity columns

2017-04-06 Thread Vitaly Burovoy
On 4/6/17, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 4/4/17 22:53, Vitaly Burovoy wrote: >> The next nitpickings to the last patch. I try to get places with >> lacking of variables' initialization. >> All other things seem good for me now. I'll cont

Re: [HACKERS] identity columns

2017-04-05 Thread Vitaly Burovoy
On 4/4/17, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > On 4/3/17, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: >> On 3/30/17 22:57, Vitaly Burovoy wrote: >>> Why do you still want to leave "ADD IF NOT EXISTS" instead of using >&

Re: [HACKERS] identity columns

2017-04-04 Thread Vitaly Burovoy
On 4/3/17, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 3/30/17 22:57, Vitaly Burovoy wrote: >> Why do you still want to leave "ADD IF NOT EXISTS" instead of using >> "SET IF NOT EXISTS"? >> If someone wants to follow the stan

Re: [HACKERS] identity columns

2017-03-30 Thread Vitaly Burovoy
On 3/29/17, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 3/24/17 05:29, Vitaly Burovoy wrote: >> It would be great if "DROP IDENTITY IF EXISTS" is in the current patch >> since we don't have any disagreements about "DROP IDENTITY" b

Re: [HACKERS] sequence data type

2017-03-30 Thread Vitaly Burovoy
On 3/30/17, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > On 3/29/17, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: >> On 3/29/17, Michael Paquier <michael.paqu...@gmail.com> wrote: >>> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy >>> &

Re: [HACKERS] sequence data type

2017-03-30 Thread Vitaly Burovoy
On 3/30/17, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > On 3/29/17, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: >> On 3/29/17, Michael Paquier <michael.paqu...@gmail.com> wrote: >>> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy >>> &

Re: [HACKERS] sequence data type

2017-03-30 Thread Vitaly Burovoy
On 3/29/17, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > On 3/29/17, Michael Paquier <michael.paqu...@gmail.com> wrote: >> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy >> <vitaly.buro...@gmail.com> wrote: >>> I think min_value and

Re: [HACKERS] sequence data type

2017-03-29 Thread Vitaly Burovoy
On 3/29/17, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy > <vitaly.buro...@gmail.com> wrote: >> I think min_value and max_value should not be set to "1" or "-1" but >> to real min/max of the

Re: [HACKERS] sequence data type

2017-03-29 Thread Vitaly Burovoy
e_test11 AS int NO MINVALUE NO MAXVALUE INCREMENT 1; ALTER SEQUENCE sequence_test11 AS int NO MINVALUE NO MAXVALUE INCREMENT -1; -- 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] identity columns

2017-03-24 Thread Vitaly Burovoy
On 3/23/17, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 3/23/17 06:09, Vitaly Burovoy wrote: >> I think we'll end up with "DROP IDENTITY IF EXISTS" to avoid raising >> an exception and "ADD OR SET" if your grammar remains. > > T

Re: [HACKERS] identity columns

2017-03-23 Thread Vitaly Burovoy
On 3/22/17, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 3/22/17 03:59, Vitaly Burovoy wrote: >> Column's IDENTITY behavior is very similar to a DEFAULT one. We write >> "SET DEFAULT" and don't care whether it was set before or not, becaus

Re: [HACKERS] identity columns

2017-03-22 Thread Vitaly Burovoy
On 3/21/17, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 3/21/17 16:11, Vitaly Burovoy wrote: >> My argument is consistency. >> Since IDENTITY is a property of a column (similar to DEFAULT, NOT >> NULL, attributes, STORAGE, etc.), it follows a differen

Re: [HACKERS] identity columns

2017-03-21 Thread Vitaly Burovoy
who will know nothing about sequences (because they'll deal with identity columns). Would it be better to change bounds of a sequence if they match the bounds of an old type (to the bounds of a new type)? > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Developmen

Re: [HACKERS] identity columns

2017-03-20 Thread Vitaly Burovoy
On 2/28/17, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > New patch that fixes everything. ;-) Great work! > On 1/4/17 19:34, Vitaly Burovoy wrote: >> 1. The fact COPY ignores GENERATED ALWAYS constraint (treats as >> GENERATED BY DEFAULT) should be me

Re: [HACKERS] identity columns

2017-03-15 Thread Vitaly Burovoy
On 3/15/17, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > Vitaly, will you be able to review this again? > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ I apologize for a delay. Yes, I'm going to do it by Sunday. -- Best regards, Vitaly Buro

[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-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] 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-05 Thread Vitaly Burovoy
(there is no UB[2] because source and destination are not signed). Moreover you've already fill in "hibits" the topmost byte by shifting by 24. If you use those two macros ("hibits" and "lobits") it allows to avoid two extra comparisons in macaddr8_cmp_internal. Version from the "macaddr64_poc.patch" is correct. [1]https://www.postgresql.org/message-id/CAKOSWNng9_+=fvo6oz4tgv1kkhmom11ankihbokpuzki1ca...@mail.gmail.com [2]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1817.htm -- 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] Re: [BUGS][PATCH] BUG #14486: Inserting and selecting interval have different constraints

2017-01-05 Thread Vitaly Burovoy
On 1/5/17, Tom Lane <t...@sss.pgh.pa.us> wrote: > Vitaly Burovoy <vitaly.buro...@gmail.com> writes: >> On 1/5/17, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> My point is that ideally, any value that can physically fit into struct >>> Interval ought to be

Re: [HACKERS] Re: [BUGS][PATCH] BUG #14486: Inserting and selecting interval have different constraints

2017-01-05 Thread Vitaly Burovoy
On 1/5/17, Tom Lane <t...@sss.pgh.pa.us> wrote: > Vitaly Burovoy <vitaly.buro...@gmail.com> writes: >> On 1/5/17, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> We could think about replacing interval2tm's output format with some >>> other struct that uses

Re: [HACKERS] Re: [BUGS][PATCH] BUG #14486: Inserting and selecting interval have different constraints

2017-01-05 Thread Vitaly Burovoy
On 1/5/17, Tom Lane <t...@sss.pgh.pa.us> wrote: > Vitaly Burovoy <vitaly.buro...@gmail.com> writes: >>> I've written a patch which fixes that bug (in attachment). >>> Should it be registered in the CF? > >> Oops. Forgot to attach the patch. Fixed. > &g

[HACKERS] Re: [BUGS][PATCH] BUG #14486: Inserting and selecting interval have different constraints

2017-01-05 Thread Vitaly Burovoy
On 1/5/17, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > On 1/4/17, Pantelis Theodosiou <yperc...@gmail.com> wrote: >> On Wed, Jan 4, 2017 at 3:03 PM, <web+postgre...@modin.io> wrote: >> >>> The following bug has been logged on the website: &g

[HACKERS] Re: [BUGS][PATCH] BUG #14486: Inserting and selecting interval have different constraints

2017-01-05 Thread Vitaly Burovoy
> postgres=# select col from xx where col < interval '10 year' ; > col > - > (0 rows) > Yes, it is a bug, but it is not a constraint, it is just different internal checks. Moreover even if a function does not raise an error, output could be wrong (pay attention to the du

Re: [HACKERS] identity columns

2017-01-04 Thread Vitaly Burovoy
finally. The command: test=# CREATE TABLE t(i int GENERATED BY DEFAULT AS IDENTITY (SEQUENCE NAME s)); leads to a core dump. It happens when no sequence parameter (like "START") is set. [1]https://www.postgresql.org/docs/devel/static/sql-createtable.html -- 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

2016-10-12 Thread Vitaly Burovoy
On 10/12/16, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: >> Tom Lane wrote: >>> Vitaly Burovoy <vitaly.buro...@gmail.com> writes: >>>> P.S.: I still think it is a good idea to change storage format,

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

2016-10-12 Thread Vitaly Burovoy
On 10/12/16, Tom Lane <t...@sss.pgh.pa.us> wrote: > Vitaly Burovoy <vitaly.buro...@gmail.com> writes: >> I'm sorry for the offtopic, but does anyone know a reason why a >> condition in mac.c > >>> if ((a < 0) || (a > 255) || (b < 0) || (b > 25

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

2016-10-12 Thread Vitaly Burovoy
t be rewritten as: > if (((a | b | c | d | e | f) < 0) || > ((a | b | c | d | e | f) > 255)) It seems more compact and a compiler can optimize it to keep a result of a binary OR for the comparison with 255... -- Best regards, Vitaly Burovoy -- Sent via pgsql-hackers mailing li

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

2016-10-12 Thread Vitaly Burovoy
On 10/12/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > On 10/12/16, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: >> Julien Rouhaud wrote: >>> On 12/10/2016 14:32, Alvaro Herrera wrote: >>> > Julien Rouhaud wrote: >>> > >>

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

2016-10-12 Thread Vitaly Burovoy
type macaddr. Right? > > (The cast function from macaddr8 to macaddr would raise error if the > 4th and 5th bytes are not either FF:FF or FF:FE -- I don't think we can > in practice distinguish EUI-48 from MAC-48 in this context. The wikipedia says[1] they are the same things but MAC-4

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
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

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, Tom Lane <t...@sss.pgh.pa.us> wrote: > Serge Rielau <se...@rielau.com> writes: >>> On Oct 6, 2016, at 5:25 AM, Vitaly Burovoy <vitaly.buro...@gmail.com> >>> wrote: >>>> Which makes me think we should call this missing_value or ab

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-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] 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
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
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
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
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

[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

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] Proposal: ON UPDATE REMOVE foreign key action

2016-10-03 Thread Vitaly Burovoy
utomatically removing on update event is more > rational. I personally don't see necessity to introduce new non-spec grammar. If you think I has not understood you, send an example with schema --- what you have now and how you expect it should be. -- 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] pg_hba_file_settings view patch

2016-10-03 Thread Vitaly Burovoy
On 10/2/16, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Mon, Oct 3, 2016 at 3:25 PM, Vitaly Burovoy <vitaly.buro...@gmail.com> > wrote: >> I guess for ability to use filtering like: >> >> SELECT * FROM pg_hba_rules WHERE options->>radiusser

Re: [HACKERS] pg_hba_file_settings view patch

2016-10-03 Thread Vitaly Burovoy
HERE options->>radiusserver LIKE '%.example.com'; I think it would be harder if options is an array of strings... -- 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] Question / requests.

2016-09-30 Thread Vitaly Burovoy
from one of simple patches in a commitfest to be familiar with the process. -- 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] Detect supported SET parameters when pg_restore is run

2016-09-27 Thread Vitaly Burovoy
On 9/27/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > On 9/27/16, Tom Lane <t...@sss.pgh.pa.us> wrote: >> (The other thing I'd want here is a --target-version option so that >> you could get the same output alterations in pg_dump or pg_restore to >> text.

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-27 Thread Vitaly Burovoy
On 9/27/16, Tom Lane <t...@sss.pgh.pa.us> wrote: > Vitaly Burovoy <vitaly.buro...@gmail.com> writes: >> On 9/27/16, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I'm not exactly convinced that you did. There's only one copy of >>> Archive->remo

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-27 Thread Vitaly Burovoy
On 9/27/16, Tom Lane <t...@sss.pgh.pa.us> wrote: > Vitaly Burovoy <vitaly.buro...@gmail.com> writes: >> On 9/27/16, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> The general policy has always been that pg_dump output is only expected >>> to >>>

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-27 Thread Vitaly Burovoy
On 9/27/16, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Sep 26, 2016 at 9:56 PM, Vitaly Burovoy >> <vitaly.buro...@gmail.com> wrote: >>> We do dump/restore schemas/data via custom/dir formats and we have t

[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] 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][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][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-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] 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][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-

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] 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] 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

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] 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] 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] 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] 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] 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

[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] [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] [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] 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

[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] [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

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] [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
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] [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

[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] [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. &

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] [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-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][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

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] [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] 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

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

  1   2   >