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: Brian Bruns <brian.bruns AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] [ freetds-Patches-1064459 ] new app program - datacopy
  • Date: Wed, 1 Jun 2005 06:17:17 -0400

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
>




Archive powered by MHonArc 2.6.24.

Top of Page