Commented by: @dyemanov

Why do you need to know the build number, architecture and port number?

Commented by: @dyemanov

Also, it makes very little sense to return the setting from firebird.conf, as overrides are possible at other levels. I'd rather think about returning the actual values used by the engine at runtime.

Commented by: @pavel-zotov

when i run some tests inside isql i often forget which exactly server version (build and architecture) is in test now.
port number may be useful to know only inside application - just to get it more quickly than open firebird.conf on server console

Commented by: @dyemanov

"show version" in ISQL should report the build number. The server arch term is getting outdated with FB3, something different should be returned instead. As for the the server port number, it's currently unknown inside the engine, thus hardly possible to return. Also, imagine two CS instances listening on different TCP ports but sharing the same database. So the server port number should be a connection property, not the server one.

Commented by: @pavel-zotov

ps. also, as admin i want to restrict access to /opt/firebird folder for any common developer but let him obtain info about some configuration parameters.

Commented by: @pavel-zotov

>"show version" in ISQL should report the build number.
this is not programmatical way!
i mean that an application must 'see' such info via calls rather than isql console

>The server arch term is getting outdated with FB3
currently there is no FB 3.x. even in beta.
most people works in 2.0 / 2.1 / 2.5.

Commented by: @dyemanov

You were speaking about the user's way ("I often forgot which version is connected to"), not the programmatical way! And it's useless information for the application, because the feature set is uniquely identified by <major ver>.<minor ver>.<sub ver>. Build number could be actual for some intermediate (snapshot) build but relying on that in the application is terribly wrong.

FB 2.x are unlikely to get any new features, especially the ones that won't make any sense in the subsequent versions.

Commented by: @dyemanov

Providing the "common developer" access to the configuration sounds like a security risk. It's also seems useless in general, e.g. if the global config says "cache size = 75", the database-specific config says "cache size = 1000" and the application overrides this with "cache size = 10000" at runtime.

Commented by: Sean Leyne (seanleyne)

Pavel why do you open tracker cases only to have them, in most cases, be rejected. Please stop this usage pattern.

The project Support, Dev and Architecture mailing lists are the correct forum to present your ideas. These are where ideas can be reviewed and discussed with the widest audience.

Then, if the issue has not been "rejected", you can open a tracker case with the details which have been agreed to.

Commented by: @hvlad

Dmitry,

> I'd rather think about returning the actual values used by the engine at runtime.

You've got my voice :) I think this is must have feature, especially in FB3 where configuration will be more complex than now.
BTW, MSSQL already have this feature, don't know about others

Commented by: @hvlad

It will be nice to have ability to query configuration settings using SQL language.
Configuration here is contents of firebird.conf, databases.conf and settings passed via DPB when applicable.

Proposed solution is to introduce new virtual table to expose settings values.
Table defined as

CREATE TABLE RDB$CONFIG
(
RDB$CONFIG_ID INTEGER NOT NULL,
RDB$CONFIG_NAME VARCHAR(63) CHARACTER SET ASCII NOT NULL,
RDB$CONFIG_VALUE VARCHAR(255) CHARACTER SET UTF8,
RDB$CONFIG_DEFAULT VARCHAR(255) CHARACTER SET UTF8,
RDB$CONFIG_IS_SET BOOLEAN NOT NULL,
RDB$CONFIG_SOURCE VARCHAR(255) CHARACTER SET UTF8
);

where
- RDB$CONFIG_ID
unique row identifier, no special meaning

- RDB$CONFIG_NAME
setting name, such as "DefaultDbCachePages", "TempCacheLimit" and so on

- RDB$CONFIG_VALUE
actual value of setting, could be set in configuration and, if necessary, "fixed" by the engine (in case of wrong value)

- RDB$CONFIG_DEFAULT
default value of setting, fixed at Firebird code

- RDB$CONFIG_IS_SET
TRUE, if value was set by user

- RDB$CONFIG_SOURCE
name of configuration file where setting was set, relative to the firebird root folder, for example: "firebird.conf", "databases.conf"
or special value "DPB" if setting was set in DPB,
If setting value was not set, this field contains NULL

Table RDB$CONFIG is populated from in-memory structures when required and instance is kept at SQL query level.
For security reasons access is allowed to the SYSDBA/OWNER only (it could be changed before release).
Non-privileged user see empty content, no error is raised (also could be changed).