The following bug has been logged online:
Bug reference: 5361
Logged by: Alexender
Email address: bav...@mail.ru
PostgreSQL version: 8.4
Operating system: Ubuntu server 9.10 (Karmic)
Description:KOI8U issue
Details:
This is real problem.
Dump from Postgres 8.2 can't
The following bug has been logged online:
Bug reference: 5362
Logged by: ALEX
Email address: bav...@mail.ru
PostgreSQL version: 8.3
Operating system: linux ubuntu 9.10 server
Description:WARNING could not determine encoding
Details:
# sudo pg_createcluster -e koi8 -
On tor, 2010-03-04 at 07:31 +, Alexender wrote:
> This is real problem.
> Dump from Postgres 8.2 can't be restored in Postgres 8.4
> if I use on server 8.2 encodings KOI8 and --lc-collate and --lc-ctype
> uk_UA.KOI8-U
> Because conversion is not supported between KOI8R and KOI8U and
> dump 8.
On ons, 2010-02-24 at 12:16 -0500, Tom Lane wrote:
> Joe Conway writes:
> > Related to this I have noticed in recent weeks on my own development
> > machine that "make install" takes *much* longer, but only sporadically,
> > due to the docs building.
>
> This might be related to Peter's changes t
On Thu, Mar 4, 2010 at 9:15 AM, Peter Eisentraut wrote:
> On ons, 2010-02-24 at 12:16 -0500, Tom Lane wrote:
>> Joe Conway writes:
>> > Related to this I have noticed in recent weeks on my own development
>> > machine that "make install" takes *much* longer, but only sporadically,
>> > due to the
May I add 2 cents?
While I'd agree a 'make all' should, uh... make _all_, and that make building
based on lots of guessing is counterintuitive,
an option to configure like:
./configure --no-docs or
./configure --with-htmldocs-only
- with some of the obvious variants - might be very usef
On Wed, Mar 3, 2010 at 8:48 AM, Gurjeet Singh wrote:
> On Wed, Mar 3, 2010 at 8:37 AM, Robert Haas wrote:
>>
>> On Wed, Mar 3, 2010 at 7:29 AM, Gurjeet Singh
>> wrote:
>> > I just realized that it is the subquery pull-up that is leading to this
>> > problem, not predicate push-down. Sleeping ove
Robert Haas writes:
> Normally this kind of reordering doesn't actually affect the result of
> the query because normally the quals that are being evaluated don't
> have any side-effects, but in your query you've chosen something that
> can throw an exception, so it's user-visible.
There's a pret
