думаю можно не заморачиваться как это устроенно внутри (если очень хочется можно скачать исходники и глянуть я глянул увидел то что ожидал) :-)

когда sql запрс пишите не боитесь что сработает что нибудь не так? вот и я о томже

если читать внимательно то написано следующее

авторinput_function
The name of a function that converts data from the type's external textual form to its internal form.

output_function
The name of a function that converts data from the type's internal form to its external textual form.

те я могу передать в базу только строчки на входе и получить строчку на выходе, а внутри происходит конверт данных (если не верите то посмотрите примеры на С в конце страници про создание типов есть ссылка)

и я никак немогу понять чего не реализовано в ЖДБЦ??? база на входе имеет стринг и ЖДБЦ работает с базой только через сетевой порт и отсылает ей стринг (вернее массив байтов из которого можно получить стринг).

Если использовать prepare то происходит кеширование плана выполнения запроса (реализованно с помощью встроенного в постгрес prepare http://www.postgresql.org/docs/8.0/interactive/sql-prepare.html) это раз и второе можно упростить проверку неправельных данных отсылаемых серверу на клиенте.

я роюсь в доке и не могу вообще найти примера или намека как запихнуть в базу НЕТЕКСТОВЫЕ данные даже через либпэку

может многоуважаемый stuav покажет где он видел подобные примеры? то что приведенно в начале треда тоже запихивает в базу стринги const char * const *paramValues

ага нашел это называется The Fast-Path Interface

http://www.postgresql.org/docs/8.0/interactive/libpq-fastpath.html

и делать это насколько я понял можно только с сервера (ну впринципе понятно почему именно так)

авторOptionally, a user-defined type can provide binary input and output routines. Binary I/O is normally faster but less portable than textual I/O. As with textual I/O, it is up to you to define exactly what the external binary representation is. Most of the built-in data types try to provide a machine-independent binary representation. For complex, we will piggy-back on the binary I/O converters for type float8:

1) обычно быстрее, но менее кросплатформенно (сами понимаете что фишка джавы именно в этом)
2) большинство (а не все!!!) встроенных типов старается предоставить ... (см. пункт первый)

в ЖДБЦ этого скорее всего никогда не реализуют потому что джава платформонезависима это действительно так, это действительно важно, и это действительно очень нужно (спорить на эту тему надо в другом форуме :-) )

так что думаю вопрос исчерпан и тему можно закрывать

спасибо stuav за то что предоставили такую замечательную возможность с вами подискутировать.

ИТОГО:
- ЖДБЦ использует тексовое представление данных при передаче в силу сохранения своей кросплатформенности (и скорее всего никогда не будет реализованна возможность передавать данные в бинарном виде)
- в топике где ЖДБЦ был обвинен в ошибке передачи точности виноват был не ЖДБЦ а неправильно выбранный разработчиком примера тип данных колонки float4 который имеет точность 6 знаков и в который пытались положить число 1.9000001 в итоге постгрес обрезал его до 1.9

в каких свободных базах это реализованно?

пока [ , RECEIVE = receive_function ] находится в квадратных скобках эту возможность скорее всего не реализуют

да и еще посмотрите как Вам придется конвертить джавой данные в вид который необходим вашей платформе (то бишь процу) и операционке например тот же самый дабл

выигрыш в скорости весьма неочевиден (выигрыша в точности не будет как мы выяснили и тот и другой способ работают одинаково хорошо :-) )

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

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

грубая схема прохождения запроса
1) (запрос) ->
2) (передача данных по сети) ->
3) (парсинг запросов) ->
4) (выполнение запросов) ->
5) (результат) ...

ну будут у Вас в 20 раз (в чем я сомневаюсь) быстрее конвертится данные пункт 3) в схеме, а какой суммарный выигрыш получится на селектах, инсертах, апдейтах? как Вы себе представляете процентное соотношение в выигрыше производительности этих блоков?

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

ЖДБЦ работают и разработанны именно под базу. Они работают нормально и стабильно. Если Вам не подходит база тогда ее надо менять. В бесплатном сегменте аналогов имхо нет. Комерческие продукты ну там может быть все что угодно но за это надо платить.

я просто за то чтобы человек который случайно или неслучайно попал на этот форум не прочел Ваши категоричные заявления о том что все плохо которые зачастую основанны на ошибках. Скорее всего Вами неправильно выбранна платформа реализации, а не СУБД.