Akina

Напрямую такого нет.

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

Я бы предложил тупой UNION:

SELECT t2.p_1, ... t2.p_n
FROM t1
LEFT JOIN t2 AS t2 ON t2.t1_id= t1.id
LEFT JOIN t3 AS t2 ON t3.t1_id= t1.id
WHERE <условие>

UNION ALL

SELECT t1.p_1, ... t1.p_n
FROM t1
LEFT JOIN t2 AS t2 ON t2.t1_id= t1.id
LEFT JOIN t3 AS t2 ON t3.t1_id= t1.id
WHERE NOT <условие> OR <условие> IS NULL;

Можно использовать анонимный блок или хранимую процедуру с той же логикой, условием в IF и двумя отдельными запросами.

Я вот вообще не вижу проблемы.

Товарищи кивают на разварку оптики - забудь. Просто купи готовые патчи нужных длин. 3 метра, 5, 50, 200 метров - сколько надо, всё это доступно и стоит не миллион (скажем, 50-метровый нормальный патч - в пределах 2 тыров). Протягиваешь да подключаешь, вот и всего делов. Можно даже без розеток...

Поскольку опыта мало, порекомендую:

1) Оптические модули брать гигабитные одномодовые WDM с разъёмом SC. Брать нужное количество комплементарных пар. Дистанция по характеристикам - 2-3 км, больше тебе не нужно.
2) Коммутаторы брать исходя из потребного количества SFP и RJ-45 портов в узлах (плюс разумный запас на будущее в точке раздачи). Коммутаторы с SFP+ брать смысла нет, если не планируешь переход на более чем гигабит.
3) Готовые патчи брать во внешнем исполнении, защищённые, одномодовые, с разъёмами SC, нужной длины с превышением. Скажем, если нужно прокинуться на 35 метров, то ближайшая доступная длина 50м.
4) Сетевые карты - с разъёмом SFP. Опять же SFP+ и избыточно, и бессмысленно, и дороже.
5) При прокладке/протяжке оптокабеля - прокладывать крайне аккуратно, не тянуть сильно, не изгибать радиусом менее 5 см, тем более никаких заломов. Избыток забухтить в кольцо диаметром 10-15 см и повесить рядом на гвоздик (чтобы не висело на разъёме под своим весом). Кабель прокладывать в трубу для электропровода (16 или 20 мм), в крайнем случае в гофру (а в земле - есссно в металл). Диаметр разъёма SC при протягивании - порядка 12 мм, проблем не будет. Для трубы - озаботиться протяжкой, а не брать первый попавшийся электропровод.
6) Обязательно купить карандаш для чистки оптики для ферул 2,5 мм, скажем, вот такой. Защитные колпачки с патчей и модулей - не терять! Ферулы чистить - при каждом подключении, и на патче, и на модуле, при эксплуатации - ежегодно.
7) Оптику отключать при любом перемещении оборудования, и сразу надевать защитные колпачки. А потом при обратном подключении - опять чистка ферулы.

Для более плотного знакомства с темой настоятельно рекомендую прочитать цикл из 4 статей "Сложно о простом. Все, что бы вы хотели знать о SFP модулях." на Хабре за авторством @ProstoKirReal.

PS. Конечно, мой вариант будет подороже. Но он гораздо менее геморройный, особенно при отсутствии опыта. Всё готовое, только проложи да состыкуй.

Как по мне, существование native VLAN само по себе нонсенс. А делать его случайным - нонсенс вдвойне. Я лично убеждён, что при наличии в возможностях устройства такой фичи как native VLAN он должен быть 1) настроен статически 2) настроен Forbidden на всех портах.

Почему без установки управляющего влана в режиме native связи нет?

Ну как раз потому, что он и выбран случайно. И что это "случайно" вдруг попадёт точно в значение 50, шанс невелик.

По-моему, достаточно установить одно приличное L3-устройство, основной задаче которого будет

По двум входящим каналам интернета - сделать либо резервирование, либо агрегацию/балансировку

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

Всё остальное вообще не требует интеллектуального управления, обычные L2-коммутаторы (даже плюс не требуется) сделают всё необходимое.

Наверное, надо всё же начинать с целей и объективки. И уже под конкретные задачи верстать решение.

Принципиально сперва надо будет решить, требуется ли для решения выделенная физика. Например, если речь идёт чисто об изоляции управления, то она скорее всего не нужна, хотя всё зависит от требуемого уровня защиты, разделения доступа, категорирования и требований по/для сертификации. А вот если речь об изоляции сети для резервного копирования, миграции, репликации - тут выделенная физика, скорее всего, будет жизненной необходимостью.

И уже после надо думать о том, что именно делить на L2, что на L3, а что на L3+L2.

Литерал '2' необязательно имеет тип CHAR. Он ведь имеет полное право быть, к примеру, BYTEA, верно?

Используйте явное указание типа в вызове:

select testboris3(2, now(), B'0', 789, '2'::CHAR, 2);

Если ставлю предпоследний параметр как просто 2, без кавычек, то он уже определяет тип корректно.

Не определяет, а преобразует в тип, определяемый шаблоном функции.

И есть windows server (IP 192.168.211.81 маска 255.255.248.0).
Есть еще в сети windows server 2019 (IP 192.168.211.1 маска 255.255.0.0)

Вот та проблема, которой нужно уделять всё своё внимание. В самую первую очередь.

Можно ли как-то настроить что бы расшареный каталог был виден без смены маски подсети ?

Настроить кого? Первый сервер? второй? любой узел сети (какой, кстати?)...

Самое простое - добавить ещё один адрес на интерфейс, из подсети компа с шарой, и не городить огород.

Всё описанное вполне себе выполняется на уровне L2 - так что коммутатор должен быть управляемым. MAC-based filtering поддерживают практически все управляемые коммутаторы (правда, некоторые - только в форме MAC-based VLAN), а traffic segmentation - ну подавляющее большинство. Ну и ещё не забыть побороться с MAC flood, что тоже умеют практически все управляемые коммутаторы,

PS. И да - если у злоумышленника есть физический доступ к устройству, никакие технологии вам не помогут.

можно ли сделать так, чтобы он раздавал интернет от маршрутизатора, а доступа к локальной сети не давал?

Только в случае, если роутер поддерживает режим изоляции клиентских портов.

Обычно для роутеров с выделенным WAN в беспроводном сегменте этот режим не только присутствует, но и включен по умолчанию. А вот его наличие в проводном сегменте и между проводным и беспроводным сегментами - надо проверять.

Что же до роутеров, не имеющих выделенного WAN, то такие, как правило, имеют продвинутые средства настройки, и форвардинг между клиентскими портами запрещается соответствующим правилом в файрволе.

Алгоритм простой. Сначала из всех имеющихся маршрутов, подсеть которых включает узел назначения, выбирается самый "узкий". Если таковых несколько, выбирается тот, у которого минимальна метрика. Именно в шлюз этого маршрута и отправляется пакет.
Тип интерфейса при этом не имеет вовсе никакого значения.