Adam Rich wrote:
> > The short answer is that Adam's statement is wrong, or at least
> > misleading.
>
> Sorry Tom, I wasn't trying to do either. Joshua Drake (who I understand
> to be a reliable source of postgresql information) said that applying
> a sequence to a column after creation created
On Sat, 22 Mar 2008 21:17:10 -0500
"Adam Rich" <[EMAIL PROTECTED]> wrote:
> > The short answer is that Adam's statement is wrong, or at least
> > misleading.
>
> Sorry Tom, I wasn't trying to do either. Joshua Drake (who I
> understand to be a reliable source of postgresql information) said
> th
> The short answer is that Adam's statement is wrong, or at least
> misleading.
Sorry Tom, I wasn't trying to do either. Joshua Drake (who I understand
to be a reliable source of postgresql information) said that applying
a sequence to a column after creation created issues, versus using the
seri
"James B. Byrne" <[EMAIL PROTECTED]> writes:
> On: Fri, 21 Mar 2008 13:53:36 -0500, "Adam Rich" <[EMAIL PROTECTED]>
> wrote:
>> I'd like to point out that using pg_dump does in fact apply sequences
>> to columns after the fact. (at least in 8.3) Columns lose their
>> "serial" designation after eac
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 22 Mar 2008 21:01:19 -0400 (EDT)
"James B. Byrne" <[EMAIL PROTECTED]> wrote:
> Message-ID: <[EMAIL PROTECTED]@sbcglobal.net>
>
> I am not at all
> clear as to the implications of this statement but it caused me to
> wonder if the primary ke
Message-ID: <[EMAIL PROTECTED]@sbcglobal.net>
On: Fri, 21 Mar 2008 13:53:36 -0500, "Adam Rich" <[EMAIL PROTECTED]>
wrote:
> > I am not sure about 8.3 but certainly earlier releases of PostgreSQL
> > would have specific dependency issues when a sequence was applied to
> > a column after the fact,
The table I have in MySQL is similar to below:
0 SET FOREIGN_KEY_CHECKS=0;
1 CREATE TABLE products (
2 product_id integer(11) not null auto_increment,
3 product_name varchar(255) not null,
4 product_descrition varchar(255) not null,
5 class_id integer(11) not null,
6 sub
On 21 Mar, 17:15, [EMAIL PROTECTED] ("Edward Blake") wrote:
>
> When I try and rewrite it as a Postgres statement (below), it fails at line
> 9.
> 0 SET CONSTRAINTS ALL DEFERRED;
> 1 CREATE TABLE products (
> 2 product_id serial[11] not null,
> 3 product_name varchar[255] not null,
>
> > I am not sure about 8.3 but certainly earlier releases of PostgreSQL
> > would have specific dependency issues when a sequence was applied to
> a
> > a column after the fact, versus using the serial or bigserial
> > psuedo-types.
I'd like to point out that using pg_dump does in fact apply sequ
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Why
> I am not sure about 8.3 but certainly earlier releases of PostgreSQL
> would have specific dependency issues when a sequence was applied to a
> a column after the fact, versus using the serial or bigserial
> psuedo-types.
As of (I think)
Joshua D. Drake wrote:
I am not sure about 8.3 but certainly earlier releases of PostgreSQL
would have specific dependency issues when a sequence was applied to a
a column after the fact, versus using the serial or bigserial
psuedo-types.
Sincerely,
Joshua D. Drake
- --
The PostgreSQL Comp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 21 Mar 2008 12:47:38 -0500
Justin <[EMAIL PROTECTED]> wrote:
> >
> Why
I am not sure about 8.3 but certainly earlier releases of PostgreSQL
would have specific dependency issues when a sequence was applied to a
a column after the fact
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 21 Mar 2008 12:38:49 -0500
Justin <[EMAIL PROTECTED]> wrote:
> > Any ideas?
>
> Another way to do auto increment fields is create your own sequences.
I would not suggest that.
Sincerely,
Joshua D. Drake
- --
The PostgreSQL Company since
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 21 Mar 2008 12:38:49 -0500
Justin <[EMAIL PROTECTED]> wrote:
Any ideas?
Another way to do auto increment fields is create your own sequences.
I would not suggest that.
Why
Edward Blake wrote:
The table I have in MySQL is similar to below:
0 SET FOREIGN_KEY_CHECKS=0;
1 CREATE TABLE products (
2 product_id integer(11) not null auto_increment,
3 product_name varchar(255) not null,
4 product_descrition varchar(255) not null,
5 class_id integer(
"Edward Blake" <[EMAIL PROTECTED]> writes:
> When I try and rewrite it as a Postgres statement (below), it fails at line
> 9.
> 0 SET CONSTRAINTS ALL DEFERRED;
I don't think that does the same thing as mysql's foreign_key_checks = 0.
> 2 product_id serial[11] not null,
This is trying to c
Hello,
On Fri, 21 Mar 2008 12:15:05 -0400 Edward Blake wrote:
> 9 KEY class_id (class_id),
> 10 KEY subclass_id (subclass_id),
> 11 KEY department_id (department_id)
this should create an index, or?
You want to do this later, after table creation.
Kind regards
--
Edward Blake escribió:
The table I have in MySQL is similar to below:
0 SET FOREIGN_KEY_CHECKS=0;
1 CREATE TABLE products (
2 product_id integer(11) not null auto_increment,
3 product_name varchar(255) not null,
4 product_descrition varchar(255) not null,
5 class_id integer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 21 Mar 2008 12:15:05 -0400
"Edward Blake" <[EMAIL PROTECTED]> wrote:
> When I try and rewrite it as a Postgres statement (below), it fails
> at line 9.
> 0 SET CONSTRAINTS ALL DEFERRED;
> 1 CREATE TABLE products (
> 2 product_id serial
The table I have in MySQL is similar to below:
0 SET FOREIGN_KEY_CHECKS=0;
1 CREATE TABLE products (
2 product_id integer(11) not null auto_increment,
3 product_name varchar(255) not null,
4 product_descrition varchar(255) not null,
5 class_id integer(11) not null,
6 sub
20 matches
Mail list logo
