Add the SQLDA_CURRENT_VERSION macro definition to the sqlda_pub.h file.

[dmitry-v-orekhov]

The Firebird project inherits its code from Borland Interbase 6.0.

Therefore, the sqlda_pub.h file, contains a description of the XSQLVAR version 1 structure.

It also contains the macro definition SQLDA_VERSION1:

#define SQLDA_VERSION1 1

In the future, it may be necessary to declare the XSQLDA structure in a new way.

Therefore, it would be good to add another macro definition to the sqlda_pub.h file :

#define SQLDA_VERSION1 1
#define SQLDA_CURRENT_VERSION SQLDA_VERSION1

Just like the developers of Borland Interbase 7.5 did.

[aafemt]

It has meaning only together with declaration of XSQLDA1 and typedef XSQLDA to XSQLDA1. Otherwise application that have following code inside will be (silently) broken when compiled against new headers:

XSQLDA sqlda;
sqlda.version = SQLDA_CURRENT_VERSION;

No need to blindly repeat Borland's mistakes.

[dmitry-v-orekhov]

Right now, the XSQLDA data type is a version 1 structure. Therefore, adding a macro definition:

#define SQLDA_CURRENT_VERSION SQLDA_VERSION1

Will not lead to incorrect compilation of the code:

XSQLDA sqlda;
sqlda.version = SQLDA_CURRENT_VERSION;

The XSQLDA_V2 structure may be announced in the future. And the alias XSQLDA is declared like this:

typedef XSQLDA_V2 XSQLDA;

And the SQLDA_CURRENT_VERSION macro definition will also be changed in the xsqlda_pub.h file:

#define SQLDA_CURRENT_VERSION SQLDA_VERSION2

Which again will allow this code to compile successfully:

XSQLDA sqlda;
sqlda.version = SQLDA_CURRENT_VERSION;

Anyone who wants to use a specific XSQLDA structure will write the following code:

XSQLDA_V1 sqlda;
sqlda.version = SQLDA_VERSION1;

Which again will not lead to an error.

What's the problem?

[aafemt]

No problem as such. I just pointed out that the macro SQLDA_CURRENT_VERSION alone is meaningless and serves no purpose. User code won't adapt for new SQLDA just by using it.

[dmitry-v-orekhov]

Sure. In order for the code to adapt, it needs to be written as I indicated.

Simply adding this macro definition allows you to write the code now so that when the new XSQLDA structure is released, it would not need to be adapted.

This is exactly what the Interbase 7.5 developers did by announcing the XSQLDA version 2 structure.

[dmitry-v-orekhov]

Firebird developers must maintain a mutual correspondence between the XSQLDA type and the SQLDA_CURRENT_VERSION macro definition.

Programmers using Firebird will write like this:

XSQLDA sqlda;
sqlda.version = SQLDA_CURRENT_VERSION;

And everything will be OK.

Is it difficult or impossible ?

[dmitry-v-orekhov]

So I made a patch for the changes I was talking about.

diff.txt

[dmitry-v-orekhov]

Please tell me, should I create a branch myself, make changes, transfer them to the repository, request a "pull request" to make the changes I indicated ? Or this project is being developed by a limited team and changes are not accepted from the outside ?

If possible, please indicate where you can learn more about the principles of working on this product.
Who has the right to put branches in the repository?
Who manages these permissions? And the like.

[hvlad]

Please tell me, should I create a branch myself, make changes, transfer them to the repository, request a "pull request" to make the changes I indicated ?

This is usual order of operations.

Or this project is being developed by a limited team and changes are not accepted from the outside ?

Team is limited, reasonable changes are accepted.

If possible, please indicate where you can learn more about the principles of working on this product. Who has the right to put branches in the repository? Who manages these permissions? And the like.

You may find info at readme in root folder and at Firebird web site.

About your proposition: many years ago it was decided to not go Borland way, not extend SQLDA, not introduce V2 for it, etc
Instead, new OO API was introduced in v3.
Thus, your proposition makes no much sense, while it is harmless at the same time.
I, personally, not going to accept it, while will not object if someone else does.

[hvlad]

Please tell me, should I create a branch myself, make changes, transfer them to the repository, request a "pull request" to make the changes I indicated ?

This is usual order of operations.

Addition: of course, you can't create branch in this repository, only in your own fork.

[AlexPeshkoff]

On 7/30/26 18:06, Dmitry V. Orekhov wrote: *dmitry-v-orekhov* left a comment (FirebirdSQL/firebird#9109) <#9109 (comment)> Please tell me, should I create a branch myself, make changes, transfer them to the repository, request a "pull request" to make the changes I indicated ? Or this project is being developed by a limited team and changes are not accepted from the outside ?

Changes are accepted and PR typically needed for that. Your change appears to be not dangerous but as for me I do not catch what for it's needed. May be a sample of use can help...

If possible, please indicate where you can learn more about the principles of working on this product. Who has the right to put branches in the repository?

Core developers. But you do not need to add something to repository to create PR.

[dmitry-v-orekhov]

When I suggested making changes, I proceeded from two assumptions:

1. The structure of XSQLDA may change in the future.
2. The code that uses the firebird api and the code that uses the Interbase api will be absolutely identical.

I have already been informed about the unacceptability of the first one:

About your proposition: many years ago it was decided to not go Borland way, not extend SQLDA, not introduce V2 for it

To achieve the second, it is enough to define only the macro definition SQLDA_CURRENT_VERSION.

Actually, an example has already been given:

XSQLDA sqlda;
sqlda.version = SQLDA_CURRENT_VERSION;

[aafemt]

Your second assumption is wrong. IB and FB had the same API at the divorce point but now they are incompatible.

[dmitry-v-orekhov]

Your second assumption is wrong. IB and FB had the same API at the divorce point but now they are incompatible.

If we consider APIs as sets, then complete sets are naturally different. However, if we select some subsets of these sets, it turns out that these subsets are identical.

So, I manage to create source code that is written exactly the same way both in the case of Interbase 6.0 (Firebird) and in the case of Interbase 15.

It works the same way.

Naturally, the binary code is different, and it works with different structures. As an example, the same XSQLDA structure.

Which has been around since Interbase 7.5, maybe earlier, already the second version.