On Tue, Jan 31, 2006 at 09:50:26PM -0600, Andrew Dunstan wrote:
> David Fetter said:
> > On Tue, Jan 31, 2006 at 08:03:41PM -0500, Bruce Momjian wrote:
> >> Uh, couldn't the delimiter be a backslash in CVS mode?
> >
> > I don't think so. Folks?
>
> Using backslash as a delimiter in CSV would be o
On Tue, Jan 31, 2006 at 08:03:41PM -0500, Bruce Momjian wrote:
> Uh, couldn't the delimiter be a backslash in CVS mode?
I don't think so. Folks?
Anyhow, if there are different sets, I could do something like:
#define BADCHARS "\r\n\\"
#define BADCHARS_CSV "\r\n"
and then check for csv_mode, et
When setting the default client_encoding for another database the validity
of the conversion is checked using the current database's server encoding,
not the targets.
jurka=# create database utf8 with encoding='utf8';
CREATE DATABASE
jurka=# create database win1251 with encoding='win1251';
CR
Uh, couldn't the delimiter be a backslash in CVS mode?
+ #define BADCHARS "\r\n\\"
Also, should we disable DELIMITER and NULL from sharing characters?
---
David Fetter wrote:
> On Sun, Jan 29, 2006 at 10:20:47PM -0
Please report this to the ODBC users lists.
---
Doug Scott wrote:
>
> The following bug has been logged online:
>
> Bug reference: 2226
> Logged by: Doug Scott
> Email address: [EMAIL PROTECTED]
> Postgr
> Is ERRCODE_FEATURE_NOT_SUPPORTED the right errcode? This isn't a
> missing feature; we are performing a sanity check here. We can
> reasonably expect never to support CR, LF or \ as the text
> delimiter.
I guess that depends on whether we ever plan to allow people to set
the output record separ
You need to file jdbc reports on the jdbc users lists.
---
Bernhard Rosenkraenzer wrote:
>
> The following bug has been logged online:
>
> Bug reference: 2220
> Logged by: Bernhard Rosenkraenzer
> Email addre
[Please copy the mailing list on replies.]
On Tue, Jan 31, 2006 at 08:53:44AM +0100, Hnoch Herv wrote:
> Thank for you response I have never written this query : I think it
> is JDBC that have generated it ... My query (written by me) is :
>
>select id_caisse as caisse from FROM adm_pat
Hi,
philipp resiner wrote a mail about this problem yesterday. I've now traced it
down to something that looks like a bug in the
query planer to me. Please have a look at this and let me know if this is a bug
or I am compleatly wrong..
(this is done right after a complete ANALYZE over the datab
-- Weitergeleitete Nachricht --
Subject: Re: [BUGS] Endless loop in ExecNestLoop
Date: Dienstag, 31. Januar 2006 16:39
From: Tom Lane <[EMAIL PROTECTED]>
To: Philipp Reisner <[EMAIL PROTECTED]>
Cc: pgsql-bugs@postgresql.org
Philipp Reisner <[EMAIL PROTECTED]> writes:
> Well af
Philipp Reisner <[EMAIL PROTECTED]> writes:
> Well after more research it turned out that sometimes we have a plan
> that executes in less than 2 seconds, and somethimes we get a plan
> does not terminate within 1h30 of CPU time.
Could you send EXPLAIN ANALYZE output for this (at least for the f
"Patrick Rotsaert" <[EMAIL PROTECTED]> writes:
> At the time of the crash, the server logs:
> LOG: server process (PID 21815) was terminated by signal 9
You're running on a Linux machine with memory overcommit enabled.
Turn that off, or nothing will ever work very reliably --- the OOM
kille
The following bug has been logged online:
Bug reference: 2225
Logged by: Patrick Rotsaert
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.2
Operating system: Linux
Description:Backend crash -- BIG table
Details:
Situation:
-
Database with 1 table:
The following bug has been logged online:
Bug reference: 2226
Logged by: Doug Scott
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Windows XP Pro
Description:Can't delete elements from Enterprise Architect diagram
when using PostgreSQL ANSI
Hi,
On Monday 30 January 2006 17:42, Tom Lane wrote:
> > Version: 8.0.2
> I don't think so ... neither bitmap scans nor slot_getattr exist in 8.0.
oops. it is 8.1.2 ..
> Not a lot. You need to find out what the difference is between the
> cases where the query runs quickly and those where it do
> > The explain analyze output shows two levels of hash join underneath
> > four levels of nestloop join, whereas the stack trace looks like there
> > are five levels of nestloop and only one hash. So this is some evidence
> > that a different plan is being used in the slow cases. The stack trac
On Tue, Jan 31, 2006 at 12:31:24PM +0100, Peter Eisentraut wrote:
> According to this documentation
>
> http://www.postgresql.org/docs/8.1/static/ecpg-connect.html
>
> it should work to connect in ECPG like this:
>
> EXEC SQL CONNECT TO tcp:postgresql://bell.credativ.de:5432/pei AS myconn USER
According to this documentation
http://www.postgresql.org/docs/8.1/static/ecpg-connect.html
it should work to connect in ECPG like this:
EXEC SQL CONNECT TO tcp:postgresql://bell.credativ.de:5432/pei AS myconn USER
pei IDENTIFIED BY 'geheim';
(Or perhaps with single quotes, but that doesn't ma
Am Montag, 30. Januar 2006 17:42 schrieb Tom Lane:
> Philipp Reisner <[EMAIL PROTECTED]> writes:
> > Version: 8.0.2
>
> I don't think so ... neither bitmap scans nor slot_getattr exist in 8.0.
>
Sorry, a typo, 8.1.2 of course.
> > Is this bug-report of any use so far ?
>
> Not a lot. You need to
19 matches
Mail list logo
