Есть такая возможность:

CREATE VIEW B AS
SELECT * FROM TBL2
UNION ALL
SELECT * FROM TBL3

и позднее

INSERT INTO B ...

В какую именно таблицу попадут строки при вставке в B, зависит от constraints на TBL2 и TBL3. Чтобы это работало, нужно однозначное разрешение: вставляемая строка удовлетворяет ограничениям либо таблицы TBL2, либо TBL3, обязательно одной, не обоим сразу.

Кутх
To Victor Metelitsa

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

Если очень сильно захотеть, то получится. Добавить поле, значение которого и будет отделять информацию.

По сути вопроса. SQL-выражения у DB2 либо статические, либо динамические. Статические хранят прекомпилированный план в базе (неважно, появился этот план явным биндингом или неявным непосредственно перед первым выполнением запроса). Построение плана требует знания всех таблиц + индексов + статистики. Только динамические вы можете строить "на лету", подставлять имена таблиц, полей и т.д.

Не удивлюсь, если имя таблицы в качестве параметра можно передать в MySQL и т.п..

Astron
Насчет Static SQL - имеется в виду EMBEDDED SQL, да? Я такой штуки действительно нигде не видел, даже спрашивал раньше на этом форуме что это за зверь....

Embedded SQL не синоним Static SQL, хотя использовать Static SQL из Embedded SQL проще всего. В Embedded SQL есть возможность конструировать SQL-выражения динамически; и напротив, CLI-приложение можно заставить использовать Static SQL (см. db2cap - CLI/ODBC Static Package Binding Tool Command ).
Разница между Embedded SQL/SQLJ и прочим - в синтаксисе "встраивания", тогда как разница между статическим и динамическим - в моменте компиляции SQL-выражения. Динамический прекомпилируется во время выполнения приложения, статический - до выполнения приложения (с некоторыми оговорками, напр., инвалидный пакет перекомпилируется при первом обращении к нему).

А автору - а если обмануть так: сделать эти вьюшки с одним именем в разных схемах, а в процедуре первой же строчкой ставить
наставить по коду квалификаторов на все остальное, кроме этих вьюх.
Последней строчкой ставить схему на место. Будет и мухой, и надежно, а?
Не выйдет. План Static SQL (нормально) прекомпилируется до первого использования (или, если пакет стал инвалидным или прибинден не помню с какой опцией - при первом использовании) и далее независим от того, кто его вызывает.

AstronНу тогда остается показанный Виктором путь
и переправить все запросы в процедуре, добавив
AND coolview.tbl_selector=input_parameter

Неужто работает? По-моему, insert into coolview сработать не должен, поскольку на таблицах нет constraint'ов a la
(или char вместо shortint, чтобы сэкономить байт)

Но я предложил это чисто формально, а сам бы, скорее всего (но необязательно - это ещё и от размера таблиц и ширины строк зависит), пожлобствовал и вместо добавления колонок и view просто создал бы процедуры P1 и P2 ;-).