Thread: Did this work in earlier version of Postgres?
I could have swore that this worked in earlier releases of Postgresql i.e. 7.4. CREATE TABLE public.test ( junk double NOT NULL, CONSTRAINT junk_pkey PRIMARY KEY (junk) )WITHOUT OIDS; Now it gives a error that type double does not exist. During the summer of 2004 I ported a large Firebird database to 7.x and firebird uses the term double which in PG is a float8 I believe. Anyway i was able to just paste the Firebird ddl in to the query editor and the server would substitute the correct PG native type. varchar works, how come double does not? Thanks, Tony
Tony Caduto wrote: > I could have swore that this worked in earlier releases of Postgresql > i.e. 7.4. > > CREATE TABLE public.test > ( > junk double NOT NULL, > CONSTRAINT junk_pkey PRIMARY KEY (junk) > )WITHOUT OIDS; > > Now it gives a error that type double does not exist. From the docs: http://www.postgresql.org/docs/8.1/static/datatype.html#DATATYPE-FLOAT the type is double precision. J > > During the summer of 2004 I ported a large Firebird database to 7.x and > firebird uses the term double which in PG is a float8 I believe. > Anyway i was able to just paste the Firebird ddl in to the query editor > and the server would substitute the correct PG native type. > > varchar works, how come double does not? > > Thanks, > > Tony > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org >
On Thu, 2006-03-23 at 17:31 -0600, Tony Caduto wrote: > I could have swore that this worked in earlier releases of Postgresql > i.e. 7.4. > > CREATE TABLE public.test > ( > junk double NOT NULL, > CONSTRAINT junk_pkey PRIMARY KEY (junk) > )WITHOUT OIDS; > > Now it gives a error that type double does not exist. CREATE DOMAIN double AS float8; There, now the type exists ;) --
Tony Caduto <tony_caduto@amsoftwaredesign.com> writes:
> I could have swore that this worked in earlier releases of Postgresql
> i.e. 7.4.
> CREATE TABLE public.test
> (
> junk double NOT NULL,
> CONSTRAINT junk_pkey PRIMARY KEY (junk)
> )WITHOUT OIDS;
> Now it gives a error that type double does not exist.
[ tries it... ] Sorry, fails in everything back to 7.0, which is the
oldest branch I have running. The error message varies a bit.
> varchar works, how come double does not?
The SQL spec has varchar, it does not have double.
<character string type> ::= CHARACTER [ <left paren> <length> <right paren> ] | CHAR
[<left paren> <length> <right paren> ] | CHARACTER VARYING <left paren> <length> <right paren>
|CHAR VARYING <left paren> <length> <right paren> | VARCHAR <left paren> <length> <right paren>
<approximate numeric type> ::= FLOAT [ <left paren> <precision> <right paren> ] |
REAL | DOUBLE PRECISION
regards, tom lane
Tony Caduto wrote: > I could have swore that this worked in earlier releases of Postgresql > i.e. 7.4. > > CREATE TABLE public.test > ( > junk double NOT NULL, > CONSTRAINT junk_pkey PRIMARY KEY (junk) > )WITHOUT OIDS; There has never been a type named double in PostgreSQL. The type name mandated by the SQL standard is double precision, and PostgreSQL supports that. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > There has never been a type named double in PostgreSQL. The type name > mandated by the SQL standard is double precision, and PostgreSQL > supports that. > > Ok, Thanks for clearing that up for me :-) Maybe it was pgAdmin that did the substitution. Thanks, Tony
Which is actually a float8 :)
CREATE TABLE public.test
(
junk double precision,
);
alter table public.test add column foo float8;
Table "public.test"Column | Type |
--------+------------------+--junk | double precision |punk | double precision |
Regards,
Guido Barosio
On 3/23/06, Peter Eisentraut <peter_e@gmx.net> wrote:
> Tony Caduto wrote:
> > I could have swore that this worked in earlier releases of Postgresql
> > i.e. 7.4.
> >
> > CREATE TABLE public.test
> > (
> > junk double NOT NULL,
> > CONSTRAINT junk_pkey PRIMARY KEY (junk)
> > )WITHOUT OIDS;
>
> There has never been a type named double in PostgreSQL. The type name
> mandated by the SQL standard is double precision, and PostgreSQL
> supports that.
>
> --
> Peter Eisentraut
> http://developer.postgresql.org/~petere/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
--
Guido Barosio
-----------------------
Rod Taylor wrote: > On Thu, 2006-03-23 at 17:31 -0600, Tony Caduto wrote: >> I could have swore that this worked in earlier releases of Postgresql >> i.e. 7.4. >> >> CREATE TABLE public.test >> ( >> junk double NOT NULL, >> CONSTRAINT junk_pkey PRIMARY KEY (junk) >> )WITHOUT OIDS; >> >> Now it gives a error that type double does not exist. > > CREATE DOMAIN double AS float8; > > There, now the type exists ;) That's a little too perl for me ;) Joshua D. Drake >
On Thu, 2006-03-23 at 16:05 -0800, Joshua D. Drake wrote: > Rod Taylor wrote: > > On Thu, 2006-03-23 at 17:31 -0600, Tony Caduto wrote: > >> I could have swore that this worked in earlier releases of Postgresql > >> i.e. 7.4. > >> > >> CREATE TABLE public.test > >> ( > >> junk double NOT NULL, > >> CONSTRAINT junk_pkey PRIMARY KEY (junk) > >> )WITHOUT OIDS; > >> > >> Now it gives a error that type double does not exist. > > > > CREATE DOMAIN double AS float8; > > > > There, now the type exists ;) > > That's a little too perl for me ;) I suppose it depends on the goal. If it is an application that is to be supported on more than one database, defining types and other things for a given DB type (PostgreSQL) is easier than injecting a large number of SWITCH statements into the code. --
>>>> Now it gives a error that type double does not exist. >>> CREATE DOMAIN double AS float8; >>> >>> There, now the type exists ;) >> That's a little too perl for me ;) > > I suppose it depends on the goal. If it is an application that is to be > supported on more than one database, defining types and other things for > a given DB type (PostgreSQL) is easier than injecting a large number of > SWITCH statements into the code. \ Why in the world would you build an application for anything except PostgreSQL? ;)
On Thu, 2006-03-23 at 16:41 -0800, Joshua D. Drake wrote: > >>>> Now it gives a error that type double does not exist. > >>> CREATE DOMAIN double AS float8; > >>> > >>> There, now the type exists ;) > >> That's a little too perl for me ;) > > > > I suppose it depends on the goal. If it is an application that is to be > > supported on more than one database, defining types and other things for > > a given DB type (PostgreSQL) is easier than injecting a large number of > > SWITCH statements into the code. > \ > > Why in the world would you build an application for anything except > PostgreSQL? To prove that, as unbelievable as it sounds, it is possible to do such a thing? Don't worry, such a thing would not get into a production environment. --
On 23/3/06 23:43, "Tony Caduto" <tony_caduto@amsoftwaredesign.com> wrote: > Peter Eisentraut wrote: >> There has never been a type named double in PostgreSQL. The type name >> mandated by the SQL standard is double precision, and PostgreSQL >> supports that. >> >> > Ok, Thanks for clearing that up for me :-) > > Maybe it was pgAdmin that did the substitution. Nope, must have been you. Why would you have been using pgAdmin anyway? :-p Regards, Dave
On Thu, Mar 23, 2006 at 06:35:58PM -0500, Rod Taylor wrote: > On Thu, 2006-03-23 at 17:31 -0600, Tony Caduto wrote: > > I could have swore that this worked in earlier releases of Postgresql > > i.e. 7.4. > > > > CREATE TABLE public.test > > ( > > junk double NOT NULL, > > CONSTRAINT junk_pkey PRIMARY KEY (junk) > > )WITHOUT OIDS; > > > > Now it gives a error that type double does not exist. > > CREATE DOMAIN double AS float8; > > There, now the type exists ;) Except that there's issues with using domains for things as opposed to base types (there's not full functionality). -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461