FB 2.0: Constraint check "для поля" не существует?

Предположим, для таблички

create table A
( F1 int
)

добавляем поле,

alter table A add F2 int constraint chk_f2 check (F2 <> F1) 

Э... constraint chk_f2 будет относиться не к полю, а на табличке?
Чтобы ограничение именно к полю относилось, нужно домены юзать?

Готов к закиданию тапками.

Глупый вопрос возник в связи с тем, что понадобилось убить "неименованный" check - констреинт, ранее объявленный при добавления поля.
Попытался найти его в системных табличках применительно полю, с которым констреинт был объявлен... с удивлением обнаружил, что чек - констреинты "живут" в контексте всей таблички, и про поле ничего не знают...

Век живи - век учись...

А что ж их (чек констреинты) объявлять на уровне поля (при добавлении поля , например) тогда можно? ...если им на поле начхать...

..."стандарт"? :)

Hello, чччД!
You wrote on 4 июня 2012 г. 18:11:22:

чччД
> А что ж их (чек констреинты) объявлять на уровне поля (при добавлении поля , например) тогда можно?

пофиг.
один хрен будет создан чек констрейнт уровня таблицы.

Posted via ActualForum NNTP Server 1.5

Мимопроходящий
Hello, чччД! You wrote on 4 июня 2012 г. 18:11:22: чччД > А что ж их (чек констреинты) объявлять на уровне поля (при добавлении поля , например) тогда можно? пофиг. один хрен будет создан чек констрейнт уровня таблицы.

Так и я об этом...

В общем, пофиг, да, раз "VALUE" только в чеках домена доступен... но как-то странно это.

вообще-то табличный constraint это именно табличный, а не "столбцовый", потому что в нем можно ссылаться на столбцы таблицы, а не только на конкретный столбец.
а что его можно цеплять к объявлению столбца - ну да, стандарт.

kdv
вообще-то табличный constraint это именно табличный, а не "столбцовый", потому что в нем можно ссылаться на столбцы таблицы, а не только на конкретный столбец. а что его можно цеплять к объявлению столбца - ну да, стандарт.

Хорошая у нас "отмазка"...

Спасибо.

чччД
Хорошая у нас "отмазка".

непонятно, при чем тут отмазка. Это вообще-то table check constraint. И точно так же, как и PK, FK, Unique, его можно писать как отдельно, так и прямо в объявлении столбца.

create table A(
id int not null primary key,

тебя не напрягает?

слава богу, все это одинаково практически для всех SQL серверов.

kdv
чччД Хорошая у нас "отмазка". непонятно, при чем тут отмазка. Это вообще-то table check constraint. И точно так же, как и PK, FK, Unique, его можно писать как отдельно, так и прямо в объявлении столбца. create table A( id int not null primary key, тебя не напрягает? слава богу, все это одинаково практически для всех SQL серверов.

Да вот как-то PK/FK вопросов не вызывали, а тут прям "разрыв шаблона"...да еще в понедельник...

Э... а теперь грохнуть "неименованные" check - констреинты для таблички как лучше?


В принципе, у меня для этой таблички они все "неименованные", поэтому...

execute block (
    I_REL_NAME int = :RELATION_NAME)
as
declare variable F_CNSTR_NAME varchar(255);
begin
  for select RC.RDB$CONSTRAINT_NAME
      from RDB$RELATION_CONSTRAINTS RC
      where RC.RDB$CONSTRAINT_TYPE = 'CHECK' and
            RC.RDB$RELATION_NAME = :I_REL_NAME
      into F_CNSTR_NAME
  do
    execute statement 'ALTER TABLE ' || I_REL_NAME || ' DROP CONSTRAINT ' || F_CNSTR_NAME;
end

... но может, что-то более правильное подскажете?