Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL

Don Baccus wrote:

> Given the stated goals of becoming a fast, efficient, reliable
> SQL engine, this has to be a crucial consideration.

I'm sure this can be made fast.

> On the other hand, as someone who once made his living off his
> designed and implemented optimizing multi-language, multi-platform
> compiler technology...is it entirely out of the question to
> consider more greatly abstracting the language (gram.y/analyze.c)
> and backend (optimizer and executor) interfaces so more than one
> front-end could exist (even if only in experimental and research
> environments)? Along with front-end specific versions of libpq?

A good thought, but we still need one good front end that supports
all the features.

> >> I would propose that that anytime you do a SELECT * from a base table
> >> that you would get back the full rows from those sub tables.
> >
> >Frankly: ugh. This doesn't square with *my* ideas of object
> >inheritance.
>
> Nor mine, in fact the stuff I've seen about primitive OO in databases
> make me thing the folks just don't get it.
>
> Not to mention that I'm not convinced that "getting it" is worth it. OO
> fits some paradigms, not others, when programming in the large.

Well, the features I'm talking about don't affect you unless you want
OO.

> And
> most database stuff is really programming in the small (the query parts,
> the data is often huge, of course). The notion of asking a query, as
> in (say) psql is more related to the notion of typing a few lines at
> BASIC than the notion of writing a few million lines of integrated
> code. In database design, even more so than in conventional programming,
> it is the data model that reigns supreme and the actual size tends to
> be manageable, though the models themselves can be very complex.

And as those models become so complex it is crucial that the data-model
that
"reigns supreme" is properly integrated with the programming language.

For example, in an IBM Java project I'm working on there is 15000 lines
of
code that converts about 10 or so SQL tables into Java objects. Insane
stuff.

> I offer this as a reason why commercial DB users are more concerned
> with things like performance, scalability, and the like than with
> reworking of the RDBMS paradigm.

Actually developers are very interested in supporting the ODBMS paradigm
as you can see from the Sun proposed standard for RDBMS interface which
is an exact copy of the ODMG ODBMS interface standard.

In fact I think about 90% of "stuff" is best solved with an ODBMS
style of interaction. The trouble is that most ODBMS don't do the other
10% very well (i.e. wierd and wonderful queries), which is where
postgresql _could_ be the ultimate at solving both.

> Complaints about queries seem to
> place heavy emphasis on "why they are slow", and the OO paradigm
> doesn't help here.

Huh? The OO paradigm helps heaps here because you can model something
with a far smaller number of tables.

> I'm not certain that psuedo-OO features help.

Don't know what a pseudo-OO feature is.

> One reason I raise the issue of possible multiple front-ends (or making
> it easy for folks to make there own by making the parser->optimizer/backend
> interface more general) is that this whole area would seem to be one
> that begs for RESEARCH and experimentalism.

No research is required. I simply want to implement the ODMG STANDARD
for ODBMS databases on PostgreSQL. There are no great design issues
here,
just a matter of nailing down the details so that everyone can live
with them.

> The reality, AFAIK, is that in the crucible of commercial use, real
> OO databases and thinking simply haven't penetrated.

Not really true. In certain areas ODBMSes are pervasive. For example
many
Telco companies use ODBMSes for the majority of their stuff. It's
necessary
to get the performance they need. Also of course CAD apps can only use
an ODBMS.

No offence, but you havn't actually used one have you?