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 synonyms for none.
3. keep
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 the
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)
is
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 will be
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 because
the
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 keywords are
(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 not sure any
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 a
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.
Right. The
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
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,
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,
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 through
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
17 matches
Mail list logo
