Skip to Content.
Sympa Menu

freetds - ODBC unimplemented functions again (was Re: [freetds] [PATCH] VMS build support)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Craig A. Berry" <craigberry AT mac.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: ODBC unimplemented functions again (was Re: [freetds] [PATCH] VMS build support)
  • Date: Sun, 2 Mar 2003 16:30:30 -0600

At 10:34 AM +0100 3/2/03, Frediano Ziglio wrote:

>I looked more deeply your patch (I don't know VMS at all)
>What does odbc object export? It seem to export all entry pointing to a
>dummy function (freetds_odbc_unimplemented) when a function is not
>implemented. This is not correct, object must export only implemented
>functions.

Thanks for reviewing the patch. Let's back up and discuss the
rationale for what I did and the rationale for only exporting
implemented functions.

Putting in placeholders for functions that are part of the published
API but are not yet implemented is the first step toward upward
compatibility. In principle, a function that has a placeholder now
(via an alias to a stub function in the linker options file) but
becomes implemented in the future can become accessible to
applications without any relinking of the application required. This
assumes a couple of things, one of them being the proper maintenance
of versioning info in the driver shareable image (dynamic library), a
step I have not taken yet. The other thing it assumes is a driver
manager that properly interrogates the driver at run-time to see what
functions it has available.

As we discussed in this forum a few weeks ago, some driver managers
rely exclusively (and erroneously) on link-time information about
what functions are available in the driver. IIRC, iODBC falls in
this category and unixODBC does not. Since iODBC has not, as far as
I know, been ported to VMS, and unixODBC does not have the problem,
the main advantage to limiting the export list doesn't seem overly
compelling. Are there other advantages?

On the other hand, since I haven't yet taken the extra steps to
maintain version info in the driver and there are other (messier)
ways to allow for upward compatibility in the linker options file
than using aliases to a stub function, the way I did it doesn't have
as many tangible advantages as I at first thought it would.

I'll give some thought to this in my next round of revisions but I
can't see it makes much difference one way or the other.
--
________________________________________
Craig A. Berry
mailto:craigberry AT mac.com

"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser




Archive powered by MHonArc 2.6.24.

Top of Page