Postgres 8.1 for Mac
How to install Postgres 8.1 on PowerMac 10.1, OS X 10.4.4 ?
Is there ready made binaries available for download of should I build from
source ?
Where are installing or building instructions for Mac available ?
Andrus
I haven't compiled it myself, but a guess would be if you installed
XCode (which comes with gcc, and should have most if not all the libs
needed) it's a matter of grabbing the source, untarring it, running ./
configure in the src dir, make, and make install, etc. (Follow the
normal build instructions)
Good luck!
Gavin
On Jan 31, 2006, at 7:58 AM, Andrus wrote:
Show quoted text
How to install Postgres 8.1 on PowerMac 10.1, OS X 10.4.4 ?
Is there ready made binaries available for download of should I
build from
source ?Where are installing or building instructions for Mac available ?
Andrus
---------------------------(end of
broadcast)---------------------------
TIP 4: Have you searched our list archives?
Initial setup, I used the packages at http://www.entropy.ch and from that
point on, I build from source for the upgrades.
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Andrus
Sent: Tuesday, January 31, 2006 9:59 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Postgres 8.1 for Mac
How to install Postgres 8.1 on PowerMac 10.1, OS X 10.4.4 ?
Is there ready made binaries available for download of should I build from
source ?
Where are installing or building instructions for Mac available ?
Andrus
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.25/246 - Release Date: 1/30/2006
I haven't tried those specific versions but I'm guessing a build from
source will work great.
If you are ok with just using 8.0 then you could use fink (http://
fink.sourceforge.net). Fink is apt-get for Mac. It looks like 8.1
is still in their unstable branch. Hopefully it will be moved to
stable soon.
Rick
On Jan 31, 2006, at 8:58 AM, Andrus wrote:
Show quoted text
How to install Postgres 8.1 on PowerMac 10.1, OS X 10.4.4 ?
Is there ready made binaries available for download of should I
build from
source ?Where are installing or building instructions for Mac available ?
Andrus
---------------------------(end of
broadcast)---------------------------
TIP 4: Have you searched our list archives?
On 1/31/06, Rick Gigger <rick@alpinenetworking.com> wrote:
I haven't tried those specific versions but I'm guessing a build from
source will work great.If you are ok with just using 8.0 then you could use fink (http://
fink.sourceforge.net). Fink is apt-get for Mac. It looks like 8.1
is still in their unstable branch. Hopefully it will be moved to
stable soon.
yeah, they should be moved to stable shortly, I've got another rev I
want to put out with some other administrative/documentation updates
in the package descriptions, and then, barring issues, I'll put that
out.
There's also darwinports, which has 8.1.2.
On Tue, Jan 31, 2006 at 09:44:13AM -0700, Rick Gigger wrote:
I haven't tried those specific versions but I'm guessing a build from
source will work great.If you are ok with just using 8.0 then you could use fink (http://
fink.sourceforge.net). Fink is apt-get for Mac. It looks like 8.1
is still in their unstable branch. Hopefully it will be moved to
stable soon.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Jan 31, 2006, at 4:57 PM, Jim C. Nasby wrote:
There's also darwinports, which has 8.1.2.
but does some idiotic bizarre weird strange install of the binaries
into /opt/local/lib/pgsql8/bin/ and symlinks the psql program as
psql8 into your normal bin directory. it is just painful to
administer a pg server with that install (unless you add the path to
your bin, which I hate to have to do for each and every app installed
-- this aint windows!!!)
Attachments:
We use the instructions at http://www.keyvaluecoding.com
Works great.
____________________________________________________________________
Brendan Duddridge | CTO | 403-277-5591 x24 | brendan@clickspace.com
ClickSpace Interactive Inc.
Suite L100, 239 - 10th Ave. SE
Calgary, AB T2G 0V9
On Feb 1, 2006, at 2:15 PM, Vivek Khera wrote:
Show quoted text
On Jan 31, 2006, at 4:57 PM, Jim C. Nasby wrote:
There's also darwinports, which has 8.1.2.
but does some idiotic bizarre weird strange install of the binaries
into /opt/local/lib/pgsql8/bin/ and symlinks the psql program as
psql8 into your normal bin directory. it is just painful to
administer a pg server with that install (unless you add the path
to your bin, which I hate to have to do for each and every app
installed -- this aint windows!!!)
Attachments:
I found this in the archives:
<http://archives.postgresql.org/pgsql-interfaces/2004-04/msg00005.php>
With 8.x, is it still true that with ECPG, it is not possible to use COPY
inline - I'd have to write the data to a file, then 'COPY FROM filename' (or
use direct libpq API calls instead of ECPG)?
Wes
On Thu, Feb 23, 2006 at 10:26:35PM -0600, Wes wrote:
I found this in the archives:
<http://archives.postgresql.org/pgsql-interfaces/2004-04/msg00005.php>
With 8.x, is it still true that with ECPG, it is not possible to use COPY
inline - I'd have to write the data to a file, then 'COPY FROM filename' (or
use direct libpq API calls instead of ECPG)?
Looks that way. The ECPGexecute() function in ecpglib/execute.c
has the following code:
case PGRES_COPY_OUT:
ECPGlog("ECPGexecute line %d: Got PGRES_COPY_OUT ... tossing.\n", stmt->lineno);
PQendcopy(stmt->connection->connection);
break;
case PGRES_COPY_IN:
ECPGlog("ECPGexecute line %d: Got PGRES_COPY_IN ... tossing.\n", stmt->lineno);
PQendcopy(stmt->connection->connection);
break;
You can see this code being executed if you enable debugging:
% cat foo.pgc
int
main(void)
{
ECPGdebug(1, stdout);
EXEC SQL CONNECT TO test;
EXEC SQL COPY foo FROM stdin;
EXEC SQL COMMIT;
EXEC SQL DISCONNECT;
return 0;
}
% ./foo
[33044]: ecpg_finish: Connection test closed.
[33044]: ecpg_finish: Connection test closed.
[33044]: ecpg_finish: Connection test closed.
[33044]: ecpg_finish: Connection test closed.
[33044]: ecpg_finish: Connection test closed.
[33044]: ecpg_finish: Connection test closed.
--
Michael Fuhr
Am Freitag, 24. Februar 2006 05:26 schrieb Wes:
I found this in the archives:
<http://archives.postgresql.org/pgsql-interfaces/2004-04/msg00005.php>
With 8.x, is it still true that with ECPG, it is not possible to use COPY
inline - I'd have to write the data to a file, then 'COPY FROM filename'
(or use direct libpq API calls instead of ECPG)?
Yes, it's still an open report. Sorry, about that and all the other open bug
reports/feature requests. I do not have the time at the moment to even
reproduce bugs. Hopefully this will become better in the near future.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes wrote:
Am Freitag, 24. Februar 2006 05:26 schrieb Wes:
I found this in the archives:
<http://archives.postgresql.org/pgsql-interfaces/2004-04/msg00005.php>
With 8.x, is it still true that with ECPG, it is not possible to use COPY
inline - I'd have to write the data to a file, then 'COPY FROM filename'
(or use direct libpq API calls instead of ECPG)?Yes, it's still an open report. Sorry, about that and all the other open bug
reports/feature requests. I do not have the time at the moment to even
reproduce bugs. Hopefully this will become better in the near future.
Should we add this to TODO? Anything else?
--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com
+ If your life is a hard drive, Christ can be your backup. +
Since I can't use ECPG COPY, I'm trying to use libpq PQputCopyData. Not
realizing I had to use CSV format to include column header names, I used:
PQexec(conn, "COPY detail FROM stdin")
I sent the column headers as the first line of the input. While this I now
know this is wrong, the problem here is that I got no error response back.
In the postmaster log, I see:
ERROR: invalid input syntax for type numeric: "messageid"
CONTEXT: COPY detail, line 1, column messagesize: "messageid"
However, every call to PQputCopyData, as well as PQputCopyEnd returned a
result of 1.
Ok, so I fixed the above error, but any other data load errors are only
showing up in the postgres log file. I tried defining
PQsetNoticeReceiver(conn, &pgsqlNoticeReceiver, (void *) &dummy);
For testing, pgsqlNoticeReceiver just writes a message and aborts. However,
pgsqlNoticeReceiver is never called.
What am I missing? I need to abort the transaction on any errors in the
COPY.
Wes
Yes, it's still an open report. Sorry, about that and all the other open
bug reports/feature requests. I do not have the time at the moment to
even reproduce bugs. Hopefully this will become better in the near
future.Should we add this to TODO? Anything else?
Yes, please add it. I do have some more open bug reports/feature requests, but
I'd like to reproduce things first before we add to the docs. Sometimes it's
easier to fix it than to add it. :-)
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Wes <wespvp@syntegra.com> writes:
I sent the column headers as the first line of the input. While this I now
know this is wrong, the problem here is that I got no error response back.
...
However, every call to PQputCopyData, as well as PQputCopyEnd returned a
result of 1.
That just indicates that the data was sent to the backend without error.
You forgot to check the copy command result afterward.
regards, tom lane
On 2/26/06 12:12 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
That just indicates that the data was sent to the backend without error.
You forgot to check the copy command result afterward.
Ok, after re-reading the docs for the 10th time, I see I missed that I need
to paragraph about calling 'PQgetResult' after the PQputCopyEnd. I was just
checking the result and PQerrorMessage. I think what threw me off was:
"If a COPY command is issued via PQexec in a string that could contain
additional commands, the application must continue fetching results via
PQgetResult after completing the COPY sequence. Only when PQgetResult
returns NULL is it certain that the PQexec command string is done and it is
safe to issue more commands."
(looked like this was needed only if multiple commands were in the Pqexec)
and
"PQgetResult
Waits for the next result from a prior PQsendQuery, PQsendQueryParams,
PQsendPrepare, or PQsendQueryPrepared call, and returns it."
(doesn't mention COPY).
I have it working now. Thanks.
Wes
Michael Meskes wrote:
Yes, it's still an open report. Sorry, about that and all the other open
bug reports/feature requests. I do not have the time at the moment to
even reproduce bugs. Hopefully this will become better in the near
future.Should we add this to TODO? Anything else?
Yes, please add it. I do have some more open bug reports/feature requests, but
I'd like to reproduce things first before we add to the docs. Sometimes it's
easier to fix it than to add it. :-)
Added for ecpg TODO:
o Add COPY TO STDIN / STDOUT handling
I think we should document _every_ thing that ecpg needs because it
helps existing users know what is missing, and encourages patches.
Would you please supply a list?
--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com
+ If your life is a hard drive, Christ can be your backup. +
On Mon, Mar 06, 2006 at 10:15:06AM -0500, Bruce Momjian wrote:
Added for ecpg TODO:
o Add COPY TO STDIN / STDOUT handling
COPY TO STDOUT has been implemented, but I'm unsure whether COPY FROM
STDIN really makes sense. Does anyone know a real life example where
this would be needed and the work couldn't be done easier using psql?
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
* Michael Meskes:
COPY TO STDOUT has been implemented, but I'm unsure whether COPY FROM
STDIN really makes sense. Does anyone know a real life example where
this would be needed and the work couldn't be done easier using psql?
COPY FROM STDIN saves lots of network round-trips.
--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Durlacher Allee 47 tel: +49-721-96201-1
D-76131 Karlsruhe fax: +49-721-96201-99
On Wed, Aug 02, 2006 at 12:03:45PM +0200, Florian Weimer wrote:
* Michael Meskes:
COPY TO STDOUT has been implemented, but I'm unsure whether COPY FROM
STDIN really makes sense. Does anyone know a real life example where
this would be needed and the work couldn't be done easier using psql?COPY FROM STDIN saves lots of network round-trips.
So what?
Could you please explain what this has to do with my original question?
Somehow I don't get it, sorry.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!