Tomas Szepe <[EMAIL PROTECTED]> writes:
>> According to the CVS logs, this was reverted in beta4 --- you sure you
>> are testing the right beta?
> Yes, I'm 100% positive I'm running 8.3beta4.
[ pokes at it ... ] Drat, I missed the corner case where the field
delimiter is a control character ---
> > for a very long time now, pg_dump has placed '\t' on output where a literal
> > tab was present in the data.
> > Since 8.3pre, this is no longer the case -- the backslash is followed
> > by an actual tab character, ('\009').
>
> According to the CVS logs, this was reverted in beta4 --- you sur
Tomas Szepe <[EMAIL PROTECTED]> writes:
> for a very long time now, pg_dump has placed '\t' on output where a literal
> tab was present in the data.
> Since 8.3pre, this is no longer the case -- the backslash is followed
> by an actual tab character, ('\009').
According to the CVS logs, this was r
Hi,
for a very long time now, pg_dump has placed '\t' on output where a literal
tab was present in the data.
Since 8.3pre, this is no longer the case -- the backslash is followed
by an actual tab character, ('\009').
I'm not sure if this change was intentional, but I didn't see it mentioned
in t
I wrote:
> The whole idea sounds pretty shaky to me, and definitely not
> something to change in late beta. LOG we could do now without
> risking breaking anything.
Poking around a bit more, I notice that there are already some places
that do it the way I was thinking of, eg in commands/variable.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There is some good reason, which I don't recall at the moment, why
>> assign-hooks (and most of the rest of GUC) shouldn't FATAL in the
>> middle of processing a config file.
> I'm thinking of keeping the ERROR, which (I think) would
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> There are a bunch of other GUC assign hooks that behave similarly.
> >> Perhaps it'd be sensible to emit these complaints as LOG messages
> >> when we're dealing with a noninteractive source (ie, the config file)?
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There are a bunch of other GUC assign hooks that behave similarly.
>> Perhaps it'd be sensible to emit these complaints as LOG messages
>> when we're dealing with a noninteractive source (ie, the config file)?
> I was wondering whethe
Tom Lane wrote:
> Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <[EMAIL PROTECTED]> writes:
> > or can we please improve the error message here -- or is it a bug?
>
> It's not a bug. However, the specific error message only comes out in
> interactive-SET cases:
>
> if (source >= PGC_S_INTERACTIVE)
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <[EMAIL PROTECTED]> writes:
> I'm getting this error when I set lot_statement_stats to on :
> FATAL: invalid value for parameter "log_statement_stats": 1
> Per Alexey (and Alvaro), both log_planner_stats and log_statement_stats
> cannot be turned on at the same t
Hi,
I'm getting this error when I set lot_statement_stats to on :
FATAL: invalid value for parameter "log_statement_stats": 1
and server does not start. This is "almost" default configuration file
(8.2.5, Fedora 8, running on my laptop):
http://www.gunduz.org/tmp/postgresql.conf
Per Alexey (a
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> And i don't know why but there are dumplicate schemas:
Duplicate pg_shadow rows for user postgres, most likely. When did
you last vacuum pg_shadow?
regards, tom lane
---(end of broadcast)--
Hello.
Can you help me? i don't know what to do with this message:
**
# pg_dump -U postgres catalog
Password:
pg_dump: query to obtain list of schemas failed: ERROR: more than one
row returned by a subq
The following bug has been logged online:
Bug reference: 3839
Logged by: Bronnikov Vladimir
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Windows 2000 SP4
Description:LDAP authentification and password with "space"-symbol
Details:
I se
The following bug has been logged online:
Bug reference: 3840
Logged by: Andrey
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Linux Ubuntu 7.04
Description:Termination of postgresql/
Details:
When I try to execute query like
SELECT * FRO
I set up my PostgreeSQL server to authenticate with LDAP. But when I connect to
my application with password containing "space" symbol, I receive following
error message: "LDAP authentication failed for user...". Other users (with
password not containg "spaces") login successfull.
--
С уважение
16 matches
Mail list logo
