> the tree. If you do a "SELECT * FROM supertable*" (for example, if you were to
> redefine table* to mean select heterogeneous rows), what row will you get for a
> row that exists in a leaf? The same row is in all tables between supertable
> and the leaf. I suppose it would be necessary to hav
Mike Mascari wrote:
> 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
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 attr
Chris Bitmead wrote:
>
> > In this
> > case, it would only look down into the tree to 3 levels below supertable and
> > you'd never get row-types that are down lower than level 3. Anyhow, I still
> > don't think returning multple row-types is going to happen,
OTOH, I'm pretty sure that original
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.
"Robert B. Easter" wrote:
> If it were allowed, you might have to
> specify the level to dig to in the tree. The rows are shared among superta
On Sun, 21 May 2000, Chris Bitmead wrote:
> Peter Eisentraut wrote:
> >
> > Chris writes:
> >
> > > I.e. "SELECT * FROM foobar*" becomes "SELECT * FROM foobar", and
> > > "SELECT * from foobar" becomes "SELECT * FROM ONLY foobar".
> >
> > This aspect of the patch I wholeheartedly agree on. The
Chris writes:
> I.e. "SELECT * FROM foobar*" becomes "SELECT * FROM foobar", and
> "SELECT * from foobar" becomes "SELECT * FROM ONLY foobar".
This aspect of the patch I wholeheartedly agree on. The rest I'm not sure
about -- yet. :)
> Benefits:
> *) SQL3 says it.
That is unfortunately false f
Tom Lane wrote:
> It's kinda fuzzy, but in practice I'd say the readers of pgsql-hackers
> and maybe pgsql-general.
One more time for the mailing list...
Hands up if you have objections to the patch I recently submitted for
postgresql. It fixes the long standing bit-rot / bug that DELETE and
