Re: Bug and/or feature? Complex data types in tables...

From: "Chris Travers" <chris(at)travelamericas(dot)com>
To: "Michael Glaesemann" <grzm(at)myrealbox(dot)com>
Cc: <pgsql-general(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Bug and/or feature? Complex data types in tables...
Date: 2004-01-02 13:44:16
Message-ID: 015401c3d136$884af9c0$1f00053d@winxp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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(at)myrealbox(dot)com>
To: "Chris Travers" <chris(at)travelamericas(dot)com>
Cc: <pgsql-general(at)postgresql(dot)org>; "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)postgresql(dot)org)
>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dennis Haney 2004-01-02 13:46:55 pull_up_subqueries question
Previous Message Chris Travers 2004-01-02 13:37:21 Re: Help with PostgreSQL porting project

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2004-01-02 14:09:03 Re: PL/Java issues
Previous Message julius 2004-01-02 12:36:22 postgresql-7.4 make error: tuptoaster.c: In function `toast_delete_datum'