Доброго времени суток!
Решил посмотреть, как ведет себя RDB$DB_KEY (сам его никогда не
использую) в нетривиальных ситуациях на 2.0.3 RC1 CS, 2.1.0.16235 CS
(все сообщения приведены для 2.0.3 RC1,
на 2.1.0.16235 они идентичные или близкие по смыслу)
Вот, что получилось
1)
select * from
(select rdb$db_key from rdb$database) r
выдает
Invalid command.
COLUMN 1 is specified without a name.
Хорошо, работоспособности такой низкоуровневой вещи с derived tables
никто и не обещал
2)
select * from
(select * from rdb$database)
where rdb$db_key is not null
invalid request BLR at offset 58.
context not defined (BLR error).
и соответственно при
select * from
(select * from rdb$relations),
rdb$database
where rdb$db_key is not null
Dynamic SQL Error.
SQL error code = -206.
Column unknown.
DB_KEY.
Если использовать алиасы, то вроде бы все в порядке
select * from
(select rdb$db_key s from rdb$relations),
rdb$database r
where r.rdb$db_key is not null
но, по идее, и без них должно работать
3)
select rdb$db_key from
(select * from rdb$relations) a
Dynamic SQL Error.
SQL error code = -607.
Cannot SELECT RDB$DB_KEY from a stored procedure.
Не знаю, стоит ли переделывать сообщение на
Cannot SELECT RDB$DB_KEY from a derived table?
4) И, наконец, смертельный номер :)
create procedure test_proc
returns (A INTEGER)
as
begin
A = 1;
SUSPEND;
end
Теперь
select * from test_proc
where rdb$db_key is not null
повалит процесс.
Не знаю, имеет ли смысл это все править (за исключением, пожалуй,
последнего), но, может, стоит перевести rdb$db_key в разряд deprecated?
Я так понимаю, что сторонники оптимизации могут заменить его на
WHERE CURRENT OF ?
P.S.
Правда, вроде все это уже всплывало
http://tracker.firebirdsql.org/browse/CORE-924
http://tracker.firebirdsql.org/browse/CORE-1313
--
С уважением, Евгений