[TYPO3-core] SELECTquery() vs exec_SELECTquery()

[Martin Kutschker]

Dmitry Dulepov schrieb:
> Hi!
> 
> Martin Kutschker wrote:
> 
>> No need to urge everyone to exec_SELECTquery. It's IMHO even more 
>> stupid as some DBs have the idea of prepared statements, which is more 
>> in line with SELECTquery.
> 
> 
> I agree with Martin. Besides, I often use SELECTquery to get query text, 
> then log it, then execute. exec_SELECTquery does not let me to do it 
> easily.
> 
> As to sql_query, it should be deprecated, of course. May be it should 
> issue warnings all the time when it is used. I remember example from 
> Java. There are functions there that do not do anything but only print 
> error mesages (like "This function is obsolete use XXX instead"). I 
> think it is too extreme but not worst thing to do. All depends on the 
> amount of effort to support sql_query...

Hmpf, so I cannot write the statements I like (even *with* the API) because 
of DBAL doing such super-fancy stuff like mapping tables to handlers.

But wait, perhaps we can get a EXECquery() method.

If SELECTquery would not return a string, but an array/object it coud be 
used as argument for EXECquery(). For compatibility reasons we may 
introduce prepare_INSERTquery (etc) instead of changing the behaviour of 
INSERTquery().

The result of prepare_INSERTquery should contain the SQL statement, the 
statement type (SELECT, INSERT, UPDATE) a flag indictaing whether the 
statement has really been prepared (should be decided by a flag as input 
parameter of prepare_XXXXquery), the handle for the prepared statement.

Masi

PostgreSQL:
  pg_prepare
  pg_execute

Oracle:
  oci_parse
  oci_bind_by_name
  oci_execute

"ODBC":
  odbc_prepare
  odbc_execute

Firebird/Interbase:
  ibase_prepare
  ibase_execute

PDO:
  $stmt = $dbh->prepare(...);
  $stmt->bindParam(...);
  stmt->execute();