av@kielo.uta.fi (Arto V. Viitanen) (05/28/91)
There was some discussion on the subject before, but I have lost the thread... A student needs a library for C++ (GNU C++) to connect to SQL database -- INGRES preferably, but ORACLE would do also -- for part of his master's thesis. So is there any PD library or otherwise ? -- Arto V. Viitanen email: av@kielo.uta.fi University Of Tampere, av@ohdake.cs.uta.fi Finland
davidm@uunet.UU.NET (David S. Masterson) (06/03/91)
>>>>> On 28 May 91 08:39:52 GMT, av@kielo.uta.fi (Arto V. Viitanen) said:
Arto> A student needs a library for C++ (GNU C++) to connect to SQL database
Arto> -- INGRES preferably, but ORACLE would do also -- for part of his
Arto> master's thesis. So is there any PD library or otherwise ?
Having gone through the process of trying to connect up C++ with an SQL
preprocessor, I would recommend against attempting it unless you have an SQL
preprocessor designed to work with C++. Instead, I have found that the much
more reliable and portable method is to modularize your SQL calls into
straight C functions so that you may use the standard SQL/C preprocessor on
them and later link these with the rest of your C++ code. The other approach
(SQL embedded in C++) will always be a hack to interface with the way one SQL
preprocessor or C++ compiler works.
#define SOAPBOX_MODE
For this reason, I believe that the SQL standard should not specify a
preprocessing standard on top of some other language, but rather a method of
using SQL that does *not* require a change to the base language that it will
be used with. If that were the standard, then any RDBMS with an SQL interface
that works under (for instance) VAX/VMS would be able to interface with *all*
the languages used on VMS. You would not need a special preprocessor for each
language.
#undef SOAPBOX_MODE
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"jfr@locus.com (Jon Rosen) (06/05/91)
In article <CIMSHOP!DAVIDM.91Jun2195536@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >Having gone through the process of trying to connect up C++ with an SQL >preprocessor, I would recommend against attempting it unless you have an SQL >preprocessor designed to work with C++. Instead, I have found that the much >more reliable and portable method is to modularize your SQL calls into >straight C functions so that you may use the standard SQL/C preprocessor on >them and later link these with the rest of your C++ code. The other approach >(SQL embedded in C++) will always be a hack to interface with the way one SQL >preprocessor or C++ compiler works. > >#define SOAPBOX_MODE >For this reason, I believe that the SQL standard should not specify a >preprocessing standard on top of some other language, but rather a method of >using SQL that does *not* require a change to the base language that it will >be used with. If that were the standard, then any RDBMS with an SQL interface >that works under (for instance) VAX/VMS would be able to interface with *all* >the languages used on VMS. You would not need a special preprocessor for each >language. >#undef SOAPBOX_MODE EXEC SQL PREPARE REBUTTAL FROM "There are only three ways to introduce SQL capability into a language. First, you can add it directly to the syntax of the language. Second, you can provide a call-level interface. Third, you can provide a preprocessor which converts something that looks like native syntax into actual native syntax and calls to a supplied run-time call-level interface. The argument you give is for a direct call-level interface. The argument against this idea (given by IBM when SQL/DS was released) is that a call-level interface directly available to the user limits the ability of the vendor to enhance the interface in the future or optimize the use of the interface in the future without requiring possible changes to the source code. Using an abstract syntax enhancement which hides much of the internal detail needed to support SQL (such things as placing data and nulls into host variables and the like) makes it much simpler to enhance the interface (i.e., the preprocessor and the call-level run-time routine) without needing to have the user make changes in the program. This was deemed a critical issue. While C programmers may not find it a good argument (although I don't see why, since we all use our own preprocessor to support our programming already), it was essential for COBOL programmers which is the prrimary market IBM is aimed at. My only complaint is that there was (and is) no need to make the underlying call-level interface a magic hidden thing... Ibm could have published it as well as the preprocessor interface and stated that they expressly reserved the right to make major changes in the call-level interface at any time... Using the preprocessor would protect you but using the call-level would allow you to interface easily with languages that didn't have a preprocessor capablity. This they chose not to do so language support is limited to use in languages that have an SQL preprocessor... By the way, no other vendor is required to observe IBM's ridiculous adherence to not publish the interface, they have all just chosen to do so... Jon Rosen " END-EXEC EXEC SQL EXECUTE REBUTTAL END-EXEC
marc@sei.cmu.edu (Marc Graham) (06/05/91)
In article <CIMSHOP!DAVIDM.91Jun2195536@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: |> #define SOAPBOX_MODE |> |> For this reason, I believe that the SQL standard should not specify a |> preprocessing standard on top of some other language, but rather a method of |> using SQL that does *not* require a change to the base language that it will |> be used with. If that were the standard, then any RDBMS with an SQL interface |> that works under (for instance) VAX/VMS would be able to interface with *all* |> the languages used on VMS. You would not need a special preprocessor for each |> language. |> |> #undef SOAPBOX_MODE The current ANSI SQL standard includes just such a facility. It is called the Module Language and is defined in ANS X3H2.135-1989 and X3H2.168-1989. A module has the following format (clause 7 of .135 and clauses 7 and 8 of .168): -=-=-=-=-=-=- MODULE My_Module LANGUAGE ADA DECLARE My_Cursor CURSOR FOR SELECT stuff FROM places WHERE Column=Parameter PROCEDURE Open_My_Cursor Parameter INT SQLCODE; OPEN My_Cursor; -- and fetch and close statements -=-=-=-=-=- Notice that the only language specific part is the LANGUAGE clause, which specifies the calling conventions to be used by the code to be produced by the module language compiler. That code will contain a callable procedure called Open_My_Cursor which will take an integer input paramter called Parameter and produce an SQLCODE. And similar things for fetch, close, and whatever else you like. The Ada standardization group (Working Group 9 of SubCommittee 22 of ISO) has been working on an extension (actually, a modest rewrite) to the module language, called the SQL Ada Module Description Language (SAMeDL) which is a module language more suitable to the needs of Ada. (Strong, abstract types, checked at compile time, for example.) Marc H. Graham Software Engineering Institute marc@sei.cmu.edu Carnegie Mellon University (412) 268 7784 Pittsburgh, PA 15213
jfr@locus.com (Jon Rosen) (06/06/91)
In article <26540@as0c.sei.cmu.edu> marc@sei.cmu.edu (Marc Graham) writes: > >In article <CIMSHOP!DAVIDM.91Jun2195536@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > >|> >|> preprocessing standard on top of some other language, but rather a method of >|> using SQL that does *not* require a change to the base language that it will >|> be used with. If that were the standard, then any RDBMS with an SQL interface >|> #undef SOAPBOX_MODE >The current ANSI SQL standard includes just such a facility. It is >called the Module Language and is defined in ANS X3H2.135-1989 >and X3H2.168-1989. A module has the following format (clause 7 of >.135 and clauses 7 and 8 of .168): I believe (although I am not ABSOLUTELY certain and I don't have a copy of the draft standard lying around here handy) that the draft SQL2 standard has done away with the concept of the Module Language... It has clearly been abandoned in practice by just about everybody who is building SQL DBMSes... I do not know of any major commercial implementations of the module language in any data base system that calls itself ANSI compliant... If anyone has any contrary information, please feel free to post (or e-mail and I will post)... as I said, I am not positive, but I am pretty sure that this is the case... Jon Rosen
davidm@uunet.UU.NET (David S. Masterson) (06/07/91)
>>>>> On 5 Jun 91 23:13:36 GMT, jfr@locus.com (Jon Rosen) said: Jon> In article <26540@as0c.sei.cmu.edu> marc@sei.cmu.edu (Marc Graham) writes: Marc> In article <CIMSHOP!DAVIDM.91Jun2195536@uunet.UU.NET>, Marc> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: David> preprocessing standard on top of some other language, but rather a David> method of using SQL that does *not* require a change to the base David> language that it will be used with. Marc> The current ANSI SQL standard includes just such a facility. It is Marc> called the Module Language and is defined in ANS X3H2.135-1989 Marc> and X3H2.168-1989. A module has the following format (clause 7 of Marc> .135 and clauses 7 and 8 of .168): Jon> I believe (although I am not ABSOLUTELY certain and I don't have a copy Jon> of the draft standard lying around here handy) that the draft SQL2 Jon> standard has done away with the concept of the Module Language... Jon> It has clearly been abandoned in practice by just about everybody Jon> who is building SQL DBMSes... I do not know of any major commercial Jon> implementations of the module language in any data base system that Jon> calls itself ANSI compliant... I know I started this, but VAX RDB does implement an SQL Module language which agrees pretty much with what Marc said. I just wasn't sure whether this was a standard thing when I posted the original message (and if it wasn't, I wanted to register a reason why it should be). Also, I've gotten a message suggesting that Oracle will be implementing this as well (no time frames). -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
davidm@uunet.UU.NET (David S. Masterson) (06/07/91)
>>>>> On 4 Jun 91 18:27:56 GMT, jfr@locus.com (Jon Rosen) said: Jon> In article <CIMSHOP!DAVIDM.91Jun2195536@uunet.UU.NET> Jon> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: David> Having gone through the process of trying to connect up C++ with an SQL David> preprocessor, I would recommend against attempting it unless you have David> an SQL preprocessor designed to work with C++. Instead, I have found David> that the much more reliable and portable method is to modularize your David> SQL calls into straight C functions so that you may use the standard David> SQL/C preprocessor on them and later link these with the rest of your David> C++ code. The other approach (SQL embedded in C++) will always be a David> hack to interface with the way one SQL preprocessor or C++ compiler David> works. David> For this reason, I believe that the SQL standard should not specify a David> preprocessing standard on top of some other language, but rather a David> method of using SQL that does *not* require a change to the base David> language that it will be used with. If that were the standard, then David> any RDBMS with an SQL interface that works under (for instance) VAX/VMS David> would be able to interface with *all* the languages used on VMS. You David> would not need a special preprocessor for each language. Jon> There are only three ways to introduce SQL capability into a language. Jon> First, you can add it directly to the syntax of the language. Second, Jon> you can provide a call-level interface. Third, you can provide a Jon> preprocessor which converts something that looks like native syntax into Jon> actual native syntax and calls to a supplied run-time call-level Jon> interface. The argument you give is for a direct call-level interface. Jon> The argument against this idea (given by IBM when SQL/DS was released) is Jon> that a call-level interface directly available to the user limits the Jon> ability of the vendor to enhance the interface in the future or optimize Jon> the use of the interface in the future without requiring possible changes Jon> to the source code. Not if you consider the call-level interface to be standard. When the call-level interface is standard, then changes to that standard have exactly the same results as changing the definition of SQL. The difference is that the language (and its support environments) in which SQL is embedded need know *nothing* about SQL. Note, there is nothing that says the SQL Module itself can't be implemented via the hidden interface. Users, though, only require a bare minimum of that interface. Jon> Using an abstract syntax enhancement which hides much of the internal Jon> detail needed to support SQL (such things as placing data and nulls into Jon> host variables and the like) makes it much simpler to enhance the Jon> interface (i.e., the preprocessor and the call-level run-time routine) Jon> without needing to have the user make changes in the program. This was Jon> deemed a critical issue. While C programmers may not find it a good Jon> argument (although I don't see why, since we all use our own preprocessor Jon> to support our programming already), it was essential for COBOL Jon> programmers which is the prrimary market IBM is aimed at. If you're comparing with C++, that's still a sore issue where debugging and other environmental support is concerned. Even in the face of these precompilers, how does COBOL code handle things like NULLS and placing data into host variables? I contend that COBOL programmers must still set aside data variables for these things and give them to SQL. A call-level interface would not affect that. Jon> My only complaint is that there was (and is) no need to make the Jon> underlying call-level interface a magic hidden thing... IBM could have Jon> published it as well as the preprocessor interface and stated that they Jon> expressly reserved the right to make major changes in the call-level Jon> interface at any time... Using the preprocessor would protect you but Jon> using the call-level would allow you to interface easily with languages Jon> that didn't have a preprocessor capablity. This they chose not to do so Jon> language support is limited to use in languages that have an SQL Jon> preprocessor... By the way, no other vendor is required to observe IBM's Jon> ridiculous adherence to not publish the interface, they have all just Jon> chosen to do so... Which is distressing because it used to be that this was not a terrible burden when using SQL embedded in C (or any supported language). The problem, though, multiplies significantly when trying to interface an SQL preprocessor with another language preprocessor (in this case, C++, but it could just as easily have been RATFOR, M4, or a host of others). By using a preprocessor to a language, the environment of the original language is broken. The more preprocessors you add, the more broken the environment. Where SQL is concerned, there was no need for it to be environment hostile. -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
marc@sei.cmu.edu (Marc Graham) (06/08/91)
In article <25095@oolong.la.locus.com>, jfr@locus.com (Jon Rosen) writes: |> In article <26540@as0c.sei.cmu.edu> marc@sei.cmu.edu (Marc Graham) writes: |> > |> >In article <CIMSHOP!DAVIDM.91Jun2195536@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: |> > |> >|> |> >|> preprocessing standard on top of some other language, but rather a method of |> >|> using SQL that does *not* require a change to the base language that it will |> >|> be used with. If that were the standard, then any RDBMS with an SQL interface |> >|> #undef SOAPBOX_MODE |> >The current ANSI SQL standard includes just such a facility. It is |> >called the Module Language and is defined in ANS X3H2.135-1989 |> >and X3H2.168-1989. A module has the following format (clause 7 of |> >.135 and clauses 7 and 8 of .168): |> |> I believe (although I am not ABSOLUTELY certain and I don't have a copy |> of the draft standard lying around here handy) that the draft SQL2 |> standard has done away with the concept of the Module Language... |> |> It has clearly been abandoned in practice by just about everybody |> who is building SQL DBMSes... I do not know of any major commercial |> implementations of the module language in any data base system that |> calls itself ANSI compliant... |> |> If anyone has any contrary information, please feel free to post |> (or e-mail and I will post)... as I said, I am not positive, but |> I am pretty sure that this is the case... |> |> Jon Rosen I do have a copy of the draft standard lying around here. The module language is chapter 12. Marc H. Graham Software Engineering Institute marc@sei.cmu.edu Carnegie Mellon University (412) 268 7784 Pittsburgh, PA 15213
davidm@uunet.UU.NET (David S. Masterson) (06/10/91)
>>>>> On 7 Jun 91 20:14:43 GMT, marc@sei.cmu.edu (Marc Graham) said:
Marc> I do have a copy of the draft standard lying around here. The module
Marc> language is chapter 12.
What's the date on the standard? Is it what is known as "SQL2"?
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"marc@sei.cmu.edu (Marc Graham) (06/10/91)
In article <CIMSHOP!DAVIDM.91Jun9135532@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: |> >>>>> On 7 Jun 91 20:14:43 GMT, marc@sei.cmu.edu (Marc Graham) said: |> |> Marc> I do have a copy of the draft standard lying around here. The module |> Marc> language is chapter 12. |> |> What's the date on the standard? Is it what is known as "SQL2"? |> -- |> ==================================================================== |> David Masterson Consilium, Inc. |> (415) 691-6311 640 Clyde Ct. |> uunet!cimshop!davidm Mtn. View, CA 94043 |> ==================================================================== |> "If someone thinks they know what I said, then I didn't say it!" The date is April 1991. It is what is >>informally<< known as SQL2. Formally, it is the DIS -- Draft International Standard -- for Database Language SQL. Its number is DIS 9075:199x. This is an ISO number and a -draft- ISO standard. The x is replaced by the digit representing the year the document becomes an International Standard. The current feeling is x == 2. (The current standard is IS 9075:1989.) Where the current standard is an intersection of existing implementations, the new standard is a union. It has not only all the obvious things missing from the current standard, dynamic SQL, exectuable DDL, datetime; it also has stuff you might not have thought of: outer join, `information schema', character set definitions. (I thought it had recursion but I can't seem to find it.) The current standard is 145 pages. The draft is 522 pages! Marc H. Graham Software Engineering Institute marc@sei.cmu.edu Carnegie Mellon University (412) 268 7784 Pittsburgh, PA 15213