-- ... stuff before
dynamic_select_cols := 'tbl1.foo, tbl1.bar, null AS theAlias1, null AS theAlias2, tbl2.foo2';
-- ... stuff after combining the dynamic queries
EXECUTE my_dynamic_query;

In my case the result of the query will be inserted in a temporary table in memory. The destination column for theAlias1 is of type INTEGER. When executing the query PostgreSQL gives me an error:

column "theAlias1" is of type integer but expression is of type text

So there is something wrong when the query is parsed, evaluated and executed.

Solving this was easy with the use of NULLIF. Zero equals zero so NULL is returned. Just as expected.

-- ... stuff before
dynamic_select_cols := 'tbl1.foo, tbl1.bar, NULLIF(0, 0) AS theAlias1, NULLIF(0, 0) AS theAlias2, tbl2.foo2';
-- ... stuff after combining the dynamic queries
EXECUTE my_dynamic_query;

Debian lenny stable packages are bundled with Postgres 8.3.x but thanks to Debian Backports the newer Postgres version is available for lenny.

Simply do it

Add the backports-sources (/etc/apt/sources.list) and update (apt-get update)

deb http://www.backports.org/debian lenny-backports main contrib non-free

Install postgres

apt-get -t lenny-backports install postgresql-8.4

Value too long for type character varying(64)

Within a function (written with plpgsql) a dynamic query is built and executed via sql-EXECUTE. The error PostgreSQL gives me stated out that the error was in the line containing the EXECUTE-statement. But the query was of type TEXT so there is no length limitation.

Guide me

In the end it showed that the error PostgreSQL gave me was misleading. The final dynamic query itself was fine. So the sql-EXECUTE cannot be the cause of the error. 

The function returns a custom (composite) type (built via PostgreSQL CREATE TYPE). This custom type consists of a few “columns”. One of this column was indeed of type character varying(64) and was simply to short to hold the data collected inside the function.

Fixing the data type of that column in the custom composite type fixes the error.

SELECT col1 FROM foobar WHERE col1 LIKE '1234%';

Yes?! Really?!

In one of our production systems this kind of query (when debugged via EXPLAIN / EXPLAIN ANALYZE) return unexpected results. Every time our comparison operator turns from equality = into LIKE the index for the column is fully ignored and instead a full-table scan (sequential scan) is used by the planner. Things are really slow …

I locale you!

After asking Google its seems some more people having this issue, too.
Our database-cluster was initialized with the locale de_DE.utf8. A quick view into the excellent documentation for CREATE INDEX revealed there is an operator class which controls the operators of the index. After adding an index with an operator class for that column the index (“FoobarWildcardIdx”) is now used even when the query contains LIKE.

CREATE INDEX FoobarWildcardIdx ON foobar (col1 varchar_pattern_ops);

Symfony makes heavy use of Propel. Propel finds objects in the storage container using criteria. If you want to let Propel (okay the database) ignore the case you can set this in the criteria.

$c = new Criteria ();
 
// Allow case sensitive searches
$c->setIgnoreCase (true);
 
// Find all posts which name contains propel
$c->add (BlogPostPeer::NAME, 'Propel');
 
$posts = BlogPostPeer::doSelect ($c);

Because PostgreSQL (unlike MySQL) does not support collations to easily manage how comparisons of strings are done Propel has to generate this sql-statement.

SELECT blog_posts.name, blog_posts.DATE
FROM blog_posts
WHERE UPPER(blog_posts.name) = 'PROPEL';

Depending on your amount of data this can become very slow even if you have an index defined for the "name"-column.

The trick is to create another index for the column "name".

CREATE INDEX "UpperNameIndex" ON blog_posts USING BTREE (UPPER(name));

Thats it. When now using setIgnoreCase its fast again.