Thread: SQL/MED spec for cross-database linkages
Joe, have you heard of a standard called SQL/MED? I came across a
description of it the other day. You might think it's got some medical
connotation, but actually the acronym is Management of External Data,
and what it is is a standard spec for shipping chunks of SQL queries to
remote servers. For instance, given
SELECT * FROM a.foo, b.bar WHERE ...
where a.foo is on a remote machine, the spec lays down how the local and
remote servers can cooperate to execute this query intelligently ---
including deciding where to execute various WHERE clauses to minimize
the amount of data shipped. (The article I found was actually about
how the new draft version of SQL/MED improves the protocol to let this
sort of thing be done better; it seems the original spec only allowed
retrieval of a whole table's contents.)
This looks like it might be a great long-term replacement for dblink,
and if it is standard, so much the better.
I imagine the draft version of the new SQL/MED spec may be available on
the web, but haven't gone looking.
Just a heads-up in case you are interested...
regards, tom lane
On Fri, 2002-12-06 at 11:04, Tom Lane wrote: > Joe, have you heard of a standard called SQL/MED? I came across a It's that one of the later parts of the SQL 99 spec? Section 9 or thereabouts? -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
On Fri, 2002-12-06 at 11:35, Rod Taylor wrote: > On Fri, 2002-12-06 at 11:04, Tom Lane wrote: > > Joe, have you heard of a standard called SQL/MED? I came across a > > It's that one of the later parts of the SQL 99 spec? Section 9 or > thereabouts? Note to self, don't reply to emails and have a separate conversation at the same time. Found SQL/MED, Section 21 of ISO 9075-9. -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
Tom Lane wrote: > Joe, have you heard of a standard called SQL/MED? I came across a > description of it the other day. You might think it's got some medical > connotation, but actually the acronym is Management of External Data, > and what it is is a standard spec for shipping chunks of SQL queries to > remote servers. For instance, given > > SELECT * FROM a.foo, b.bar WHERE ... > > where a.foo is on a remote machine, the spec lays down how the local and > remote servers can cooperate to execute this query intelligently --- > including deciding where to execute various WHERE clauses to minimize > the amount of data shipped. (The article I found was actually about > how the new draft version of SQL/MED improves the protocol to let this > sort of thing be done better; it seems the original spec only allowed > retrieval of a whole table's contents.) > > This looks like it might be a great long-term replacement for dblink, > and if it is standard, so much the better. Great! Thanks for the heads up. I see that Rod provided the reference in his post -- I'll go find it. The idea of expanding dblink to other RDBMSs is picking up steam. I've been conversing off list with someone who has a semi-working hacked version of dblink that uses JDBC in place of libpq. Do you think a proposal based on the SQL/MED spec would be entertained for 7.4, or would the release after be a safer bet? I'm not sure (since I haven't seen it yet) what I'm getting myself into ;-), but I might like to take it on since there seems to be a lot of interest. Joe Joe
Rod Taylor <rbt@rbt.ca> writes: > Found SQL/MED, Section 21 of ISO 9075-9. That's the old version, though. The new draft is at (digs out article) http://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-14-XML-2002-03.pdf according to this article, but I'm not having any luck accessing that URL. Let me email the authors and see if I can get a copy. regards, tom lane
Joe Conway <mail@joeconway.com> writes:
> Do you think a proposal based on the SQL/MED spec would be entertained for
> 7.4, or would the release after be a safer bet?
The impression I get from this article is that SQL/MED is nontrivial.
If you think you can get something useful going for 7.4, step right up
--- but I think you should plan on being at it for awhile. In any
case, a multi-step implementation plan would be a good idea.
regards, tom lane
On Fri, Dec 06, 2002 at 01:52:01PM -0500, Tom Lane wrote: > Rod Taylor <rbt@rbt.ca> writes: > > Found SQL/MED, Section 21 of ISO 9075-9. > > That's the old version, though. The new draft is at (digs out article) > http://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-14-XML-2002-03.pdf > according to this article, but I'm not having any luck accessing that > URL. Let me email the authors and see if I can get a copy. Hmm, seems you need to change protocols: ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-14-XML-2002-03.pdf Ross
On Fri, Dec 06, 2002 at 01:52:01PM -0500, Tom Lane wrote: > Rod Taylor <rbt@rbt.ca> writes: > > Found SQL/MED, Section 21 of ISO 9075-9. > > That's the old version, though. The new draft is at (digs out article) > http://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-14-XML-2002-03.pdf > according to this article, but I'm not having any luck accessing that > URL. Let me email the authors and see if I can get a copy. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? Having pulled that one, I discover it's actually the XML related spec. The MED one is at: ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-09-MED-2002-01.pdf There's a text version, as well (always nice for grepping): ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-09-MED-2002-01.txt Ross
"Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> Having pulled that one, I discover it's actually the XML related spec. The
> MED one is at:
> ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-09-MED-2002-01.pdf
Ah-hah, so the URL in the SIGMOD Record article is just wrong :-(
Meanwhile, one of the authors sent me a copy privately (it helps to have
shared an office at grad school ;-)) which I was about to offer around,
but I guess we can just use the FTP link instead.
regards, tom lane