Folks. start sending in those plaform reports, OS name and version
number please.
DOESN'T WORK on Digital Unix/Tru64 4.0g, with both cc or gcc compiler.
Using Compaq C V6.4-216 (dtk) on Digital UNIX V4.0G (Rev. 1530)
Compiler Driver V6.4-013 (dtk) cc Driver:
make[3]: Entering directory
Constraints also run as the user modifying a table instead of the table
owner.
Again I don't see a good reason to want to execute constraints as the
user modifying a table. But I do think there can be reasons to want to
execute them as the table owner.
To summarize, my suggestion for change is:
On Thu, 2002-10-31 at 09:54, Bruno Wolff III wrote:
Constraints also run as the user modifying a table instead of the table
owner.
Again I don't see a good reason to want to execute constraints as the
user modifying a table. But I do think there can be reasons to want to
execute them as the
On Thu, Oct 31, 2002 at 10:17:26 -0500,
Rod Taylor [EMAIL PROTECTED] wrote:
Can't necessarily run them as the table owner, as it may give
information to other users with the ability to ALTER that table.
You have to be the table owner to alter a table. So it should be OK
to have the default
I've built and run the regression tests on PostgreSQL7.3 beta 2 on
SGI Irix and found the following suspicious compiler error message:
gmake[4]: Entering directory `/pg/postgresql-7.3b2/src/backend/utils/hash'
cc -64 -g -woff 1164,1171,1185,1195,1552 -I../../../../src/include
On Thu, 2002-10-31 at 10:33, Bruno Wolff III wrote:
On Thu, Oct 31, 2002 at 10:17:26 -0500,
Rod Taylor [EMAIL PROTECTED] wrote:
Can't necessarily run them as the table owner, as it may give
information to other users with the ability to ALTER that table.
You have to be the table owner
On Thu, 31 Oct 2002, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Ok, fair enough -- I agree that we should treat the two cases
differently. But one thing I think we should do in any case is improve
the wording of the error message.
Got a suggestion?
Change:
I am thinking it would be useful for debugging if elog(PANIC) were to
exit by calling abort() so that a core dump would be produced.
Going out via proc_exit(), as it now does, seems like a bad idea in any
case, since that will try to do a bunch of cleanup activity that's
probably inappropriate
Alessio Bragadini [EMAIL PROTECTED] writes:
Folks. start sending in those plaform reports, OS name and version
number please.
DOESN'T WORK on Digital Unix/Tru64 4.0g, with both cc or gcc compiler.
Evidently main.c needs #include errno.h added. Please add that and
see if you get any further.
Robert E. Bruccoleri [EMAIL PROTECTED] writes:
gmake[4]: Entering directory `/pg/postgresql-7.3b2/src/backend/utils/hash'
cc -64 -g -woff 1164,1171,1185,1195,1552 -I../../../../src/include
-I/stf/sys64/include -I/stf/sys64/include/readline -U_NO_XOPEN4 -c dynahash.c -o
dynahash.o
cc-1184 cc:
On Thu, Oct 31, 2002 at 11:15:31 -0500,
Rod Taylor [EMAIL PROTECTED] wrote:
Yes, default expressions and check constraints could possibly. However,
both revoke complex expressions (no sub-selects, etc) so there is little
point.
I disagree. They can call functions which can do unexpected
Tom Lane wrote:
Barry Lind [EMAIL PROTECTED] writes:
In either case I am concerned about licensing issues. gcj is not under
a BSD style license. Depending on what you need you are either dealing
with regular GPL, LGPL, or LGPL with a special java exception.
I beleive (without giving it
Found another:
ERROR: cannot find attribute 2 of relation pg_temp_12100_0
On Thu, 2002-10-31 at 11:33, scott.marlowe wrote:
On Thu, 31 Oct 2002, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Ok, fair enough -- I agree that we should treat the two cases
differently. But one
Rod Taylor [EMAIL PROTECTED] writes:
Found another:
ERROR: cannot find attribute 2 of relation pg_temp_12100_0
Can you reproduce that?
It could be that this just represents someone's temp table deletion
committing while VACUUM is partway through trying to build a relcache
entry to open the
Dear Tom,
Robert E. Bruccoleri [EMAIL PROTECTED] writes:
gmake[4]: Entering directory `/pg/postgresql-7.3b2/src/backend/utils/hash'
cc -64 -g -woff 1164,1171,1185,1195,1552 -I../../../../src/include
-I/stf/sys64/include -I/stf/sys64/include/readline -U_NO_XOPEN4 -c dynahash.c -o
On Thu, 2002-10-31 at 13:03, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
Found another:
ERROR: cannot find attribute 2 of relation pg_temp_12100_0
Can you reproduce that?
It could be that this just represents someone's temp table deletion
committing while VACUUM is partway
Robert E. Bruccoleri [EMAIL PROTECTED] writes:
No, the code is correct, although no doubt too clever by half :-(
How can it be correct? If the assertion checking is turned off, then
saveState.currBucket will not be changed, but if assertion checking is
on, it will be set to NULL. The only way
On Thu, Oct 31, 2002 at 12:58:21 -0500,
Tom Lane [EMAIL PROTECTED] wrote:
But I think an EXTRA_DIGITS setting might be interesting. In
particular, suppose we allowed EXTRA_DIGITS to be negative? Setting
it to -1 or -2 would go a long way towards eliminating our problems
with platform
Hi guys,
Just got back from my European vacation - 7.3 still not out? :)
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
I said:
Peter Bierman [EMAIL PROTECTED] writes:
Perhaps the change from gcc2.x to 3.x changed floats a bit?
Could be. We had previous reports of the same diff on OSX 10.2 with
a G4 processor, so I was wondering if it was hardware or software
differences (geometry-powerpc-darwin.out matches
I found a message I've never seen before in VACUUM, its:
NOTICE: Too old parent tuple found - can't continue repair_frag
The version is Postgresql 7.2.1.
The problem occurs in vacuum.c, around line 1700, but the interesting part is the
comment around:
/*
* Read above about cases when
*
Just one more note,
Maybe it makes sense that in the proposal below the parameter
EXTRA_DIGITS could be SIGNIFICANT_DIGITS with a default value of 15 and
maximum 18.
Its more 'documentable' and maybe easy to understand in general.
Pedro M. Ferreira wrote:
Yes. I think there are several
Maybe it makes sense that in the proposal below the parameter
EXTRA_DIGITS could be SIGNIFICANT_DIGITS with a default value
of 15 and maximum 18.
Its more 'documentable' and maybe easy to understand in general.
Yes agree (or double_significant_digits or format_double_digits ?),
but
Zeugswetter Andreas SB SD wrote:
Yes agree (or double_significant_digits or format_double_digits ?),
but default to DBL_DIG and allow range between 1 and DBL_DIG + 3.
format_* could be used for all future output format tweaks.
Unfortunately %A is not portable :-(
What do you mean ?
It is C99,
Stephan Szabo [EMAIL PROTECTED] writes:
On Wed, 30 Oct 2002, Tom Lane wrote:
sprintf(ascii, %.*g, DBL_DIG+1, num);
and similarly for float4. Given carefully written float I/O routines,
reading the latter output should reproduce the originally stored value.
Well, on my system, it doesn't
Pedro M. Ferreira [EMAIL PROTECTED] writes:
Zeugswetter Andreas SB SD wrote:
Unfortunately %A is not portable :-(
What do you mean ?
Just what he said.
It is C99, introduced in glibc 2.1.
What are the requirements for PostgreSQL ?
glibc does not define the universe; nor are all platforms
Pedro M. Ferreira [EMAIL PROTECTED] writes:
Its like I said before, the guys from matlab (in x86 IEEE float) go to
DBL_BIG+3 to have 'maximum precision'.
Apparently they have not read the canonical papers in the field.
[ googles for a moment... ] See
How to read floating point numbers
Tom Lane wrote:
I was misremembering these papers to claim DBL_DIG+1 is enough, but
actually they prove that DBL_DIG+2 is necessary and sufficient (and
give code to do it correctly, too).
Yeahh! If there's a proof its safe to implement.
I also Googled a bit and found another paper saying that
Pedro M. Ferreira [EMAIL PROTECTED] writes:
Have two parameters, say DOUBLE_OUTPUT and EXTRA_DIGITS. DOUBLE_OUTPUT
would select from decimal output or normalized output. EXTRA_DIGITS
would add the required extra digits, from 0 (default) to 3, when output
is decimal.
I'm not happy with
Tom Lane wrote:
Bottom line: if DBL_DIG=15 and the float arithmetic is binary, then
there are some double values that require 17 displayed digits to
distinguish, even though not all 16-digit numbers are distinct.
So I retract my original proposal and instead suggest that we offer
a switch to
I sent an email before receiving the one below. I am happier also with
the extra_digits way (from the previous email I thought the options were
DBL_DIG or DBL_DIG+2).
I'm not happy with adding the hex-output option, since it's not
very portable and doesn't seem necessary to solve the problem
What version of postgres are you using? I am using PostgreSQL 7.3b1 on
i686-pc-linux-gnu, compiled by GCC 2.96 and when I execute the following
statement:
select '{124,567,66}'::int[] + 345;
I get the error:
ERROR: cache lookup failed for type 0
Any ideas?
Thanks for your help!
-r
Peter Eisentraut [EMAIL PROTECTED] writes:
The proposed fix was to include the flex output in some other file (such
as the corresponding grammar file) rather than to compile it separately.
Seems like a reasonable solution. Can you make that happen in the next
day or two? If not, I'll take a
Christopher Kings-Lynne wrote:
Hi guys,
Just got back from my European vacation - 7.3 still not out? :)
Nope, we think maybe RC1 tomorrow. I was busy the past two days and am
catching up on email just now.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL
Seems like someone ought to issue a call for port reports. The
supported platforms list hasn't been touched ...
Good point. Thomas, can you take that on?
No, at least not now. I'm not able to communicate reliably with the
mailing lists, and so can not coordinate anything :( Not
35 matches
Mail list logo
