Re: [HACKERS] sequence data type

On 4/4/17, Peter Eisentraut 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 cases of changing bounds when >> data

Re: [HACKERS] sequence data type

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 cases of changing bounds when > data type is changed. Committed all that. Thanks! -- Peter Eisentraut

Re: [HACKERS] sequence data type

On 3/30/17, Vitaly Burovoy wrote: > On 3/29/17, Vitaly Burovoy wrote: >> On 3/29/17, Michael Paquier wrote: >>> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy >>> wrote: I think

Re: [HACKERS] sequence data type

On 3/30/17, Vitaly Burovoy wrote: > On 3/29/17, Vitaly Burovoy wrote: >> On 3/29/17, Michael Paquier wrote: >>> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy >>> wrote: I think

Re: [HACKERS] sequence data type

On 3/29/17, Vitaly Burovoy wrote: > On 3/29/17, Michael Paquier wrote: >> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy >> wrote: >>> I think min_value and max_value should not be set to "1" or "-1" but >>> to

Re: [HACKERS] sequence data type

On 3/29/17, Michael Paquier wrote: > On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy > wrote: >> I think min_value and max_value should not be set to "1" or "-1" but >> to real min/max of the type by default. > > This is the default behavior

Re: [HACKERS] sequence data type

On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy wrote: > I think min_value and max_value should not be set to "1" or "-1" but > to real min/max of the type by default. This is the default behavior for ages, since e8647c45 to be exact. So you would change 20 years of

Re: [HACKERS] sequence data type

On 3/29/17, Peter Eisentraut wrote: > Over at > > is is being discussed that maybe the behavior when altering the sequence > type isn't so great, because it

Re: [HACKERS] sequence data type

On Thu, Mar 30, 2017 at 2:36 AM, Peter Eisentraut wrote: > Over at > > is is being discussed that maybe the behavior when altering the sequence > type isn't

Re: [HACKERS] sequence data type

Over at is is being discussed that maybe the behavior when altering the sequence type isn't so great, because it currently doesn't update the min/max values of the sequence at all. So here

Re: [HACKERS] sequence data type

On 2/1/17 10:01 PM, Michael Paquier wrote: > On Wed, Feb 1, 2017 at 10:02 AM, Michael Paquier > wrote: >> On Wed, Feb 1, 2017 at 1:11 AM, Peter Eisentraut >> wrote: >>> And here is a rebased patch for the original feature. I think

Re: [HACKERS] sequence data type

On Wed, Feb 1, 2017 at 10:02 AM, Michael Paquier wrote: > On Wed, Feb 1, 2017 at 1:11 AM, Peter Eisentraut > wrote: >> And here is a rebased patch for the original feature. I think this >> addresses all raised concerns and suggestions

Re: [HACKERS] sequence data type

On Wed, Feb 1, 2017 at 1:11 AM, Peter Eisentraut wrote: > And here is a rebased patch for the original feature. I think this > addresses all raised concerns and suggestions now. Thanks for the new version. That looks good to me after an extra lookup. --

Re: [HACKERS] sequence data type

And here is a rebased patch for the original feature. I think this addresses all raised concerns and suggestions now. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From ce2680ef072a9a4dc2cb879a70610d71ad24

Re: [HACKERS] sequence data type

On 1/30/17 12:42 AM, Michael Paquier wrote: > Sure. Thanks for looking into that and getting a patch out. Oh, I have > just noticed that sequence_1.out has been removed by 9c18104c. That's > nice. > Looking at the patch adding some new tests, the coverage really > increases (I did not run make

Re: [HACKERS] sequence data type

On Sat, Jan 28, 2017 at 2:49 AM, Peter Eisentraut wrote: > On 1/25/17 11:57 PM, Michael Paquier wrote: >> @@ -15984,6 +15992,9 @@ dumpSequence(Archive *fout, TableInfo *tbinfo) >> "CREATE SEQUENCE %s\n", >>

Re: [HACKERS] sequence data type

