Commented by: @asfernandes

And it has said since the start DYN was planned to be removed, that the alternative would be EXECUTE IMMEDIATE in GPRE, left for the user, as nobody except ourselves uses GPRE in this way.

Why would we care to do a major development for a obsolete tool?

Commented by: @dyemanov

While GPRE is obviously somewhat outdated, I would not call it obsolete or deprecated. It's still in use by some customers. But so far everybody was OK with GPRE lagging behind, so this ticket should not be a showstopper for v3 even if we do nothing for DDL support right now.

Commented by: Eberhard Leba (eleba)

In one of our projects we use GPRE and were happy with FB 2.5 so far. But FB 2.5
does not exist on Debian 9 and now we are forced to switch to FB 3.
Unfortunately the compile failed because 'isc_dyn_def_function' is now undefined.

The problematic SQL is DECLARE EXTERNAL FUNCTION which leads gpre to call
declare_udf(..) in src/gpre/cmd.cpp

IMHO to be clean the tool shall at least emit sth. like "Statement unsupported"
while parsing the source rather to produce wrong secondary code.
Because no one else complained about this so far we seem to be the only ones to
use features like this. We'll find a workaround for that, but it would have
reduced the effort to pin down the issue.

And finally having 'gpre is deprecated please switch to ...' hint in the text
emitted by gpre -? and in some release note would help allot to understand that
we need to swallow the bitter pill mid to long term:
Completely change our FB access layer in a product being on the market for 16 years now.

The workaround for this issue is to do the declaration during database creation.

Never the less embeded SQLusing gpre is still the primary method described in
https://www.firebirdsql.org/pdfmanual/html/ufb-cs-appdev.html