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: Frediano Ziglio <freddyz77 AT tin.it>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] [ freetds-Patches-1064459 ] new app program - datacopy
  • Date: Wed, 01 Jun 2005 10:31:50 +0200

Il giorno mar, 31-05-2005 alle 21:17 -0400, James K. Lowden ha scritto:
> 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.
>

Well, I did a huge job on 0.63 in the aim to not bump anymore so
version... If we add a function in 0.64 this function has to maintain in
future version:
- ABI (declaration with all parameters)
- behavior

> 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.
>

I'm not again adding a new dbXXXX function however it should be well
designed and discussed. Current implementation for example do not
distinguish from varchar to nvarchar nor it support cursor or compute
rows. Perhaps it would also be fine if it could return column
declaration (a member with "VARCHAR(20)" content).

> 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.
>

Or perhaps we could add a "core-ftds" category

> 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

As you see it's quite hard to shout me down :)

freddy77






Archive powered by MHonArc 2.6.24.

Top of Page