Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>To <strong>insert bytea contents</strong> with the pg_* API, the binary value should always be run through the <code>pg_escape_bytea()</code> function, even if it's passed to the <code>pg_execute</code> or <code>pg_query_params</code> functions. This is because the pg_* layer doesn't "know" that a particular parameter has binary contents, and it does not implement any real support for parameter types anyway. So the text representation must be used. It can either be in the <code>escape</code> form or the <code>hex</code> form, it doesn't matter to the PG server, and it's independant of the value of <code>bytea_output</code>, which is meaningful only for values read from the server.</p> <p>Example:</p> <pre><code>$esc=pg_escape_bytea("\000\001\002"); pg_query_params('INSERT INTO some_table(some_col) VALUES($1)', array($esc)); </code></pre> <hr> <p>To <strong>read bytea contents</strong> with the pg_* API, the value must be run through <code>pg_unescape_bytea()</code> after the fetch. Assuming the client library is not older than 9.0 (libq.so.5.3 or higher), it can decode the contents whether it's in <code>hex</code> form or <code>escape</code> form and it will autodetect it. Only with an older library would it be necessary to force <code>bytea_output</code> to <code>escape</code> for it to decode properly, either dynamically with <code>SET</code> or statically for the whole database (<code>ALTER DATABASE SET bytea_output=escape</code>) or in <code>postgresql.conf</code> for the whole instance.</p> <p>Example:</p> <pre><code> $p=pg_query("SELECT some_col FROM some_table WHERE..."); $r=pg_fetch_array($p); $contents = pg_unescape_bytea($r[0]); </code></pre>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload