| From: | Mike Mascari <mascarm(at)mascari(dot)com> |
|---|---|
| To: | Chris Bitmead <chris(at)bitmead(dot)com> |
| Cc: | "Robert B(dot) Easter" <reaster(at)comptechnews(dot)com>, Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Postgres Hackers List <hackers(at)postgresql(dot)org>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Re: [HACKERS] Postgresql OO Patch |
| Date: | 2000-05-22 10:12:40 |
| Message-ID: | 39290818.CF17D125@mascari.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Chris Bitmead wrote:
>
> While SQL3 talks about trees and leaf rows, it's not implemented like
> that, so all this worrying about digging down trees and leafs is all a
> bit mute.
Moot. ;-)
At a minimum, it seems to me, the backend must support the
concept of multiple tuples with different attributes at the
relation level since concurrency and rollback-ability of ALTER
TABLE ADD COLUMN will cause two concurrent transactions to see a
single relation with different attributes. It doesn't seem a
large leap to support this concept for OO purposes from "leaf" to
"base". For "base" to "leaf" type queries, wouldn't it be
acceptable to return the base attributes only, as long as the
equivalent of run-time type information could be had from the
OID?
Just curious,
Mike Mascari
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chris Bitmead | 2000-05-22 11:25:18 | Re: Re: [HACKERS] Postgresql OO Patch |
| Previous Message | Hannu Krosing | 2000-05-22 09:03:11 | Re: [HACKERS] Postgresql OO Patch |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ragnar Hakonarson | 2000-05-22 10:37:32 | plperl |
| Previous Message | Oliver Elphick | 2000-05-22 09:55:40 | Re: OO Patch |