> Got it upgraded on the cvsup.postgresql.org server ... still have to do
> the other servers ...
I'm hopelessly confused on what servers we have, and whether that one is
new, old, online, offline, being built, or being decommissioned. Can I
use this machine (or virtual machine) for cvsup now?
...
> I think we have agreed that 'current' is a Bad Idea and should be
> eliminated from the date/time datatypes...
I've started purging it from the timestamp code I'm working on for 7.2.
Should be gone by the start of beta...
- Thomas
---(end of br
Due to international instability, I have shortened my vacation and will
remain in the US. Because of this, I _will_ be attending the upcoming
OSDN database summit:
http://www.osdn.com/conferences/osdb2/
I had previously reported I could not attend.
Also, I will be around for more of th
Greetings:
I am (have attempted to) porting PostgreSQL 7.1.2 to Lynx RT OS (http://www.lynx.com).
This OS does not support dynamic loading (on non-MIPS platforms).
After successful build, I did a 'make check' and
am getting the following errors. I would appreciate if anyone can point me toward
Peter Eisentraut wrote:
>
> * What about the JDBC driver? I think the driver should be compiled in
> place by whatever JDK the build system provides.
Don't know about the rest of this stuff, but I totally agree here.
There should be a dependancy on Ant and some kind of JDK, and it should
comp
I just took a dreadful look at the RPMs. I've managed to build something
that resembles a 7.2 package, but there are a number of things that we
should talk about so this ends up being useful.
* The {pgaccess} parameter doesn't do anything AFAICT. PgAccess is
installed whenever Tk support is con
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> If removing artificial limitiations and improving 24/7 usability were
> considerations for 7.1 and 7.2, what will be the focus for 7.3?
Whatever people want to work on. The above-stated descriptions of 7.1
and 7.2 work aren't bad, but they
Or if you download WebPG (phpPgAdmin) it includes code for retrieving
foreign keys.
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Justin Clift
> Sent: Sunday, 16 September 2001 1:04 PM
> To: Rene Pijlman
> Cc: jiby george; [EMAIL PROTECTED]
If removing artificial limitiations and improving 24/7 usability were
considerations for 7.1 and 7.2, what will be the focus for 7.3?
Personally, I would like to see the SQL features completed, ie:
ADD PRIMARY KEY
SET NULL / SET NOT NULL
DROP COLUMN
DROP PRIMARY KEY
DROP UNIQUE
DROP FOREIGN KEY
> What a coincidence. I was about to say the exact opposite. Obviously,
> PostgreSQL isn't the one true database and everyone should Jump
> into MySQL.
> It is easier to type.
>
> I hope your post was meant as a joke because it was hilarious.
These days MySQL is less of a database and more of a
nevermind, PGUSER is the variable
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
I am trying to use pg_dump as user root but using another username for the
database.
I set USER="postgres" and exported it. It still tries to login using the
root username. PGPASSWORD can be set and exported, is there a way I can do
this for the username?
Also, could it be possible for someone t
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> ... Tom Lane is
> probably the person who made those changes, and we should have him in
> the discussion on whether the current behavior is appropriate.
> Keep in mind that he is a mathematician, and I'll guess that he won't
> have much patience with
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Actually, it may be simply that we (now) implement factorial operators
> for int8, int4, and int2. Not sure what previous releases implemented,
> but perhaps it is just an issue of knowing which one should be used for
> the operation. If before we only
Tom Lane writes:
> Wouldn't you have to apply this change in *every* /CVS subdirectory of
> the tree? A fresh checkout seems easier.
I just ran this on my tree:
find -name Root -exec perl -pi -e
's,:pserver:([a-z]+)\@postgresql.org:/home/projects/pgsql/cvsroot,:pserver:\1\@cvs.postgresql.org:
>> For those with already checked out repositories, from everything I've
>> read, all you have to do is change the value of the CVS/Root file to point
>> to the new Root ...
> CVS/Repository as well.
Wouldn't you have to apply this change in *every* /CVS subdirectory of
the tree? A fresh checko
On Sun, 16 Sep 2001, Peter Eisentraut wrote:
> Marc G. Fournier writes:
>
> > Now, I don't imagine it being *that* simple to move it over, so please let
> > me know if anyone sees any errors on commits or stuff like that ...
>
> cvs commit
> ...
> cvs server: failed to create lock directory for
Marc G. Fournier writes:
> Now, I don't imagine it being *that* simple to move it over, so please let
> me know if anyone sees any errors on commits or stuff like that ...
cvs commit
...
cvs server: failed to create lock directory for \
`/cvsroot/pgsql/doc/src/sgml' (/cvsroot/pgsql/doc/src/
- Original Message -
From: Marc G. Fournier <[EMAIL PROTECTED]>
Sent: Sunday, September 16, 2001 1:37 PM
> CVSWeb is going to be broken for a day or two, while Vince and I work out
> some issues as regards moving the main www site over to the same server
> ... but thanks for pointing it
CVSWeb is going to be broken for a day or two, while Vince and I work out
some issues as regards moving the main www site over to the same server
... but thanks for pointing it out, as I hadn't thought about it ..
On Sun, 16 Sep 2001, Serguei Mokhov wrote:
> - Original Message -
> From:
- Original Message -
From: Marc G. Fournier <[EMAIL PROTECTED]>
Sent: Sunday, September 16, 2001 1:05 PM
> Now, I don't imagine it being *that* simple to move it over, so please let
> me know if anyone sees any errors on commits or stuff like that ...
CVSweb seems to be screwed up.
It
This will most likely screw some ppl up, and fix others ...
CVSROOT has now moved to the new machine, finally ... and I've cleaned up
pathing ... and CVS_RSH=ssh now works again too ...
So, now CVSROOT is accessible as:
:pserver:@cvs.postgresql.org:/cvsroot
-or-
:ext:@cvs.postgresql.org:/cvs
22 matches
Mail list logo