F.38. postgres_fdw
Модуль postgres_fdw
предоставляет обёртку сторонних данных postgres_fdw
, используя которую можно обращаться к данным, находящимся на внешних серверах Postgres Pro.
Функциональность этого модуля во многом пересекается с функциональностью старого модуля dblink. Однако postgres_fdw
предоставляет более прозрачный и стандартизированный синтаксис для обращения к удалённым таблицам и во многих случаях даёт лучшую производительность.
Чтобы подготовиться к обращению к удалённым данным через postgres_fdw
:
Установите расширение
postgres_fdw
с помощью команды CREATE EXTENSION.Создайте объект стороннего сервера, используя CREATE SERVER, который будет представлять удалённую базу данных, к которой вы хотите подключаться. Укажите свойства подключения, кроме
user
иpassword
, в параметрах объекта сервера.Создайте сопоставление пользователей, используя CREATE USER MAPPING, для каждого пользователя базы, которому нужен доступ к удалённому серверу. Укажите имя и пароль удалённого пользователя в параметрах
user
иpassword
сопоставления.Создайте стороннюю таблицу, используя CREATE FOREIGN TABLE или IMPORT FOREIGN SCHEMA, для каждой удалённой таблицы, к которой вы хотите обращаться. Столбцы сторонней таблицы должны соответствовать столбцам целевой удалённой таблицы. Однако вы можете использовать локально имена таблиц и/или столбцов, отличные от удалённых, если укажете корректные удалённые имена в параметрах объекта сторонней таблицы.
После этого для обращения к данным, хранящимся в нижележащей удалённой таблице, вам нужно только выполнять SELECT
. Вы также можете изменять данные в удалённой таблице, выполняя INSERT
, UPDATE
или DELETE
. (Разумеется, удалённый пользователь, указанный в сопоставлении, должен иметь необходимые права для этого.)
Заметьте, что в настоящее время в postgres_fdw
не поддерживаются операторы INSERT
с предложением ON CONFLICT DO UPDATE
. Однако предложение ON CONFLICT DO NOTHING
поддерживается, при отсутствии указания для выбора уникального индекса.
Обычно рекомендуется объявлять столбцы сторонней таблицы точно с теми же типами данных и правилами сортировки, если они применимы, как у целевых столбцов удалённой таблицы. Хотя postgres_fdw
в настоящее время довольно лоялен к преобразованиям типов данных при необходимости, но когда типы или правила сортировки не совпадают, возможны неожиданные семантические аномалии, вследствие того, что удалённый сервер будет обрабатывать предложения WHERE
не совсем так, как локальный сервер.
Заметьте, что сторонняя таблица может быть объявлена с меньшим количеством или с другим порядком столбцов, чем в нижележащей удалённой таблице. Сопоставление столбцов удалённой таблицы осуществляется по имени, а не по позиции.
F.38.1. Параметры обёртки для postgres_fdw
F.38.1.1. Параметры подключения
Для стороннего сервера, настраиваемого с использованием обёртки сторонних данных postgres_fdw
, можно задать те же параметры, что принимает libpq в строках подключения, как описано в Подразделе 31.1.2, за исключением следующих недопустимых параметров:
user
иpassword
(их следует задавать в сопоставлениях пользователей)client_encoding
(автоматически принимается равной локальной кодировке сервера)fallback_application_name
(всегдаpostgres_fdw
)
Подключаться к сторонним серверам без аутентификации по паролю могут только суперпользователи, поэтому в сопоставлениях для обычных пользователей всегда нужно задавать пароль (password
).
F.38.1.2. Параметры имени объекта
Эти параметры позволяют управлять тем, как на удалённый сервер Postgres Pro будут передаваться имена, фигурирующие в операторах SQL. Данные параметры нужны, когда сторонняя таблица создаётся с именами, отличными от имён удалённой таблицы.
schema_name
Этот параметр, который может задаваться для сторонней таблицы, указывает имя схемы для обращения к этой таблице на удалённом сервере. Если данный параметр опускается, применяется схема сторонней таблицы.
table_name
Этот параметр, который может задаваться для сторонней таблицы, указывает имя таблицы для обращения к этой таблице на удалённом сервере. Если данный параметр опускается, применяется имя сторонней таблицы.
column_name
Этот параметр, который может задаваться для столбца сторонней таблицы, указывает имя столбца для обращения к этому столбцу на удалённом сервере. Если данный параметр опускается, применяется исходное имя столбца.
F.38.1.3. Параметры оценки стоимости
Модуль postgres_fdw
получает удалённые данные, выполняя запросы на удалённых серверах, поэтому в идеале ожидаемая стоимость сканирования сторонней таблицы должна равняться стоимости выполнения на удалённом сервере плюс издержки сетевого взаимодействия. Самый надёжный способ получить такие оценки — узнать стоимость у удалённого сервера и добавить некоторую надбавку — но для простых запросов может быть невыгодно передавать дополнительный запрос, только чтобы получить оценку стоимости. Поэтому postgres_fdw
предоставляет следующие параметры, позволяющие управлять вычислением оценки стоимости:
use_remote_estimate
Этот параметр, который может задаваться для сторонней таблицы или для стороннего сервера, определяет, будет ли
postgres_fdw
выполнять удалённо командыEXPLAIN
для получения оценок стоимости. Параметр, заданный для сторонней таблицы, переопределяет параметр сервера, но только для данной таблицы. Значение по умолчанию —false
(выкл.).fdw_startup_cost
Этот параметр, который может задаваться для стороннего сервера, устанавливает числовое значение, добавляемое к оценке стоимости запуска для любого сканирования сторонней таблицы на этом сервере. Он выражает дополнительные издержки на установление подключения, разбор и планирование запроса на удалённой стороне и т. д. Значение по умолчанию —
100
.fdw_tuple_cost
Этот параметр, который может задаваться для стороннего сервера, устанавливает числовое значение, выражающее дополнительную цену чтения одного кортежа из сторонней таблицы на этом сервере. Это число можно увеличить или уменьшить, отражая меньшую или большую фактическую скорость сетевого взаимодействия с удалённым сервером. Значение по умолчанию —
0.01
.
Когда поведение use_remote_estimate
включено, postgres_fdw
получает количество строк и оценку стоимости с удалённого сервера, а затем добавляет к оценке стоимости fdw_startup_cost
и fdw_tuple_cost
. Когда поведение use_remote_estimate
отключено, postgres_fdw
рассчитывает число строк и оценку стоимости локально, а затем так же добавляет к этой оценке fdw_startup_cost
и fdw_tuple_cost
. Локальная оценка может быть точной только при условии наличия локальной копии статистики удалённых таблиц. Обновить эту статистику для сторонней таблицы можно с помощью команды ANALYZE; при этом удалённая таблица будет просканирована, и по её содержимому будут вычислена и сохранена статистика как для локальной таблицы. Локальное хранение статистики может быть полезно для сокращения издержек планирования для удалённой таблицы — но если удалённая таблица меняется часто, локальная статистика будет быстро устаревать.
F.38.1.4. Параметры изменения данных
По умолчанию все сторонние таблицы, доступные через postgres_fdw
, считаются допускающими изменения. Это можно переопределить с помощью следующего параметра:
updatable
Этот параметр определяет, будет ли
postgres_fdw
допускать изменения в сторонних таблицах посредством командINSERT
,UPDATE
иDELETE
. Его можно задать для сторонней таблицы или для стороннего сервера. Параметр, определённый на уровне таблицы, переопределяет параметр уровня сервера. Значение по умолчанию —true
(изменения разрешены).Конечно, если удалённая таблица на самом деле не допускает изменения, всё равно произойдёт ошибка. Использование этого параметра прежде всего позволяет выдать ошибку локально, не обращаясь к удалённому серверу. Заметьте, однако, что представление
information_schema
будет показывать, что определённая сторонняя таблицаpostgres_fdw
является изменяемой (или нет), согласно значению данного параметра, не проверяя это на удалённом сервере.
F.38.1.5. Параметры импорта
Обёртка postgres_fdw
позволяет импортировать определения сторонних таблиц с применением команды IMPORT FOREIGN SCHEMA. Эта команда создаёт на локальном сервере определения сторонних таблиц, соответствующие таблицам или представлениям, существующим на удалённом сервере. Если импортируемые удалённые таблицы содержат столбцы пользовательских типов данных, на локальном сервере должны быть совместимые типы с теми же именами.
Поведение процедуры импорта можно настроить следующими параметрами (задаваемыми в команде IMPORT FOREIGN SCHEMA
):
import_collate
Этот параметр устанавливает, будут ли в определения сторонних таблиц, импортируемых с внешнего сервера, включаться характеристики столбцов
COLLATE
. По умолчанию они включаются. Вам может потребоваться отключить его, если на удалённом сервере набор имён правил сортировки отличается от локального, что скорее всего будет иметь место, если серверы работают в разных операционных системах.import_default
Этот параметр устанавливает, будут ли в определения сторонних таблиц, импортируемых с внешнего сервера, включаться заданные для столбцов выражения
DEFAULT
. По умолчанию они не включаются. Если вы включите этот параметр, остерегайтесь выражений по умолчанию, которые могут вычисляться на локальном сервере не так, как на удалённом; например, частый источник проблем —nextval()
. Если в импортируемом выражении используются функции или операторы, несуществующие локально, командаIMPORT
в целом выдаст сбой.import_not_null
Этот параметр устанавливает, будут ли в определения сторонних таблиц, импортируемых с внешнего сервера, включаться ограничения столбцов
NOT NULL
. По умолчанию они включаются.
Заметьте, что никакие другие ограничения, кроме NOT NULL
, из удалённых таблиц импортироваться не будут. Хотя Postgres Pro поддерживает ограничения CHECK
для сторонних таблиц, никаких средств для автоматического импорта их нет из-за риска различного вычисления выражения ограничения на локальном и удалённом серверах. Любая такая несогласованность в поведении ограничений CHECK
могла бы привести к сложно выявляемым ошибкам в оптимизации запросов. Поэтому, если вы хотите импортировать ограничения CHECK
, вы должны сделать это вручную и должны внимательно проверить семантику каждого. Более подробно интерпретация ограничений CHECK
для сторонних таблиц описана в CREATE FOREIGN TABLE.
F.38.2. Управление соединением
Модуль postgres_fdw
устанавливает соединение со сторонним сервером при первом запросе, в котором участвует сторонняя таблица, связанная со сторонним сервером. Это соединение сохраняется и повторно используется для последующих запросов в том же сеансе. Однако, если для обращения к стороннему серверу задействуются разные пользователи (сопоставления пользователей), отдельное соединение устанавливается для каждого сопоставления пользователей.
F.38.3. Управление транзакциями
В процессе выполнения запроса, в котором участвуют какие-либо удалённые таблицы на стороннем сервере, postgres_fdw
открывает транзакцию на удалённом сервере, если такая транзакция ещё не была открыта для текущей локальной транзакции. Эта удалённая транзакция фиксируется или прерывается, когда фиксируется или прерывается локальная транзакция. Подобным образом реализуется и управление точками сохранения.
Для удалённой транзакции выбирается режим изоляции SERIALIZABLE
, когда локальная транзакция открыта в режиме SERIALIZABLE
; в противном случае применяется режим REPEATABLE READ
. Этот выбор гарантирует, что если запрос сканирует несколько таблиц на удалённом сервере, он будет получать согласованные данные одного снимка для всех сканирований. Как следствие, последовательные запросы в одной транзакции будут видеть одни данные удалённого сервера, даже если на нём параллельно происходят изменения, вызванные другими действиями. Это поведение ожидаемо для локальной транзакции в режимах SERIALIZABLE
и REPEATABLE READ
, но для локальной транзакции в режиме READ COMMITTED
оно может быть неожиданным. В будущих выпусках Postgres Pro эти правила могут быть изменены.
Заметьте, что подготовку удалённой транзакции для двухфазной фиксации postgres_fdw
в настоящее время не поддерживает.
F.38.4. Оптимизация удалённых запросов
Модуль postgres_fdw
пытается оптимизировать удалённые запросы с целью сокращения объёма данных, получаемых от сторонних серверов. Для этого удалённому серверу на выполнение передаются предложения WHERE
, а колонки, не требующиеся в текущем запросе, с него не запрашиваются. Чтобы сократить риск некорректного выполнения запросов, предложения WHERE
передаются на удалённый сервер, только если в них используются встроенные типы данных, операторы и функции. Кроме того, операторы и функции в таких запросах должны быть постоянными (IMMUTABLE
).
Запрос, фактически отправляемый удалённому серверу для выполнения, можно изучить с помощью команды EXPLAIN VERBOSE
.
F.38.5. Окружение удалённого выполнения запросов
В удалённых сеансах, установленных обёрткой postgres_fdw
, в параметре search_path задаётся только pg_catalog
, так что без указания схемы видны только встроенные объекты. Это не проблема для запросов, которые генерирует сама postgres_fdw
, так как она всегда добавляет такие указания. Однако это может быть опасно для функций, которые выполняются на удалённом сервере при срабатывании триггеров или правил для удалённых таблиц. Например, если удалённая таблица на самом деле представляет собой представление, любые функции, используемые в этом представлении, будут выполняться с таким ограниченным путём поиска. Поэтому рекомендуется в таких функциях дополнять схемой все имена либо добавлять параметры SET search_path
(см. CREATE FUNCTION) в определения таких функций, чтобы установить ожидаемый ими путь поиска в окружении.
Обёртка postgres_fdw
подобным образом устанавливает для удалённого сеанса значения параметров TimeZone, DateStyle, IntervalStyle и extra_float_digits. С ними проблемы менее вероятны, чем с search_path
, но если они возникнут, их можно урегулировать, установив нужные параметры с помощью SET
.
Это поведение не рекомендуется переопределять, устанавливая значения этих параметров на уровне сеанса; это скорее всего приведёт к поломке postgres_fdw
.
F.38.6. Совместимость с разными версиями
Модуль postgres_fdw
может применяться с удалёнными серверами версий, начиная с PostgreSQL 8.3. Способность только чтения данных доступна, начиная с 8.1. Однако, при этом есть ограничение, вызванное тем, что postgres_fdw
полагает, что постоянные встроенные функции и операторы могут безопасно передаваться на удалённый сервер для выполнения, если они фигурируют в предложении WHERE
для сторонней таблицы. Таким образом, встроенная функция, добавленная в более новой версии, чем на удалённом сервере, может быть отправлена на выполнение, что в результате приведёт к ошибке «функция не существует» или подобной. Отказы такого типа можно предотвратить, переписав запрос, например, поместив ссылку на стороннюю таблицу во вложенный SELECT
с OFFSET 0
в качестве защиты от оптимизации, и применив проблематичную функцию или оператор снаружи этого вложенного SELECT
.
F.38.7. Примеры
Ниже приведён пример создания сторонней таблицы с применением postgres_fdw
. Сначала установите расширение:
CREATE EXTENSION postgres_fdw;
Затем создайте сторонний сервер с помощью команды CREATE SERVER. В данном примере мы хотим подключиться к серверу Postgres Pro, работающему по адресу 192.83.123.89
, порт 5432
. База данных, к которой устанавливается подключение, на удалённом сервере называется foreign_db
:
CREATE SERVER foreign_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '192.83.123.89', port '5432', dbname 'foreign_db');
Для определения роли, которая будет задействована на удалённом сервере, с помощью CREATE USER MAPPING задаётся сопоставление пользователей:
CREATE USER MAPPING FOR local_user SERVER foreign_server OPTIONS (user 'foreign_user', password 'password');
Теперь можно создать стороннюю таблицу, применив команду CREATE FOREIGN TABLE. В этом примере мы хотим обратиться к таблице some_schema.some_table
на удалённом сервере. Локальным именем этой таблицы будет foreign_table
:
CREATE FOREIGN TABLE foreign_table ( id integer NOT NULL, data text ) SERVER foreign_server OPTIONS (schema_name 'some_schema', table_name 'some_table');
Важно, чтобы типы данных и другие свойства столбцов, объявленных в CREATE FOREIGN TABLE
, соответствовали фактической удалённой таблице. Также должны соответствовать имена столбцов, если только вы не добавите параметры column_name
для отдельных столбцов, задающие их реальные имена в удалённой таблице. Во многих случаях использовать IMPORT FOREIGN SCHEMA предпочтительнее, чем конструировать определения сторонних таблиц вручную.
45.3. Built-in Functions
45.3.1. Database Access from PL/Perl
Access to the database itself from your Perl function can be done via the following functions:
-
spi_exec_query
(query
[,limit
]) spi_exec_query
executes an SQL command and returns the entire row set as a reference to an array of hash references. Iflimit
is specified and is greater than zero, thenspi_exec_query
retrieves at mostlimit
rows, much as if the query included aLIMIT
clause. Omittinglimit
or specifying it as zero results in no row limit.You should only use this command when you know that the result set will be relatively small. Here is an example of a query (
SELECT
command) with the optional maximum number of rows:$rv = spi_exec_query('SELECT * FROM my_table', 5);
This returns up to 5 rows from the table
my_table
. Ifmy_table
has a columnmy_column
, you can get that value from row$i
of the result like this:$foo = $rv->{rows}[$i]->{my_column};
The total number of rows returned from a
SELECT
query can be accessed like this:$nrows = $rv->{processed}
Here is an example using a different command type:
$query = "INSERT INTO my_table VALUES (1, 'test')"; $rv = spi_exec_query($query);
You can then access the command status (e.g.,
SPI_OK_INSERT
) like this:$res = $rv->{status};
To get the number of rows affected, do:
$nrows = $rv->{processed};
Here is a complete example:
CREATE TABLE test ( i int, v varchar ); INSERT INTO test (i, v) VALUES (1, 'first line'); INSERT INTO test (i, v) VALUES (2, 'second line'); INSERT INTO test (i, v) VALUES (3, 'third line'); INSERT INTO test (i, v) VALUES (4, 'immortal'); CREATE OR REPLACE FUNCTION test_munge() RETURNS SETOF test AS $$ my $rv = spi_exec_query('select i, v from test;'); my $status = $rv->{status}; my $nrows = $rv->{processed}; foreach my $rn (0 .. $nrows - 1) { my $row = $rv->{rows}[$rn]; $row->{i} += 200 if defined($row->{i}); $row->{v} =~ tr/A-Za-z/a-zA-Z/ if (defined($row->{v})); return_next($row); } return undef; $$ LANGUAGE plperl; SELECT * FROM test_munge();
-
spi_query(
command
)
spi_fetchrow(
cursor
)
spi_cursor_close(
cursor
) spi_query
andspi_fetchrow
work together as a pair for row sets which might be large, or for cases where you wish to return rows as they arrive.spi_fetchrow
works only withspi_query
. The following example illustrates how you use them together:CREATE TYPE foo_type AS (the_num INTEGER, the_text TEXT); CREATE OR REPLACE FUNCTION lotsa_md5 (INTEGER) RETURNS SETOF foo_type AS $$ use Digest::MD5 qw(md5_hex); my $file = '/usr/share/dict/words'; my $t = localtime; elog(NOTICE, "opening file $file at $t" ); open my $fh, '<', $file # ooh, it's a file access! or elog(ERROR, "cannot open $file for reading: $!"); my @words = <$fh>; close $fh; $t = localtime; elog(NOTICE, "closed file $file at $t"); chomp(@words); my $row; my $sth = spi_query("SELECT * FROM generate_series(1,$_[0]) AS b(a)"); while (defined ($row = spi_fetchrow($sth))) { return_next({ the_num => $row->{a}, the_text => md5_hex($words[rand @words]) }); } return; $$ LANGUAGE plperlu; SELECT * from lotsa_md5(500);
Normally,
spi_fetchrow
should be repeated until it returnsundef
, indicating that there are no more rows to read. The cursor returned byspi_query
is automatically freed whenspi_fetchrow
returnsundef
. If you do not wish to read all the rows, instead callspi_cursor_close
to free the cursor. Failure to do so will result in memory leaks.-
spi_prepare(
command
,argument types
)
spi_query_prepared(
plan
,arguments
)
spi_exec_prepared(
plan
[,attributes
],arguments
)
spi_freeplan(
plan
) spi_prepare
,spi_query_prepared
,spi_exec_prepared
, andspi_freeplan
implement the same functionality but for prepared queries.spi_prepare
accepts a query string with numbered argument placeholders ($1, $2, etc.) and a string list of argument types:$plan = spi_prepare('SELECT * FROM test WHERE id > $1 AND name = $2', 'INTEGER', 'TEXT');
Once a query plan is prepared by a call to
spi_prepare
, the plan can be used instead of the string query, either inspi_exec_prepared
, where the result is the same as returned byspi_exec_query
, or inspi_query_prepared
which returns a cursor exactly asspi_query
does, which can be later passed tospi_fetchrow
. The optional second parameter tospi_exec_prepared
is a hash reference of attributes; the only attribute currently supported islimit
, which sets the maximum number of rows returned from the query. Omittinglimit
or specifying it as zero results in no row limit.The advantage of prepared queries is that is it possible to use one prepared plan for more than one query execution. After the plan is not needed anymore, it can be freed with
spi_freeplan
:CREATE OR REPLACE FUNCTION init() RETURNS VOID AS $$ $_SHARED{my_plan} = spi_prepare('SELECT (now() + $1)::date AS now', 'INTERVAL'); $$ LANGUAGE plperl; CREATE OR REPLACE FUNCTION add_time( INTERVAL ) RETURNS TEXT AS $$ return spi_exec_prepared( $_SHARED{my_plan}, $_[0] )->{rows}->[0]->{now}; $$ LANGUAGE plperl; CREATE OR REPLACE FUNCTION done() RETURNS VOID AS $$ spi_freeplan( $_SHARED{my_plan}); undef $_SHARED{my_plan}; $$ LANGUAGE plperl; SELECT init(); SELECT add_time('1 day'), add_time('2 days'), add_time('3 days'); SELECT done(); add_time | add_time | add_time ------------+------------+------------ 2005-12-10 | 2005-12-11 | 2005-12-12
Note that the parameter subscript in
spi_prepare
is defined via $1, $2, $3, etc., so avoid declaring query strings in double quotes that might easily lead to hard-to-catch bugs.Another example illustrates usage of an optional parameter in
spi_exec_prepared
:CREATE TABLE hosts AS SELECT id, ('192.168.1.'||id)::inet AS address FROM generate_series(1,3) AS id; CREATE OR REPLACE FUNCTION init_hosts_query() RETURNS VOID AS $$ $_SHARED{plan} = spi_prepare('SELECT * FROM hosts WHERE address << $1', 'inet'); $$ LANGUAGE plperl; CREATE OR REPLACE FUNCTION query_hosts(inet) RETURNS SETOF hosts AS $$ return spi_exec_prepared( $_SHARED{plan}, {limit => 2}, $_[0] )->{rows}; $$ LANGUAGE plperl; CREATE OR REPLACE FUNCTION release_hosts_query() RETURNS VOID AS $$ spi_freeplan($_SHARED{plan}); undef $_SHARED{plan}; $$ LANGUAGE plperl; SELECT init_hosts_query(); SELECT query_hosts('192.168.1.0/30'); SELECT release_hosts_query(); query_hosts ----------------- (1,192.168.1.1) (2,192.168.1.2) (2 rows)
-
spi_commit()
spi_rollback()
Commit or roll back the current transaction. This can only be called in a procedure or anonymous code block (
DO
command) called from the top level. (Note that it is not possible to run the SQL commandsCOMMIT
orROLLBACK
viaspi_exec_query
or similar. It has to be done using these functions.) After a transaction is ended, a new transaction is automatically started, so there is no separate function for that.Here is an example:
CREATE PROCEDURE transaction_test1() LANGUAGE plperl AS $$ foreach my $i (0..9) { spi_exec_query("INSERT INTO test1 (a) VALUES ($i)"); if ($i % 2 == 0) { spi_commit(); } else { spi_rollback(); } } $$; CALL transaction_test1();
45.3.2. Utility Functions in PL/Perl
-
elog(
level
,msg
) Emit a log or error message. Possible levels are
DEBUG
,LOG
,INFO
,NOTICE
,WARNING
, andERROR
.ERROR
raises an error condition; if this is not trapped by the surrounding Perl code, the error propagates out to the calling query, causing the current transaction or subtransaction to be aborted. This is effectively the same as the Perldie
command. The other levels only generate messages of different priority levels. Whether messages of a particular priority are reported to the client, written to the server log, or both is controlled by the log_min_messages and client_min_messages configuration variables. See Chapter 20 for more information.-
quote_literal(
string
) Return the given string suitably quoted to be used as a string literal in an SQL statement string. Embedded single-quotes and backslashes are properly doubled. Note that
quote_literal
returns undef on undef input; if the argument might be undef,quote_nullable
is often more suitable.-
quote_nullable(
string
) Return the given string suitably quoted to be used as a string literal in an SQL statement string; or, if the argument is undef, return the unquoted string "NULL". Embedded single-quotes and backslashes are properly doubled.
-
quote_ident(
string
) Return the given string suitably quoted to be used as an identifier in an SQL statement string. Quotes are added only if necessary (i.e., if the string contains non-identifier characters or would be case-folded). Embedded quotes are properly doubled.
-
decode_bytea(
string
) Return the unescaped binary data represented by the contents of the given string, which should be
bytea
encoded.-
encode_bytea(
string
) Return the
bytea
encoded form of the binary data contents of the given string.-
encode_array_literal(
array
)
encode_array_literal(
array
,delimiter
) Returns the contents of the referenced array as a string in array literal format (see Section 8.15.2). Returns the argument value unaltered if it's not a reference to an array. The delimiter used between elements of the array literal defaults to "
,
" if a delimiter is not specified or is undef.-
encode_typed_literal(
value
,typename
) Converts a Perl variable to the value of the data type passed as a second argument and returns a string representation of this value. Correctly handles nested arrays and values of composite types.
-
encode_array_constructor(
array
) Returns the contents of the referenced array as a string in array constructor format (see Section 4.2.12). Individual values are quoted using
quote_nullable
. Returns the argument value, quoted usingquote_nullable
, if it's not a reference to an array.-
looks_like_number(
string
) Returns a true value if the content of the given string looks like a number, according to Perl, returns false otherwise. Returns undef if the argument is undef. Leading and trailing space is ignored.
Inf
andInfinity
are regarded as numbers.-
is_array_ref(
argument
) Returns a true value if the given argument may be treated as an array reference, that is, if ref of the argument is
ARRAY
orPostgreSQL::InServer::ARRAY
. Returns false otherwise.