Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Offhand I don't see a related change in pg_dump in
> recent times, so it probably isn't necessarily an upgrade related issue,
> it might be an inconsistent schema.
The proximate cause is that I changed pg_index.indproc from plain "oid"
to "regproc" a
Some people have suggested we develop a roadmap of future pgsql
releases. As you can see in this Mozilla article, having a roadmap just
means you get to change it often: :-)
http://mozillaquest.com/Mozilla_News_01/Mozilla_RoadMap_17aug01_Story01.html
--
Bruce Momjian
Here are a few dates of interest:
Monday-Friday: Tom, Jan, and I will be at LinuxWorld in San
Francisco. Vadim will be at LinuxWorld too, but of course he lives in
San Francisco.
Beta may start as soon as Saturday, September 1. I know Tom has
mentioned it and no one has said a
> > > > Is it crazy to
> > > > put md5.c in interfaces/odbc and symlink it from there to backend/libpq
> > > > and interfaces/libpq?
> > >
> > > YES, that's crazy. If you think ODBC should build separately, then give
> > > it its own copy of md5.c. But please first check that your assumption
> >
* Peter Eisentraut <[EMAIL PROTECTED]> [010826 20:23]:
> Larry Rosenman writes:
>
> > pg_dump: query to get function name of oid - failed: ERROR: oidin:
> > error in "-": can't parse "-"
>
> It's trying to dump a functional index but the function appears to be
> absent. (Therefore the name com
Bruce Momjian wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > In trying to decide how to keep ODBC compilable standalone, I can't
> > > figure out how to get md5.c in there from backend/libpq.
> >
> > AFAIK ODBC hasn't been compilable standalone for awhile; doesn't it
> > depend on ou
Larry Rosenman writes:
> pg_dump: query to get function name of oid - failed: ERROR: oidin:
> error in "-": can't parse "-"
It's trying to dump a functional index but the function appears to be
absent. (Therefore the name comes out as '-'.) It's hard to tell which
index this is because the qu
Larry Rosenman <[EMAIL PROTECTED]> writes:
> NOW, do we need a regression test for pg_dump?
We always have and still do (isn't it on the TODO list?). Some Great
Bridge people have been poking at the problem but haven't yet come up
with a clean answer AFAIK. The obvious approach of dumping and
* Tom Lane <[EMAIL PROTECTED]> [010826 19:39]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > pg_dump: query to get function name of oid - failed: ERROR: oidin:
> > error in "-": can't parse "-"
>
> Actually, I'm seeing it here too ... seems to have been a side-effect
> of the change that I re
* Tom Lane <[EMAIL PROTECTED]> [010826 19:25]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > I had upgraded yesterday and *THOUGHT* all was fine.
> > Forgot to pg_dump, so I restored my $PGLIB and bin directory, now get
> > the following when I try to pg_dump:
>
> Uh ... you did what exactly?
I had upgraded yesterday and *THOUGHT* all was fine.
Forgot to pg_dump, so I restored my $PGLIB and bin directory, now get
the following when I try to pg_dump:
$ pg_dump ler >z
Password:
pg_dump: query to get function name of oid - failed: ERROR: oidin:
error in "-": can't parse "-"
$
And t
In current sources, lock.c's LockDisable() function is called only
for bootstrapping or if the (useless) -L backend switch is used.
I have verified that it's not needed for bootstrapping: initdb
succeeds just fine without it. Accordingly, I'm strongly tempted
to remove the function, the switch, a
* Peter Eisentraut <[EMAIL PROTECTED]> [010826 17:42]:
> I've checked in a fix for the runpath, DESTDIR, and VPATH problems. The
> first needs to be tested on a variety of platforms because I had to guess
> the osname configuration values and the linker/compiler that Perl uses.
I ass/u/me that yo
I've checked in a fix for the runpath, DESTDIR, and VPATH problems. The
first needs to be tested on a variety of platforms because I had to guess
the osname configuration values and the linker/compiler that Perl uses.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Trond Eivind Glomsrød writes:
>
> > > Pg.so does not get the proper RPATH in a DESTDIR build environment.
> >
> > Rather: Perl decides it wants to specify a LD_RUN_PATH in its makefile.
> > This will automatically make use of -R. It's fixed in the R
Trond Eivind Glomsrød writes:
> > Pg.so does not get the proper RPATH in a DESTDIR build environment.
>
> Rather: Perl decides it wants to specify a LD_RUN_PATH in its makefile.
> This will automatically make use of -R. It's fixed in the RPMs
> available at http://people.redhat.com/teg/pg/
AFAIC
Lamar Owen <[EMAIL PROTECTED]> writes:
> On Saturday 25 August 2001 19:18, Peter Eisentraut wrote:
> > AFAICT, Pg.so does get the runpath set correctly. Are you saying it
> > doesn't work on your system or do you want to get rid of the
> > recompilation during installation?
>
> Pg.so does not g
* Tom Lane <[EMAIL PROTECTED]> [010826 11:11]:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Another fun feature of the DESTDIR build environment is that the
> > writability test of the target directory will most likely fail because it
> > doesn't exist at all.
>
> > I've been thinking how I
I like the change.
> Leandro Fanzone <[EMAIL PROTECTED]> writes:
> > I have compiled PostgreSQL 7.1.2 with gcc 3.0.1, and have the following
> > problem: if I include first libpq++.h before iostream, id est:
> > #include
> > #include
> > the compiler complains:
>
> > This is because somewhere
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Another fun feature of the DESTDIR build environment is that the
> writability test of the target directory will most likely fail because it
> doesn't exist at all.
> I've been thinking how I'd like to fix this: We add an option to
> configure that
Lamar Owen writes:
> Pg.so does not get the proper RPATH in a DESTDIR build environment.
>
> Trying to fix this for the RPMS -- the RPATH contains the buildroot instead
> of where the libs really are. Could cause security problems. Working on it,
> but it's slow going for me at this busy time.
21 matches
Mail list logo
