Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Вопросы по bytea
|
|||
|---|---|---|---|
|
#18+
1. Кто придумал ескейпить служебные символы (0-31) и (127-255) восьмиричной системой счисления? :) Вопрос риторический, но очень интересный. 2. Есть ли альтернативы по укладыванию в БД бинарных данных? Вопросы возникли в связи с тем, что де-факто файл при конвертации разрастается в 5 раз. Т.е. \\xxx вместо X. Сейчас конвертацию делаю следующим asm кодом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2005, 17:34 |
|
||
|
Вопросы по bytea
|
|||
|---|---|---|---|
|
#18+
Prikol ... a chto za problema ? Ja vot Javoi zipovanie dannie v Postgres kidayou i dostayou i ni kakich "ESC" .... tom bolee ASM ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2005, 19:38 |
|
||
|
Вопросы по bytea
|
|||
|---|---|---|---|
|
#18+
Насчет размера файла есть сомнения.Почему ты решил что данные храняться не в бинарном виде?На винте в файле ИМХО никаких \\ххх не будет. Вообще-то протестить можно и посмотреть на размер файла. Как вариант можно хранить строки (тип TEXT), а бинарные данные конвертить в hex-строку(т.е. размер увеличится в 2 раза), но по мне это геморно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 10:33 |
|
||
|
Вопросы по bytea
|
|||
|---|---|---|---|
|
#18+
HordiНасчет размера файла есть сомнения.Почему ты решил что данные храняться не в бинарном виде?На винте в файле ИМХО никаких \\ххх не будет. Вообще-то протестить можно и посмотреть на размер файла. Как вариант можно хранить строки (тип TEXT), а бинарные данные конвертить в hex-строку(т.е. размер увеличится в 2 раза), но по мне это геморно. То, как он хранится в СУБД - описано в документации. Он действительно хранится(как и все остальные данные) в бинарном виде, и поскольку он явно переменной длины, то скорее всего он будет еще и сжиматься, тносительно своего изначального размера. Вопрос не в этом. Если я хочу положит в СУБД файл длинной 1Мб, то для выполнения SQL запроса Код: plaintext Итак вопрос - есть ли другие способы укладывания бинарных данных в СУБД. Для доступа использую ADO+ODBC из С++builder. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 11:13 |
|
||
|
Вопросы по bytea
|
|||
|---|---|---|---|
|
#18+
Andrey Daeron1. Кто придумал ескейпить служебные символы (0-31) и (127-255) восьмиричной системой счисления? :) Вопрос риторический, но очень интересный. 2. Есть ли альтернативы по укладыванию в БД бинарных данных? Вопросы возникли в связи с тем, что де-факто файл при конвертации разрастается в 5 раз. Т.е. \\xxx вместо X. Ваще-то в документации сказано : [quote документация] The requirement to escape "non-printable" octets actually varies depending on locale settings. In some instances you can get away with leaving them unescaped. [/quote] Личный опыт показывает, что escape'ить необязательно. Могут, наверное, быть проблемы в случае многобайтовых кодировок... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 11:21 |
|
||
|
Вопросы по bytea
|
|||
|---|---|---|---|
|
#18+
Ваще-то в документации сказано : e документация The requirement to escape "non-printable" octets actually varies depending on locale settings. In some instances you can get away with leaving them unescaped. [/quote] Личный опыт показывает, что escape'ить необязательно. Могут, наверное, быть проблемы в случае многобайтовых кодировок... И вот рядышком, в той-же документации: e документация When entering bytea values, octets of certain values must be escaped (but all octet values may be escaped) when used as part of a string literal in an SQL statement. In general, to escape an octet, it is converted into the three-digit octal number equivalent of its decimal octet value, and preceded by two backslashes. Table 8-7 shows the characters that must be escaped , and gives the alternate escape sequences where applicable. Вот по этому собственно вопрос и возник... Может я чего-то неправильно понимаю? Вопрос к личному опыту :) - на каких кодировках это работало? Нужно ли эскейпить 0 символ? Ковычки? Данные помещаю в СУБД оператором INSERT INTO. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 11:29 |
|
||
|
Вопросы по bytea
|
|||
|---|---|---|---|
|
#18+
Ескейпить 0 и кавычки нужно однозначно! На вход-то идет const char*. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 11:38 |
|
||
|
Вопросы по bytea
|
|||
|---|---|---|---|
|
#18+
Если у тебя метровые файлы в базу кидаются, то не проще ли использовать lo_export,lo_import и подобное? Придется через временные файлы работать,но по скорости однозначно намного быстрее чем огромные запросы выполнять! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 12:16 |
|
||
|
Вопросы по bytea
|
|||
|---|---|---|---|
|
#18+
HordiЕсли у тебя метровые файлы в базу кидаются, то не проще ли использовать lo_export,lo_import и подобное? Придется через временные файлы работать,но по скорости однозначно намного быстрее чем огромные запросы выполнять! Эти функции несколько неудобны для удаленной работы с БД. ИМХО. Кроме того, они нарушают логику работы через ADO+ODBC. Если я не прав - с удовольствием выслушаю Вашу точку зрения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 12:41 |
|
||
|
Вопросы по bytea
|
|||
|---|---|---|---|
|
#18+
Почему неудобны? Почему нарушают? Тебе просто нужно вытягивать(вставлять) данные по идентификатору или уникальному имени, и все.Тебе нужно совать файл только для INSERT и SELECT. Реально-то данные хранятся на сервере,а не у клиента. Это чтобы долго не рыться: 28.4. Server-Side Functions There are server-side functions callable from SQL that correspond to each of the client-side functions described above; indeed, for the most part the client-side functions are simply interfaces to the equivalent server-side functions. The ones that are actually useful to call via SQL commands are lo_creat, lo_unlink, lo_import, and lo_export. Here are examples of their use: CREATE TABLE image ( name text, raster oid ); SELECT lo_creat(-1); -- returns OID of new, empty large object SELECT lo_unlink(173454); -- deletes large object with OID 173454 INSERT INTO image (name, raster) VALUES ('beautiful image', lo_import('/etc/motd')); SELECT lo_export(image.raster, '/tmp/motd') FROM image WHERE name = 'beautiful image'; The server-side lo_import and lo_export functions behave considerably differently from their client-side analogs. These two functions read and write files in the server's file system, using the permissions of the database's owning user. Therefore, their use is restricted to superusers. In contrast, the client-side import and export functions read and write files in the client's file system, using the permissions of the client program. The client-side functions can be used by any PostgreSQL user. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 12:47 |
|
||
|
Вопросы по bytea
|
|||
|---|---|---|---|
|
#18+
Значит ли это, что я должен транспортировать файл на сервер самостоятельно? И уже на нем вызывать INSERT INTO image (name, raster) VALUES ('beautiful image', lo_import('/etc/motd')); ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 13:51 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=344&tid=2007320]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
18ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 314ms |

| 0 / 0 |
