The man page for createlang refers to the --echo option, but in fact
that option does not exist.
This patch implements it and also expands the man page for a couple of
options that were not documented.
diff -ur postgresql-7.1RC3/doc/src/sgml/ref/createlang.sgml
postgresql-7.1cRC3/doc/src/sgml/r
Franck Martin wrote:
> I have no idea if what I say is true about the PG distribution by PG people, but
> I have noticed than in the rpms of other distros the postgresql-devel rpms do not
> include all the .h files necessary to build PG extensions. For instance the
> rtree.h and itup.h and gist.h
Thomas Lockhart wrote:
>
> > > OTOH, if Marc was only thinking of removing the pre-built docs from the
> > > tarball, I don't object to that. I'm not sure why those weren't
> > > distributed as separate tarballs from the get-go. I just say that the
> > > doc sources are part of the source distr
The Hermit Hacker wrote:
> Okay, unless someone can come up with a really good argument *for* why
> docs has to be included as part of the main tar file, I'm going to change
> the distributin generating script so that it generates a .src.tar.gz file
> seperate from the .doc.tar.gz file, which will
On Sat, 7 Apr 2001, Lamar Owen wrote:
> The Hermit Hacker wrote:
> > Okay, unless someone can come up with a really good argument *for* why
> > docs has to be included as part of the main tar file, I'm going to change
> > the distributin generating script so that it generates a .src.tar.gz file
>
The Hermit Hacker wrote:
> there will be an RC4, I'm just waiting to hear back from Peter E as to
Good.
> whether there is anything in the build process we even risk breaking ...
> we've been doing the whole split thing for the past release or two as it
> is (the FreeBSD ports collection using t
Karl DeBisschop wrote:
> In my experience so far, it is also noticably slower than gzip. It does
> work, and it is available. I have not yet been convinced that the space
> savings is worth the time lost. But ISTM this is a minor point.
The official tarball is gzipped -- the RPM will use that unt
On Sat, 7 Apr 2001, Lamar Owen wrote:
> The Hermit Hacker wrote:
> > there will be an RC4, I'm just waiting to hear back from Peter E as to
>
> Good.
>
> > whether there is anything in the build process we even risk breaking ...
> > we've been doing the whole split thing for the past release or t
I searched for the error and I have found :
when I execute psql template0
the SIGSEGV is generated when postinit calls RelationPhaseInitializePhase2
in heap_openr with RelationName = pg_am at the return r I have the error.
when I execute psql template1
the SIGSEGV is generated when postinit call
The Hermit Hacker wrote:
> On Sat, 7 Apr 2001, Lamar Owen wrote:
> > Just not well-tested for the RPM build environment :-).
> Ya, but you could concievably test that now, without us doign an RC4 ..
> the files are all there :)
So the structure isn't going to change -- just there's not going to
I will save this for 7.2. Thanks.
> The man page for createlang refers to the --echo option, but in fact
> that option does not exist.
>
> This patch implements it and also expands the man page for a couple of
> options that were not documented.
>
> diff -ur postgresql-7.1RC3/doc/src/sgml/ref
Thomas Lockhart writes:
> > > The docs are ready for shipment.
> > Even better ...
> > Okay, let's let this sit as RC3 for the next week...
>
> I'll go ahead and start generating hardcopy, though I understand that it
> is no longer allowed into the shipping tarball :(
I'm not speaking about "all
The Hermit Hacker writes:
> At 2Meg, is there a reason why we include any of the docs as part of the
> standard tar ball? It shouldn't be required to compile, so should be able
> to be left out of the main tar ball and downloaded seperately as required
> .. thereby shrinking the distribution to
Bruce Momjian writes:
> Can we drop TODO.detail from the tarball too? No need to include that,
> I think. The web site has nice links to it now. Uncompressed it is
> 1.314 megs.
You see where this discussion goes? Do we want to go through each file
and argue whether it needs to be distribute
Tom Lane writes:
> OTOH, if Marc was only thinking of removing the pre-built docs from the
> tarball, I don't object to that. I'm not sure why those weren't
> distributed as separate tarballs from the get-go. I just say that the
> doc sources are part of the source distribution...
Why would yo
Lamar Owen writes:
> We're going to do this at this point in the release cycle? IOW, is
> there going to be an RC4 with this new packaging, or is the first-off
> tarball with new packaging going to be the *final* 7.1 release *raised
> eyebrow*?
>
> I am certainly NOT opposed to doing this -- jus
The Hermit Hacker writes:
> Okay, unless someone can come up with a really good argument *for* why
> docs has to be included as part of the main tar file,
Because people want to read the documentation.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
--
Bruce Momjian writes:
> A major issue is that we don't regenerate docs for 7.1.1 or later, so
Sure we do.
> the 7.1 docs carry for all the 7.1.X releases. That would seem to argue
> for a separate tarball for docs so people don't redownload the docs
> again for 7.1.1.
>
>
--
Peter Eisentraut
The Hermit Hacker writes:
> On Sat, 7 Apr 2001, Peter Eisentraut wrote:
>
> > The Hermit Hacker writes:
> >
> > > Okay, unless someone can come up with a really good argument *for* why
> > > docs has to be included as part of the main tar file,
> >
> > Because people want to read the documentatio
The Hermit Hacker writes:
> those that don't want it, it sames them 2meg of download time ...
Another way to save at least 1 MB of download time would be bzip2'ed
tarballs.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)--
Giles Lean <[EMAIL PROTECTED]> writes:
> It is still necessary to add -ltermcap after -ledit in
> src/Makefile.global to have functional history editing in psql.
This is a weakness in the configure script: it goes through a loop
where it tries to link a program that calls readline() with, in ord
> Bruce Momjian writes:
>
> > A major issue is that we don't regenerate docs for 7.1.1 or later, so
>
> Sure we do.
>
> > the 7.1 docs carry for all the 7.1.X releases. That would seem to argue
> > for a separate tarball for docs so people don't redownload the docs
> > again for 7.1.1.
I didn
On Sat, 7 Apr 2001, Peter Eisentraut wrote:
> Thomas Lockhart writes:
>
> > > > The docs are ready for shipment.
> > > Even better ...
> > > Okay, let's let this sit as RC3 for the next week...
> >
> > I'll go ahead and start generating hardcopy, though I understand that it
> > is no longer allo
Tom Ivar Helbekkmo writes:
> Giles Lean <[EMAIL PROTECTED]> writes:
>
> > It is still necessary to add -ltermcap after -ledit in
> > src/Makefile.global to have functional history editing in psql.
>
> This is a weakness in the configure script: it goes through a loop
> where it tries to link a pr
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> On such a platform it would hardly be possible to detect anything with any
> reliably. A linker that links a program "succesfully" while the program
> really needs more libraries to be runnable isn't very useful.
You're right, of course -- it's a b
Hi.
A few weeks (months?) ago I made a patch to the postgres
backend to get back the number of realized moves after
a MOVE command. So if I issue a "MOVE 100 IN cusrorname",
but there was only 66 rows left, I get back not only "MOVE",
but "MOVE 66". If the 100 steps could be realized, then
"MOVE
Hi!
I had very funny problems with "make install" of the
CVS version. The clue was a bit strange behavior of bash
(/bin/sh is only a link in my debian).
The whole thing is about wildcard expansion: there's an
option called nocaseglob. I never heard of it before,
but this was the cause for th
Since people suddenly seem to be suffering from bandwidth concerns I have
devised a new distribution split to address this issue. I propose the
following four sub-tarballs:
* postgresql-XXX.base.tar.gz3.3 MB
Everything not in one of the ones below.
* postgresql-XXX.opt.tar.gz 1.7 MB
E
Oh, I definitely like this ... and get rid of the *large* file, which will
save all the mirrors a good deal of space over time ...
On Sun, 8 Apr 2001, Peter Eisentraut wrote:
> Since people suddenly seem to be suffering from bandwidth concerns I have
> devised a new distribution split to addres
The Hermit Hacker wrote:
> Oh, I definitely like this ... and get rid of the *large* file, which will
> save all the mirrors a good deal of space over time ...
You gonna make a set of RC3 or 4 tarballs along these lines to test? I
want to try a build with this split before doing too much else --
As the subject says, PostgreSQL 7.1RC3 passes 'make check' when built
as a 64 bit application on HP-UX 11.00.
Yes Vince, I've added it to your results page too:
http://www.postgresql.org/~vev/regress/report.php?50
Regards,
Giles
---(end of broadcast)--
as soon as Peter commits the changes, I'll do up an RC4 with the new
format so that everyone can test it ...
On Sat, 7 Apr 2001, Lamar Owen wrote:
> The Hermit Hacker wrote:
> > Oh, I definitely like this ... and get rid of the *large* file, which will
> > save all the mirrors a good deal of sp
On Sat, 7 Apr 2001, The Hermit Hacker wrote:
>
> Oh, I definitely like this ... and get rid of the *large* file, which will
> save all the mirrors a good deal of space over time ...
>
> On Sun, 8 Apr 2001, Peter Eisentraut wrote:
>
> > Since people suddenly seem to be suffering from bandwidth con
You don't need pltcl, just libtcl.
>
> I tried to intall pltcl, but failed when I tried to build a
> pltcl.so
> it seems hangging on there forever, what's wrong??
>
> su-2.04# cd /work/src/pgsql702/src/pl/tcl/
> su-2.04# ls
> CVS mkMakefile.tcldefs.sh.in
> INSTALL
On Sat, 7 Apr 2001, Peter Eisentraut wrote:
> The Hermit Hacker writes:
>
> > Okay, unless someone can come up with a really good argument *for* why
> > docs has to be included as part of the main tar file,
>
> Because people want to read the documentation.
get postgresql.src.tar.gz
get postgres
Franck Martin wrote:
>
> I have no idea if what I say is true about the PG distribution by PG people, but
> I have noticed than in the rpms of other distros the postgresql-devel rpms do not
> include all the .h files necessary to build PG extensions. For instance the
> rtree.h and itup.h and gist
I tried to intall pltcl, but failed when I tried to build a
pltcl.so
it seems hangging on there forever, what's wrong??
su-2.04# cd /work/src/pgsql702/src/pl/tcl/
su-2.04# ls
CVS mkMakefile.tcldefs.sh.in
INSTALL modules
Makefile
> -Original Message-
> From: Mikheev, Vadim [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 04, 2001 3:37 AM
> To: 'Tom Lane'
> Subject: RE: [BUGS] Loosing files after backend crash
>
>
> 1. Indices could be recreated with REINDEX or pg_class could
> be queried
> with seq scan (s
>
>Hi EveryBody:
>
>How can i get the structure of a table (Fields names, data types, etc)
try this:
\d table
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddre
What I need to do to install libtcl
Do I still need to
createlang -d dbname pltcl??
and when??
Jie LIANG
St. Bernard Software
10350 Science Center Drive
Suite 100, San Diego, CA 92121
Office:(858)320-4873
[EMAIL PROTECTED]
www.stbernard.com
www.ipinc.com
On Sat, 7 Apr 2001, Bruce Momjian w
Michael Meskes wrote:
>
> On Tue, Apr 03, 2001 at 06:32:25PM +0300, Adriaan Joubert wrote:
> > we had a problem on Alpha that in interfaces/ecpg/lib/typename.c we
> > have
> > HAVE_LONG_INT_64 defined, but not HAVE_LONG_LONG_INT_64. Consequently no
>
> Sure since that means your long int a
Uploaded. Please take a look.
ftp://ftp.postgresql.org/pub/dev/test-rpms
There _are_ changes. I will detail the changes for the RC4 RPMset.
Karl's pl/perl changes will go into the next set. pg_dumplo will have a
built binary, to be located in /usr/lib/pgsql/contrib.
--
Lamar Owen
WGCR Intern
Hi!
I've noticed a pg_dump/pg_dumpall problem with timestamp variables, in
dumping the minute, and second values:
instead of dumping
12:01:00.00 it dumps out 12:60:00.00 which is not accepted when
restoring a database...
Gyuro Lehel
---(end of broadcast)---
We are just (as per other queries recently) building a new system
using postgresql as the backend database. 7.1 seems like it is going
give us a number of essential fixes and useful features that make it
worth waiting a while.
As I have not seen announcements of the beta and RC cuts on
pgsql-anno
No, I was wrong in even mentioning libpgtcl. You don't even need that.
pgmonitor does not connect to the database at any time. I should run as
a shell script if you have tcl/tk >= 8.0 installed.
>
> What I need to do to install libtcl
>
> Do I still need to
> createlang -d dbname pltcl??
> a
On Tue, 3 Apr 2001 14:10:12 -0700, Nathan Myers alluded:
> I saw three separate reports of successful builds on Linux 2.4.2 on x86
> (including mine), but it isn't listed here.
[jeff@cairhien pronto]$ /var/postgresql/bin/psql -V
psql (PostgreSQL) 7.1RC1
contains history support
..
[jeff@ca
Karl DeBisschop wrote:
> Actually, since you can suppress installation of the docs with --nodocs,
> I would very much prefer to keep the html and text docs in the main RPM.
> Otherwise I have two directories in /usr/doc for one software suite.
I'm researching how to get a subpackage to place docs
>> i will be reinstalling this SS20 with a full installation sometime in
>> the next few days. i will re-run the testsuite after this to see if
>> that is causing any of the lossage.
Please let us know.
actually, i had a classic i could test with -- all except horology passe
Hello all,
I would like to inform you all that I am currently working on the
implementation of PL/pgSQL packages on both server-side (PostgreSQL 7.1)
and client-side (PgAdmin).
The idea is to add an PL/pgSQL Integrated Development Environment to
pgadmin. Help and suggestions needed. If someone
>> digging into the regression.diffs, i can see that:
>> - reltime failed because it just had:
>> ! psql: Backend startup failed
The postmaster log file should have more info, but a first thought is
that you ran up against process or swap-space limitations. The parallel
On Fri, 06 April 2001, Tom Lane wrote:
>
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > Try using int2()/int4()/int8() instead of integer().
> >> Why is that NOT documented under "Matematical functions"?
>
> > Because we haven't received any patches to document it? ;)
>
> Or because it's no
matthew green <[EMAIL PROTECTED]> writes:
> digging into the regression.diffs, i can see that:
> - reltime failed because it just had:
> ! psql: Backend startup failed
>The postmaster log file should have more info, but a first thought is
>that you ran up against
A friend of mine (Matthew Green) mentioned that 7.1RC2 had NetBSD/powerpc
down as unttested, and asked me to test it. So here are the results:
On my NetBSD/macppc system running NetBSD 1.5, gmake check reported that 2
of 62 tests failed. I've attached regression.diff to this message.
The two tha
> >> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
> >> + ERROR: cannot read block 3 of hash_i4_index: Bad address
>
> "Bad address"? That seems pretty bizarre.
This is obviously something that shows up on _some_ NetBSD platforms.
The above w
One quick note -- since 'R' < 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already installed.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:
"Oliver Elphick" wrote:
>Debian packages of 7.1RC3 have been uploaded to the Debian experimental
>distribution and are also available at http://www.debian.org/~elphick/postgr
>esql
>
>These packages are built for sid (Debian unstable); I am currently
>trying to build a set for pota
Debian packages of 7.1RC3 have been uploaded to the Debian experimental
distribution and are also available at http://www.debian.org/~elphick/postgresq
l
These packages are built for sid (Debian unstable); I am currently
trying to build a set for potato (stable).
Incidentally, when the next re
Hi Peter ...
The problem this cycle has been that as soon as a package is ready
for announce, ppl have been cropping up with bugs that need to be fixed,
so we don't bother announcing it ... except to -hackers ...
We are currently at Release Candidate 3, with an RC4 most likely
g
On Sun, 08 Apr 2001 11:24, Peter Eisentraut wrote:
> Since people suddenly seem to be suffering from bandwidth concerns I
> have devised a new distribution split to address this issue.
[ ... snipping the many tarballs argument ... ]
For me and I expect many other folk on the edge of civiliz
Are up. Contrib subpackage includes built binaries.
Binary RPMset built for _Red_Hat_6.2_. I will be building Red Hat 7.0
RPMS after I get back from a two day vacation -- which will put me back
online Wednesday. I might get a set out for RH7 tomorrow, though.
The split to contrib and docs subp
On Sat, 7 Apr 2001, Lamar Owen wrote:
> One quick note -- since 'R' < 'b', the RC RPM's must be forced to
> install with --oldpackage, as RPM does a simple strcmp of version
> numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
> --oldpackage if you have a 7.1beta RPM already installe
61 matches
Mail list logo
