но мне кажется что логичней тут уже применить dbix

Думаю, может, просто отказаться от возможности выполнять множество запросов с одними и теми же subst и binds. В общем-то это полезно разве что в случае, когда есть только subst, мне трудно представить себе множество запросов с одними и теми же биндами: в одних и тех же местах одни и те же параметры - маловероятно.

легко! в партицированную таблицу, если непосредственно по портациям селектить

Тогда собственно запрос будет сразу ARRAYREF'ом, и можно будет формировать его из кусков текста и sub {}'ов, а в сабы пихать SQL::Abstract::More-инстанс, заранее заполненный

Мда... Такое бывает вполне

Ну ладно, тогда пока что обойдусь малой кровью и просто добавлю поддержку в тексте запросов синтаксиса

[[some_id]]

А дальше заменять этот [[some_id]] на либо

`some_id`

либо

"some_id"

и т.д. - в зависимости от типа извращений с квотингом id-шников, принятых для движка БД (хотя у меня пока только PG и MY)

По сравнению с SQL::Abstact'ом есть одна проблема только: если где-то встретится статичный кусок текста

col='[[jkkjkjk]]'

- пиши пропало

В целом конечно смотришь на глубокую маразматичность дизайна многих вещей, используемых в IT - и как-то легче становится на душе: алгоритм коммивояжера придумывает один человек из миллиарда, а потом 100000 разработчиков радостно пользуются SQL, HTML, CSS...

у нас это частый кейс, чтобы не лопатить всю таблицу, то на 9 постгре можно конкретно в портации смотреть, а вот на 10-11 постгре такой финт не прокатит, там надо табличку сначала детачить с портации

можно как варик union прицепить

но тоже это все стремное

$self->run_queries([
   'SELECT FROM {{table_name}} WHERE col {{=macro}} and other_col=?',
  {table_name => 'people', macro => 'some value'},
  [9000]
])

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

ORM здесь просто близко не лежал. Мне нужен способ формировать **баный как бы стандартизованный SQL под разные движки СУБД. Аж под 2 движка. Мне не нужны ни объекты, ни модели, ни формирование запросов из структур данных.

Если бы ODBC выступал вменяемым прокси-сервисом, преобразующим запросы ANSI в другие форматы - я бы  пользовался ODBC

а, ветряные мельницы...

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

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

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

в перл-мире есть колея, проложенная риделем, габором, мст и прочими "проповедниками" и все просто идут туда, поскольку "об этом будет строчка в резюме"

> я регулярно рассказываю про свой компилятор джейсон-схем

Где ссылка на Хабр?