Hi Richard,
On Fri, 2007-04-20 at 12:14 +0100, Richard Huxton wrote:
> I'm not sure that anyone is clear why you just don't write this as a
> simple php/perl/ruby/whatever script? There are libraries that will
> output XML for you in most of these I'd suspect, and if not it's just an
> afternoon's work.
>
> I mean, your application is written in *some* language, isn't it?
It appears that Dmitry wants that an application, written in whatever
language, will issue an SQL query (or maybe a TML "query" such as
"a.b.c") and get back the XML. He's not concerned about loss of
datatype information because from his perspective the application will
just "present" the XML and similarly he's not concerned about DDL
features because TML is a "transport" mechanism.
I hope I haven't totally misrepresented Dmitry's words, but it seems he
wants to create a universal "database to web" interface language, so
that you and I won't have to deal with the pesky complications of
retrieving data in C with libpq or with PHP, Python and what not
libraries or "adapters", and then have to transform that data for
display to the user.
However, IMHO this appears to be rather simplistic and not completely
grounded in actual experience. In other words, Dmitry, have you written
a TML parser or a libpq prototype that given a TML "query" produces the
XML and tested it with datatypes other than integer and float. Or do
you have feedback from actual average users that TML is indeed easier to
use than SQL?
Two other items to think about. One is that the scheme apparently
requires that tables be defined in a special way, but no indication is
given as to how this will be accomplished or ensured that it is correct.
Second is how does TML handle relational manipulations such as
restriction, projection or aggregation. It appears TML is primarily for
joins.
Lastly, Dmitry, I think you'll be better off discussing this in
comp.databases.theory.
Joe
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
