From: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Arrays and foreign keys |
Date: | 2000-08-11 04:39:11 |
Message-ID: | 3993836F.5379B24C@nimrod.itg.telecom.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephan Szabo wrote:
> And whatever is done should leave arrays with the same meaning they
> currently have for people who use them in other ways. I'm almost
> thinking that we want a set rather than an array here where sets have
> different semantics that make more sense for this sort of behavior.
> It just seems to make more sense to me that a set would be indexed
> by its elements than array, since position is supposed to be meaningful
> for arrays, and that set(1,2) is equal to the set(2,1) whereas the
> indexes aren't. Of course, I guess that's not much different from
> the normalized table case.
Probably a collection rather than a set. No sense in excluding
duplicates.
What often happens in an ODBMS is that some general purpose collection
classes are written based on arrays. A simple example would be...
class Set<type> {
RefArray<type> array;
}
Where RefArray<Object> gets mapped to something like oid[] in the odbms.
Then when you want a class that has a set..
class Person {
Set<Car> owns;
}
which gets flattened and mapped to
create table Person (owns oid[]);
The set semantics being enforced by the language bindings.
From | Date | Subject | |
---|---|---|---|
Next Message | Ben Adida | 2000-08-11 04:54:09 | Re: [Fwd: Re: haven't forgotten about you...] |
Previous Message | Ben Adida | 2000-08-11 04:37:08 | Re: [Fwd: Re: haven't forgotten about you...] |