Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > 2. I had first dismissed Neil's idea of transactional sequence updates
> > as impossible, but on second look it could be done. Suppose RESTART
> > IDENTITY does this for each sequence;
> >
> > * obtain AccessExclusiveLock;
> > * assign a new
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 2. I had first dismissed Neil's idea of transactional sequence updates
>> as impossible, but on second look it could be done. Suppose RESTART
>> IDENTITY does this for each sequence;
>>
>> * obtain AccessExclusiveLock;
>> * assign a
Tom Lane wrote:
> 2. I had first dismissed Neil's idea of transactional sequence updates
> as impossible, but on second look it could be done. Suppose RESTART
> IDENTITY does this for each sequence;
>
> * obtain AccessExclusiveLock;
> * assign a new relfilenode;
> * insert a se
On Sat, 2008-05-17 at 12:04 -0400, Tom Lane wrote:
> So what I think we should do is leave the patch there, revise the
> warning per Neil's complaint, and add a TODO item to reimplement
> RESTART IDENTITY transactionally.
Sounds good.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL T
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2008-05-16 at 21:50 -0400, Tom Lane wrote:
>> Actually, I agree. Shall we just revert that feature?
> Perhaps, but we should also take into account that TRUNCATE is not and
> never will be MVCC compliant, so its not something you'd expect to run
>
On Fri, 2008-05-16 at 21:50 -0400, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Ugh. The fact that the RESTART IDENTITY part of TRUNCATE is
> > non-transactional is a pretty unsightly wort.
>
> Actually, I agree. Shall we just revert that feature? The ALTER
> SEQUENCE part of t
Neil Conway <[EMAIL PROTECTED]> writes:
> Ugh. The fact that the RESTART IDENTITY part of TRUNCATE is
> non-transactional is a pretty unsightly wort.
Actually, I agree. Shall we just revert that feature? The ALTER
SEQUENCE part of this patch is clean and useful, but I'm less than
enamored of the
On Fri, 2008-05-16 at 19:41 -0400, Tom Lane wrote:
> Applied with corrections. Most notably, since ALTER SEQUENCE RESTART
> is nontransactional like most other ALTER SEQUENCE operations, I
> rearranged things to try to ensure that foreseeable failures like
> deadlock and lack of permissions would
I wrote:
> One interesting point here is that the patch as submitted allowed
> ALTER SEQUENCE MINVALUE/MAXVALUE to be used to set a sequence range
> that the original START value was outside of. This would result in
> a failure at ALTER SEQUENCE RESTART. Since, as stated above, we
> really don't
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
>> Attached patch implements the extension found in the current SQL200n draft,
>> implementing stored start value and supporting ALTER SEQUENCE seq RESTART;
> Updated patch implements TRUNCATE ... RESTART IDENTITY
> which restarts all owned sequences
Zoltan Boszormenyi wrote:
> I just saw this on the CommitFest:May page:
>
> "alvherre says: I'm not sure if this is the same patch in the previous
> entry, or a different feature"
>
> I wanted to clarify, the second patch contains two features.
> 1. stored start value for sequences, ALTER SEQUEN
Hi,
Zoltan Boszormenyi írta:
Updated patch implements TRUNCATE ... RESTART IDENTITY
which restarts all owned sequences for the truncated table(s).
Regression tests updated, documentation added. pg_dump was
also extended to output original[1] START value for creating SEQUENCEs.
[1] For 8.3 and b
Zoltan Boszormenyi írta:
Zoltan Boszormenyi írta:
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the
Zoltan Boszormenyi írta:
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the minimum value.
There's
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the minimum value.
There's the START WITH option for
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the minimum value.
--
Decibel!, aka Jim C. Nasby, Database Architect
Decibel! írta:
On Mar 25, 2008, at 11:40 AM, Zoltan Boszormenyi wrote:
All of them? PostgreSQL allow multiple SERIALs to be present,
the standard allows only one IDENTITY column in a table.
And what about this case below?
CREATE TABLE t1 (id1 serial, ...);
ALTER SEQUENCE seq_t1_id1 RESTART WITH
On Mar 25, 2008, at 11:40 AM, Zoltan Boszormenyi wrote:
All of them? PostgreSQL allow multiple SERIALs to be present,
the standard allows only one IDENTITY column in a table.
And what about this case below?
CREATE TABLE t1 (id1 serial, ...);
ALTER SEQUENCE seq_t1_id1 RESTART WITH 5432 CYCLE;
or
Zoltan Boszormenyi írta:
Simon Riggs írta:
On Tue, 2008-03-25 at 09:08 -0700, Steve Crawford wrote:
Simon Riggs wrote:
RESTART IDENTITY will reset the SERIAL sequences back to the original
start value.
Assuming this feature were to be added
In cases where the same sequence
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> SQL200n specifies a new qualifier on a TRUNCATE command
>
> TRUNCATE TABLE foo
> [ CONTINUE IDENTITY | RESTART IDENTITY ]
>
> CONTINUE IDENTITY is the default and does nothing, like now.
>
> RESTART IDENTITY will reset the SERIAL sequences back to
Zoltan Boszormenyi wrote:
> All of them? PostgreSQL allow multiple SERIALs to be present,
> the standard allows only one IDENTITY column in a table.
> And what about this case below?
>
> CREATE TABLE t1 (id1 serial, ...);
> ALTER SEQUENCE seq_t1_id1 RESTART WITH 5432 CYCLE;
>
> or the equivalent
Simon Riggs írta:
On Tue, 2008-03-25 at 09:08 -0700, Steve Crawford wrote:
Simon Riggs wrote:
RESTART IDENTITY will reset the SERIAL sequences back to the original
start value.
Assuming this feature were to be added
In cases where the same sequence has been used across m
On Tue, 2008-03-25 at 09:08 -0700, Steve Crawford wrote:
> Simon Riggs wrote:
> > RESTART IDENTITY will reset the SERIAL sequences back to the original
> > start value.
> >
> Assuming this feature were to be added
>
> In cases where the same sequence has been used across multiple tables,
>
Simon Riggs wrote:
RESTART IDENTITY will reset the SERIAL sequences back to the original
start value.
Assuming this feature were to be added
In cases where the same sequence has been used across multiple tables,
what will be the appropriate response when a user attempts to TRUNCATE
one
On Tue, 2008-03-25 at 11:48 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > SQL200n specifies a new qualifier on a TRUNCATE command
> > TRUNCATE TABLE foo
> > [ CONTINUE IDENTITY | RESTART IDENTITY ]
>
> > CONTINUE IDENTITY is the default and does nothing, like now.
>
> >
Simon Riggs <[EMAIL PROTECTED]> writes:
> SQL200n specifies a new qualifier on a TRUNCATE command
> TRUNCATE TABLE foo
> [ CONTINUE IDENTITY | RESTART IDENTITY ]
> CONTINUE IDENTITY is the default and does nothing, like now.
> RESTART IDENTITY will reset the SERIAL sequences back to the ori
SQL200n specifies a new qualifier on a TRUNCATE command
TRUNCATE TABLE foo
[ CONTINUE IDENTITY | RESTART IDENTITY ]
CONTINUE IDENTITY is the default and does nothing, like now.
RESTART IDENTITY will reset the SERIAL sequences back to the original
start value.
Seems like a % project for
27 matches
Mail list logo
