MySQL extension

[iArnold]

@hostilefork

The natives you are writing need to be parameterized somehow in a way that separates the code and the data. Something like:

table: "widgets"
quantity: 10
mysql-query "select data from ? where x = ?" [table quantity]  ; "good"

mysql-query spaced ["select data from" table "where x =" quantity]  ; "bad"

You're not using the mysql_escape_xxx or mysql_real_escape_xxx functions.

I see and understand the principle.
How would this work out?
Will the native mysql-query always have to expect a string and a block of items to be replaced, even if the query is used when there is NO user input at all intended? I have several scripts that are just internal use on the website, like retrieving the number of visitors (and upping it by 1 and saving it). An extra empty block to add seems useless to me.

Perhaps introducing a mysql-execute function for this is a good option.

PHP real escape example So this can be done from within the script handling the input itself when a function mysql-real-escape-string is available.

There is an alternative in prepared statements too.

[hostilefork]

@iArnold

PHP real escape example So this can be done from within the script handling the input itself when a function mysql-real-escape-string is available.

The prepared statements offer a "placeholder" form, similar to ODBC...which may be better than using the escaping form:

"As an alternative to explicitly escaping special characters, many MySQL APIs provide a placeholder capability that enables you to insert special markers into a statement string, and then bind data values to them when you issue the statement. In this case, the API takes care of escaping special characters in the values for you."

An advantage of using that form would be that it would be more similar to the way the ODBC is implemented.

@iArnold

Will the native mysql-query always have to expect a string and a block of items to be replaced, even if the query is used when there is NO user input at all intended?

If the implementation is done in layers, then you can have a higher level form which takes a single parameter...either a string, or a block with the values escaped inline.

See the ODBC-EXECUTE example.

What I suggest is making the C natives about as simple and close to the C API they wrap as possible, and doing the transformative work in usermode code above that.

[iArnold]

I managed to achieve what I wanted, using the dynamic library that was installed outside one of the regular folders.

I had to link with

-Wl,-rpath,/usr/lib64/irregularfolder

and

-L/usr/lib64/irregularfolder -lmariadb

I checked on the server and ldd gave me the usage as I wanted to see it.
Only hurdle I had to face was an illegal Foo in my header info, I had typed

print "Content-type: text/html^/Foo"

Where I should have typed

print "Content-type: text/html^/^/Foo"

(The second ^/ is implicit if you omit the "Foo" part)
So that scared me for a moment as if it were Halloween already

Now up to integrating this solution into the build process.

[iArnold]

I finally convinced my hosting provider to fix the setup. Pointing at this page about shared libraries I noticed the ldconfig had not been updated. So now I can use the programs I compile by the regular method and do not need to use the -Wl,rpath and other arguments any more. These tricks will be included in some form of documentation though in case somebody will run into similar issues on future occasions.