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

Brian Bruns brian.bruns at gmail.com
Wed Jun 1 06:17:17 EDT 2005


Jim,

It's not that I think it shouldn't be there, I believe it is a fine
additon to the library.  I want to make sure this issue gets a proper
airing before we commit to a name.  Changes to the .so version not
withstanding, it'll be a pain to change it later, and more to the
point it's a precedence thing.

I believe this guy should stick out like a sore thumb.  When looking
at the code, or copying from somewhere else anyone should immediate
say "ah that's not a portable function".  We already have the tds_*
namespace for our own functions.  Problem is the name is a bit
unwieldy to begin with so tds_dbtablecolinfo() is even worse. ;-) 
Perhaps something shorter like tds_dbtabinfo() ??? Opinions?

As we accumulate more of these over time (not sure how likely that is
really, but...) we should adopt some kind of convention and follow it.

Cheers,

Brian

2005/5/31, James K. Lowden <jklowden at freetds.org>:
> 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
>


More information about the FreeTDS mailing list