From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, ghatpande(at)vsnl(dot)net, Dann Corbit <DCorbit(at)connx(dot)com>, pgsql hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: First step towards Intelligent, integrateddatabase |
Date: | 2010-12-02 00:22:13 |
Message-ID: | 4FDE4580-04F7-4530-BDBE-078BD91321AA@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Dec 1, 2010, at 8:59 AM, Andrew Dunstan wrote:
> On 12/01/2010 09:41 AM, Tom Lane wrote:
>> ghatpande(at)vsnl(dot)net writes:
>>> Create domain is only useful for abstracting common constraints on fields into single location for maintenance. It may not be useful to link tables.
>> It's still unclear what this does that you don't get from inheritance,
>> typed tables, use of a table's rowtype as a field type, or CREATE TABLE
>> LIKE. This isn't exactly virgin territory.
>>
>>
>
> Yeah. Actually, the whole thing reminded me somewhat of the pre-RDBMS data stores I worked with 25 years or so ago. "Those who cannot remember history are doomed to repeat it."
Something that did what Pavel mentioned:
SELECT name, parent->name FROM children;
would be very useful. It means you no longer have to write explicit joins (or perhaps more accurately, you no longer have to specify exactly how to join the two tables).
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Maciek Sakrejda | 2010-12-02 00:39:53 | Re: [HACKERS] Improved JDBC driver part 2 |
Previous Message | Jim Nasby | 2010-12-02 00:18:25 | Re: FK's to refer to rows in inheritance child |