Тип lo (Lage Object)

помещать в базу и извлекать из нее проще всего вызовами "lo_import" "lo_export"
На вход этим ф-ям скармливать имя файла, содержащего картинку.

Смотря какая у тебя база. Но вообще стандартным типом является BLOB.

Поправочка: Тип oid - Object ID - идентификатор блоба

2polecast: речь идет о постгресе, а в нем блобы обзываются oid-ами.

Затащить картинку в базу можно так:

insert into some_table(picture_field) values(lo_import("/tmp/some_picture.jpeg"))

2NewComer: Спасибо, a в какой row добавится запись? И существует ли возможность использовать буфер вместо filename (животрепещущий вопрос)

Про row - идиотский вопрос, просто я немножко подвис на С
интерфейсе и мне показалось, что oid нужно прописывать в уже
созданую запись.

Про oid я знал, но не понял как связывается созданный в
программе объект с конкретным полем - sample в документации
странноват, выглядит будто все операйии с oid-oм выполнены
в исключительно декоративных целях.

Если есть идеи (oid из C/C++) поделитесь пожалуйста!

Дык все очень просто из с/с++
Вытаскиваем oid из базы SQL-запросом типа:
PQResult res=PQExec(conn,"select some_picture from_table where что-то равно чему-то")

some_picture - это поле типа oid. (напомним, oid-Object ID, целочисленный идентификатор
его тип - unsigned long)

Затем вызовами lo_open,lo_read,и т.д., которые аналогичны файловым API,(oid используется аналогично дескриптору файла)
тянем содержимое блоба в локальный буфер.
В конце закрываем блоб вызовом lo_close(oid)

Удачи.

Да, спасибо, я сегодня по утру допер уже. Чего я ТОТАЛЬНО не понимал, так это то, что Oid в программе на С и объект в базе суть одно и то же!!! Если я когда-нибудь напишу мемуары, этот случай будет венчать список "грандиозных тормозов" Еще раз СПАСИБО!

Real DELETE

Снова я.

А почему после DELETE (и даже DROP TABLE)
Размер ДБ вовсе не уменьшается?

С чего-то решил, что это fsync -
нет, не fsync...
А что?!...


П.С.
Ссылочку каку на доку - идеально!


П.П.С
Потому как когда по 300м туда-сюда пихаешь,
все такое мммеееедддлллеееннноооеее становится

Oid не уничтожаются автоматически по команде DELETE, ею Вы убиваете только
упоминание об блобе. Ведь они хранятся не в таблице, а в базе.

Для уничтожения блоба используйте функцию "lo_unlink"

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

триггер на DELETE

Нет, я все-таки непроходимый товарищ!...
Где лежат SPI_ функции (библиотека)?

Полдня вчера искал - мимо.

Вы имеете в виду Server Programming Interface?
А зачем? Для написания триггера? Напишите его на SQL.

триггер на SQL

С SPI библиотекой я разобрался все-таки, а выбрал SPI функции
потому как они лежали на поверхности в документации. К тому же
там упоминалось: "Trigger functions can be written in any of these languages except SQL". Особо разбираться желания не
наблюдалось, вот и взял SPI.

А какой из способов (SQL vs SPI) лучше с точки зрения
производительности и расхищения ресурсов?

И если есть примеры SQL триггеров было бы очень
любопытно поглазеть (живу я на smirnov@dresearch.de)

Спасибо за помощь!

lo_unlink

Хм... Несмотря на все старания размер базы уменьшаться и не думает.

\lo_list говорит что никаких lo не обнаружено, но
думает над этой емкой фразой 5 минут.

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

Может быть нужно как-то ограничивать размер при создании базы?
Правда у createdb таких параметров нет.

Наверное, уменьшить размер БД поможет vacuum-ирование.
Видимо, так задумано (не бага же).

По поводу SPI vs SQL ничего сказать не могу, не тестировал.

Триггеры на SQL не пробовал, а вот правила писал. Пытался сделать обновление
некоторой таблицы после вставки строки в другую, пришлось отказаться от
такого подхода и обновлять первую таблицу SQL-запросом из с-ного приклада,
тк скорость базы (v7.0) падала катастрофически.

А чем занимаетесь в Германии, если не секрет?