Error when reading unknown SYSTEM context variable [CORE1733]

[firebird-automations]

Submitted by: Emil Totev (emilt)

Trying to retrieve an unknown context variable in the SYSTEM namespace causes an error, instead of returning NULL as stated in the release notes.

SELECT RDB$GET_CONTEXT ('SYSTEM', 'UNKNOWN') FROM RDB$DATABASE

Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
Context variable UNKNOWN is not found in namespace SYSTEM.

RDB$_GET_CONTEXT should return NULL for unknown variables even in the SYSTEM namespace, because different firebird versions implement different context variables (e.g. ENGINE_VERSION in 2.1), and querying for them should always be safe.

[firebird-automations]

Commented by: Smirnoff Serg (wildsery)

I don't think so.
There's no RDB$GET_CONTEXT at all in versions below 2, and may disappear in future versions.

[firebird-automations]

Commented by: @dyemanov

Emil, two questions:

1) How are you going to distinguish between missing system variable and existing one that returns NULL?
2) Do you suggest to return NULL for e.g. RDB$GET_CONTEXT('UNKNOWN', <smth>) as well?

[firebird-automations]

Commented by: Emil Totev (emilt)

Serg
I never saw anywhere that RDB$GET_CONTEXT may disappear in future versions. Why would that be?
Of course, the more I think about it, the more it seems that this functionality can be designed better, but removing it will break backward compatibility - and firebird has always been strong on that.

Dmitry,

1) This would depend on the system variable I'm checking. I think system variables that are defined should never be NULL. In other contexts setting a variable to NULL means deleting it. I still don't understand what NULL means in NETWORK_PROTOCOL. Maybe some string like NONE or UNKNOWN would be better than returning NULL. I think returning NULL is more like "I am unable to tell" than "I don't know"...

In any case, I find it much easier to handle this than trying to catch an exception in code - "check the engine version and if the statement fails then the engine version is 2.0.x"

2) "Currently, there is a fixed number of pre-defined namespaces you may use."
If that means that other namespaces may be added in the future - then definitely yes. If we delete the "currently" part - then probably no.
At this point I'm not sure how other namespaces could be useful.

[firebird-automations]

Commented by: @dyemanov

NETWORK_PROTOCOL returns NULL for an embedded access. It means no network protocol is used. CLIENT_ADDRESS returns NULL for the WNET (aka NetBEUI) protocol which doesn't support the feature.

> In any case, I find it much easier to handle this than trying to catch an exception in code -
> "check the engine version and if the statement fails then the engine version is 2.0.x"

On the client side, the engine version should be checked with the API call isc_version(). This obviously works for all server versions.

[firebird-automations]

Commented by: Emil Totev (emilt)

The initial question was, why does the SYSTEM namespace have to be different with respect to handling unknown variables. (different also from the documentation). So far the only reason seems to be that some SYSTEM variables use NULL to return a meaningful value. But as long as any future additions to the SYSTEM namespace do not return NULL 'by design', there should be no problem to return NULL for unknown names. CLIENT_ADDRESS and NETWORK_PROTOCOL are guaranteed to exist in all 2.x and above, so you'd know what NULL means for them.

Using ENGINE_VERSION is the only way to check the server version on the server side, is it not? If things stay that way, then we have to add in the release notes that the way to check for the engine version that will work in all 2.x versions is:

begin
ver = RDB$GET_CONTEXT ('SYSTEM', 'ENGINE_VERSION');
WHEN ANY
DO ver = '2.0.x';
end