Доброго времени суток!

Решил посмотреть, как ведет себя 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

--
С уважением, Евгений


Ответить