pg_lo_import
(PHP 4 >= 4.2.0, PHP 5)
pg_lo_import — Импорт большого объекта из файла
Описание
pg_lo_import() создает большой объект в базе данных, используя локальный файл в качестве источника данных.
Операции с использованием интерфейса больших объектов необходимо заключать в блок транзакции.
Замечание: Когда опция safe mode включена, PHP проверяет, имеют ли файлы/каталоги, с которыми вы собираетесь работать, такой же UID (владельца), как и выполняемый скрипт.
Замечание:
Прежнее название функции: pg_loimport().
Список параметров
-
connection -
Ресурс подключения к базе данных PostgreSQL. Если параметр
connectionне задан, будет использовано подключение по умолчанию - последнее соединение, открытое функцией pg_connect() или pg_pconnect(). -
pathname -
Полный путь и имя файла в клиентской файловой системе для чтения данных большого объекта.
-
object_id -
Если задан аргумент
object_id, функция попытается создать объект с этим идентификатором, в противном случае будет использован свободный идентификатор, назначенный сервером. Этот аргумент появился в PHP 5.3 и основан на функционале, впервые реализованном в PostgreSQL 8.1.
Возвращаемые значения
OID созданного большого объекта,
либо FALSE в случае ошибки.
Список изменений
| Версия | Описание |
|---|---|
| 5.3.0 |
Добавлен необязательный аргумент |
| 4.2.0 | Определение функции изменено. Прежнее определение:
int pg_lo_import
( string
$pathname
[, resource $connection
] ) |
Примеры
Пример #1 Пример использования pg_lo_import()
<?php
$database = pg_connect("dbname=jacarta");
pg_query($database, "begin");
$oid = pg_lo_import($database, '/tmp/lob.dat');
pg_query($database, "commit");
?>
Смотрите также
- pg_lo_export() - Вывод большого объекта в файл
- pg_lo_open() - Открывает большой объект базы данных
- PHP Руководство
- Функции по категориям
- Индекс функций
- Справочник функций
- Расширения для работы с базами данных
- Расширения для работы с базами данных отдельных производителей
- PostgreSQL
- pg_affected_rows
- pg_cancel_query
- pg_client_encoding
- pg_close
- pg_connect_poll
- pg_connect
- pg_connection_busy
- pg_connection_reset
- pg_connection_status
- pg_consume_input
- pg_convert
- pg_copy_from
- pg_copy_to
- pg_dbname
- pg_delete
- pg_end_copy
- pg_escape_bytea
- pg_escape_identifier
- pg_escape_literal
- pg_escape_string
- pg_execute
- pg_fetch_all_columns
- pg_fetch_all
- pg_fetch_array
- pg_fetch_assoc
- pg_fetch_object
- pg_fetch_result
- pg_fetch_row
- pg_field_is_null
- pg_field_name
- pg_field_num
- pg_field_prtlen
- pg_field_size
- pg_field_table
- pg_field_type_oid
- pg_field_type
- pg_flush
- pg_free_result
- pg_get_notify
- pg_get_pid
- pg_get_result
- pg_host
- pg_insert
- pg_last_error
- pg_last_notice
- pg_last_oid
- pg_lo_close
- pg_lo_create
- pg_lo_export
- pg_lo_import
- pg_lo_open
- pg_lo_read_all
- pg_lo_read
- pg_lo_seek
- pg_lo_tell
- pg_lo_truncate
- pg_lo_unlink
- pg_lo_write
- pg_meta_data
- pg_num_fields
- pg_num_rows
- pg_options
- pg_parameter_status
- pg_pconnect
- pg_ping
- pg_port
- pg_prepare
- pg_put_line
- pg_query_params
- pg_query
- pg_result_error_field
- pg_result_error
- pg_result_seek
- pg_result_status
- pg_select
- pg_send_execute
- pg_send_prepare
- pg_send_query_params
- pg_send_query
- pg_set_client_encoding
- pg_set_error_verbosity
- pg_socket
- pg_trace
- pg_transaction_status
- pg_tty
- pg_unescape_bytea
- pg_untrace
- pg_update
- pg_version
Коментарии
it works for me (php-4.2.1)
not like this
int pg_lo_import ( string pathname [, resource connection])
but
int pg_lo_import ( resource connection, string pathname )
don't know the reason
Due to a bug, PHP 4.2.0 and 4.2.1 does not support pg_lo_import() old API. It's fixed in PHP 4.2.2.
BTW, new API will be always available from PHP 4.2.0 to later versions. Older API will be kept long enough, also.
Due to a bug, OLD API does not available with PHP 4.2.0 and 4.2.1.
PHP 4.2.2 will support OLD API again and will be kept long enough.
New API will be available PHP 4.2.0 to later versions.
its not very clear if pg_lo_import needs to have pg_lo_open called first. Because pg_lo_import handles the process of writign to the file, it seems logical that pg_lo_open does not need to be called. However due to the ugly nature of how postgres handles oid objects, it would be nice to have this documented.