Tom Lane <[EMAIL PROTECTED]> wrote:
[snip]
>
> Exactly how much work (and code bulk) would we be taking on? I've
> never looked at how big the timezone databases are...
>
Some answers on database sizes, if this is any help...
I did "du -sh /usr/share/zoneinfo/" on them all.
OpenBSD
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> Why should we rely on broken glibc and the standard? Why don't we make
>> our own mktime() and use it on all platforms.
> The downside to doing that is that we then take over maintenance of the
> code and, more importantly, the timezone database.
>
...
> Why should we rely on broken glibc and the standard? Why don't we make
> our own mktime() and use it on all platforms.
The downside to doing that is that we then take over maintenance of the
code and, more importantly, the timezone database.
But it might be the best thing to do. It looks l
> On Tue, 21 May 2002 14:27:00 -0600 (MDT)
> "Bear Giles" <[EMAIL PROTECTED]> wrote:
> > A second cut at SSL documentation
> [snip]
> > To set up a SSH/OpenSSH tunnel, a shell account for each
> > user should be set up on the database server. It is acceptable
> > for the shell program to b
> On Wed, 2002-05-22 at 15:30, Thomas Lockhart wrote:
> > > IIRC the spec is not _really_ broken - it still allows the correct
> > > behaviour :)
> >
> > Yes.
> >
> > > The fact the ISO spec is broken usually means that at least one of the
> > > big vendors involved in ISO spec creation must hav
> > ./configure --help
> > Isn't anywhere else yet.
> Not seeing it. Is this a 7.3 thing? What does it do?
Sorry, yes it is a 7.3 thing.
- Thomas
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PR
Thomas,
> ./configure --help
>
> Isn't anywhere else yet.
Not seeing it. Is this a 7.3 thing? What does it do?
--
-Josh Berkus
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs
> > This is due to floating point rounding issues on output. Try configuring
> > and compiling with --enable-integer-datetimes and you should see this go
> > away.
> Hey, where is this compile-time option documented? It may have part of the
> functionality I need.
./configure --help
Isn't anywh
I sent this earlier, but accidently sent it from the wrong account
and it's been sitting in the pending spool all day.
Since writing it, I've sketched in server-side GSS-API and SASL
support for my prior patches. The objective isn't to immediately
support either, but to ensure that future suppor
> > OK. They must be new guys.
> :-) Very funny.
Hey, it worked. Got you out of the woodwork. :))
- Thomas
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourE
See http://www.vividsolutions.com/jts/jtshome.htm for a robust set of
algorithms in Java which do all the spatial predicates (the 3x3
Egenhofer matrix). Also union, difference, and buffer. It is licenced
LGPL. Also see PostGIS (http://postgis.refractions.net) (licenced GPL)
for a set of PostgreSQL
Hi guys,
Just in case anyone is around, I've recently
arrived in Costa Mesa, California from Australia for a couple of weeks on
business. So, if anyone's in the area - it might be cool to catch
up...
Chris
Neil Conway <[EMAIL PROTECTED]> writes:
> The current KSQO code is currently #ifdef'ed out, and the 'ksqo' GUC
> variable does nothing. Is there a reason for keeping this code around?
> (or conversely, what was the original justification for disabling it?)
I disabled it because I didn't have time
Manfred Koizar <[EMAIL PROTECTED]> writes:
> So it looks save to use this bit for marking dead tuples. Wouldn't it
> be even possible to simply reset LP_USED instead of setting
> LP_DELETED?
Mmmm ... I don't think so. That would cause the tuple to actually
disappear from the perspective of the
This might be a possible fit:
http://www.magic-software.com/Applications.html
(see "Boolean operations on 2D polygons. Based on BSP trees" near the
bottom of the page).
The license agreement might be acceptable. I'm not a lawyer, so I can't
be sure how free it really is to use from reading this:
> -Original Message-
> From: Kenneth Chan [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 22, 2002 12:24 PM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] A more precise polygon_overlap()
>
>
> Gents,
>
> I am looking for a more precise polygon overlap test and any
> comment/pointers/s
On Tue, 21 May 2002 12:48:39 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>4. How exactly should a killed index tuple be marked on-disk? While there
>is one free bit available in IndexTupleData.t_info, I would prefer to use
>that bit to expand the index tuple size field to 14 bits instead of 13.
>(
Gents,
I am looking for a more precise polygon overlap test and any
comment/pointers/suggestions are appreciated. Attached is the modified poly_overlap
in geoops.c.
If the polygons pass the bounding box check, the following tests will be carried out.
The tests are terminated as soon as on
The current KSQO code is currently #ifdef'ed out, and the 'ksqo' GUC
variable does nothing. Is there a reason for keeping this code around?
(or conversely, what was the original justification for disabling it?)
Should I just send in a patch getting rid of it?
Cheers,
Neil
--
Neil Conway <[EMA
This thread is getting pretty annoying rather than constructive. By
the mean time I can see the users of many db's running under linux
loudly complaining.
As a user of both products (glibc and postgres), I would like to see a
good compromise in both sides. For instance: postgreSQL will implement
On Wednesday 22 May 2002 01:58 pm, Ulrich Drepper wrote:
> On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
> > What isn't funny is Oliver Elphick's results on Debian, running glibc
> > 2.2.5 (same as Red Hat 7.3's version).
> This is a completely different version. Once Debian updates (in a few
>
Ulrich Drepper <[EMAIL PROTECTED]> writes:
> If you are misusing interfaces you get what you deserve. At no time was
> it correct to use these functions for general date manipulation. It
> always only was allowed to use them to represent system times and there
> was no Unix system before the epo
On Wednesday 22 May 2002 01:12 pm, Ulrich Drepper wrote:
> On Wed, 2002-05-22 at 08:00, Thomas Lockhart wrote:
> > > > If so, can we get them to champion changes which would comply with
> > > > the standard but remove this arbitrary breakage?
> > > Unlikely. They already saw (and participated, at
Jan Wieck <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Right, that's why I said that the limit would only go up to ~10K anyway;
>> btree won't take keys > 1/3 page.
> What's the point then?
Well, btree's not the only index access method we have. I'm not sure
whether gist or rtree allow
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Also, in btree haven't we had some problems with index page
> > splits when using entries large enought so that not at least
> > 3 of them fit on a page?
>
> Right, that's why I said that the limit would only go up to ~10K
>From a recent bug report:
test72=# create sequence s;
CREATE
test72=# begin;
BEGIN
test72=# select nextval('s');
nextval
-
1
(1 row)
test72=# drop sequence s;
DROP
test72=# end;
NOTICE: LockRelease: no such lock
COMMIT
The NOTICE is a symptom of bad problems underneath (memory
Jan Wieck <[EMAIL PROTECTED]> writes:
> Also, in btree haven't we had some problems with index page
> splits when using entries large enought so that not at least
> 3 of them fit on a page?
Right, that's why I said that the limit would only go up to ~10K anyway;
btree won't take ke
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On Wed, 2002-05-22 at 12:28, Zeugswetter Andreas SB SD wrote:
> >> While I agree that it might be handy to save this bit for future use,
> >> I do not see any value in increasing the max key length from 8k,
>
> > I'm not sure if it ap
Switched to -hackers from -sql and -bugs.
On Tue, 2002-05-21 at 16:24, Thomas Lockhart wrote:
>
> You can continue to explore the current behavior and to form an opinion
> on what correct behavior should be. I've resisted adding fields to the
> internal interval type for performance and design r
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> There seems to be a pg_dump issue with inherited tables when columns
> are added to the parent table after creating the child table.
It's always been there --- ever tried dumping and reloading the
regression database?
Right now the only safe way t
On Wed, 22 May 2002, Thomas Lockhart wrote:
> > IIRC the spec is not _really_ broken - it still allows the correct
> > behaviour :)
>
> Yes.
>
> > The fact the ISO spec is broken usually means that at least one of the
> > big vendors involved in ISO spec creation must have had a broken
> > impl
> There are certain oddities in current interval behaviour:
> template1=# select '125.567772 seconds'::interval(12);
> ERROR: INTERVAL(12) precision must be between 0 and 6
> The documentation says 0 and 13 (users' manual 3.5.1.6).
OK, docs need fixing.
> Then there seem to be some
Shra wrote:
> hi,
> can v define our own datatype n use it in PostgreSQL tables?
> Shra
u can
Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.
...
> > AIX and (I think) Irix.
> How do we currently support AIX/Irix ?
Dates and times prior to 1970 have no time zone (they are in GMT, as is
the case for all platforms on dates before 1903 and after 2038). We have
separate regression test results for those platforms.
Thomas Lockhart writes:
> Right. IBM.
> > Most likely they have fixed it by now ...
> Nope, though I don't know for sure. Anyone here have a recent AIX
> machine to test?
Well on AIX 4.3.3 the output from Lamar's earlier test program is:
The system thinks 11/30/1969 is a timestamp of -1
a
I have looked at the cube datataype in the contrib but I''m not sure
that I'm on the right way
I have found these functions:
-- support routines for indexing
CREATE FUNCTION cube_union(cube, cube) RETURNS cube
AS 'MODULE_PATHNAME' LANGUAGE 'c' with (isstrict);
CREATE FUNCTION cube_int
There seems to be a pg_dump issue with inherited tables when columns
are added to the parent table after creating the child table. Here is
how to repeat the problem.
Create a test database and run the following SQL statements:
create table a (x int);
create table b (y int) inherits (a);
alter t
On Wed, 2002-05-22 at 15:30, Thomas Lockhart wrote:
> > IIRC the spec is not _really_ broken - it still allows the correct
> > behaviour :)
>
> Yes.
>
> > The fact the ISO spec is broken usually means that at least one of the
> > big vendors involved in ISO spec creation must have had a broken
>
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Wed, 2002-05-22 at 12:28, Zeugswetter Andreas SB SD wrote:
>> While I agree that it might be handy to save this bit for future use,
>> I do not see any value in increasing the max key length from 8k,
> I'm not sure if it applies here, but key length
> IIRC the spec is not _really_ broken - it still allows the correct
> behaviour :)
Yes.
> The fact the ISO spec is broken usually means that at least one of the
> big vendors involved in ISO spec creation must have had a broken
> implementation at that time.
Right. IBM.
> Most likely they hav
hi,
can v define our own datatype n use it in PostgreSQL tables?
Shra
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
> >
> > But I recall a number of rounds of bug-fixes concerning quoting in
> > the pgsql shell scripts, so I'd not be surprised in the
> least to hear
> > that pre-7.2 PG releases get this wrong. Or for that
> matter, we might
> > still have some problems in this line on some platforms with od
On Wed, 2002-05-22 at 12:28, Zeugswetter Andreas SB SD wrote:
> > 4. How exactly should a killed index tuple be marked on-disk? While there
> > is one free bit available in IndexTupleData.t_info, I would prefer to use
> > that bit to expand the index tuple size field to 14 bits instead of 13.
> >
> 4. How exactly should a killed index tuple be marked on-disk? While there
> is one free bit available in IndexTupleData.t_info, I would prefer to use
> that bit to expand the index tuple size field to 14 bits instead of 13.
> (This would allow btree index entries to be up to 10K when BLCKSZ is 3
On Sun, May 19, 2002 at 04:19:58PM -0400, Tom Lane wrote:
> Michael Meskes <[EMAIL PROTECTED]> writes:
> > Haven't found time to dig into this. So be careful, current CVS WILL NOT
> > COMPILE!
>
> If you're not going to fix it right away, would you mind reverting the
> commit?
Sorry, I just foun
There are certain oddities in current interval behaviour:
template1=# select version();
version
--
PostgreSQL 7.3devel on i686-pc-linux-gnu, compiled by GCC
46 matches
Mail list logo
