Kind people,
I've been digging through the CVS code and trying to figure out the
best approach to making one psql that does the right thing for
different versions of the back-end. This has come up in a real
situation already, where the dev box is 7.3.3 and the production box
is (Yikes!) 7.2.1.
I'm wondering if maybe the Right Thing(TM) might be for all
connections to return (optionally?) the version number, but that seems
like a giant project with many backward-compatibility snags attached.
I think it would be for psql to check the connection version and then load a
shared library
Bruce Momjian writes:
Does anyone know anything about pkgconfig?
It's basically a generalized version of pg_config and similar tools that
works out of a centralized database. I'm not convinced that it solves any
real problems without introducing new ones. The idea is alright, but I'm
not
Tom Lane writes:
gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI
C -I. -I. -I./snowball -I./ispell -I./wordparser -I../../src/include -c -o
snowball/english_stem.o snowball/english_stem.c -MMD
cp: snowball/english_stem.d: No such file or directory
Tom Lane writes:
I've repaired this in CVS tip. While testing it, though, I notice that
CVS-tip pg_dump puts out useless commands
REVOKE ALL ON SCHEMA public FROM PUBLIC;
GRANT ALL ON SCHEMA public TO PUBLIC;
which are not generated when dumping from 7.3. The reason evidently
Guys, looking at ecpg from CVS HEAD's 7.4. The following code
fragement:
EXEC SQL INCLUDE sqlca;
EXEC SQL WHENEVER SQLERROR call sqlprint;
void lofsdb_GetMinMaxRxStations(int *from, int *to)
{
EXEC SQL BEGIN DECLARE SECTION;
int l_from = 0;
int l_to = 0;
EXEC SQL END DECLARE
On Fri, Aug 01, 2003 at 12:06:07PM +0100, Lee Kindness wrote:
Guys, looking at ecpg from CVS HEAD's 7.4. The following code
fragement:
...
Fix just committed. Should work now.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM: michaelmeskes, Jabber: [EMAIL
Tom Lane writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
In other words, an info, notice, or warning must have a class 00, 01, 02.
I suspect though that the spec is assuming that the SQLSTATE code is the
*only* way for the application to determine whether the message is
success,
Peter Eisentraut [EMAIL PROTECTED] writes:
This could be fixed, but note that elsewhere we use
/*
* Always start with REVOKE ALL FROM PUBLIC, so that we don't have to
* wire-in knowledge about the default public privileges for different
* kinds of objects.
*/
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
I suspect though that the spec is assuming that the SQLSTATE code is the
*only* way for the application to determine whether the message is
success, warning, or error.
The severity field is useless, because it contains localized
Hey Thierry,
I'm forwarding this on to the hackers group to see if we can get an
authoritative answer, as you don't want to rely on my fuzzy memory. :-)
Anyone know the scoop on this?
Robert Treat
-- Forwarded Message --
Subject: Re: [ANNOUNCE] PostgreSQL Weekly
David Fetter [EMAIL PROTECTED] writes:
I'm wondering if maybe the Right Thing(TM) might be for all
connections to return (optionally?) the version number, but that seems
like a giant project with many backward-compatibility snags attached.
Already done, see PQparameterStatus at
Peter Eisentraut [EMAIL PROTECTED] writes:
These files are created when --enable-depend is on. The problem appears
to be that the Makefile is trying to create files in a directory not its
own. You cannot do that; it creates all kinds of problems in complex
installation setups.
I was afraid
What date was the move? I can get you a diff.
---
D'Arcy J.M. Cain wrote:
On Friday 01 August 2003 00:41, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Somehow, when we moved it to gborg way back, the
Yes, ecpg will be thread-safe in 7.4.
---
Robert Treat wrote:
Hey Thierry,
I'm forwarding this on to the hackers group to see if we can get an
authoritative answer, as you don't want to rely on my fuzzy
On Tue, 29 Jul 2003, vajjhala chakravarthi wrote:
HI
I am running MFcobol on a linux machine which is
having Postgresql. can I access pgsql database thru
mfcobol.
If it is possible where can I get odbc drivers and
what is the procedure help me
ODBC driver is available here:
Tom Lane writes:
I was afraid it was something like that. Can we leave the directory
structure as-is and just make the .o (and .d) files get built in the
upper directory, that is
gcc ... -o english_stem.o snowball/english_stem.c
That will fail for a more basic reason: not all
On Friday 01 August 2003 00:41, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Somehow, when we moved it to gborg way back, the 'cvs remove' wasn't done
on the mail repository ... there ... cvs remove'd now, so its still part
of v7.3.x, but no longer part of v7.4 ...
According
I'm getting an ecpg related compile failure on cvs tip:
gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic
-I../../../../src/interfaces/ecpg/include
-I../../../../src/include/utils -I../../../../src/include -g -c -o
timestamp.o timestamp.c -MMD
timestamp.c: In function
Joe Conway wrote:
I'm getting an ecpg related compile failure on cvs tip:
gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic
-I../../../../src/interfaces/ecpg/include
-I../../../../src/include/utils -I../../../../src/include -g -c -o
timestamp.o timestamp.c -MMD
timestamp.c:
Hackers,
Does anyone know if we've been ported to OS/400, ever?
And/or does anyone have any experience with Postgres on Linux LPAR (IBM
iSeries)?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 4: Don't 'kill
On Fri, Aug 01, 2003 at 10:22:59AM -0700, Joe Conway wrote:
Looks like a simple matter of replacing replace_int64 with int64_val
at line 549 in src/interfaces/ecpg/pgtypeslib/timestamp.c
Yes, it is. Thanks. I didn't have HAVE_INT64_TIMESTAMP defined.
In fact there's another one in common.c
We (PostgreSQL, Inc) are just in the process of tying up some loose ends
on eRServer v1.2, to be released OSS on GBorg over the next week or so ...
since this is meant to replace rserv, I'd like to remove rserv from the
v7.4 source tree ...
As far as I know, the only patch made to rserv in the
On Fri, 2003-08-01 at 14:46, The Hermit Hacker wrote:
We (PostgreSQL, Inc) are just in the process of tying up some loose ends
on eRServer v1.2, to be released OSS on GBorg over the next week or so ...
since this is meant to replace rserv, I'd like to remove rserv from the
v7.4 source tree
Robert Treat [EMAIL PROTECTED] writes:
On Fri, 2003-08-01 at 14:46, The Hermit Hacker wrote:
Is there anyone actually using rserv who would be adverse to my removing
it from the source tar ball?
I'm not actually using it, but I'd be adverse to removing from 7.4 if
only for the fact that
gborg has the cvs access, bugs, features, etc. listed
for the pygresql project.
The website link on the gborg page does point to PyGreSQL.org,
however.
Will these auxilliary links be available from gborg or
are you going to manage it all from PyGreSQL.org?
In otherwords, if someone is looking
Testing a connection that should fail (for lack of pg_hba entry):
$ psql -h sss2 tgl
psql: FATAL: missing or erroneous pg_hba.conf file
HINT: See postmaster log for details.
$
Say what? This is with a completely default pg_hba.conf file...
looking in the postmaster log as suggested:
LOG:
Yeah, I'd be very surprised if many need it, and those who do can
uncomment it. I think commenting it out is the right thing (tm).
andrew
Tom Lane wrote:
Testing a connection that should fail (for lack of pg_hba entry):
$ psql -h sss2 tgl
psql: FATAL: missing or erroneous pg_hba.conf file
On Fri, 2003-08-01 at 15:29, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
On Fri, 2003-08-01 at 14:46, The Hermit Hacker wrote:
Is there anyone actually using rserv who would be adverse to my removing
it from the source tar ball?
I'm not actually using it, but I'd be adverse
Agreed. I wanted to put the ipv6 entry in there only if they compiled
with ipv6 suport, but that seemed strange to some, I think.
I would comment it out.
---
Andrew Dunstan wrote:
Yeah, I'd be very surprised if many
Guys,
I've been testing 7.4 against an application today. Recompiled
everything against the new libraries. However the application includes
code which builds up a bulkload file in the documented 7.1 format. The
documentation for COPY goes on at length about the format being
forward compatible...
Lee Kindness [EMAIL PROTECTED] writes:
I've attached a patch which lets COPY read in the 7.1 format. However
i'm not convinced this is the right way to go - I think the format
which is output by 7.4 should be identical to the 7.1 format.
You are greatly underestimating the changes that
Bruce Momjian [EMAIL PROTECTED] writes:
Agreed. I wanted to put the ipv6 entry in there only if they compiled
with ipv6 suport, but that seemed strange to some, I think.
I would comment it out.
Done.
regards, tom lane
---(end of
At 11:44 AM 1/08/2003 +0800, Christopher Kings-Lynne wrote:
What I'd like to see it do is grab the dependency data in pg_depend and
do a topological sort using that.
At the end though, we'd need to dump stuff not caught be the topsort, for
cases where pg_depend has been messed with.
I have made
Does the new protocol fix the fact that psql \encoding doesn't see SET
CLIENT_ENCODING changes.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be
what determines what level of locking(table level, page level or row level)
an object is locked in?
how do we determine from postgresql code what level a object is locked in?
Iam working on a project where i have to display the locks information of
all the transactions that have acquired locks
Hi everyone,
I've just got our DBT-2 workload (TPC-C derivate) working with
PostgreSQL using C stored functions and libpq. I'd love to get some
feedback.
v0.10 is available on SourceForge at:
http://prdownloads.sourceforge.net/osdldbt/dbt2-v0.10.tar.gz?download
We keep the source in
Mark,
I've just got our DBT-2 workload (TPC-C derivate) working with
PostgreSQL using C stored functions and libpq. I'd love to get some
feedback.
I'm confused. Jenny Zhang just announced OSDL-DBT3 for Postgres; is this a
different test or does one of you have the name wrong?
--
-Josh
On Fri, Aug 01, 2003 at 05:05:18PM -0700, Josh Berkus wrote:
Mark,
I've just got our DBT-2 workload (TPC-C derivate) working with
PostgreSQL using C stored functions and libpq. I'd love to get some
feedback.
I'm confused. Jenny Zhang just announced OSDL-DBT3 for Postgres; is this a
On Fri, 2003-08-01 at 20:32, Mark Wong wrote:
On Fri, Aug 01, 2003 at 05:05:18PM -0700, Josh Berkus wrote:
Mark,
I've just got our DBT-2 workload (TPC-C derivate) working with
PostgreSQL using C stored functions and libpq. I'd love to get some
feedback.
I'm confused. Jenny
Bruce Momjian [EMAIL PROTECTED] writes:
Does the new protocol fix the fact that psql \encoding doesn't see SET
CLIENT_ENCODING changes.
regression=# \encoding
SQL_ASCII
regression=# set client_encoding TO unicode;
SET
regression=# \encoding
UNICODE
regression=#
regards,
OK, psql docs updated to remove mention of that problem.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Does the new protocol fix the fact that psql \encoding doesn't see SET
CLIENT_ENCODING changes.
Bruce Momjian [EMAIL PROTECTED] writes:
OK, psql docs updated to remove mention of that problem.
They already were, I thought.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Philip Warner [EMAIL PROTECTED] writes:
In terms of the dependency data, I was planning to dump dependencies as
well (a trivial skeleton exists); the ordering should happen at
restore-time (except dump should store it in useful-order on the assumption
that it will not be possible to
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, psql docs updated to remove mention of that problem.
They already were, I thought.
It was still mentioned in the psql manual page. I know because I added
it in 7.3, and it was still there.
--
Bruce Momjian
At 11:07 PM 1/08/2003 -0400, Tom Lane wrote:
So all the dependency info must appear at the front.
Correct. It currently gets stored in the TOC, which is at the front, and is
read into memory at the start of the restore process.
46 matches
Mail list logo
