<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rss [<!ENTITY % HTMLlat1 PUBLIC "-//W3C//ENTITIES Latin 1 for XHTML//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent">]>
<rss version="2.0" xml:base="http://www.whitemiceconsulting.com">
<channel>
 <title>WhitemiceConsulting.Com - PostgreSQL</title>
 <link>http://www.whitemiceconsulting.com/taxonomy/term/25/0</link>
 <description></description>
 <language>en</language>
<item>
 <title>OGo &amp; PostgreSQL 8.3</title>
 <link>http://www.whitemiceconsulting.com/node/141</link>
 <description>&lt;p&gt;&lt;a href=&quot;http://www.postgresql.org&quot;&gt;PostgreSQL&lt;/a&gt; 8.3 not longer performs automatic casting of INT to TEXT when INTs are compared to character types.   This change is documented in the &lt;a href=&quot;http://www.postgresql.org/docs/8.3/static/release-8-3.html&quot;&gt;release notes&lt;/a&gt;.  This change causes a database exception to occur in OpenGroupare&#039;s ACL processing.  The specific error is:&lt;br /&gt;
&lt;code&gt;&lt;br /&gt;
ERROR:  IN types character varying and integer cannot be matched&lt;br /&gt;
&lt;/code&gt;&lt;/p&gt;
&lt;p&gt;ACL queries like the following cause the exception because they contain a condition that compares string value to an array of integers: &lt;code&gt;auth_id IN ( 9981, 9991,...&lt;/code&gt; where &lt;code&gt;auth_id&lt;/code&gt; is a &lt;code&gt;VARCHAR(255)&lt;/code&gt; value.&lt;/p&gt;
</description>
 <category domain="http://www.whitemiceconsulting.com/taxonomy/term/11">OpenGroupware</category>
 <category domain="http://www.whitemiceconsulting.com/taxonomy/term/25">PostgreSQL</category>
 <pubDate>Mon, 18 Feb 2008 20:14:54 -0500</pubDate>
</item>
<item>
 <title>Improvement to SOPE&#039;s PostgreSQL Adaptor</title>
 <link>http://www.whitemiceconsulting.com/node/140</link>
 <description>&lt;p&gt;Do you have lots of errors like:&lt;br /&gt;
&lt;code&gt;&lt;br /&gt;
Feb 17 20:39:28 ogo-zidestore-1.5 [14569]: ERROR(+[NSCalendarDate(PostgreSQL72Values) valueFromCString:length:postgreSQLType:attribute:adaptorChannel:]): unexpected string &#039;2007-03-13 15:38:41.420456+00&#039; for date type &#039;DATE&#039;, returning now (expected format: &#039;2001-07-26 14:00:00+02&#039;)&lt;br /&gt;
&lt;/code&gt;&lt;br /&gt;
in your ZideStore error log?  This is because the time &amp;amp; date parser in &lt;a href=&quot;http://sope.opengroupware.org/&quot;&gt;SOPE&lt;/a&gt;&#039;s &lt;a href=&quot;http://www.postgresql.org/&quot;&gt;PostreSQL&lt;/a&gt; adaptor didn&#039;t understand the milliseconds portion of the value.  As of &lt;a href=&quot;http://sope.opengroupware.org/&quot;&gt;SOPE&lt;/a&gt; r1601 this should be corrected.    &lt;a href=&quot;http://sope.opengroupware.org/&quot;&gt;SOPE&lt;/a&gt; now just ignores the millisecond value.   See the &lt;a href=&quot;http://svn.opengroupware.org/viewcvs/trunk/sope-gdl1/PostgreSQL/NSCalendarDate%2BPGVal.m?root=SOPE&amp;amp;rev=1601&amp;amp;r1=999&amp;amp;r2=1601&quot;&gt;diff&lt;/a&gt; for details.&lt;/p&gt;
</description>
 <category domain="http://www.whitemiceconsulting.com/taxonomy/term/11">OpenGroupware</category>
 <category domain="http://www.whitemiceconsulting.com/taxonomy/term/25">PostgreSQL</category>
 <pubDate>Sun, 17 Feb 2008 17:06:37 -0500</pubDate>
</item>
<item>
 <title>Partial Indexes</title>
 <link>http://www.whitemiceconsulting.com/node/116</link>
 <description>&lt;p&gt;&lt;a href=&quot;http://www.postgresql.org&quot;&gt;PostgreSQL&lt;/a&gt; supports an often overlooked feature called &quot;Partial Indexes&quot;;  this allows you to have an index with a WHERE clause just like in a SELECT statement.  With a partial index the querying for records with a frequently used key can be greatly accelerated; records without that key value can be immediately discarded.&lt;/p&gt;
&lt;p&gt;From the &lt;a href=&quot;http://www.postgresql.org/docs/8.0/static/indexes-partial.html&quot;&gt;PostgreSQL documentation&lt;/a&gt;: &lt;cite&gt;Since a query searching for a common value (one that accounts for more than a few percent of all the table rows) will not use the index anyway, there is no point in keeping those rows in the index at all. This reduces the size of the index, which will speed up queries that do use the index.&lt;/cite&gt;&lt;/p&gt;
</description>
 <category domain="http://www.whitemiceconsulting.com/taxonomy/term/11">OpenGroupware</category>
 <category domain="http://www.whitemiceconsulting.com/taxonomy/term/25">PostgreSQL</category>
 <pubDate>Tue, 24 Apr 2007 18:08:53 -0400</pubDate>
</item>
</channel>
</rss>
