Re: Alternatives to SQL ... - Mailing list pgsql-general
From | Bruce Momjian |
---|---|
Subject | Re: Alternatives to SQL ... |
Date | |
Msg-id | 200206071751.g57HpKM29223@candle.pha.pa.us Whole thread Raw |
In response to | Alternatives to SQL ... (Gunther Schadow <gunther@aurora.regenstrief.org>) |
List | pgsql-general |
The SQL interface is bullet-proof because it validates tables, computes offsets, and stuff like that. Passing something else into the database and bypassing the SQL stage would require rewriting all the C logic for SQL to match your new language --- a lot of work for little gain. --------------------------------------------------------------------------- Gunther Schadow wrote: > Hi, > > I'm wondering about alternative accesses to a PostgreSQL data base > by means other than SQL. I know one can map many things to SQL, but > let me think outside the box for just a moment: > > - Sending a parse tree in XML for processing by the optimizer. > This circumvents the SQL language and avoids the kinds of > syntactic ideosyncrasies of SQL (e.g., where you put commas.) > This is fairly trivial, but of course the question is, would > it be worth it? > > - Sending an execution plan in XML directly to the executor. > This now circumvents the SQL parser and optimizer. I know this > in in a way against the relational doxology and I don't take that > light-heartedly. However, isn't it true that most optimizers > cannot deal very well with more than 6 joins? I may be wrong, > but I find myself spending quite a bit of time fighting with the > Oracle or PostgreSQL optimizer to convince it to choose the plan > that I want. There is so much magic to it with hints and the > way you write SQL (where in relational theory the expressions are > equivalent, they make huge difference in what plan is being > generated.) So, it appears to me almost easier to just send a > plan directly and have the system execute that plan. > > - These direct interfaces could be a nice way to experiment with > new strategies without having to implement it on all three > layers (SQL language, optimizer, and executor.) > > You noticed I sneaked in XML as the interface, and that would be > neat because with XSLT it's so easy to manipulate. But I'm also > thinking about a Prolog binding or constraint logic programming > binding, that might be better optimizeable if it goes through a > more direct path than SQL. > > Am I crazy? > -Gunther > > -- > Gunther Schadow, M.D., Ph.D. gschadow@regenstrief.org > Medical Information Scientist Regenstrief Institute for Health Care > Adjunct Assistant Professor Indiana University School of Medicine > tel:1(317)630-7960 http://aurora.regenstrief.org > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
pgsql-general by date: