On Fri, 16 Aug 2002, Zeugswetter Andreas SB SD wrote:
Note that the other obvious way to solve this would be to store all of
the information inherited from the parent in the parent table, so that
you don't have to do anything special to make all of the constraints and
whatnot apply.
On Thu, 15 Aug 2002, Peter Eisentraut wrote:
integrate or remove new libpqxx
integrate or add to gborg Pg:DBD
Seems like gborg is the place for these.
I would volunteer to package libpq++ separately.
Okay, the procedure is simple, but where do we want to put this? Do we
want
Am Freitag, 16. August 2002 15:51 schrieben Sie:
Mario Weilguni [EMAIL PROTECTED] writes:
Here are the problems I've encountered:
* pg_restore tries to create a table with ltree and ltree[] datatypes
before the type itself is created, so it fails.
Odd; what are the OIDs of the table and
At 00:18 17/08/2002 -0400, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
Obviously this is not a 7.3 item, but would people support such
functionality going into a future version?
Actually, I wouldn't.
This forces application-based caches, which in turn need indexed local
Patch applied. Thanks.
---
Gavin Sherry wrote:
On Wed, 14 Aug 2002, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
... do we want to modify every 7.2 error message?
Nyet ... but I don't think tacking
Marc G. Fournier wrote:
On Thu, 15 Aug 2002, Peter Eisentraut wrote:
integrate or remove new libpqxx
integrate or add to gborg Pg:DBD
Seems like gborg is the place for these.
I would volunteer to package libpq++ separately.
Okay, the procedure is simple, but where do we
I can't find any TODO item that mentions fixing pg_dump's deficiencies
concerning choosing an order to dump the database objects in. The
existing method (basically, dump in OID order) tends to fail in
situations where you've used ALTER TABLE, and in any case it breaks down
completely after OID
Added:
* Use dependency information to dump data in proper order
---
Tom Lane wrote:
I can't find any TODO item that mentions fixing pg_dump's deficiencies
concerning choosing an order to dump the database
OK, with two people now asking to have the patch removed, and with no
comment from Thomas, I have removed the patch. This removes XLogDir
environment variable, and -X postmaster/postgres/initdb/pg_ctl flag.
I have also removed the code that dynamically sized xlogdir.
I will post the patch to
Bruce Momjian [EMAIL PROTECTED] writes:
Now, I know one of Marc's goals is to have libpq as a stand-alone
tarball, but I thought we decided that this _didn't_ require it to be in
a separate CVS repository.
Removing libpq is impossible since psql, pg_dump, etc all depend on it.
I don't think
Bruce Momjian [EMAIL PROTECTED] writes:
OK, with two people now asking to have the patch removed, and with no
comment from Thomas, I have removed the patch. This removes XLogDir
environment variable, and -X postmaster/postgres/initdb/pg_ctl flag.
I thought we intended to keep the -X switch
Christopher Kings-Lynne writes:
I notice that the new default for the contrib Makefiles is to build
libfti.so, etc. instead of the old fti.so.
The default is to build nothing ... (?)
Won't this cause dump restore problems for everyone already using the
contrib?
No, because what is build
Tom Lane writes:
Really what we need is a test on the glibc version, which seems a
bit difficult.
Well, it's not that difficult to figure out the version (run
/lib/libc.so.6), but I'm afraid the version is not going to tell you
anything. For instance, the libc versions that are claimed to
Marc G. Fournier [EMAIL PROTECTED] writes:
Bruce, can you make a project for Pg::DBD?
Erm, has anyone contacted the maintainer of DBD::Pg? Given that Bruce
doesn't maintain it and AFAIK Jeffrey Baker (the current maintainer)
and hasn't expressed any dissatisfaction with CPAN, I'm not sure why
Neil Conway wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Bruce, can you make a project for Pg::DBD?
Erm, has anyone contacted the maintainer of DBD::Pg? Given that Bruce
doesn't maintain it and AFAIK Jeffrey Baker (the current maintainer)
and hasn't expressed any dissatisfaction with
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, with two people now asking to have the patch removed, and with no
comment from Thomas, I have removed the patch. This removes XLogDir
environment variable, and -X postmaster/postgres/initdb/pg_ctl flag.
I thought we intended
On Sat, 17 Aug 2002, Bruce Momjian wrote:
OK, I am ready to do the work, but I would like to get a plan of where
we are going. I see in interfaces:
cli
ecpg
jdbc
libpgeasy
libpgtcl
libpq
libpq++
libpqxx
odbc
perl5
OK, I think we are doing this backwards. Instead of adding '@' to
global users, and then removing it in the backend, why don't we have
local users end with '@', that way, global users continue to connect
just as they have before, and local users connect with @, so dave@db1
connects as 'dave@'
On Sat, 17 Aug 2002, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Now, I know one of Marc's goals is to have libpq as a stand-alone
tarball, but I thought we decided that this _didn't_ require it to be in
a separate CVS repository.
Removing libpq is impossible since psql,
Marc G. Fournier wrote:
Chris has made code changes to GBorg to allow for this based on requests
from Dave Page (ie. PgAdminII) ... so there is no problems with that ...
As for keeping them in our main CVS, the more we put over onto GBorg, the
more it will get used, test, debugged, pounded
Bruce Momjian [EMAIL PROTECTED] writes:
OK, I think we are doing this backwards. Instead of adding '@' to
global users, and then removing it in the backend, why don't we have
local users end with '@', that way, global users continue to connect
just as they have before, and local users
On Sat, 17 Aug 2002, Bruce Momjian wrote:
Marc G. Fournier wrote:
Chris has made code changes to GBorg to allow for this based on requests
from Dave Page (ie. PgAdminII) ... so there is no problems with that ...
As for keeping them in our main CVS, the more we put over onto GBorg, the
Marc G. Fournier [EMAIL PROTECTED] writes:
I think the only unknown is whether their CVS's should be moved out of
the main tree.
Yes, they should be ...
Certainly. I was a bit worried about losing CVS history, but Marc
indicated he could make the move with history and all, so there's
no
On Sat, 17 Aug 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
I think the only unknown is whether their CVS's should be moved out of
the main tree.
Yes, they should be ...
Certainly. I was a bit worried about losing CVS history, but Marc
indicated he could make the
I get the following compiling the current CVS code with gcc 3.1:
...
fe-connect.c: In function `connectDBComplete':
fe-connect.c:1081: warning: suggest parentheses around within ||
fe-connect.c:1086: warning: implicit declaration of function `gettimeofday'
...
pg_controldata.c: In function
Neil Conway [EMAIL PROTECTED] writes:
I get the following compiling the current CVS code with gcc 3.1:
I also get 4 regression test failures, due to Gavin's improvements to
the parser error messages. AFAICT no actual problems, the expected
error message strings just needed to be updated.
Neil Conway [EMAIL PROTECTED] writes:
pg_controldata.c: In function `main':
pg_controldata.c:91: warning: `%c' yields only last 2 digits of year in some locales
pg_controldata.c:93: warning: `%c' yields only last 2 digits of year in some locales
Yeah. I was willing to ignore that while
I'd like to propose dropping the auto-creation of UNIQUE indexes on
serial columns for the following reasons:
1. Serials with indexes are quite difficult to handle in pg_dump. It
means that the implicitly created unique index must be destroyed prior
to loading the data, then re-created
Rod Taylor wrote:
I'd like to propose dropping the auto-creation of UNIQUE indexes on
serial columns for the following reasons:
1. Serials with indexes are quite difficult to handle in pg_dump. It
means that the implicitly created unique index must be destroyed prior
to loading the data,
On Fri, Aug 16, 2002 at 05:44:50PM -0400, Rod Taylor wrote:
Is it possible for the cvs emails to include a URL to the appropriate
entries in cvs web?
The below is current:
Modified files:
src/backend/utils/adt: ruleutils.c
If you're using a Web browser with support for smart
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, I think we are doing this backwards. Instead of adding '@' to
global users, and then removing it in the backend, why don't we have
local users end with '@', that way, global users continue to connect
just as they have before,
OK, I have fixed the first two with the following patch. The second
pair Tom has commented on.
---
Neil Conway wrote:
I get the following compiling the current CVS code with gcc 3.1:
...
fe-connect.c: In function
Yes, very nanny-ish. Not sure how to turn it off.
---
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
pg_controldata.c: In function `main':
pg_controldata.c:91: warning: `%c' yields only last 2 digits of year
n file included from fe-connect.c:24:
libpq-int.h:337: warning: `struct timeval' declared inside parameter
list
libpq-int.h:337: warning: its scope is only this definition or
declaration, which is probably not what you want.
fe-connect.c: In function `connectDBComplete':
fe-connect.c:1060:
Joe Conway [EMAIL PROTECTED] writes:
I agree 100%. If you want an index, unique constraint, or primary key on
a SERIAL, I think you should explicitly add it. SERIAL should give me a
column that automatically increments -- no more, no less.
Hmm, do you also want to eliminate the implicit NOT
I am not seeing the failure here on BSD/OS. I just fixed the
libpq-int.h problem. Please update to cvs current and let me know what
you see.
---
Rod Taylor wrote:
n file included from fe-connect.c:24:
libpq-int.h:337:
Bruce Momjian [EMAIL PROTECTED] writes:
I am not seeing the failure here on BSD/OS. I just fixed the
libpq-int.h problem. Please update to cvs current and let me know what
you see.
FWIW, libpq seems to build fine here (HPUX 10.20) both before and after
your latest commit. Rod should
The code was clearly wrong, mentioning timeval with no time.h nor
sys/types.h include. My patches should fix him [good]. :-)
Who used to say, I will fix him good? I don't remember.
---
Tom Lane wrote:
Bruce Momjian
I have applied patches to the regression test to fix this. Thanks.
---
Neil Conway wrote:
Neil Conway [EMAIL PROTECTED] writes:
I get the following compiling the current CVS code with gcc 3.1:
I also get 4
Bruce Momjian [EMAIL PROTECTED] writes:
OK, here is the patch with the suggested changes. I am sending the
patch to hackers because there has been so much interest in this.
One minor gripe:
+ /* If user@, it is a global user, remove '@' */
+ if (strchr(port-user,
On Sat, 2002-08-17 at 22:08, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am not seeing the failure here on BSD/OS. I just fixed the
libpq-int.h problem. Please update to cvs current and let me know what
you see.
FWIW, libpq seems to build fine here (HPUX 10.20) both
I think I added time.h and sys/types.h. That should do it for you.
---
Rod Taylor wrote:
On Sat, 2002-08-17 at 22:08, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am not seeing the failure here on
I said:
Another alternative is
char *fmt = %c;
...
strftime(..., fmt, ...);
which I think will probably defeat gcc's check (haven't tried it
though).
I tried this, and it did shut up the warning in my local copy of gcc.
So I committed it.
Does anyone want to argue that
OK, applied, with that change.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, here is the patch with the suggested changes. I am sending the
patch to hackers because there has been so much interest
As you can see, the open items list is greatly shrunk. We have two
weeks to go and most of these seems do-able, except for point-in-time
recovery, which may not make it. I haven't heard anything recently on
it.
Would someone put together a porting document for schema changes and
drop column
On Sat, 2002-08-17 at 22:44, Bruce Momjian wrote:
I think I added time.h and sys/types.h. That should do it for you.
Hmm.. whelp, the file in question on FreeBSD is sys/time.h (attached
earlier) so this won't fix it.
Rod Taylor [EMAIL PROTECTED] writes:
Hmm.. whelp, the file in question on FreeBSD is sys/time.h (attached
earlier) so this won't fix it.
Added #include sys/time.h. We seem to use this unconditionally in
many other files, so I don't see a reason not to include it here.
47 matches
Mail list logo
