On L, 2005-07-30 at 22:26 -0400, Denis Lussier wrote:
Thanks, I'll check it out. I didn't see much evidence on the SugarCRM
site that they are interested in an DB besides MySQL. But, it is also
my hope that the core SugarCRM project will come around to supporting
EDB/PostgreSQL (once we have
Am Freitag, 29. Juli 2005 06:28 schrieb Tom Lane:
The following query doesn't return the version of PostgreSQL currently
running, but rather the version of initdb that initialized the cluster:
Not sure if it was really thought about, but seeing that (a) you can get
the current version from
Am Freitag, 29. Juli 2005 16:34 schrieb Tom Lane:
Yeah. I desisted from deleting it after I noticed that there are
provisions for re-generating it over in the doc/src/sgml Makefile.
However, I'm now wondering why it's not handled exactly like INSTALL
--- ie, don't keep it in CVS, but
As of now, translators have the opportunity to commit their translations
themselves as the PgFoundry project at
http://pgfoundry.org/projects/pgtranslation/
Everyone who has previously worked on translations is invited to send me a
private email so I can add them to this project.
The plan is
Am Mittwoch, 3. August 2005 01:18 schrieb Jeff Davis:
I guess what I'm trying to find out: does this mean that after all this
change to the way strings are handled in the future, PostgreSQL still
won't be standards-compliant for the basic '' string?
It will be more conforming regarding
Peter Eisentraut wrote:
Also, let's say I have apps now in 7.4/8.0, and I want them to be
forward-compatible. Should I make a type called E so that the E''
notation will work, and then use that for strings? What is the right
way to do it?
To be standards-conforming, don't use any backslash
ECPG seems to be a little overzealous with the new escape string syntax:
% cat foo.pgc
int
main(void)
{
putchar('\n');
return 0;
}
% ecpg foo.pgc
% gcc -I`pg_config --includedir` -c foo.c
foo.pgc: In function `main':
foo.pgc:4: `E' undeclared (first use in this function)
foo.pgc:4:
#postgresql freenode channel directed me to write the hackers list
I have backup files. Version I believe is 7.4.
pg server stopped - short log file is pasted at end of this email
PANIC re checkpoint record seems to indicate running pg_resetxlog
Ran pg_restxlog with -n successfully and it
Am Mittwoch, 3. August 2005 15:40 schrieb Oliver Jowett:
To be standards-conforming, don't use any backslash escapes. If you must
use them, use the E'' notation.
That doesn't really answer the question, though, since none of
7.4/8.0/8.1 interprets '' strings in a strictly
Am Mittwoch, 3. August 2005 15:40 schrieb Oliver Jowett:
The impression I got from previous discussion was that you need to check
the value of the standard_compliant_strings GUC, and double backslashes
inside '' only if it was false or missing.
The correct lingo would be
Did we recently make some fixes for FBSD that cured the problem with
unresolved pthread* symbols for plpython? If so, should we look at
possibly doing something similar for OpenBSD? That might clean up
buildfarm member spoonbill which has been failing ever since we started
testing PLs.
ECPG ignores SAVEPOINT if it's the first statement of a transaction:
% cat foo.pgc
int
main(void)
{
EXEC SQL WHENEVER SQLERROR SQLPRINT;
EXEC SQL WHENEVER SQLWARNING SQLPRINT;
EXEC SQL CONNECT TO test;
EXEC SQL SAVEPOINT foo;
EXEC SQL DROP TABLE nosuch_1;
EXEC SQL
Andrew Dunstan [EMAIL PROTECTED] writes:
Did we recently make some fixes for FBSD that cured the problem with
unresolved pthread* symbols for plpython?
No, it's not fixed. I think the owner of the freebsd buildfarm machine
masked the problem by building an unthreaded libpython.
The only fix
hello.I use postgresql 8.0 . I've created the server.key and
server.crt in this manner:
openssl req -new -nodes -keyout server.key -out server.csr
openssl req -x509 -key /home/data/server.key -in /home/data/server.csr -out
server.crt
and I put theese in my data home.
I launch postgres in
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Did we recently make some fixes for FBSD that cured the problem with
unresolved pthread* symbols for plpython?
No, it's not fixed. I think the owner of the freebsd buildfarm machine
masked the problem by building an
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
The alternative is to say that plpython isn't supported on BSDen unless
you choose to build an unthreaded libpython.
I'm OK with that, but if that's what's done I think we should check for
it up front at configure time and not let it
I just finished converting and loading the US census data into PostgreSQL
would anyone be interested in it for testing purposes?
It's a *LOT* of data (about 40+ Gig in PostgreSQL)
---(end of broadcast)---
TIP 6: explain analyze is your friend
I discovered the following confusing issue in CVS HEAD:
CREATE TABLE test(id SERIAL NOT NULL);
ALTER TABLE TEST OWNER TO testuser;
SELECT typname, typowner, relname, relowner from pg_type c JOIN pg_class d
ON (d.reltype = c.oid) WHERE typname = 'test';
typname | typowner | relname | relowner
I was reminded again today of the problem that once a database has been
in existence long enough for the OID counter to wrap around, people will
get occasional errors due to OID collisions, eg
http://archives.postgresql.org/pgsql-general/2005-08/msg00172.php
Getting rid of OID usage in user
Bernd Helmle [EMAIL PROTECTED] writes:
I discovered the following confusing issue in CVS HEAD:
...
As you can see, the owner of the sequence and table row type isn't changed
as well.
Hmmm ... this did not matter before shared dependencies, but it does
now ... I agree, we have to fix it.
On Wed, Aug 03, 2005 at 05:00:16PM -0400, Mark Woodward wrote:
I just finished converting and loading the US census data into PostgreSQL
would anyone be interested in it for testing purposes?
It's a *LOT* of data (about 40+ Gig in PostgreSQL)
Sure. Got a torrent?
Cheers,
D
--
David Fetter
David Fetter wrote:
On Wed, Aug 03, 2005 at 05:00:16PM -0400, Mark Woodward wrote:
I just finished converting and loading the US census data into PostgreSQL
would anyone be interested in it for testing purposes?
It's a *LOT* of data (about 40+ Gig in PostgreSQL)
Sure. Got a
On Wed, 3 Aug 2005, Tom Lane wrote:
I seem to recall having thought of this idea before, and having rejected
it as being too much overhead to solve a problem that occurs only rarely
--- but in a quick test involving many repetitions of
create temp table t1(f1 int, f2 int);
drop
Gavin Sherry [EMAIL PROTECTED] writes:
Looks good. Another approach would be to put the existing code in a
PG_TRY() block and catching the duplicate key violation.
Not really feasible from a code-structure point of view, I'm afraid.
Also there is the issue of cleaning up leaked resources
postgres=# create user u1;
CREATE ROLE
postgres=# create schema s1;
CREATE SCHEMA
postgres=# create table s1.t1(f1 int);
CREATE TABLE
postgres=# alter table s1.t1 owner to u1;
ERROR: permission denied for schema s1
postgres=#
Considering I am superuser, it should darn well allow this.
The
Tom Lane [EMAIL PROTECTED] writes
So wouldn't this mean that any CREATE DATABASE won't work properly in
PITR?
It works fine in a rollforward situation.
Since there is no xlog replay mechanism to CREATE INDEX (bottom-up method),
so CREATE INDEX won't get replayed in PITR?
This seems also
Qingqing Zhou [EMAIL PROTECTED] writes:
Since there is no xlog replay mechanism to CREATE INDEX (bottom-up method),
so CREATE INDEX won't get replayed in PITR?
On what do you base either part of that statement?
regards, tom lane
---(end of
Tom Lane [EMAIL PROTECTED] writes
Since there is no xlog replay mechanism to CREATE INDEX (bottom-up
method),
so CREATE INDEX won't get replayed in PITR?
On what do you base either part of that statement?
I see _bt_load() still relies on smgrimmedsync() to assure a correct disk
image of
* Tom Lane ([EMAIL PROTECTED]) wrote:
Considering I am superuser, it should darn well allow this.
Agreed.
The problem of course is the test that u1 would have the rights to
create t1 in s1, which he doesn't. I think we have to skip that
test if superuser. As long as we need an explicit
Stephen Frost [EMAIL PROTECTED] writes:
I don't like this approach to solving the problem. I would rather see
the check modified to allow the ownership change provided:
the user issueing the command has access to destination role
AND
(
the destination role can create the table
OR the
30 matches
Mail list logo