On 1/25/17 11:57 PM, Michael Paquier wrote: > @@ -15984,6 +15992,9 @@ dumpSequence(Archive *fout, TableInfo *tbinfo) > "CREATE SEQUENCE %s\n", > fmtId(tbinfo->dobj.name)); > > + if (strcmp(seqtype, "bigint") != 0) > + appendPQExpBuffer(query, "

Re: [HACKERS] sequence data type

On Wed, Jan 25, 2017 at 11:53 PM, Peter Eisentraut wrote: > Here is an updated patch that allows changing the sequence type. This > was clearly a concern for reviewers, and the presented use cases seemed > convincing. I have been torturing this patch and it

Re: [HACKERS] sequence data type

Here is an updated patch that allows changing the sequence type. This was clearly a concern for reviewers, and the presented use cases seemed convincing. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From

Re: [HACKERS] sequence data type

Peter Eisentraut wrote: > So in order to correctly answer the question, is the sequence about to > run out, you need to look not only at > the sequence but also any columns it is associated with. check_postgres > figures this out, but it's complicated and slow, and not easy to do >

Re: [HACKERS] sequence data type

Michael Paquier wrote: > Hm. Is symmetry an important properly for sequences? It seems to me > that if we map with the data types we had better use the MIN values > instead for consistency. So the concept of this patch is rather weird > and would introduce an exception with the rest of

Re: [HACKERS] sequence data type

> "Daniel" == Daniel Verite writes: Daniel> Consider the case of a table with a SERIAL column which later Daniel> has to become a BIGINT due to growth. Currently a user would Daniel> just alter the column's type and does need to do anything with Daniel> the

Re: [HACKERS] sequence data type

Peter Eisentraut wrote: > This could probably be sorted out somehow, but I don't want > to be too lax now and cause problems for later features. There is a > similar case, namely changing the return type of a function, which we > also prohibit. Consider the case of a table with a SERIAL

Re: [HACKERS] sequence data type

On Tue, Jan 10, 2017 at 5:03 AM, Peter Eisentraut wrote: > On 1/8/17 2:39 PM, Steve Singer wrote: >> The only concern I have with the functionality is that there isn't a way >> to change the type of a sequence. > > If we implement the NEXT VALUE FOR expression

Re: [HACKERS] sequence data type

On 1/8/17 2:39 PM, Steve Singer wrote: > The only concern I have with the functionality is that there isn't a way > to change the type of a sequence. If we implement the NEXT VALUE FOR expression (or anything similar that returns a value from the sequence), then the return type of that

Re: [HACKERS] sequence data type

On 12/31/2016 01:27 AM, Peter Eisentraut wrote: Another updated patch, with quite a bit of rebasing and some minor code polishing. Patch applies cleanly and the tests pass The feature seems to work as expected. I've tried this out and it behaves as expected and desired. I also tested the

Re: [HACKERS] sequence data type

On 9/8/16 4:06 PM, Peter Eisentraut wrote: > On 9/3/16 2:41 PM, Vik Fearing wrote: >> On 08/31/2016 06:22 AM, Peter Eisentraut wrote: >>> Here is a patch that adds the notion of a data type to a sequence. So >>> it might be CREATE SEQUENCE foo AS integer. The types are restricted to >>>

Re: [HACKERS] sequence data type

On Tue, Nov 22, 2016 at 10:54 PM, Haribabu Kommi wrote: > Hi Vik and Vinayak, > > This is a gentle reminder. > > you both are assigned as reviewer's to the current patch in the 11-2016 > commitfest. > But you haven't shared your review yet. Please share your review

Re: [HACKERS] sequence data type

Hi Vik and Vinayak, This is a gentle reminder. you both are assigned as reviewer's to the current patch in the 11-2016 commitfest. But you haven't shared your review yet. Please share your review about the patch. This will help us in smoother operation of commitfest. Please Ignore if you

Re: [HACKERS] sequence data type

On Sun, Sep 11, 2016 at 12:38 PM, Vitaly Burovoy wrote: > On 9/10/16, Jim Nasby wrote: >> On 9/3/16 6:01 PM, Gavin Flower wrote: >>> I am curious as to the use cases for other possibilities. >> >> A hex or base64 type might be interesting,

Re: [HACKERS] sequence data type

On 9/10/16, Jim Nasby wrote: > On 9/3/16 6:01 PM, Gavin Flower wrote: >> I am curious as to the use cases for other possibilities. > > A hex or base64 type might be interesting, should those ever get created... > -- > Jim Nasby, Data Architect, Blue Treble Consulting,

Re: [HACKERS] sequence data type

On 9/3/16 6:01 PM, Gavin Flower wrote: I am curious as to the use cases for other possibilities. A hex or base64 type might be interesting, should those ever get created... -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL

Re: [HACKERS] sequence data type

On 9/3/16 2:41 PM, Vik Fearing wrote: > On 08/31/2016 06:22 AM, Peter Eisentraut wrote: >> Here is a patch that adds the notion of a data type to a sequence. So >> it might be CREATE SEQUENCE foo AS integer. The types are restricted to >> int{2,4,8} as now. > > This patch does not apply cleanly

Re: [HACKERS] sequence data type

On 04/09/16 06:41, Vik Fearing wrote: On 08/31/2016 06:22 AM, Peter Eisentraut wrote: Here is a patch that adds the notion of a data type to a sequence. So it might be CREATE SEQUENCE foo AS integer. The types are restricted to int{2,4,8} as now. This patch does not apply cleanly to current

Re: [HACKERS] sequence data type

On 08/31/2016 06:22 AM, Peter Eisentraut wrote: > Here is a patch that adds the notion of a data type to a sequence. So > it might be CREATE SEQUENCE foo AS integer. The types are restricted to > int{2,4,8} as now. This patch does not apply cleanly to current master (=600dc4c). -- Vik Fearing

[HACKERS] sequence data type

Here is a patch that adds the notion of a data type to a sequence. So it might be CREATE SEQUENCE foo AS integer. The types are restricted to int{2,4,8} as now. The main point of this is to make monitoring sequences less complicated. Right now, a serial column creates an int4 column but