Re: My honours project - databases using dynamically attached entity-properties - Mailing list pgsql-hackers

From Richard Huxton
Subject Re: My honours project - databases using dynamically attached entity-properties
Date
Msg-id 45F5EAB9.9000703@archonet.com
Whole thread Raw
In response to Re: My honours project - databases using dynamically attached entity-properties  ("Andrew Hammond" <andrew.george.hammond@gmail.com>)
Responses Re: My honours project - databases using dynamically attached entity-properties  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Andrew Hammond wrote:
> On 3/12/07, Richard Huxton <dev@archonet.com> wrote:
>> Josh Berkus wrote:
>> > I really don't see any way you could implement UDFs other than EAV that
>> > wouldn't be immensely awkward, or result in executing DDL at runtime.
>>
>> What's so horrible about DDL at runtime? Obviously, you're only going to
>> allow specific additions to specific schemas/tables, but why not?
> 
> More to the point, since EAV is effectively smearing the semantics of
> DDL with DML, what, if any of the arguments against doing DDL at
> runtime don't apply equally to EAV? Well, aside from being able to say
> "hey, I'm not executing DDL at runtime". :)
> 
> I see the issue as one of cost: it's substantially harder to implement
> DDL at runtime than to work around the problem using EAV. If that
> analysis is reasonable, then it would be a very interesting research
> project to see how to cut down that cost of implementation.

Well the cost depends on where/how complex the extra fields are. If 
you're just talking about adding columns usercol01..NN with different 
types and possibly a lookup to a single client_attributes table, it's 
not difficult.

Of course, if inheritence worked fully, you could just have core and 
user versions of relevant tables.

--   Richard Huxton  Archonet Ltd


pgsql-hackers by date:

Previous
From: "Andrew Hammond"
Date:
Subject: Re: My honours project - databases using dynamically attached entity-properties
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values