Question 1: Is the EXTERNAL NAME clause with no LANGUAGE attribute bound at compile time (when the CREATE PROCEDURE is executed) or is it bound at run time (when the procedure is called or the DLL is loaded)?

The answer appears to be "run time" although that doesn't seem to be mentioned in the Help.

Question 2: Is it possible to specify separate DLL names for Windows 32-bit and Windows 64-bit in the same EXTERNAL NAME clause?

A procedure using the EXTERNAL NAME clause with no LANGUAGE attribute defines an interface to a native function written in a programming language such as C. The native function is loaded by the database server into its address space.

The library name can include the file extension, which is typically .dll on Windows and .so on Unix. In the absence of the extension, the software appends the platform-specific default file extension for libraries. The following is a formal example.

When called, the library containing the function is loaded into the address space of the database server. The native function will execute as part of the server. In this case, if the function causes a fault, then the database server will be terminated. Because of this, loading and executing functions in an external environment using the LANGUAGE attribute is recommended. If a function causes a fault in an external environment, the database server will continue to run.

For syntaxes that support operating-system, if you do not specify operating-system, then it is assumed that the procedure runs on all platforms. If you specify Unix for one of the calls, then it is assumed that the other call is for Windows.

2) No, there currently is no way to specify both a 32-bit and 64-bit dll in the same external name clause. Your best bet is to have two external functions (one for 32-bit and one for 64-bit) and then have an extra SQL stored function that determines the appropriate bitness and calls the correct external function.