Bruce Momjian wrote:
I trimmed it down to:
--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
--with-prefer-libedit prefer libedit over readline
--without-readline do not use Readline
--without-zlib do not use Zlib
On Thu, 2005-12-01 at 23:34 -0500, Bruce Momjian wrote:
Where are we on this patch? It is ready for the patch queue?
It's good to be applied, AFAIK.
Simon Riggs wrote:
As previously agreed, reviewing this is a 2 stage process:
1. review/possibly agree OK to commit
2. check with
On 12/1/05, Bruce Momjian pgman@candle.pha.pa.us wrote:
Where are we on this patch? Is it to be applied?
After Tom's advice (he was doubtful about the patch), while I was
thinking about how to improve the spectrum of tests, decided to use
src/test/mb. In the tests, patch just succeded for
Bruce Momjian writes:
Where are we on this patch? Was it submitted? Applied? Just an
idea?
| This has been saved for the 8.2 release:
|
| http://momjian.postgresql.org/cgi-bin/pgpatches_hold
I tested it with 8.1RC1 and noticed the inconsistency with the \edit
command. I guess one
Peter Eisentraut [EMAIL PROTECTED] writes:
I'm concerned that this still gives nondeterministic behavior. There's
no way to say, I want readline, period or I want libedit, period.
I'd prefer simple --with-readline and --with-libedit, giving one turns
off the other, giving both is an
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I trimmed it down to:
--with-prefer-libedit prefer libedit over readline
OK, I can live with that.
I think it's ugly. Can't we just say --prefer-libedit ?
If must be a --with-foo flag,
http://projects.commandprompt.com/projects/public/pgsql/browser/trunk/pgsql
It has the additional advantage over our current CVSweb that it's
set with tabs to 4 spaces, so it looks just like our code is
supposed to ...
I need to spend some time on it to see if there is a way that
Simon Riggs wrote:
Now we're into 8.2devel mode, its time to submit the previously
discussed patch that:
- reduces Numeric storage format by 2 bytes
- limits scale to +/- 508 decimal places
This is sufficient to allow Numeric to continue to be used as the
default numeric representation
[EMAIL PROTECTED] (Tom Lane) writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
I'm concerned that this still gives nondeterministic behavior.
There's no way to say, I want readline, period or I want
libedit, period. I'd prefer simple --with-readline and
--with-libedit, giving one turns off
Bruce Momjian wrote:
OK, seems all objections have been dealt with so it goes into the patch
queue. I will ask on 'general'.
The only downside I see is that I can't impress people by doing:
SELECT factorial(4000);
I don't suppose the _impression_ factor is worth two bytes per
Volkan YAZICI wrote:
On 12/1/05, Bruce Momjian pgman@candle.pha.pa.us wrote:
Where are we on this patch? Is it to be applied?
After Tom's advice (he was doubtful about the patch), while I was
thinking about how to improve the spectrum of tests, decided to use
src/test/mb. In the tests,
Chris Browne [EMAIL PROTECTED] writes:
To my mind, giving BIG weight to the opinions of the relatively small
set of individuals that manage PostgreSQL packages for the popular
distributions of Linux and *BSD seems fairly appropriate.
The packagers are bright enough to adapt to whatever we do
Bruce Momjian pgman@candle.pha.pa.us writes:
So we are really decreasing the specified precision from 1000 to 508,
and the computational precision from 4096 to 508.
The internal computational precision isn't any less, the limit is only
on the result of a function (ie, partial results within one
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
So we are really decreasing the specified precision from 1000 to 508,
and the computational precision from 4096 to 508.
The internal computational precision isn't any less, the limit is only
on the result of a function (ie,
unsuscribe
pgsql-patches
Julio
César Elizondo GTI- Adm. Base Datos y SAP
Distribuidora de Gas Cuyana S.A.Distribuidora de Gas Del Centro
S.A. [EMAIL PROTECTED]
Bruce Momjian pgman@candle.pha.pa.us writes:
I am confused by your use of the term dynamic range. From what you
say above that we are just moving from 1000 to 508 for storage, and that
computational range would still be 4096?
No, computational range would still be on the order of 10^16G ...
Bruce Momjian pgman@candle.pha.pa.us writes:
The basic problem is that with two deterministic flags the default
values for those flags are unclear.
That's a really good point ... the only explainable default would be
that both are --without, which is a crummy default.
I think the way that
Andrew Dunstan wrote:
I trimmed it down to:
--with-prefer-libedit prefer libedit over readline
I think it's ugly. Can't we just say --prefer-libedit ?
If must be a --with-foo flag, maybe --with-libedit-preferred or
--with-libedit-first would be better.
OK, changed:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
The basic problem is that with two deterministic flags the default
values for those flags are unclear.
That's a really good point ... the only explainable default would be
that both are --without, which is a crummy default.
I
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
--with-libedit-preferred prefer libedit over readline
--without-readline do not use Readline
Possibly
--without-readline do not use readline or libedit
In any case please be consistent about the
Bruce Momjian pgman@candle.pha.pa.us writes:
Sorry, I am confused. If our computational range is that high, why does
SELECT factorial(4000) and SELECT factorial(6000) produce the same
number of digits on my screen.
Are you counting correctly?
regression=# select log(factorial(4000));
OK, updated text:
--with-openssl build with OpenSSL support
--with-libedit-preferred prefer Libedit over Libreadline
--without-readline do not use Libreadline/Libedit line editing
--without-zlib do not use Zlib
This all seems kind of extra... Why not just:
Uh, I tried factorial(4000) and for display I got:
Bruce Momjian pgman@candle.pha.pa.us writes:
Both are 4096 characters.
You forgot the part that scrolled off the screen. Or else your
installation is broken.
I get this for factorial(4000)
Bruce Momjian wrote:
I tried your \g test and the file size difference is the length of the
dashed line in the file, not the number of digits display, which are
both 4096. One has 12550 dashes, the other 19950 dashes.
So this is a psql bug? I can count the correct number of chars with
SPI:
Last minute edit:
src/test/mb seems a little bit old. I've tested SQL files in
src/test/mb/sql with the expected results in src/test/mb/expected
manually and it worked. (Output files need a little bit editing, like
removing lines similar to CREATE TABLE.) But it'll be better if any
EUC users will
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
So this is a psql bug?
Not here. Do you see it?
Actually, no. If I cut'n paste the number from psql to
cat foo
shift insert
then only 4096 chars are copied. (Amusingly, I can't add a newline to
^D and close the file. I must
Please try Tom's \g test:
test= select factorial(4000)
test- \g /tmp/x
test= \q
$ wc -c /tmp/x
20881 /tmp/x
Do you see a number greater than 20881, something like 3?
Alvaro Herrera [EMAIL PROTECTED] writes:
Actually, no. If I cut'n paste the number from psql to
cat foo
shift insert
then only 4096 chars are copied. (Amusingly, I can't add a newline to
^D and close the file. I must delete one char to do that.)
Hmm, cut buffer limitation in X or
Joshua D. Drake wrote:
OK, updated text:
--with-openssl build with OpenSSL support
--with-libedit-preferred prefer Libedit over Libreadline
--without-readline do not use Libreadline/Libedit line editing
--without-zlib do not use Zlib
This all seems
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Actually, no. If I cut'n paste the number from psql to
cat foo
shift insert
then only 4096 chars are copied. (Amusingly, I can't add a newline to
^D and close the file. I must delete one char to do that.)
Hmm, cut buffer
On Fri, 2005-12-02 at 15:12 -0500, Bruce Momjian wrote:
Joshua D. Drake wrote:
OK, updated text:
--with-openssl build with OpenSSL support
--with-libedit-preferred prefer Libedit over Libreadline
--without-readline do not use Libreadline/Libedit line
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Actually, no. If I cut'n paste the number from psql to
cat foo
shift insert
then only 4096 chars are copied. (Amusingly, I can't add a newline to
^D and close the file. I must delete one char to do
Bruce Momjian pgman@candle.pha.pa.us writes:
I just tested from a standalone backend:
backend select pow(10::numeric, 131071) + 1
and got 4095 zeros and no trailing '1' (wrong), so it isn't psql, it
must be something in the backend.
If the backend is truncating the result length, I
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I just tested from a standalone backend:
backend select pow(10::numeric, 131071) + 1
and got 4095 zeros and no trailing '1' (wrong), so it isn't psql, it
must be something in the backend.
If the backend is truncating the
On Fri, 2005-12-02 at 14:09 -0500, Bruce Momjian wrote:
I ran your SELECT pow(10::numeric, 131071), and gain, 4096 0's are
displayed on my screen. SELECT pow(10::numeric, 7000) and SELECT
pow(10::numeric, 1) generate identical displays on my screen.
Are you saying there is a bug with or
Simon Riggs wrote:
On Fri, 2005-12-02 at 14:09 -0500, Bruce Momjian wrote:
I ran your SELECT pow(10::numeric, 131071), and gain, 4096 0's are
displayed on my screen. SELECT pow(10::numeric, 7000) and SELECT
pow(10::numeric, 1) generate identical displays on my screen.
Are you
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
If that gives the right answer then the NUMERIC code is off the hook,
and what you've got is a strange limitation on output column length.
test= select length((pow(10::numeric, 131071))::text);
length
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
If that gives the right answer then the NUMERIC code is off the hook,
and what you've got is a strange limitation on output column length.
test= select length((pow(10::numeric, 131071))::text);
Bruce Momjian pgman@candle.pha.pa.us writes:
Wow, check this out:
test= SELECT CAST (pow(10::numeric, 1) + 1 AS TEXT)
It works fine! I have all the digits, and the trailing 1.0:
01.
while SELECT pow(10::numeric, 1) fails.
That's just about as wacky as
On Fri, Dec 02, 2005 at 04:30:54PM -0500, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Wow, check this out:
test= SELECT CAST (pow(10::numeric, 1) + 1 AS TEXT)
It works fine! I have all the digits, and the trailing 1.0:
01.
while SELECT
Michael Fuhr wrote:
On Fri, Dec 02, 2005 at 04:30:54PM -0500, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Wow, check this out:
test= SELECT CAST (pow(10::numeric, 1) + 1 AS TEXT)
It works fine! I have all the digits, and the trailing 1.0:
Attached is a proposed patch for bug #2085. It's pretty grotty because
it introduces a new TOC tag type into the pg_dump format, which makes it
incompatible with existing pg_restores; so I think we probably couldn't
back-patch this, it'd have to be treated as a new feature for 8.2.
I don't see
Bruce Momjian pgman@candle.pha.pa.us writes:
I found the cause. I traced into printf then realized I was not in libc
but port/snprintf.c, and I see 4096 defined for those buffers.
Uh, how is control getting to snprintf? I don't see that used either
in numeric.c or in printtup.c.
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I found the cause. I traced into printf then realized I was not in libc
but port/snprintf.c, and I see 4096 defined for those buffers.
Uh, how is control getting to snprintf? I don't see that used either
in numeric.c or in
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Uh, how is control getting to snprintf? I don't see that used either
in numeric.c or in printtup.c.
I am seeing it in the standalone backend here:
debugtup (slot=0x856e0b0, self=0x84306d0) at printtup.c:548
548
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Uh, how is control getting to snprintf? I don't see that used either
in numeric.c or in printtup.c.
I am seeing it in the standalone backend here:
debugtup (slot=0x856e0b0, self=0x84306d0) at
Bruce Momjian wrote:
If you run the query that fails in a standalone backend, do you get
something like (typeid = 1700, len = -1, typmod = -1, byval = f)
at the end of the line, or is that part truncated too?
I found the cause. I traced into printf then realized I was not in libc
but
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
That would only affect a standalone backend, however, not normal
operation.
Ah, psql itself is using the same buggy snprintf.c.
Doh. OK, we gotta fix it then. But what are you going to do when you
can't malloc enough memory? You
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
That would only affect a standalone backend, however, not normal
operation.
Ah, psql itself is using the same buggy snprintf.c.
Doh. OK, we gotta fix it then. But what are you going to do when you
can't
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Doh. OK, we gotta fix it then. But what are you going to do when you
can't malloc enough memory? You can't ereport in a client environment,
and there's no API for printf to report failure.
Yep, I am digging through snprintf.c
Alvaro Herrera [EMAIL PROTECTED] writes:
So this is a psql bug?
Not here. Do you see it?
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Bruce Momjian pgman@candle.pha.pa.us writes:
Yep, I am digging through snprintf.c now to try find a solution.
The cleanest solution is probably to fix things so that dopr_outch is
aware of whether it's working for sprintf or fprintf, and can dump the
buffer directly to the file when it gets full
Thanks for comments. I modified the patch.Tom Lane wrote: Atsushi Ogawa [EMAIL PROTECTED] writes: (2)About processing when column identifier of SET clause is specified
like 'AAA.BBB'. 'AAA' is a composite column now. When an alias for target table is supported, 'AAA' is a composite column or a
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Yep, I am digging through snprintf.c now to try find a solution.
The cleanest solution is probably to fix things so that dopr_outch is
aware of whether it's working for sprintf or fprintf, and can dump the
buffer directly to the
This is half of an item in TODO list. I patch this because now pgbench is
threaded in Win32, so it is better to check thread safety of libpq.dll.
Patch ecpg could be done in a similar way, but I am not sure how we will
use this function there ...
Regards,
Qingqing
---
Index: fe-connect.c
Qingqing Zhou [EMAIL PROTECTED] writes:
This is half of an item in TODO list. I patch this because now pgbench is
threaded in Win32, so it is better to check thread safety of libpq.dll.
ISTM this was proposed once before, and rejected on the grounds that
no one could present a convincing use
Tom Lane [EMAIL PROTECTED] wrote
Is there a point in checking the thread-safety of
libpq when you can't check the thread-safety of libc?
Exactly :-(
Regards,
Qingqing
---(end of broadcast)---
TIP 5: don't forget to increase your free space
58 matches
Mail list logo
