This queue is for tickets about the DBIx-DBSchema CPAN distribution.

Report information
The Basics
Id:
32228
Status:
open
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
ANDK [...] cpan.org
Cc:
AdminCc:

BugTracker
Severity:
Normal
Broken in:
0.36
Fixed in:
(no value)



Subject: postgres sequences/default not fully supported?
When I use the Pg driver for one of my databases and collect what the sql() command gives me, then I find there the following statement: CREATE TABLE foo ( id int4 NOT NULL DEFAULT nextval('foo_id_seq'::regclass) , name varchar(64) NOT NULL , PRIMARY KEY (id) ) This command has the problem that it cannot be thrown at an empty database because the postgressql 'SEQUENCE' needs to be created before the 'DEFAULT nextval(...)' clause can be used. So something like this would be required first: CREATE SEQUENCE foo_id_seq INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1; Alternatively, a column definition with the type 'serial' would do in all my tables, so I started to try the following eeevil hack which indeed works but is so eeevil that it doesn't seem to have a future: sub column_callback { my( $proto, $dbh, $table, $column_obj ) = @_; my $hashref = {}; if ( $column_obj->default =~ /^nextval\(/i ) { $hashref->{'effective_type'} = "serial not null --"; # "--"! $hashref->{'explicit_null'} = "1"; $hashref->{'effective_default'} = "eeevil hack\n"; # LF! } return $hashref; } I do not see this problem mentioned in the Driver Write Guide and nothing else looks similar in concept. So my question is: how is this supposed to work? Or better, how could we get away woutout the ugly hack above? Thanks,
On Thu Jan 10 10:37:54 2008, ANDK wrote:
Show quoted text
> When I use the Pg driver for one of my databases and collect what the > sql() command gives me, then I find there the following statement: > > CREATE TABLE foo ( > id int4 NOT NULL DEFAULT nextval('foo_id_seq'::regclass) , > name varchar(64) NOT NULL , > PRIMARY KEY (id) > ) > > This command has the problem that it cannot be thrown at an empty > database because the postgressql 'SEQUENCE' needs to be created before > the 'DEFAULT nextval(...)' clause can be used. So something like this > would be required first: > > CREATE SEQUENCE foo_id_seq > INCREMENT BY 1 > NO MAXVALUE > NO MINVALUE > CACHE 1; > > Alternatively, a column definition with the type 'serial' would do in > all my tables, so I started to try the following eeevil hack which > indeed works but is so eeevil that it doesn't seem to have a future: > > sub column_callback { > my( $proto, $dbh, $table, $column_obj ) = @_; > my $hashref = {}; > if ( $column_obj->default =~ /^nextval\(/i ) { > $hashref->{'effective_type'} = "serial not null --"; # "--"! > $hashref->{'explicit_null'} = "1"; > $hashref->{'effective_default'} = "eeevil hack\n"; # LF! > } > return $hashref; > } > > I do not see this problem mentioned in the Driver Write Guide and > nothing else looks similar in concept. So my question is: how is this > supposed to work? Or better, how could we get away woutout the ugly
hack
Show quoted text
> above? > > > Thanks,
What about using pg_get_serial_sequence('table','column') for detecting serial columns? Regards Racke


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.