Re: sql_cmd in unittests

2009/2/6 James K. Lowden <[email protected]>:
> 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