freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: Frediano Ziglio <freddy77 AT gmail.com>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] sql_cmd in unittests
- Date: Fri, 6 Feb 2009 11:05:10 +0100
2009/2/6 James K. Lowden <jklowden AT freetds.org>:
> Frediano Ziglio wrote:
>> new sql_cmd stuff produce a leak (we do not close INPUT file so
>> we have a leak).
>
> Eh. Program exits, OS reclaims resources. When the unittests are
> finished running, there are no files open. I don't consider that to be a
> "leak". I don't think main() should call free(3), either. :-)
>
> The idea that one pedantically must close every file reminds me of the
> days when Structured Programming insisted that every function had to have
> one entry and one exit point (never "if (!foo) return 0"). I tend to
> favor the Less Is More school of thought.
>
Yes, but using an automatic leak detector I have to manually ignore
these leaks every time :(
I'll try with atexit.
>> - sql_cmd is always called with INPUT as second argument, so I would
>> remove this argument (also because sql_cmd refer to sql_file but for
>> user supplied files is not valid)
>
> My idea was that indeed we could add a getopts option to override the
> filename. That would be more useful for some tests than others. It
> seemed to me that the query-reader should be able to read any file
> including standard input.
>
Why not replace the source file?? I don't think you will replace file
many times... code is always the same so you can't alter query that
much. Also is better to parse arguments in read_login_info and use
INPUT instead of parsing in every unittests. And in the rarest
situation where we use more scripts we could add a function to
override INPUT and sql_file.
>> we could add some special comments in sql script and an
>> additional argument to sql_cmd to specify a name for a specific
>> command.
>
> I thought about it. I didn't find any immediate use, so I left it as-is.
> One objective, though, is to be able to compare the unit test's behavior
> to that of another utility, so plain-jane SQL has its advantages.
>
But you would need an utility to emulate test behavior.... we could
add extra comment in a tsql compatible way, something like
-- #Name:preparation
create table #tmp(int a)
go -- #Continue #Execute
so TSQL is happy too
> No answer to my automake question yet. :-(
>
> http://lists.gnu.org/archive/html/automake/2009-02/threads.html
>
?? FREETDS_SRCDIR macro is not sufficient?
freddy77
-
[freetds] sql_cmd in unittests,
Frediano Ziglio, 02/05/2009
-
Re: [freetds] sql_cmd in unittests,
James K. Lowden, 02/05/2009
-
Re: [freetds] sql_cmd in unittests,
Frediano Ziglio, 02/06/2009
- Re: [freetds] sql_cmd in unittests, James K. Lowden, 02/06/2009
-
Re: [freetds] sql_cmd in unittests,
Frediano Ziglio, 02/06/2009
-
Re: [freetds] sql_cmd in unittests,
James K. Lowden, 02/05/2009
Archive powered by MHonArc 2.6.24.