Re: Bug and/or feature? Complex data types in tables...
От | Michael Glaesemann |
---|---|
Тема | Re: Bug and/or feature? Complex data types in tables... |
Дата | |
Msg-id | 76363C6F-473C-11D8-9C78-000A95C88220@myrealbox.com обсуждение исходный текст |
Ответ на | Re: Bug and/or feature? Complex data types in tables... ("Chris Travers" <chris@travelamericas.com>) |
Список | pgsql-general |
Hi Chris, I know this thread is a little old, but it's something I'm interested in learning more about. On Jan 2, 2004, at 9:59 PM, Chris Travers wrote: > AFAICS, there are only one thing missing and it could probably be > worked > around if the backend did nto crash when you try to retrieve the > information > via a casting function. It is: > > Some way to define a standard input and output representation (how it > is > done in C). > > If you can define your own casts, you can then select complex::text > from > mytable (but this would crash the backend again :-( ) Could you explain this a little more? My strengths (such as they are) are more on relational theory rather than implementation. My interpretation of what you're saying (which is probably just restating what's obvious to others) is that there isn't a way to define the input and output functions in (the PostgreSQL flavor of) SQL. You have to do it in C, as described in the "User-Defined Types" section (33.10). 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? 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. Michael Glaesemann grzm myrealbox com
В списке pgsql-general по дате отправления: