Aleksey Karyakin wrote:

>What about other extension types besides triggers and procedures?
>Extarnal scalar functions? Aggregate functions? These should have
>separate interfaces that don't provide database connection. In the
>long run, the interface to external-defined functions should have
>become no different to the internal ones.
>
>Also, it would be necessary for external procedures that have side
>effects to participate in transactions. Thus, the engine may
>establish 2PC transaction between itself and any involved external
>providers. There are magnitudes of gains that can be achieved by
>that - logging, replication, data distribution, etc.
>
>
>
>

I'm sorry, but this doesn't make any sense to me. I have no idea of
what triggers have to do with this.

The intended purpose of the internal SQL interface (InternalConnection,
et al) is to provide a mechanism to export database access and context
to loadable modules within the engine. The SecurityDb instances of
SecurityPlugin, for example, uses the mechanism to do database lookups:

// We've got some work to do.

Connection *connection = context->getConnection();
PStatement statement = connection->prepareStatement(
"select * from users where user_name=?");
statement->setString(1, accountName);
RSet resultSet = statement->executeQuery();
int hit = false;

if (resultSet->next())
{
hit = true;
const char *password = resultSet->getString("PASSWD");
JString oldHash = userData.getOldPasswordHash();
...

It would be nice to find ways to make the InternalConnection object
available to UDFs and blob filters as well.



--

Jim Starkey
Netfrastructure, Inc.
978 526-1376