Skip to Content.
Sympa Menu

freetds - Re: [freetds] [ freetds-Patches-1064459 ] new app program - datacopy

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: brian AT bruns.com, FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Cc:
  • Subject: Re: [freetds] [ freetds-Patches-1064459 ] new app program - datacopy
  • Date: Tue, 31 May 2005 21:17:34 -0400

Brian Bruns wrote:
> I know we had a big discussion about the name "dbtablecolinfo" and
> namespace pollution in dblib. What was the resolution on this? I for
> one would prefer to clearly delineate this as a FreeTDS only function.

Hi Brian,

I believe Nick raised the concern of "polluting" the namespace.

My feeling is that FreeTDS is a set of libraries that conform to the
specifications and/or behaviors of the vendors' offerings. As long as we
do that, there's nothing wrong with adding functions that make our version
more convenient or efficient. Ours is an open source project, after all,
making it extremely easy for anyone so inclined to remove our "extra"
functions. And, in the event we actually trip over something that's
widely inconvenient -- a la dbopen() -- we can always change the symbol's
name and bump the .so version.

By that reasoning, I think dbtablecolinfo() is a fine addition to the
db-lib namespace. Anyone writing db-lib programs and naming his own
functions dbanything() is playing with fire anyway; anyone reading
application code would automatically assume dbsomething() is a db-lib
function.

As for documentation, aye. Bill's innovation would require a new column
in api_status.txt, if we want to include it. (I think we don't.) It
already has a doxygen comment block that clearly denotes it's a
FreeTDS-only function.

But I don't mean to shout anyone down. If I'm missing something, I'm sure
you or someone else will tell me. :-)

Regards,

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page