;s suspicious that the error message mentions libz.so when the actual
> file name is libz.so.1, but I still don't see how that could result in
> configure's link test succeeding but the executable not running.
That puzzles me as well. It seems to be because there is no libz.so
ils are:
1. My (relevant) environment:
LD_LIBRARY_PATH=/usr/openwin/lib:/usr/lib:/usr/ucblib:/usr/ccs/lib
PGLIB=/home/customer/selkovjr/pgsql/lib
PGDATA=/home/customer/selkovjr/pgsql/data
PATH=/usr/local/vendor/SUNWspro/bin:/usr/local/bin:/usr/local/gnu/bin:/usr/local/GNU/bin:/usr/sbin:/usr/bin:/u
I am sorry I wasn't listening -- I may have helped by at least
answering the direct questions and by testing. I have, in fact,
positively tested both my and Oleg's code in the today's snapshot on a
number of linux and FreeBSD systems. I failed on this one:
SunOS typhoon 5.7 Generic_106541-10 sun4
Tom Lane wrote:
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > We've done some work with GiST indices and found a little problem
> > with optimizer.
>
> > test=# set enable_seqscan = off;
> > SET VARIABLE
> > test=# explain select * from test where s @ '1.05 .. 3.95';
> > NOTICE: QUERY PLAN:
>
Tom Lane wrote:
> Do you have any problem with releasing your stuff under the Postgres
> distribution terms (BSD license)?
No, I don't see any problem with the BSD license, or any other
license, for that matter. I just had some reservations about releasing
stuff that was far from perfect, and it
Franck Martin wrote:
> I have already created geographical objects which contains MBR(Minimum
> Bounding Rectangle) in their structure, so it is a question of rewriting
> your code to change the access to the cube structure to the MBR structure
> inside my geoobject. (cf http://fmaps.sourceforge.n
the current version of regression
tests for the data types that depend on it. One can find them in my
contrib directory, under test/ (again, it's
http://wit.mcs.anl.gov/~selkovjr/pg_extensions/contrib.tgz)
It would be nice if at least one of the GiST types became a built-in
(that would provide for
eral access method built on top of R-tree to provide
a user-friendly interface to it and to allow indexing of more abstract
types, for which straight R-tree is not directly applicable.
I have a small set of complete data types, of which a couple
illustrate the use of GiST indexing with the
Mark Hollomon wrote:
> Correct. I don't know why anyone would want to change the definition of
> (say) int48eq, but if we are going to allow them to do so, we should be
> careful to allow them to backup and restore such a change.
Yes, and it is also important that if such weirdos exist, they are
Philip Warner wrote:
> I think both this and the OID-wrap problem will be permanent features until
> we have a non-oid-based dump procedure. Pretty much every piece of metadata
> needs some kind of 'I am a system object, don't dump me' flag.
Curiously enough, Philip, you seem to have been ahea
Jan Wieck wrote:
> Tom Lane wrote:
> > Philip Warner <[EMAIL PROTECTED]> writes:
> > > Where would you store the value if not in pg_database?
> >
> > No other ideas at the moment. I was just wondering whether there was any
> > way to delete it entirely, but seems like we want to have the value fo
11 matches
Mail list logo
