Re: Bug and/or feature? Complex data types in tables... - Mailing list pgsql-general

From Chris Travers
Subject Re: Bug and/or feature? Complex data types in tables...
Date
Msg-id 015401c3d136$884af9c0$1f00053d@winxp
Whole thread Raw
In response to Bug and/or feature? Complex data types in tables...  ("Chris Travers" <chris@travelamericas.com>)
Responses Re: Bug and/or feature? Complex data types in tables...
List pgsql-general
creating a complex type and using it in a table would create the same
problem, would it not?
If my type has more than one component, then it would not work well.

Here is a better example.  Imagine creating a type for complex numbers.
Each complex number has 2 components:  a real component (x, numeric) and an
imaginary component (y, numeric).  The standard representation is  x +/- yi,
so if the real component is 3.4 and the imaginary component is 5, it would
be written 3.4 + 5i.

Storing this data in the database would require either:
1:  A text string which would be parsed by the app.  (not really very
useful)
2:  A native datatype consisting of 2 numeric components, that could be cast
as text by the rules above.

Obviously the second one is best.  Currently in PostgreSQL, I would have to
write this in C, but with complex types, I could write this mostly in
PLPGSQL!

Best Wishes,
Chris Travers

----- Original Message -----
From: "Michael Glaesemann" <grzm@myrealbox.com>
To: "Chris Travers" <chris@travelamericas.com>
Cc: <pgsql-general@postgresql.org>; "Tom Lane" <tgl@sss.pgh.pa.us>
Sent: Thursday, January 01, 2004 10:48 PM
Subject: Re: [GENERAL] Bug and/or feature? Complex data types in tables...


> On Dec 31, 2003, at 7:20 PM, Chris Travers wrote:
>
> > This concept of using complex types in tables actually does have one
> > legitimate use.  When used with casts and functions, you could use it
> > as a
> > "poor-man's datatype"  development method.
> >
> > Here is a hypothetical example.  Imagine for a moment that there was
> > no CIDR
> > datatype.  I could create a datatype as a set of ints and then create
> > casting functions which I could use for display of the data.  This
> > would be
> > similar to C except that it could be done by people like myself whose C
> > coding skills are not up to the level where I or anyone else would
> > want them
> > in the database backend ;-)
>
> This is a situation where PostgreSQL's CREATE DOMAIN, or CREATE TYPE
> support would be useful, I think. Is there a reason these wouldn't work
> as well as using a "table type"?
>
> Happy New Year!
> Michael Glaesemann
> grzm myrealbox com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
>


pgsql-general by date:

Previous
From: "Chris Travers"
Date:
Subject: Re: Help with PostgreSQL porting project
Next
From: Dennis Haney
Date:
Subject: pull_up_subqueries question