Re: Composite datatypes, dynamic member fields - Mailing list pgsql-interfaces

From Robert Staudinger
Subject Re: Composite datatypes, dynamic member fields
Date
Msg-id 1021297326.381.48.camel@ws224
Whole thread Raw
In response to Re: Composite datatypes, dynamic member fields  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Composite datatypes, dynamic member fields
List pgsql-interfaces
On Mon, 2002-05-13 at 16:17, Tom Lane wrote:
> Robert Staudinger <robson@stereolyzer.net> writes:
> > One idea is to implement a . operator on a basic data type and return
> > the value 
> > for the corresponding field from the "operator function".
> > E.g.
> > "select * from mytable where mytype.mymember='x'"
> > could call something like
> > mytype_member_read( mytype, member_name )
> > but I'm not sure which datatype member_name would be in this case.
> 
> PG has always had the ability to define functions that could be
> notationally treated as fields.  A trivial example:
> 
> test72=# create table tours(depart date, return date);
> CREATE
> test72=# insert into tours values('2002-01-01', '2002-01-10');
> INSERT 525275 1
> test72=# insert into tours values('2001-12-15', '2002-01-05');
> INSERT 525276 1
> test72=# create function numdays(tours) returns int as '
> test72'# select $1.return - $1.depart' language sql;
> CREATE
> test72=# select *, tours.numdays from tours;
>    depart   |   return   | numdays
> ------------+------------+---------
>  2002-01-01 | 2002-01-10 |       9
>  2001-12-15 | 2002-01-05 |      21
> (2 rows)
> 
> The computed field doesn't quite have the same status as real fields
> --- notice that * doesn't know about it in the above example --- but
> it's a useful technique anyway.
> 
>             regards, tom lane

Hmm I don't know if this solves my problem.
E.g.
I want to store a group of linked objects. Maybe x(ht)ml could be an
example:

<table bgcolor="#000000">
<tr>
<td border="1">one</td>
<td cellpadding="2">two</td>
<td border="1">three</td>
</tr>
</table>

these should be stored in a table
( column "object" is of a base type written in c and should hold
arbitrary string attributes)

id parentid object
------------------
1  0        table
2  1        tr
3  2        td1
4  2        td2
5  2        td3

to be able to query something like
"select * from mytable where object.border='1'"
i'd probably need a . operator on "object" if "object" is a base type
implemented in c which holds the attributes internally - just as
described in my previous post.

The problem is that i don't know how to handle
"update mytable set object.margin='2' where parentid='2'"

Please note that I'm just thinking about how OR mapping could be done by
taking advantage of postgresql's extensibility - this is not a real
world problem ;-)

Thanks for sharing
Robert Staudinger




pgsql-interfaces by date:

Previous
From: Tom Lane
Date:
Subject: Re: Composite datatypes, dynamic member fields
Next
From: "Denis CARTIER-MILLON"
Date:
Subject: libpq and borland c++ 5......