d point @ polygon_field;
again, i haven't tested this to make sure that the index would be used
properly, but it should filter out enough of the chaff to make the query
reasonably fast. hope that helps (even more, i hope it works)
--
Jeff Hoffmann
PropertyKey.com
verification that a URL is valid and the ability to search the
URL's by hostname, protocol, etc. i can't say that i'd be that
interested in it, but that shouldn't stop somebody from thinking about
doing something like this.
--
Jeff Hoffmann
PropertyKey.com
option
for pg_dump, but it's really not that much more work to just pipe the
input and output through gzip.
--
Jeff Hoffmann
PropertyKey.com
t in there before because it wasn't really "free" software.
postgres (7.0.2) is indeed still in redhat 7, but with some of the
comments on the list about the RPMs, it's possible that it may not stay
as part of the distribution because of upgrading issues.
--
Jeff Hoffmann
PropertyKey.com
bout that. all
in all, i'm just not clear on why you're interested in the added
headache of multiple database systems & copying data between them.
--
Jeff Hoffmann
PropertyKey.com
Barnes wrote:
>
> Thank you. This works, and is close to what I need, but if I don't launch
> the postmaster from a window with PGDATA2 defined, such as is done with
> "/etc/init.d/postgresql start" or on a system boot, then it doesn't work. I
> tried to export PGDATA2 within /etc/init.d/postgr
Jeff Hoffmann wrote:
> select zip, location <@> '(lat, lon)'::box
> from zipcodes
> order by location <@> '(lat, lon)'::box
> limit 10;
>
oops, typo. those boxes should be points. plus, it looks like you can
get zipcodes & lat-longs
Richard J Kuhns wrote:
>
> Could anyone please tell me what I'm doing wrong? I'm sure I'm just
> overlooking something, but what?
>
> ==
>
> moran:/acct$ id
> uid=1007(postgres) gid=1003(postgres) groups=1003(postgres)
> moran:/acct$ export P=/acct/pindybook
first guess is
i've started testing version 7 with my databases (dumped and restored
from a 6.5.3 install) and it seems that none of the queries are
utilizing the rtree indexes like they should be. can somebody comment
on why this would be happening?
"Ross J. Reedstrom" wrote:
>
> On Wed, Dec 15, 1999 at 11:27:36AM -0400, The Hermit Hacker wrote:
> > On Wed, 15 Dec 1999, Jeff Hoffmann wrote:
> >
> > Most of my RAID tests are on Solaris+Disksuite...with good drives
> > in the machine, my write
The Hermit Hacker wrote:
>
> On Wed, 15 Dec 1999, Adam Rossi wrote:
>
> > I know this question has been asked before. I have seen it in the archives.
> > Unfortunately the archives are dead right now (any search will yield "no
> > results") and I need to make some decisions.
> >
> > Can anyone g
"Aaron J. Seigo" wrote:
> this needs to be in the back end... otherwise, if you have multiple people
> performing updates on different replicated servers, how can you guarentee
> concurancy? how do you manage the differences between read-only and updateable
> replicants? (this can be done using y
> Actually, it's just text. Here's a sample record:
>
> 10003 43140280 B Smallwood Road A31 13131891899301893018 9501 9501 227
> 222 -82521645+33638976 -82528956+33639940
>
> ...the CD-ROM "database" is about 600MB.
i never looked at the tiger that was that old, but i know that the new
ones f
David Giffin wrote:
>
> Hello,
>
> I'm trying to run postgres on two different post 5432 and port 5433 with
> different data directories for each instance:
>
> [ -x /usr/local/pgsql/bin/postmaster ] && {
> su -l postgres -c '/usr/local/pgsql/bin/postmaster -S -i'
> echo -n ' pgs
should be simple, but it seems to have disappeared from the locations
dredged up by altavista et al. anybody have a copy lying around?
thanks
jeff
>Jeff Hoffmann wrote:
>
>> i've just gotten around to upgrading to 6.4 on a couple of FreeBSD
(2.2.7)
>> servers, and i'm having problems creating databases in alternate
locations.
>> basically, here's what i did:
>>
>> 1) dumped the data
i've just gotten around to upgrading to 6.4 on a couple of FreeBSD (2.2.7)
servers, and i'm having problems creating databases in alternate locations.
basically, here's what i did:
1) dumped the data from a 6.3.2 install
2) compiled 6.4 (completely generically -- configure; make; make install)
3)
17 matches
Mail list logo
