Andrew Dunstan wrote:
> >>Here are some options:
> >>
> >>1. change the type of "log_statement" option from boolean to string,
> >>with allowed values of "all, mod, ddl, none" with default "none".
> >>2. same as 1. but make boolean true values synonyms for "all" and
> >>boolean false values synon
Unless I'm missing something, this patch has the effect that with values
of "ddl" or "mod" for log_statement, a statement with a parse error
will not be logged, which was what I hoped to avoid.
cheers
andrew
Bruce Momjian wrote:
Andrew Dunstan wrote:
Here are some options:
1. change th
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> Another is that depending on where you put the renaming that this patch
>> removes without replacing :-(,
> I do not understand your point. It seems to me that the renaming is
> performed when a type name is expected? The "boolean" keyword (not token)
Kris Jurka wrote:
>
> COPY allows DELIMITER and NULL to be specified which don't allow the data
> to be copied back in properly. Using any delimiter that could be part of
> a backslash escape sequence (\n \0 \t) will break if any of the data has a
> character matching the delimiter because it wil
Where are we on this patch?
---
Magnus Hagander wrote:
> You need to make all variable access (including libpq, I think) in the
> handler threadsafe. The control handler will execute on a different
> thread from the main one
Andrew Dunstan wrote:
>
> Unless I'm missing something, this patch has the effect that with values
> of "ddl" or "mod" for log_statement, a statement with a parse error
> will not be logged, which was what I hoped to avoid.
Right. The query type can't be determined during a syntax error becau
Dear Tom,
> > I join a small proof-of-concept patch to drop some tokens out of the
> > parser.
>
> I believe these were treated this way *specifically* because of the
> keyword-is-not-an-identifier issue. SQL99 calls out most of these
> as being keywords:
Well, I think that the "reserved keywor
> >>(b) write a new "recursive descendant" parser, and drop "gram.y"
>
> er, that's "recursive descent" :-)
Sorry for my French version.
> Well, unless you are a serious masochist,
I'm not a masochist;-) I'm arguing about where hint should/could be put.
> In fact, considering this thread I'm n
On Mon, 05 Apr 2004 18:30:29 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
>> noise-contributing factors.
>
>I think it would have to be visibility-bit updates. Can you try it with
>a pre-vacuumed relation, so that there is no slowdown for updates?
I'd like to avoid VACUUM to keep the dead tuples.
Bruce Momjian wrote:
Andrew Dunstan wrote:
Unless I'm missing something, this patch has the effect that with values
of "ddl" or "mod" for log_statement, a statement with a parse error
will not be logged, which was what I hoped to avoid.
Right. The query type can't be determined during
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Unless I'm missing something, this patch has the effect that with values
of "ddl" or "mod" for log_statement, a statement with a parse error
will not be logged, which was what I hoped to avoid
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >Andrew Dunstan wrote:
> >
> >
> >>Unless I'm missing something, this patch has the effect that with values
> >>of "ddl" or "mod" for log_statement, a statement with a parse error
> >>will not be logged, which was what I hoped to avoid.
> >>
Andrew Dunstan wrote:
> >>However, I think with a little extra work it might be possible to have both.
> >>
> >>
> >
> >Right now, the way it is done, only a real syntax error skips logging.
> >If you referenced an invalid table or something, it does print the log
> >just before the invalid tab
Hello,
Please install attached translation updates.
This is for 7.5.
initdb to to about ~50%
the rest is complete
$ msgfmt -cv initdb-ru.po
37 translated messages, 35 untranslated messages.
$ msgfmt -cv pg_controldata-ru.po
41 translated messages.
$ msgfmt -cv pg_dump-ru.po
335 translated messag
Dear Tom,
> In particular you can't any longer tell the difference between BOOLEAN
> and "boolean" (with quotes), which are not the same thing --- a quoted
> string is never a keyword, per spec. [...]
Ok, so you mean that on -boolean- the lexer returns a BOOLEAN_P token, but
with -"boolean"- it
Bruce Momjian wrote:
Right now we have log_min_error_statement:
#log_min_error_statement = panic # Values in order of increasing severity:
# debug5, debug4, debug3, debug2, debug1,
# info, notice
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >Right now we have log_min_error_statement:
> >
> > #log_min_error_statement = panic # Values in order of increasing severity:
> > # debug5, debug4, debug3, debug2, debug1,
> >
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Right now we have log_min_error_statement:
#log_min_error_statement = panic # Values in order of increasing severity:
# debug5, debug4, debug3, debug2, debug1,
Pavel Stehule wrote:
> Hello
>
> I send my first patch for PostgreSQL - maybe ugly patch. This patch
> generate on top of dump file line with setting of current encoding. Its
> useful for languages like czech with more than one wide used encoding.
> We need informations about used encoding.
FY
Andrew Dunstan wrote:
> >>I think I'd prefer that to having it tied to the log_min_error_statement
> >>level. But I don't care that much.
> >>
> >>
> >
> >OK, at least we understand each other. Right now we don't have any
> >special "syntax error" log processing. We have errors logged throug
I have a database with about 250,000 entries in a table, PG 7.5, One
of the fields is text. LIKE queries on this field execute much faster
than the equivalent regex queries.
Is this what you would expect? Should I prefer LIKE to regex?
(I'm a regex fan, but the performance hit seems steep.)
Patch applied.
---
Bruce Momjian wrote:
> Andrew Dunstan wrote:
> > >>Here are some options:
> > >>
> > >>1. change the type of "log_statement" option from boolean to string,
> > >>with allowed values of "all, mod, ddl, non
22 matches
Mail list logo
