Peter Eisentraut [EMAIL PROTECTED] writes:
Mark Butler writes:
Thanks. I didn't realize the need to move the DOUBLE token from the TokenId to
the ColId production. Will this patch be integrated into the head branch?
Not sure. It's not a standard type, but at least two other RDBMS have it
Mark Butler [EMAIL PROTECTED] writes:
I noticed the storage format for the numeric type is rather inefficient:
...
A zero value uses two bytes total in Oracle, where in the current version of
PostgreSQL it uses ten bytes.
Yawn ... given row overhead, alignment padding, etc, this is not
Tom Lane wrote:
Yawn ... given row overhead, alignment padding, etc, this is not nearly
as big a deal as you make it ...
For a table with ten decimal columns with an average of 5 significant digits
apiece, each row could be reduced from ~170 bytes to about ~90 bytes, which
could be rather
Tom Lane wrote:
Mark Butler [EMAIL PROTECTED] writes:
Surely if we have an write exclusive table lock we can rewrite tuples
in place rather than creating new versions with its corresponding 2x
space requirement.
Nyet. Consider transaction rollback.
Well, the first thing to consider
[EMAIL PROTECTED] (Nathan Myers) writes:
Yacc and yacc-like programs are most useful when the target grammar (or
your understanding of it) is not very stable. With Yacc you can make
sweeping changes much more easily; big changes can be a lot of work in
a hand-coded parser.
And, in fact,
= create view testview as select relname, 'Constant'::text from pg_class;
= \d testview
View "testview"
Attribute | Type | Modifier
---+--+--
relname | name |
?column? | text |
View definition: SELECT DISTINCT pg_class.relname, 'Constant'::text FROM
pg_class
Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's
patch should be applied?
I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD
seems to insist on calling every Intel processor a "i386". In this case,
are you suggesting that this patch covers all
Mark Butler [EMAIL PROTECTED] writes:
By the way, is alignment padding really a good use of disk space? Surely
storage efficiency trumps minor CPU overhead in any I/O bound database.
Weren't you just complaining about excess palloc's ;-) ? Seriously,
I have no idea about the costs/benefits
Nat Irons [EMAIL PROTECTED] writes:
Regression tests for Yellow Dog Linux (PPC RedHat derivative) failed all
over the place with 7.0.3. Passed smoothly with 7.1RC3, though.
Unsurprising if you compiled with any optimization level higher than -O0.
regards, tom lane
Bruce Momjian [EMAIL PROTECTED] writes:
I can imagine some people wanting this. However, 7.1 has new deadlock
detection code, so I would you make a 7.1 version and send it over. We
can get it into 7.2.
I object strongly to any such "feature" in the low-level form that
Henryk proposes,
Peter Eisentraut [EMAIL PROTECTED] writes:
Btw., it would really seem like a neat feature if a given pg_dump suite
would also handle the respective previous version. Otherwise we're in a
situation like now where we've got a shiny new pg_dump but people that
want to upgrade are still stuck
On Fri, Apr 13, 2001 at 01:25:45PM +, Thomas Lockhart wrote:
Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's
patch should be applied?
I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD
seems to insist on calling every Intel processor a
I was thinking SET because UPDATE does an auto-lock.
Bruce Momjian [EMAIL PROTECTED] writes:
I can imagine some people wanting this. However, 7.1 has new deadlock
detection code, so I would you make a 7.1 version and send it over. We
can get it into 7.2.
I object strongly to any
Bruce Momjian [EMAIL PROTECTED] writes:
I was thinking SET because UPDATE does an auto-lock.
Not to mention a ton of implicit locks acquired on various system tables
during parsing/planning. You really want auto timeout on all of those?
I sure don't.
The appropriate way to do this given a
On Fri, Apr 13, 2001 at 01:16:43AM -0400, Tom Lane wrote:
[EMAIL PROTECTED] (Nathan Myers) writes:
We have noticed here also that object (e.g. table) names get truncated
in some places and not others. If you create a table with a long name,
PG truncates the name and creates a table with
Pascal Scheffers [EMAIL PROTECTED] writes:
Some five functions are used in views before their definitions. In the
original (7.0) dump they were in the correct order, but rc2/4 (the only
ones I tried) got it wrong. The original OIDs for the
functions in the 7.1 dump are lower than those of the
[EMAIL PROTECTED] (Nathan Myers) writes:
Sorry, false alarm. When I got the test case, it turned out to
be the more familiar problem:
create table foo_..._bar1 (id1 ...);
[notice, "foo_..._bar1" truncated to "foo_..._bar"]
create table foo_..._bar (id2 ...);
[error,
On Fri, Apr 13, 2001 at 02:54:47PM -0400, Tom Lane wrote:
[EMAIL PROTECTED] (Nathan Myers) writes:
Sorry, false alarm. When I got the test case, it turned out to
be the more familiar problem:
create table foo_..._bar1 (id1 ...);
[notice, "foo_..._bar1" truncated to
Tom,
dump), anyone interested may have them for testing.
Please. Philip Warner would likely want to see them too.
I don't have his email address... but I am quite willing to send it.
Pascal.
---(end of broadcast)---
TIP 4: Don't 'kill
Hi all,
I've read pg_dump threads with great interest as I plan to upgrade from
703 to 71 on next monday if 71 final is out.
Although I did'nt have any of the ploblems listed in threads durin my
tests from 7.0.3 to 7.1betas and 7.1RCs.
I have noticed that pg_dump and pg_dumpall could'nt
On Fri, 13 Apr 2001, Tom Lane wrote:
Obviously, these objections are not strong enough to keep us from
increasing the standard value of NAMEDATALEN if it seems that many
people are running into the limit. But AFAICT relatively few people
have such problems, and I'm hesitant to make everyone
Olivier PRENANT [EMAIL PROTECTED] writes:
I have noticed that pg_dump and pg_dumpall could'nt generate correctly
CREATE FUNCTION when function has been created using the form
CREATE FUNCTION foo(x) RETURNS type AS '/foo.so','foo2' LANGUAGE C;
pg_dumps "forgets" the 'foo2' part: that
[EMAIL PROTECTED] (Nathan Myers) writes:
On Fri, Apr 13, 2001 at 04:27:15PM -0400, Tom Lane wrote:
Have you thought about simply increasing NAMEDATALEN in your
installation? If you really are generating names that aren't unique
in 31 characters, that seems like the way to go ...
We
Well folks, I just fixed the CVS tags (renamed REL7_1 to REL7_1_BETA and
moved REL7_1 to today) and packaged up the release ... this is it, any new
fixes go into v7.1.1 ... :)
I'm preparing a formal PR/Announce, and will send that out later on this
evening, but want to give some of the mirror
hello everybody,
Can you help me?
I have POSTGRESQL 7.0.3,
I try to create simple view by typing.
create view "xx" as select "aa.yy", "bb.yy" from "yy" order by "bb.yy"
the problem is that parameter order is not implemented with create view.
so how can I create such simple query??
Best
The Hermit Hacker [EMAIL PROTECTED] writes:
Here is what we've always sent to to date ... anyone have any good ones
to add?
Addresses : [EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
Hello, everybody
I have a new question to you. ;-)))
1. I wrote a database in access an I put there some Polish words like ±¶¿¼.
2. Migrate the base using PGADMIN to Postgresql.0.3 on Solaris 8.
3. What can I do to see that Polish words.
Maybe set a codepage or any standard.
I need help
debian unstable, i386.
upgrade libreadline 4.2
postgres doesn't compile.
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../src/interfaces/libpq -I../../../src/include -c -o tab-complete.o
tab-complete.c
tab-complete.c: In function `initialize_readline':
tab-complete.c:103:
Hi Lamar. What are the plans for RPMs? Do we have an "integrated RPM"
which will work with Mandrake, or should I keep carrying along my
patches to make the spec file work for now?
How are you planning on packaging the hardcopy docs? They are not yet
available, but will be Real Soon Now :(
On Fri, 13 Apr 2001, Bruce Momjian wrote:
Here is what we've always sent to to date ... anyone have any good ones
to add?
Addresses : [EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
On Wed, Apr 11, 2001 at 02:57:16AM +, Thomas Lockhart wrote:
Alright man, you've got me confused. Are you saying that despite the
existance of INT8 as a column type, and PreparedStatement.setLong(), that
these ought not be used? If so, there is a really big warning missing
from the
Mark Butler wrote:
I did several tests with functions designed to sum the number 12345 a million
times. The results are as follows (Pentium II 450, Redhat 6.2):
Postgres PL/PGSQL original numeric:14.8 seconds
Postgres PL/PGSQL modified numeric:11.0 seconds
Postgres PL/PGSQL
email added, thanks ...
On 13 Apr 2001, Matthew Rice wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Here is what we've always sent to to date ... anyone have any good ones
to add?
I think that this is still the moderator's address for comp.os.linux.announce:
[EMAIL
Freshmeat updated, Linuxtoday bookmarked ... thanks ;)
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Here is what we've
On Fri, Apr 13, 2001 at 06:32:26PM -0400, Trond Eivind Glomsr?d wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Here is what we've always sent to to date ... anyone have any good ones
to add?
Addresses : [EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL
The Hermit Hacker [EMAIL PROTECTED] writes:
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrd wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Here is what we've always sent to to date ... anyone have any good ones
to add?
Addresses : [EMAIL PROTECTED],
Hi
I've been experimenting with 7.1rc4 for a couple of hours. I was messing with
blobs, and the new toast setup worked quite nicely. One thing I especially
liked was the fact that by having pg_dump create a dumpfile in the custom or
tar format, I could also backup all blobs in one go.
Lamar Owen writes:
One quick note -- since 'R' 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already installed.
Couldn't this
At 17:34 13/04/01 -0400, Tom Lane wrote:
A possible kluge answer is to make pg_dump's OID-ordering of views
depend on the OID of the view rule rather than the view relation.
I am not sure if that would break any cases that work now, however.
This seems good to me; it should be based on the
Well folks, I just fixed the CVS tags (renamed REL7_1 to REL7_1_BETA and
moved REL7_1 to today) and packaged up the release ... this is it, any new
fixes go into v7.1.1 ... :)
OK, I have some (small) patches for documentation, but afaicr it is not
critical.
Postscript docs should be
On Wed, 11 Apr 2001, Marcin Wasilewski wrote:
hello everybody,
Can you help me?
I have POSTGRESQL 7.0.3,
I try to create simple view by typing.
create view "xx" as select "aa.yy", "bb.yy" from "yy" order by "bb.yy"
the problem is that parameter order is not implemented with create
At 17:34 13/04/01 -0400, Tom Lane wrote:
A possible kluge answer is to make pg_dump's OID-ordering of views
depend on the OID of the view rule rather than the view relation.
I am not sure if that would break any cases that work now, however.
This seems good to me; it should be based on
Here is what we've always sent to to date ... anyone have any good ones
to add?
Addresses : [EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
Thomas Lockhart wrote:
Hi Lamar. What are the plans for RPMs? Do we have an "integrated RPM"
which will work with Mandrake, or should I keep carrying along my
patches to make the spec file work for now?
I haven't addressed that as yet. Is it safe to assume that -ffast-math
should be
Tom Ivar Helbekkmo [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
+ ERROR: cannot read block 3 of hash_i4_index: Bad address
"Bad address"? That seems pretty bizarre.
This is obviously something that
At 21:15 13/04/01 -0400, Bruce Momjian wrote:
At 17:34 13/04/01 -0400, Tom Lane wrote:
A possible kluge answer is to make pg_dump's OID-ordering of views
depend on the OID of the view rule rather than the view relation.
I am not sure if that would break any cases that work now, however.
At 01:14 14/04/01 +0200, Mathijs Brands wrote:
...
sol2:~$ pg_dump -b -Fc -f blaat.bk blaat
sol2:~$ pg_restore -l blaat.bk
...
;
; Archive created at Sat Apr 14 01:03:02 2001
...
This all looks fine.
sol2:~$ pg_dump -b -Ft -f blaat.tar blaat
zsh: segmentation fault (core dumped) pg_dump -b
On Sat, Apr 14, 2001 at 11:44:18AM +1000, Philip Warner allegedly wrote:
At 01:14 14/04/01 +0200, Mathijs Brands wrote:
...
sol2:~$ pg_dump -b -Fc -f blaat.bk blaat
sol2:~$ pg_restore -l blaat.bk
...
;
; Archive created at Sat Apr 14 01:03:02 2001
...
This all looks fine.
Hmm, I can
Lamar Owen writes:
In the postgresql-docs subpackage, along with the SGML source.
Why would you want to ship the source?
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 5: Have you checked
On Fri, 13 Apr 2001, Peter Eisentraut wrote:
Lamar Owen writes:
In the postgresql-docs subpackage, along with the SGML source.
Why would you want to ship the source?
For those with SGML tools and viewers, who might like to build hardcopy of
their own. Frankly, it was an easy thing to do;
I wrote:
I think this is indisputably a bug in (some versions of) NetBSD. If I
can seek past the end of file, read() shouldn't consider it a hard error
to read there --- and in any case, EFAULT isn't a very reasonable error
code to return. Since it seems not to be a widespread problem, I'm
We've gotten several different reports lately of peculiar compilation
errors and warnings involving readline in 7.1. They look like configure
is actively doing the wrong thing --- for example, how could we see
reports like this:
tab-complete.c:734: `filename_completion_function' undeclared
Using the head branch, when I execute the following in psql on Redhat 6.2
i386, the postmaster process dies gives an error message about corrupted
shared memory:
--begin---
create function bug1(integer) returns numeric as '
begin
return $1;
end;'
language 'plpgsql';
select bug1(5);
We've gotten several different reports lately of peculiar compilation
errors and warnings involving readline in 7.1. They look like configure
is actively doing the wrong thing --- for example, how could we see
reports like this:
tab-complete.c:734: `filename_completion_function'
I wrote:
... how could we see reports like this:
tab-complete.c:734: `filename_completion_function' undeclared (first use in this
function)
when the code makes a point of providing a declaration for
filename_completion_function if configure didn't see it in the headers?
Never mind ...
I
Ok, the 7.1-1 RPMset for Red Hat 6.2 has been uploaded. The Source RPM is up,
in RPM 3 format. Red Hat 7.0 RPMs are on their way. (whew). 28.8K is slow
when uploading 8MB worth of binary RPMset -- as it was when downloading the
source RPM from my 6.2 build machine, located at work and hung off
Mark Butler [EMAIL PROTECTED] writes:
Using the head branch, when I execute the following in psql on Redhat 6.2
i386, the postmaster process dies gives an error message about corrupted
shared memory:
Works for me ... when was your last update?
regards, tom lane
57 matches
Mail list logo
