The <I>~</I> operator does regular-expression matching, and <I>~*</I>
The <I>~</I> operator does regularexpression matching, and <I>~*</I>
does case-insensitive regular-expression matching. There is no
does case-insensitive regularexpression matching. There is no
case-insensitive variant of the LIKE operator, but you can get the
case-insensitive variant of the LIKE operator, but you can get the
effect of case-insensitive <SMALL>LIKE</SMALL> with this:
effect of case-insensitive <SMALL>LIKE</SMALL> with this:
<PRE>
<PRE>
...
@@ -999,7 +999,7 @@ BYTEA bytea variable-length array of bytes
...
@@ -999,7 +999,7 @@ BYTEA bytea variable-length array of bytes
You will see the internal name when examining system catalogs
You will see the internal name when examining system catalogs
and in some error messages.<P>
and in some error messages.<P>
The last four types above are "varlena" types (i.e. the first four bytes
The last four types above are "varlena" types (i.e., the first four bytes
are the length, followed by the data). <I>char(#)</I> allocates the
are the length, followed by the data). <I>char(#)</I> allocates the
maximum number of bytes no matter how much data is stored in the field.
maximum number of bytes no matter how much data is stored in the field.
<I>text, varchar(#),</I> and <I>bytea</I> all have variable length on the disk,
<I>text, varchar(#),</I> and <I>bytea</I> all have variable length on the disk,
...
@@ -1043,17 +1043,26 @@ One approach is to to retrieve the next SERIAL value from the sequence object wi
...
@@ -1043,17 +1043,26 @@ One approach is to to retrieve the next SERIAL value from the sequence object wi
$newSerialID = nextval('person_id_seq');
$newSerialID = nextval('person_id_seq');
INSERT INTO person (id, name) VALUES ($newSerialID, 'Blaise Pascal');
INSERT INTO person (id, name) VALUES ($newSerialID, 'Blaise Pascal');
</PRE>
</PRE>
You would then also have the new value stored in <CODE>$newSerialID</CODE> for use in other queries (e.g., as a foreign key to the <CODE>person</CODE> table). Note that the name of the automatically-created SEQUENCE object will be named <<I>table</I>>_<<I>serialcolumn</I>>_<I>seq</I>, where <I>table</I> and <I>serialcolumn</I> are the names of your table and your SERIAL column, respectively.
You would then also have the new value stored in
<CODE>$newSerialID</CODE> for use in other queries (e.g., as a foreign
key to the <CODE>person</CODE> table). Note that the name of the
automatically created SEQUENCE object will be named
<<I>table</I>>_<<I>serialcolumn</I>>_<I>seq</I>, where
<I>table</I> and <I>serialcolumn</I> are the names of your table and
your SERIAL column, respectively.
<P>
<P>
Alternatively, you could retrieve the just-assigned SERIAL value with the <I>currval</I>() function <I>after</I> it was inserted by default, e.g.,
Alternatively, you could retrieve the assigned SERIAL value with the <I>currval</I>() function <I>after</I> it was inserted by default, e.g.,
<PRE>
<PRE>
INSERT INTO person (name) VALUES ('Blaise Pascal');
INSERT INTO person (name) VALUES ('Blaise Pascal');
$newID = currval('person_id_seq');
$newID = currval('person_id_seq');
</PRE>
</PRE>
Finally, you could use the <AHREF="#4.17"><small>OID</small></A> returned from the
INSERT statement to lookup the default value, though this is probably
Finally, you could use the <AHREF="#4.17"><small>OID</small></A>
the least portable approach. In Perl, using DBI with Edmund Mergl's
returned from the INSERT statement to look up the default value, though
DBD::Pg module, the oid value is made available via
this is probably the least portable approach. In Perl, using DBI with
Edmund Mergl's DBD::Pg module, the oid value is made available via
<I>$sth->{pg_oid_status} after $sth->execute().</I>
<I>$sth->{pg_oid_status} after $sth->execute().</I>
<H4><ANAME="4.16.3">4.16.3</A>) Don't <I>currval()</I> and <I>nextval()</I> lead to
<H4><ANAME="4.16.3">4.16.3</A>) Don't <I>currval()</I> and <I>nextval()</I> lead to
...
@@ -1065,12 +1074,13 @@ No. This is handled by the backends.
...
@@ -1065,12 +1074,13 @@ No. This is handled by the backends.
<H4><ANAME="4.17">4.17</A>) What is an <small>OID</small>? What is a
<H4><ANAME="4.17">4.17</A>) What is an <small>OID</small>? What is a
<small>TID</small>?</H4><P>
<small>TID</small>?</H4><P>
<small>OID</small>s are PostgreSQL's answer to unique row ids. Every row that is
<small>OID</small>s are PostgreSQL's answer to unique row ids. Every
created in PostgreSQL gets a unique <small>OID</small>. All <small>OID</small>s generated during
row that is created in PostgreSQL gets a unique <small>OID</small>. All
<I>initdb</I> are less than 16384 (from <I>backend/access/transam.h</I>). All
<small>OID</small>s generated during <I>initdb</I> are less than 16384
user-created <small>OID</small>s are equal or greater that this. By default, all these
(from <I>backend/access/transam.h</I>). All user-created
<small>OID</small>s are unique not only within a table, or database, but unique within
<small>OID</small>s are equal to or greater than this. By default, all
the entire PostgreSQL installation.<P>
these <small>OID</small>s are unique not only within a table or
database, but unique within the entire PostgreSQL installation.<P>
PostgreSQL uses <small>OID</small>s in its internal system tables to link rows between
PostgreSQL uses <small>OID</small>s in its internal system tables to link rows between
tables. These <small>OID</small>s can be used to identify specific user rows and used
tables. These <small>OID</small>s can be used to identify specific user rows and used
...
@@ -1175,7 +1185,7 @@ Use <i>now()</i>:
...
@@ -1175,7 +1185,7 @@ Use <i>now()</i>:
<P>
<P>
<H4><ANAME="4.23">4.23</A>) Why are my subqueries using
<H4><ANAME="4.23">4.23</A>) Why are my subqueries using
<CODE><small>IN</small></CODE> so slow?<BR></H4><P>
<CODE><small>IN</small></CODE> so slow?<BR></H4><P>
Currently, we join subqueries to outer queries by sequential scanning
Currently, we join subqueries to outer queries by sequentially scanning
the result of the subquery for each row of the outer query. A workaround
the result of the subquery for each row of the outer query. A workaround
is to replace <CODE>IN</CODE> with <CODE>EXISTS</CODE>:
is to replace <CODE>IN</CODE> with <CODE>EXISTS</CODE>:
<CODE><PRE>
<CODE><PRE>
...
@@ -1216,12 +1226,12 @@ does an <i>outer</i> join of the two tables:
...
@@ -1216,12 +1226,12 @@ does an <i>outer</i> join of the two tables:
I run it in <I>psql,</I> why does it dump core?</H4><P>
I run it in <I>psql,</I> why does it dump core?</H4><P>
The problem could be a number of things. Try testing your user-defined
The problem could be a number of things. Try testing your user-defined
function in a standalone test program first.
function in a stand-alone test program first.
<H4><ANAME="5.2">5.2</A>) What does the message
<H4><ANAME="5.2">5.2</A>) What does the message
<I>"NOTICE:PortalHeapMemoryFree: 0x402251d0 not in alloc set!"</I> mean?</H4><P>
<I>"NOTICE:PortalHeapMemoryFree: 0x402251d0 not in alloc set!"</I> mean?</H4><P>
You are <I>pfree'ing</I> something that was not <I>palloc'ed.</I>
You are <I>pfree'</I>ing something that was not <I>palloc'</I>ed.
Beware of mixing <I>malloc/free</I> and <I>palloc/pfree.</I>
Beware of mixing <I>malloc/free</I> and <I>palloc/pfree.</I>