Teradata Python Module

Tools
Tools covers the tools and utilities you use to work with Teradata and its supporting ecosystem. You'll find information on everything from the Teradata Eclipse plug-in to load/extract tools.
Teradata Employee

Re: Teradata Python Module

@ofajardo: As noted in other posts, the eventual goal for teradatasql is feature parity with the JDBC driver. Yes, that's a work in progress; but a lot of core functionality is in place already that makes the driver suitable for many applications in place of ODBC (e.g. via pyodbc or the "teradata" Python package).

 

ANSI mode is now supported, for example, though at the moment only with autocommit off.

Teradata Employee

Re: Teradata Python Module

Auto-commit is the next feature that we plan to ship for the teradatasql package.

Re: Teradata Python Module

Thanks a lot for your hard work! It's really awesome!
When do you think that the package will be complete, i.e. having parity with JDBC?
Teradata Employee

Re: Teradata Python Module

Teradata JDBC Driver development began back in 1998, so it has been in development for over 20 years.

 

I expect it will take a few years for the teradatasql package to achieve feature parity with the Teradata JDBC Driver.

New Member

Re: Teradata Python Module

Hello everyone,

 

We are using the Teradata Python module to connect our application to Teradata, and everything works well. However, we are wondering if this module protects against SQL injection attacks, specifically when using parametrized functions.

 

E.g., when passing parameters using the ? syntax as explained here:

https://developer.teradata.com/tools/reference/teradata-python-module#ParameterizedSQL

Are these parameters cleaned?

 

Thanks in advance for your reply!

Teradata Employee

Re: Teradata Python Module

No and yes and no.

No, the Teradata Python module does not do any cleaning of data passed to the database.

Yes, if you are using “?” parameters into standard SQL statements then SQL injection is not possible. Teradata only allows constant values to be passed via parameters and does not parse the contents of the parameter as a SQL statement so it cannot be executed.

No, if you pass the parameter into a stored procedure, table UDF,... and your code uses the parameter to construct and execute SQL then your code needs to be responsible for checking for SQL injection.