Neil Conway <[EMAIL PROTECTED]> writes:
> your handwaving has yet to convince me :)
Zing ;-)
I'm too tired to think about this more tonight, but it seems like
the basic point is that we can't just construct a list of pointers
into (a copy of) the original input string. A certain amount of
data c
Tom Lane wrote:
Sorry, s/downcased/downcased and null-terminated/. I have not read the
parsing code in question lately, but offhand it seems like transferring
one token at a time into a work buffer isn't a completely broken idea...
I wouldn't call it "broken", but I don't see how it could be done
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I believe that the reason for the local buffer is to hold a downcased
>> version of the input, which we can compare to the all-lower-case tables
>> of relevant keywords.
> Well, that's one of the reasons, but not the only one. For exampl
Tom Lane wrote:
I believe that the reason for the local buffer is to hold a downcased
version of the input, which we can compare to the all-lower-case tables
of relevant keywords.
Well, that's one of the reasons, but not the only one. For example, how
do you parse '17 minutes31 seconds'::interval
Neil Conway <[EMAIL PROTECTED]> writes:
>> Perhaps it would work to downcase just one token at a time, so that
>> the max buffer length equals the max acceptable token?
> Not sure I follow you.
I believe that the reason for the local buffer is to hold a downcased
version of the input, which we ca
Tom Lane wrote:
Well, if you allow for whitespace between tokens then it's immediately
clear that there is no fixed upper bound.
Good point -- there is no upper bound on the input string, but since we
skip whitespace, AFAICS this shouldn't affect the requirements for the
size of the working buffe
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There are a lot of fixed-size local buffers in that code. The ones
>> used in output routines seem defensible since the string to be generated
>> is predictable. The ones that are used for processing input are likely
>> wrong.
> I'm no
Alexander Volk wrote:
configure: WARNING: you should use --build, --host, --target
checking build system type... i386-portbld-freebsd5.4
checking host system type... i386-portbld-freebsd5.4
checking which template to use... freebsd
checking whether to build with 64-bit integer date/time support...
Tom Lane wrote:
There are a lot of fixed-size local buffers in that code. The ones
used in output routines seem defensible since the string to be generated
is predictable. The ones that are used for processing input are likely
wrong. OTOH I'm not eager to throw a palloc into each of those code
p
Gregory L Miller-Kramer <[EMAIL PROTECTED]> writes:
> I entered the statement you wanted. (show client_min_messages;) It
> returned...
> client_min_messages
> -
> log
> (1 row)
[ scratches head... ] It's pretty hard to see why SHOW would display
something but error messages
- Original Message -
From: "Alexander Volk" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 17, 2005 11:15 AM
Subject: Error when install
=== BACKUP YOUR DATA! =
As always, backup your data before
upgrading. If the upgrade leads to a higher
minor re
Thanks again for getting back to me.
I entered the statement you wanted. (show client_min_messages;) It returned...
client_min_messages
-
log
(1 row)
I did try what you mentioned (set client_min_messages to notice;) and it didn't work.
Any other recommendations? I do ap
On Wed, May 18, 2005 at 09:11:00AM -0400, Gregory L Miller-Kramer wrote:
>
> I entered the statement you wanted. (show client_min_messages;) It
> returned...
> client_min_messages
> -
> log
> (1 row)
>
> I did try what you mentioned (set client_min_messages to notice;) and it
13 matches
Mail list logo
