Re: We all are looped on Internet: request + transport = invariant - Mailing list pgsql-sql

Hi Dmitry,

On Tue, 2007-04-24 at 15:31 +0300, Dmitry Turin wrote:
> J> How do I see employees in just one department?
> 
> department[id="1"].employee >>;
> 
> or
> 
> department[name="Technical"].employee >>;

How is that any different or better than a standard SQL SELECT (or to
use another context, a Tutorial D statement)?

> J> How do I see a single employee?
> 
> employee[id="31"] >>;
> 
> or
> 
> employee[name="Tomson"] >>;
>    -- maybe several employee with surname Tomson

What if I want to see specific columns of the employee row or see the
name of the department that Tomson works in or the name of Tomson's
manager?

> J> How do I actually retrieve SUM(salary)
> 
> Declare field "sum" as not fictional.
> 
> You can always declare field "sum" as not fictional and
> put sign "#" before field to prevent output of field.

This "fictional" attribute of yours implies a change to SQL DDL.

> J> GROUP BY department?
> 
> It is always "group by", because it is field of record "department"

That is only in *your* view of the data.  What if someone comes along
and wants to do SELECT name, SUM(salary) FROM employee GROUP BY name?
Or GROUP BY date_trunc('year', hire_date)?

The point is that SQL has been refined (although some may disagree :-)
over the past quarter century to answer this and many other questions
and I don't see how TML improves on that (for an enhanced answer to SQL,
take a look at Tutorial D).  And XML is *not* the only answer to viewing
or even "transporting" data.  Some people prefer a tabular
representation, others may prefer a hierarchical view, and yet others
want to see a chart (and even the same person may prefer a different
view for various purposes or at various times).

And there's nothing wrong with Perl, PHP, Python and the myriad
interface languages.  That's what "free" software is all about.  The
POSTGRES UCB project had a language called PostQUEL, which may have been
technically superior to SQL, but market forces (unfortunately not all
"free") pushed Postgres95 and then PostgreSQL to adopt the latter in
preference to PostQUEL.  Maybe one day we'll have one (or two) interface
languages to PostgreSQL that 80% of the users will use, but it will not
be because you or I or even the PG Global Dev Group leaders say it's
"better" or "it's necessary", but because thousands of users may agree
and converge on those choices.

Joe