Oliver Elphick writes:
When using the COPY command to load data into a Great Bridge PostgreSQL
database, the triggers and constraints on tables are disabled.
Perhaps that's a feature of Great Bridge PostgreSQL, but it's not a
feature of Plain Old PostgreSQL. ;-)
(It would be correct to say
On Sat, Aug 18, 2001 at 03:49:10PM -0700, Joe Conway wrote:
Sometimes (about 20%, it seems) with several of the data sets, we
get an error trying to insert rows into the table with the serial in
it.
On investigation, it seems that the serial number has got to 101, then
set itself
Oliver Elphick [EMAIL PROTECTED] writes:
I've been reading Great Bridge's document on Administration and Tuning
(PDF document under http://www.greatbridge.com/product/software.php)
and came across this statement on page 27:
When using the COPY command to load data into a Great Bridge
Hi Stephen,
That's weird behaviour. If you'd manually created the sequence like
this :
CREATE SEQUENCE foo_seq MINVALUE 4 MAXVALUE 101 CYCLE
Then referenced it as the default like this :
CREATE TABLE bar (idnum integer UNIQUE DEFAULT nextval('foo_seq') NOT
NULL, otherstuff varchar(20));
On Sun, Aug 19, 2001 at 12:42:36PM +1000, Justin Clift wrote:
Hi Stephen,
That's weird behaviour. If you'd manually created the sequence like
this :
CREATE SEQUENCE foo_seq MINVALUE 4 MAXVALUE 101 CYCLE
Then referenced it as the default like this :
CREATE TABLE bar (idnum integer
On Sun, Aug 19, 2001 at 01:23:13PM +1000, Justin Clift wrote:
Hmmm...
Well, that would be a
CREATE SEQUENCE foo_seq START 1 MINVALUE 4 MAXVALUE 101 CYCLE
Still, that's not helpful. :(
Is there any chance that the application created the sequence, or that
someone created it
On Sun, Aug 19, 2001 at 10:02:02AM +0800, Lincoln Yeoh wrote:
At 09:18 AM 8/19/01 +1000, Stephen Robert Norris wrote:
Recreating the sequence solves the problem, of course. So does setval(102).
My problem is that it got into this state originally. The test case that
demonstrates it sometimes
