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

From Tom Lane
Subject Re: Composite datatypes, dynamic member fields
Date
Msg-id 29191.1021299475@sss.pgh.pa.us
Whole thread Raw
In response to Re: Composite datatypes, dynamic member fields  (Robert Staudinger <robson@stereolyzer.net>)
Responses Re: Composite datatypes, dynamic member fields
Re: Composite datatypes, dynamic member fields
List pgsql-interfaces
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 |       92001-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


pgsql-interfaces by date:

Previous
From: Bartus Levente
Date:
Subject: Re: [HACKERS] internal voting
Next
From: Robert Staudinger
Date:
Subject: Re: Composite datatypes, dynamic member fields