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

From: Michael Glaesemann <grzm(at)myrealbox(dot)com>
To: "Chris Travers" <chris(at)travelamericas(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Bug and/or feature? Complex data types in tables...
Date: 2004-01-15 11:29:41
Message-ID: 1C75A818-474E-11D8-878B-000A95C88220@myrealbox.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers


On Jan 15, 2004, at 6:40 PM, Chris Travers wrote:
>> I'm unclear about what follows. Using SELECT complex::text FROM
>> mytable
>> would be used to get data out of the table. How would you get it in?
>> How do user-defined casts help out with this?
>
> Simple, you have to define a complex() function which takes real and
> imaginary components and returns a complex type.

Sorry. This is what I had shown already. I was trying to figure out how
casts were involved.

> You can then insert it as:
> insert into complex_nums (c_num, text_rep) values (complex('2', '3'),
> complex_to_text(complex('2','3'));
> This will successfully return, however, you can only retrieve the
> value that
> is stored as the text string. Anything else causes the backend to
> *crash.*

So basically you're storing a representation of the complex number (or
other type) as text, rather than as the type itself. So, as Tom
mentioned, you're left writing a function to parse that text string and
return a the value as the composite type you want. Am I catching on?

>>
>> Thanks for your time! I'm slowing trying to learn here. I'm interested
>> in figuring out how to implement point and interval/duration types for
>> temporal work, but know I have a lot to learn to make this possible.
>>
> Is there a problem with the built in definitions of point and interval?

I'm thinking along the lines of the temporal proposals Date, Darwen,
and Lorentzos ("Temporal Data and the Relational Model"). Their
"interval" type is more along the lines of a beginning and end time,
such as ['2003-1-23':'2003-1-25'], rather than just '2 days'. They
generalize this to be useful for any ordered, discrete sequence, such
as integers, even numbers, weekdays, part number sequences (if
appropriate), or primes. A point type, in this case, is a value that is
part of such a sequence, e.g., '2003-1-23' could be a date point type
useful in a date interval. Here's a link to Hugh Darwen's summary of
the book:

<http://www.hughdarwen.freeola.com/TheThirdManifesto.web/
TemporalData.pdf>

Michael Glaesemann
grzm myrealbox com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Glaesemann 2004-01-15 11:49:53 Re: Bug and/or feature? Complex data types in tables...
Previous Message Oleg Bartunov 2004-01-15 11:06:22 Re: Postgress and MYSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Glaesemann 2004-01-15 11:49:53 Re: Bug and/or feature? Complex data types in tables...
Previous Message jihuang 2004-01-15 11:11:30 FYI , Intel CC and PostgreSQL , benchmark by pgsql