At 06:30 PM 24/04/2009, Sasha Matijasic wrote:

>>
>> The thing is, python's so adept at string handling that having this sort
>> of feature in KInterbasDB would be redundant.
>>
>> If each line of SQL is one command, then you can do something like
>> this:
>>
>
>Your approach doesn't work when the script is:
>
>recreate table b(a char(1) default ';' not null );
>-- set term ^;
>/* ; */
>set term ^;
>recreate procedure c(i char(1)='/*''')
>returns (result char(1))
>as begin
> select '^' from rdb$database into :result;
>end^
>set term ;^
>
>Admittedly, it's contrived example, but I do use set terms

SET TERM is not sql. It is a command syntax that belongs only to the isql utility. In fact, if you try to pass it across the API, you will get an "unknown token" error. Thus, amongst other manipulations, if don't want to remove isql-specific commands from scripts, you will *have* to manipulate the script input to have your Python client hide isql commands from the API.

*Any* sql parser has to deal with its input so that it passes fully valid statements across the API. Some sql elements, for example the semi-colon that is a valid (and required) symbol in PSQL, have special meaning in Python; all host language interfaces have this kind of problem, which is why they provide ways to distinguish - typically by using escape characters - when a symbol is used literally and when it is used as a host language element.

A script is nothing but a succession of multiple DSQL statements, i.e., there's nothing special about parsing the multiple statements in a script that makes it different from parsing the individual DSQL statement. You can even pass comments in single DML statements, although it doesn't achieve anything. Comments passed in DDL statements defining PSQL objects and views - whether dynamically or by way of a script - *is* meaningful, since the engine will store the comments in the source code.

So - what Michael says is exactly right. You have a powerful string-processing client language in Python: use it!

Helen