FYI, one of the main goals of the Muldis D language is to be an "open source SQL
standard". It is intended to satisfy both relational and NoSQL folks, and
predates UnQL significantly.
Muldis D has always been published openly and is comprehensive enough to cover
anything that SQL does, and anyone is welcome to improve it.
Moreover, this standard has built-in resilience against "embrace, extend and
extinguish" by including explicit versioning with authorities (Perl 6 inspired
that feature), so that if anyone forks the language, it is possible for the
different versions to be easily distinguishable and non-conflicting, and in a
more benign respect it is designed to be extensible so DBMSs can be free to
evolve under it, adding unique features, while not causing compatibility
conflicts with other DBMSs in the process.
Note that I have fallen behind in specifying a number of intended significant
design improvements/simplifications to the spec proper, though much of this is
hashed out in the laundry list TODO_DRAFT file in github.
-- Darren Duncan
Joe Abbate wrote:
On 09/19/2011 12:40 PM, Christopher Browne wrote:
On Mon, Sep 19, 2011 at 12:20 PM, David Fetter <da...@fetter.org> wrote:
Actually, I think it *is* a bad idea, as it would require construction
from whole cloth of kinds of mostly political infrastructure that we
don't have, as a community and aren't necessarily notably competent to
construct.
The nearest sort of thing that *could* conceivably be sensible would
be to participate in UnQL
<http://www.unqlspec.org/display/UnQL/Home>. That's early enough in
its process that it's likely somewhat guidable, and, with the
popularity of NoSQL, being at the "ground breaking" of a common query
language to access that would likely be useful to us.
If we wanted to start a new standards process, I imagine it would best
involve embracing "truly relational," stepping back to PostQUEL, and
promoting a standard based on something off more in that direction.
If I were looking for something "truly relational" I wouldn't go towards
JSON or NoSQL, I'd go with something like Dee
(http://www.quicksort.co.uk/ ) which IIRC were interested in building a
PostgreSQL inteface.
As much as that might sound like a terrible idea, trying to "take
over" SQL by forking it strikes me as a much *worse* idea.
My intention was not to "take over" anything. I only think it may be
useful to discuss SQL features, informally or otherwise, with other open
source "competitors" such as SQLite, MySQL (brethren), Firebird, etc.,
and Josh, having been close to the MySQL camp (even physically, from
what I recall :-) is possibly well suited to start that discussion.
Joe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
