хочу странного: hstore(record except keys[])

Если заглянет кто-то из hstore--писателей
-- хочу [в весьма отдалённом будущем] что-то типа:

hstore(record except keys[])

т.е. пропустить уже на этапе заворачивания

delete (hstore(NEW.*) ,fields[])

-- а то неприятная дилемма --
то ли вычитывать из системников состав полей, и собирать весь hstore самому, руками на коленке, со всеми вычетами [так и сделаю, кажется],
то ли через упомянутый delete чистить результат полного заворачивания. (в исключаемых полях предполагаются БЛОБ-ы -- зачем мне их сначала класть в hstore, чтобы потом подропать из него же ? )

или же хочу операцию/функцию обратную

populate_record(record,hstore)
--- скажем: ---
populate_hstore(record,hstore)

(заполнить предопределенный поля hstore тем, что найдётся в record-е, оставив бесхозные поля необработанными.


PS если кто видит третий путь -- намекните.

qwwq,

а что мешает использовать delete ?

=# select delete('a=>b, c=>1'::hstore, ARRAY['c','a']);
delete
--------

(1 row)

qwwq,

если это after insert/update триггер, то можно прямо прописать null в нужные поля в NEW.

Oleg Bartunov
qwwq, а что мешает использовать delete ? =# select delete('a=>b, c=>1'::hstore, ARRAY['c','a']); delete -------- (1 row)

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

вот этого всего хотелось бы избежать.

таки вы , олег, не практикуете, с очевидностью.

Alexius
qwwq, если это after insert/update триггер, то можно прямо прописать null в нужные поля в NEW.

красивая мысль.
только в new оно остаться должно
-- следовательно -- использовать буферный record.
-- следовательно размножить блоб минимум дважды -- при кладке в этот буферный рекорд, с последующем обнулением. (или кладку уже писать с разбором всего набора полей (это универсальный триггер, т.ч. тип надо будет извлекать на лету), другого способа положить сразу null в выделенное поле я не вижу -- т.е. тот же вид, но уже в профиль.

Oleg Bartunov,

размышляя о вечном [ковыряя в носу], обнаружил отсутствие в hstore--расширении агрегата вида "hstore_agg()"

думаете, он не нужен ?

в моем конкретном случае оно бы меня вряд ли спасло [-- надо заполнить хештаблицу имён prepared стейтментов на агрегирующем проходе, агрегируя sql создания и вызова самих prepared string_agg-ами в том же проходе], но факт


попутно не обнаружил в справке ограничения на длину ключа. его нет ?
и чем чреваты длинные ключи ? (например -- ключ , созданный из имён по маске ~ "схема.таблица.поле1[,поле2[,...полеN]..] при 100 полях даёт оценку длины ключа в ~6400 символов ).