FarjadFarid(ChkNet) schrieb am 02.09.2015 um 11:05:
> How can I obtain the initial and incremental value of a serial entity?
You can use:
select *
from sequence_name;
where "sequence_name" is the name of the sequence associated with your column.
Thomas
--
Sent via pgsql-general mai
Sorry folks,
I should have included this in my last question.
How can I obtain the initial and incremental value of a serial entity?
Many thanks
Best Regards
Farjad Farid
On 03/16/2012 08:00 AM, salah jubeh wrote:
Hello Adrian,
Sorry, I was not clear.
what I meant is that.
GRANT INSERT, UPDATE ON tablenaem TO USER; -- leads to GRANT ALL ON
TABLE tablename_colname_seq TO USER
Another thought you do not happen to have DEFAULT PRIVILEGES set up for
sequences:
On 03/16/2012 08:00 AM, salah jubeh wrote:
Hello Adrian,
Sorry, I was not clear.
what I meant is that.
GRANT INSERT, UPDATE ON tablenaem TO USER; -- leads to GRANT ALL ON
TABLE tablename_colname_seq TO USER
CCing the list.
Still not following.
What version of Postgres are you using?
Using 9.
On 03/16/2012 07:06 AM, salah jubeh wrote:
Hello,
When creating a serial, a sequence is created automatically.
CREATE TABLEtablename (
colname SERIAL
);
CREATE SEQUENCE tablename_colname_seq;
CREATE TABLE tablename (
colname integer NOT NULL DEFAULT nextval('tablename_colname_seq')
Hello,
When creating a serial, a sequence is created automatically.
CREATE TABLE tablename ( colname SERIAL
);
CREATE SEQUENCE tablename_colname_seq;
CREATE TABLE tablename ( colname integer NOT NULL DEFAULT
nextval('tablename_colname_seq')
);
ALTER SEQUENCE tablename_colname_seq OWNED BY tablen
On 01/31/11 10:55 PM, Adarsh Sharma wrote:
Dear all,
I am not able to distinct these two datatypes ( Serial and Sequence )
in Postgresql which resembles like auto-increment in Mysql.
Which one gets priority and When ?
The only thing I am able to find is to use SERIAL because if a drop
table
Hello
SEQUENCE isn't datatype. It is a database object. Simple object, that
can to generate unique integer numbers.
SERIAL is a fictive datatype. It can create a own SEQUENCE object and
can create a reference on this object.
pavel=# create sequence ;
CREATE SEQUENCE
Time: 461.883 ms
pavel=#
Dear all,
I am not able to distinct these two datatypes ( Serial and Sequence ) in
Postgresql which resembles like auto-increment in Mysql.
Which one gets priority and When ?
The only thing I am able to find is to use SERIAL because if a drop
table occurs , still SEQUENCE memory is not freed
On Sat, Dec 18, 2010 at 7:12 AM, Vishnu S. wrote:
> I am using Slony-I slony-I-2.0.2 in windows .I have a master and a slave
> machine. The replication is working fine. When the master switches to slave
> , there exists a serial key mismatch in master and slave machines. So
> insertion fails in th
Hi,
I am using Slony-I slony-I-2.0.2 in windows .I have a master and a slave
machine. The replication is working fine. When the master switches to
slave , there exists a serial key mismatch in master and slave machines.
So insertion fails in the slave machines. I am using the failover
comman
Sean,
take a look at UUID type. It might suit you better than serial.
Changing the increment also works, but puts a lot of restrictions on you
(such as planning to prevent collision, having to change the increment on
several nodes when adding a new node, etc.).
Regards,
--
Jorge Godoy
O
Dear all,
At work we're considering using postgres in a cluster. But I am
wondering what implications does multi-master write replication have
on auto-incrementing serial columns?
E.g. Do we need to fiddle with the increment amount depending on the
number of nodes we have?
--
Thanks and regards,
On 2009-01-27, db.subscripti...@shepherdhill.biz
wrote:
> Hi,
>
> I have a table with BIG SERIAL field as Primary KEY. During high load,
> entries in the BIG SERIAL field are jumped. One could see a row with
> 1367 and expecting the next INSERT to be 1368, one would end up
> getting 1369.
>
> Ple
On Tue, 2009-01-27 at 05:55 +0100, db.subscripti...@shepherdhill.biz
wrote:
> I have a table with BIG SERIAL field as Primary KEY. During high load,
> entries in the BIG SERIAL field are jumped. One could see a row with
> 1367 and expecting the next INSERT to be 1368, one would end up
> getting 13
In response to db.subscripti...@shepherdhill.biz :
> Hi,
>
> I have a table with BIG SERIAL field as Primary KEY. During high load,
> entries in the BIG SERIAL field are jumped. One could see a row with
> 1367 and expecting the next INSERT to be 1368, one would end up
> getting 1369.
>
> Please i
Bill Moran wrote:
> db.subscripti...@shepherdhill.biz wrote:
>> Hi,
>>
>> I have a table with BIG SERIAL field as Primary KEY. During high load,
>> entries in the BIG SERIAL field are jumped. One could see a row with
>> 1367 and expecting the next INSERT to be 1368, one would end up
>> getting 1369
db.subscripti...@shepherdhill.biz wrote:
>
> Hi,
>
> I have a table with BIG SERIAL field as Primary KEY. During high load,
> entries in the BIG SERIAL field are jumped. One could see a row with
> 1367 and expecting the next INSERT to be 1368, one would end up
> getting 1369.
>
> Please is this n
Hi,
I have a table with BIG SERIAL field as Primary KEY. During high load,
entries in the BIG SERIAL field are jumped. One could see a row with
1367 and expecting the next INSERT to be 1368, one would end up
getting 1369.
Please is this normal?
Regards,
Chris
--
Sent via pgsql-general mailing
On Fri, Dec 5, 2008 at 8:24 AM, Thomas Kellerer <[EMAIL PROTECTED]> wrote:
> Scott Marlowe, 04.12.2008 16:34:
>>
>> Like an Oracle DBA who told me
>> pgsql was broken because the output of group by wasn't properly
>> ordered like it was on Oracle 9.
>
> Then he did not know Oracle very well :)
> Ev
Scott Marlowe, 04.12.2008 16:34:
Like an Oracle DBA who told me
pgsql was broken because the output of group by wasn't properly
ordered like it was on Oracle 9.
Then he did not know Oracle very well :)
Even Oracle 9 does not guarantee that the output of an GROUP BY is actually sorted, with
On 04/12/2008 14:47, Gregory Williamson wrote:
> With respect, sir, let me point out that Informix usage says to insert a
> zero to trigger a serial column, so don't be indicting Gustavo on MySQL
So what do you do if you just want to insert a zero? - just curious...
In fairness, I suppose you wo
On Thu, Dec 4, 2008 at 7:47 AM, Gregory Williamson
<[EMAIL PROTECTED]> wrote:
> The esteemed Scott Marlowe said:
>
>>
>> On Thu, Dec 4, 2008 at 7:42 AM, Gustavo Rosso <[EMAIL PROTECTED]>
>> wrote:
>> > I created this table:
>> >
> <...>
>>
>> Because MySQL taught you bad habits? You told the db to
The esteemed Scott Marlowe said:
>
> On Thu, Dec 4, 2008 at 7:42 AM, Gustavo Rosso <[EMAIL PROTECTED]> wrote:
> > I created this table:
> >
<...>
>
> Because MySQL taught you bad habits? You told the db to insert a 0,
> so it inserted a 0.
With respect, sir, let me point out that Informix us
On Thu, Dec 4, 2008 at 7:06 AM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 4, 2008 at 7:42 AM, Gustavo Rosso <[EMAIL PROTECTED]> wrote:
>> I created this table:
>>
>> create table se (n serial);
>>
>> Column | Type | Modifiers
>> -+-+
On Thu, Dec 4, 2008 at 7:42 AM, Gustavo Rosso <[EMAIL PROTECTED]> wrote:
> I created this table:
>
> create table se (n serial);
>
> Column | Type | Modifiers
> -+-+
> n | integer| not null defaul
2008/12/4 Gustavo Rosso <[EMAIL PROTECTED]>:
> I created this table:
>
> create table se (n serial);
>
> Column | Type | Modifiers
> -+-+
> n | integer| not null default nextval('se_n_seq'::regcla
On Thu, Dec 4, 2008 at 3:42 PM, Gustavo Rosso <[EMAIL PROTECTED]> wrote:
> I created this table:
>
> create table se (n serial);
>
> Column | Type | Modifiers
> -+-+
> n | integer| not null defau
On Thu, Dec 4, 2008 at 2:42 PM, Gustavo Rosso <[EMAIL PROTECTED]> wrote:
> I created this table:
>
> create table se (n serial);
>
in case you did just insert into se(n) values(0); twice, it won't work
if you want to add series of numbers, don't define it as serial.
Serial is for a different purpo
I created this table:
create table se (n serial);
Column | Type | Modifiers
-+-+
n | integer| not null default nextval('se_n_seq'::regclass)
I inserted two record, later select, but column n (
On Tue, Nov 25, 2008 at 05:39:49PM +0930, Michael Hall wrote:
> On Tue, Nov 25, 2008 at 08:26:55AM +0100, A. Kretschmer wrote:
> > Set the sequence to the new value, 3636+9, via
> > setval('your_sequence', 3636+9)
>
> I'll re-import the data with DEFAULT in the id (SERIAL) column,
> hopefully new
> The 3636 INSERT-Statements contains a fix value for the ID-Column,
> right? Thats wrong, omit the id-column and value or use simply 'default' for
> it.
That's right. I thought that might be the case.
> > - how can I rectify the situation?
> Set the sequence to the new value, 3636+9, via
> s
am Tue, dem 25.11.2008, um 16:41:43 +0930 mailte Mike Hall folgendes:
> I have just imported 3636 rows into a PG database table (PG 8.1 on CentOS 5.2
> ... the default).
> The rows were imported using separate INSERT statements for each row. All OK
> so far.
>
> After having had a few attempts
I have just imported 3636 rows into a PG database table (PG 8.1 on CentOS 5.2
... the default).
The rows were imported using separate INSERT statements for each row. All OK so
far.
After having had a few attempts at inserting new test rows (which all inserted
OK), I notice that the last_value c
hendra kusuma wrote:
>
> Let me get this clear
> it should looks like this?
>
> create function something() returns integer as $$
> declare
> ret integer;
> begin
> -- just assume something table has a serial column as primary key
> insert into something values ('a value');
> select currv
hendra kusuma wrote:
> Hi there
> a little basic question here
>
> I usually use something like this in stored function
> to get the last value of a serial type column
>
> select last_value into ret from id_sequence
>> return ret
>
> What i'm asking is,
> if many people run the same stored funct
Hi there
a little basic question here
I usually use something like this in stored function
to get the last value of a serial type column
select last_value into ret from id_sequence
> return ret
>
What i'm asking is,
if many people run the same stored function at the same time
will they get the
EXT-Rothermel, Peter M wrote:
I have a table where I would like the primary key to be generated during
the insert.
Here is a simplified example:
CREATE TABLE employee_type
{
tname varchar(10) PRIMARY KEY,
id_prefix char(1) ;
...
}
tname | id_prefix
--+--
On Thursday 06 November 2008, "EXT-Rothermel, Peter M"
<[EMAIL PROTECTED]> wrote:
> I have thought about using the serial data type for the employee.id but
> I also want to automate the prepending of the { W, M, E } prefix.
>
You'll need write a before-insert trigger to assign the ID.
--
Alan
I have a table where I would like the primary key to be generated during
the insert.
Here is a simplified example:
CREATE TABLE employee_type
{
tname varchar(10) PRIMARY KEY,
id_prefix char(1) ;
...
}
tname | id_prefix
--+--
worker | W
manager | M
exec
Mark Roberts írta:
> On Mon, 2008-08-25 at 11:02 -0600, Scott Marlowe wrote:
>
>> Well, of course a 64 bit int is gonna be bigger than a 32 bit, but
>> with alignment issues and on 64 bit hardware, I'm guessing the
>> difference isn't exactly twice as slow / twice as much storage. And
>> it's w
On Mon, 2008-08-25 at 11:02 -0600, Scott Marlowe wrote:
> Well, of course a 64 bit int is gonna be bigger than a 32 bit, but
> with alignment issues and on 64 bit hardware, I'm guessing the
> difference isn't exactly twice as slow / twice as much storage. And
> it's way faster than a GUID which w
On Mon, Aug 25, 2008 at 10:23 AM, Mark Roberts
<[EMAIL PROTECTED]> wrote:
>
> On Thu, 2008-08-21 at 13:53 -0600, Scott Marlowe wrote:
>> Regular SERIAL type is limited to a 32 bit int. BIGSERIAL uses a 64
>> bit int.
>
> I think one of the things that would be offsetting is the size
> difference b
On Thu, 2008-08-21 at 13:53 -0600, Scott Marlowe wrote:
> Regular SERIAL type is limited to a 32 bit int. BIGSERIAL uses a 64
> bit int.
I think one of the things that would be offsetting is the size
difference between the two types (32 vs 64 bits, 5 foreign keys, and a
billion rows or so makes
On Aug 21, 2008, at 9:51 PM, Peter Billen wrote:
My concern is not that the table will become full, but that the
sequence will be exhausted. Doing INSERT, DELETE, INSERT,
DELETE ... will exhaust the sequence. What will happen then? Do I
have to manually re-order my serial values and reset t
On Thu, Aug 21, 2008 at 09:08:24PM +0200, Peter Billen wrote:
> Is it possible to insert a new entry? Will the serial sequence somehow
> be able to find the gap (3)?
As others have said, no it's not going to. Sequences will only return
values out of order when explicitly told to. The main reaso
Thanks. I thought it was a bit counter-intuitive to have a BIGSERIAL
while I will only have a few thousands of entries, which are updated (by
DELETE and INSERT) constantly.
Thanks Scott,
Peter
Scott Marlowe schreef:
On Thu, Aug 21, 2008 at 1:08 PM, Peter Billen <[EMAIL PROTECTED]> wrote:
On Thu, Aug 21, 2008 at 1:51 PM, Peter Billen <[EMAIL PROTECTED]> wrote:
> My concern is not that the table will become full, but that the sequence
> will be exhausted. Doing INSERT, DELETE, INSERT, DELETE ... will exhaust the
> sequence. What will happen then? Do I have to manually re-order my ser
On Thu, Aug 21, 2008 at 1:08 PM, Peter Billen <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I would like to ask a question about the serial datatype. Say I have a field
> of type serial, and say for the sake of example that the range of a serial
> goes from 1 to 5 (inclusive). I insert 5 (ed) entries in
My concern is not that the table will become full, but that the sequence
will be exhausted. Doing INSERT, DELETE, INSERT, DELETE ... will exhaust
the sequence. What will happen then? Do I have to manually re-order my
serial values and reset the start sequence ID to MAX() + 1?
Thanks in advance
On Aug 21, 2008, at 2:23 PM, Peter Billen wrote:
Oops, my example was a bit incorrectly edited.
I wanted to say that the range of a serial datatype goes from 1 to 5
(incluse) and I insert five entries (not 10).
Peter
Peter Billen schreef:
Hi all,
I would like to ask a question about the
Oops, my example was a bit incorrectly edited.
I wanted to say that the range of a serial datatype goes from 1 to 5
(incluse) and I insert five entries (not 10).
Peter
Peter Billen schreef:
Hi all,
I would like to ask a question about the serial datatype. Say I have a
field of type serial,
Hi all,
I would like to ask a question about the serial datatype. Say I have a
field of type serial, and say for the sake of example that the range of
a serial goes from 1 to 5 (inclusive). I insert 10 entries into the
table, so the table is 'full':
INSERT INTO my_table (my_serial) VALUES (D
"Adam Rich" <[EMAIL PROTECTED]> writes:
>> I have just created a table using SELECT INTO however the PK was
>> supposed to be a serial. It is now an integer. To make it a serial I
>> just create the seq and set the default to be the nextval() of that
>> sequence right? is there anything else I need
On Wed, Apr 2, 2008 at 10:12 PM, Naz Gassiep <[EMAIL PROTECTED]> wrote:
> I have just created a table using SELECT INTO however the PK was
> supposed to be a serial. It is now an integer. To make it a serial I
> just create the seq and set the default to be the nextval() of that
> sequence right
> I have just created a table using SELECT INTO however the PK was
> supposed to be a serial. It is now an integer. To make it a serial I
> just create the seq and set the default to be the nextval() of that
> sequence right? is there anything else I need to do?
You'll want to do this:
ALTER SE
I have just created a table using SELECT INTO however the PK was
supposed to be a serial. It is now an integer. To make it a serial I
just create the seq and set the default to be the nextval() of that
sequence right? is there anything else I need to do? It'll maintain the
transactional safety
On Fri, Feb 29, 2008 at 2:28 PM, Mike Gould <[EMAIL PROTECTED]> wrote:
>
>
> CREATE TABLE "fav5"."batchnumber" (
> "batchnumberid" SERIAL NOT NULL,
> "processtype" SMALLINT NOT NULL,
> "termloc" CHAR(3) NOT NULL,
> "batchno" INTEGER NOT NULL
> ) WITHOUT OIDS;
>
> With the above table defini
On Fri, Feb 29, 2008 at 03:28:11PM -0500, Mike Gould wrote:
> CREATE TABLE "fav5"."batchnumber" (
> "batchnumberid" SERIAL NOT NULL,
> "processtype" SMALLINT NOT NULL,
> "termloc" CHAR(3) NOT NULL,
> "batchno" INTEGER NOT NULL
> ) WITHOUT OIDS;
> With the above table definition, is bat
On Feb 29, 2008, at 2:28 PM, Mike Gould wrote:
CREATE TABLE "fav5"."batchnumber" (
"batchnumberid" SERIAL NOT NULL,
"processtype" SMALLINT NOT NULL,
"termloc" CHAR(3) NOT NULL,
"batchno" INTEGER NOT NULL
) WITHOUT OIDS;
With the above table definition, is batchnumberid by default also
CREATE TABLE "fav5"."batchnumber" (
"batchnumberid" SERIAL NOT NULL,
"processtype" SMALLINT NOT NULL,
"termloc" CHAR(3) NOT NULL,
"batchno" INTEGER NOT NULL
) WITHOUT OIDS;
With the above table definition, is batchnumberid by default also defined as
the primary key or do I still need
On Nov 14, 2007 5:17 PM, Bob Pawley <[EMAIL PROTECTED]> wrote:
> Hi
>
> Is there any method of clearing the serial numbering so that ID references
> can start afresh without rebuilding the database.
>
> Of I use postgresql as part of my application I would like to use pgdump to
> ensure that I hav
Hi
Is there any method of clearing the serial numbering so that ID references
can start afresh without rebuilding the database.
Of I use postgresql as part of my application I would like to use pgdump to
ensure that I have the latest version and starting the serial numbering at
#1 would be
rihad <[EMAIL PROTECTED]> schrieb:
> When I do an insert that fails (like FK inconsistency, illegal value, etc.)
> the users.id grows nonetheless... This is unacceptable for my current
normal behavior.
> needs. Any way to prevent that while still maintaining ease of use? Using
> PostgreSQL 8.
Hi, my table is defined as:
CREATE TABLE users (
id integer NOT NULL,
...
);
CREATE SEQUENCE users_id_seq
INCREMENT BY 1
NO MAXVALUE
NO MINVALUE
CACHE 1;
ALTER SEQUENCE users_id_seq OWNED BY users.id;
Although it's just a more verbose way to say
create table users (id serial
Title: RE: [GENERAL] serial column
Yes, but if I tear down the house at 245 Main St, we don't renumber 247 Main St and on down the line, do we?
The problem here is that even if you get the sequencing to work, your table is dangerously unstable. If you have 700 rows and you delete row
mailto:[EMAIL PROTECTED]
Sent: Monday, September 25, 2006 12:00 PM
To: Brandon Aiken; pgsql-general@postgresql.org
Subject: Re: [GENERAL] serial column
Actually, I am not trying to "force keys" nor, I don't beleive, am I
trying
to force an hierarchal structure within the database.
On Mon, 2006-09-25 at 00:19 +0200, Gevik Babakhani wrote:
> On Sun, 2006-09-24 at 14:49 -0700, Bob Pawley wrote:
> > It's the behavior I expect - but the gaps aren't acceptable.
> >
> > Bob
>
> Then using the SERIAL or SEQUENCE won't do you any good.
>
> A possible solution for this would be to
e lowest serial ID number. )
Thanks for your comments - everything helps at my stage.
Bob Pawley
- Original Message -
From: "Brandon Aiken" <[EMAIL PROTECTED]>
To:
Sent: Monday, September 25, 2006 7:47 AM
Subject: Re: [GENERAL] serial column
I would tend to
do relationships it doesn't know about, so you technically violate first
normal form by having a multi-valued field (it identifies uniqueness and
order).
--
Brandon Aiken
CS/IT Systems Engineer
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of To
a gap.
>
> Perhaps a manually built table is the answer??
>
> Bob
>
>
> - Original Message -
> From: "Tom Lane" <[EMAIL PROTECTED]>
> To: "Bob Pawley" <[EMAIL PROTECTED]>
> Cc: "Ragnar" <[EMAIL PROTECTED]>; "
uot;
Sent: Sunday, September 24, 2006 4:30 PM
Subject: Re: [GENERAL] serial column
Bob Pawley <[EMAIL PROTECTED]> writes:
I am using the numbers to identify devices.
If a device is deleted or replaced with another type of device I want the
numbering to still be sequential.
It sounds to me l
D]>
To:
Cc: "Bob Pawley" <[EMAIL PROTECTED]>
Sent: Sunday, September 24, 2006 6:11 PM
Subject: Re: [GENERAL] serial column
On Sunday 24 September 2006 02:29 pm, Bob Pawley wrote:
Choice a.
I am using the numbers to identify devices.
If a device is deleted or replaced with anothe
On Sunday 24 September 2006 02:29 pm, Bob Pawley wrote:
> Choice a.
>
> I am using the numbers to identify devices.
>
> If a device is deleted or replaced with another type of device I want the
> numbering to still be sequential.
>
> Bob
>
Do you have some other way of tracking a device? I am just
Thanks
I'll give that a try.
Bob
- Original Message -
From: "Gevik Babakhani" <[EMAIL PROTECTED]>
To: "Bob Pawley" <[EMAIL PROTECTED]>
Cc: "Postgresql"
Sent: Sunday, September 24, 2006 4:13 PM
Subject: Re: [GENERAL] serial column
On S
Bob Pawley <[EMAIL PROTECTED]> writes:
> I am using the numbers to identify devices.
> If a device is deleted or replaced with another type of device I want the
> numbering to still be sequential.
It sounds to me like you oughtn't be storing these numbers in the
database at all. You just want to
On Sun, 2006-09-24 at 15:29 -0700, Bob Pawley wrote:
> "A possible solution for this would be to regenerate the entire column's
> values every time a record gets deleted starting form 1. but then again
> this would be very slow if you have a very large table"
>
> I don't anticipate the table to be
ly
fewer than 1,000.
Could you point to some documentation for regenerating a column's values
other than manual??
Bob
- Original Message -
From: "Gevik Babakhani" <[EMAIL PROTECTED]>
To: "Bob Pawley" <[EMAIL PROTECTED]>
Cc: "Postgresql&qu
Do you have a for instance??
Bob
- Original Message -
From: "Ragnar" <[EMAIL PROTECTED]>
To: "Bob Pawley" <[EMAIL PROTECTED]>
Cc: "Postgresql"
Sent: Sunday, September 24, 2006 3:10 PM
Subject: Re: [GENERAL] serial column
On sun, 2006-09-24
On Sun, 2006-09-24 at 14:49 -0700, Bob Pawley wrote:
> It's the behavior I expect - but the gaps aren't acceptable.
>
> Bob
Then using the SERIAL or SEQUENCE won't do you any good.
A possible solution for this would be to regenerate the entire column's
values every time a record gets deleted sta
On sun, 2006-09-24 at 14:29 -0700, Bob Pawley wrote:
> Choice a.
>
> I am using the numbers to identify devices.
>
> If a device is deleted or replaced with another type of device I want the
> numbering to still be sequential.
have you tried to implement ths using
triggers?
gnari
--
It's the behavior I expect - but the gaps aren't acceptable.
Bob
- Original Message -
From: "Gevik Babakhani" <[EMAIL PROTECTED]>
To: "Bob Pawley" <[EMAIL PROTECTED]>
Cc: "Postgresql"
Sent: Sunday, September 24, 2006 2:42 PM
S
esolve.
>
> Bob
>
> - Original Message -
> From: "Gevik Babakhani" <[EMAIL PROTECTED]>
> To: "Bob Pawley" <[EMAIL PROTECTED]>
> Cc: "Postgresql"
> Sent: Sunday, September 24, 2006 2:00 PM
> Subject: Re: [GENERAL] ser
CTED]>
Cc: "Postgresql"
Sent: Sunday, September 24, 2006 2:24 PM
Subject: Re: [GENERAL] serial column
On sun, 2006-09-24 at 13:50 -0700, Bob Pawley wrote:
I need to develop a serial column that always starts at 1 and is
sequential even after deletes.
what exactly do you mean?
On sun, 2006-09-24 at 13:50 -0700, Bob Pawley wrote:
> I need to develop a serial column that always starts at 1 and is
> sequential even after deletes.
what exactly do you mean?
say you have rows where your
columns has values 1,2,3 and 4.
you now delete the row where
the value is 2.
what do yo
akhani" <[EMAIL PROTECTED]>
To: "Bob Pawley" <[EMAIL PROTECTED]>
Cc: "Postgresql"
Sent: Sunday, September 24, 2006 2:00 PM
Subject: Re: [GENERAL] serial column
On Sun, 2006-09-24 at 13:50 -0700, Bob Pawley wrote:
I need to develop a serial column that always sta
On Sun, 2006-09-24 at 13:50 -0700, Bob Pawley wrote:
> I need to develop a serial column that always starts at 1 and is
> sequential even after deletes.
>
> Any ideas???
>
Did you try the:
create table tbl
(
id SERIAL
);
or even with primary key...
create table tbl
(
id SERI
I need to develop a serial column that always starts at 1
and is sequential even after deletes.
Any ideas???
Bob
Thanks for all the help, it works and I've learned some more about
COPY, which is treated thinly in Douglas's first edition of
"PostgreSQL" (which was my source.)
r
---(end of broadcast)---
TIP 4: Have you searched our list archives?
On Tue, Sep 12, 2006 at 02:48:30PM -0400, Brandon Aiken wrote:
> Serial fields have a default value of nextval, so if you add an 18th
> field to your text file with DEFAULT in every record it should work as
> intended.
DEFAULT works with INSERT but not with COPY:
test=> CREATE TABLE foo (col1 int
On Tue, 2006-09-12 at 13:48, Brandon Aiken wrote:
> Serial fields have a default value of nextval, so if you add an 18th
> field to your text file with DEFAULT in every record it should work as
> intended.
Or you can use the
copy table (field1,field2,field3,...field18) from stdin;
syntax, and l
[EMAIL PROTECTED] wrote:
> All,
>
> I have a pipe delimited text file I'm trying to copy to a table. The
> file has 17 fields per line. The table has 18, with that last field
> (record) a serial with sequence. I have done:
> select setval('sequence_name_seq', 555, 'TRUE')
> but when I do: COPY tab
On Tue, Sep 12, 2006 at 09:27:55AM -0700, [EMAIL PROTECTED] wrote:
> I have a pipe delimited text file I'm trying to copy to a table. The
> file has 17 fields per line. The table has 18, with that last field
> (record) a serial with sequence. I have done:
> select setval('sequence_name_seq', 555, '
]
Sent: Tuesday, September 12, 2006 12:28 PM
To: pgsql-general@postgresql.org
Subject: [GENERAL] serial, sequence, and COPY FROM
All,
I have a pipe delimited text file I'm trying to copy to a table. The
file has 17 fields per line. The table has 18, with that last field
(record) a serial
All,
I have a pipe delimited text file I'm trying to copy to a table. The
file has 17 fields per line. The table has 18, with that last field
(record) a serial with sequence. I have done:
select setval('sequence_name_seq', 555, 'TRUE')
but when I do: COPY tablename FROM '/path/to/file/file.txt' de
am Sun, dem 03.09.2006, um 14:24:41 -0700 mailte Bob Pawley folgendes:
> I have a column that I wish to use to designate loop numbers.
>
> A loop number is composed of a letter (F for flow, T for temperatures etc.)
> followed by a sequence number starting at one and ending with the last loop.
>
On Sunday 03 September 2006 02:24 pm, Bob Pawley wrote:
> I have a column that I wish to use to designate loop numbers.
>
> A loop number is composed of a letter (F for flow, T for temperatures etc.)
> followed by a sequence number starting at one and ending with the last
> loop.
>
> The loop numbe
I have a column that I wish to use to designate loop
numbers.
A loop number is composed of a letter (F for flow, T for
temperatures etc.) followed by a sequence number starting at one and ending with
the last loop.
The loop numbers will appear as F-1, T-2 and so
on.
I seem to have no p
On 10/28/05, alessandra de gregorio <[EMAIL PROTECTED]> wrote:
What function should I use to get a serial number, together with my results,from a query?Ex. Of output I want:1 ooo pp ij2 hou joo iu3 bhi ft yhBasically, I would like to have one column with
Hi,
What function should I use to get a serial number, together with my results,
from a query?
Ex. Of output I want:
1 ooo pp ij
2 hou joo iu
3 bhi ft yh
Basically, I would like to have one column with integers, from 1 onwards, no
matter how man
1 - 100 of 161 matches
Mail list logo
