

 Hi hackers,

 1) I programming to_char() routine (inspire with oracle, and with good 
    advice from Thomas L.) Current version is on 
    ftp://ftp2.zf.jcu.cz/users/zakkr/pg/ora_func.tar.gz, 

    (In future I want implement more (oracle compatible routines (to_date, 
    to_number.. and more)..)

 2) I have comlete imlementation of MD5 routine for PqSQL 
    (ftp://ftp2.zf.jcu.cz/users/zakkr/pg/md5.tar.gz). As base for source code
    is used code from Debian md5sum. In Debian is this code distributed 
    _without_ some restriction under GPL. Is any problem add this code 
    (if we want) to PgSQL contrib? 

    (If it is not problem I can try make more routines based on md5
    (aggregate func. - md5_count() ...etc)).

 I enclose description for the current version of to_char(). Please, send me 
 any commets.. 

							Zakkr

------------------------------------------------------------------------------
TO_CHAR(datetime, text)
 
	* now is not supported:
		- spelled-out SP suffix
		- AM/PM
		- ...and not supported number to character converting
		TO_CHAR(number, 'format')

	* now is supported:

		suffixes:
			TH ot th	- ordinal number							
			FM		- fill mode
	
	  	HH 	- hour of day (01-12)
	 	HH12	-  -- // --
	 	HH24	- hour (00-24)
	 	MI	- minute (00-59)
	 	SS	- socond (00-59)
	 	SSSS	- seconds past midnight (0-86399)	
	 	Y,YYY	- year with comma (full PgSQL datetime range) digits) 
	 	YYYY	- year (4 and more (full PgSQL datetime range) digits) 
	 	YYY	- last 3 digits of year 
	 	YY	- last 2 digits of year 
	 	Y	- last digit of year 
	 	MONTH	- full month name (upper) (9-letter)
	 	Month	- full month name - first character is upper (9-letter)
	 	month	- full month name - all characters is upper (9-letter) 
		MON	- abbreviated month name (3-letter)
		Mon	- abbreviated month name (3-letter) - first character is upper 
		mon	- abbreviated month name (3-letter) - all characters is upper 
		MM	- month (01-12)
	 	DAY	- full day name (upper) (9-letter)
	 	Day	- full day name - first character is upper (9-letter)
		day	- full day name - all characters is upper (9-letter)
	 	DY	- abbreviated day name (3-letter) (upper)
	 	Dy	- abbreviated day name (3-letter) - first character is upper 
	 	Dy	- abbreviated day name (3-letter) - all character is upper 
	 	DDD	- day of year (001-366)
	 	DD	- day of month (01-31)
	 	D	- day of week (1-7; SUN=1)
	 	WW	- week number of year
	 	CC	- century (2-digits)
		Q	- quarter
		RM	- roman numeral month (I=JAN; I-XII)
		W	- week of month 
		J	- julian day (days since January 1, 4712 BC)

	* Other:
		\
			- must be use as double \\
			- if \\ is in front " is \\ direct character
			ex:	
				\\	-is->	\
				\\"	-is->	"
		
		" of text "	
			- all between " is output as text (not parsed) 		
			
	* Note:
	
	- as base for date and time is used full PostgreSQL DateTime range

* Examples:
	
template1=> select to_char('now', 'HH24:MI:SS, Day, Month, Y,YYY');
to_char
-------------------------------------
16:53:17, Friday   , October  , 1,999

template1=> select to_char('now', 'HH24:MI:SS, FMDay, FMMonth, Y,YYY');
to_char
--------------------------------
16:55:47, Friday, October, 1,999

template1=> select to_char('now', 'DDDth DDDTH SSth Y,YYYth FMSSth');
to_char
----------------------------
288th 288TH 02nd 1,999th 2nd

template1=> select to_char('now', 'Hello HH:MI:SS day');
to_char
------------------------
Hello 05:00:12 friday

template1=> select to_char('now', 'Hello "day" HH:MI:SS day');
to_char
----------------------------
Hello day 05:00:33 friday

template1=> select to_char('now', '\\"Hello "day" HH:MI:SS FMday\\"');
to_char
---------------------------
"Hello day 05:01:15 friday"

template1=> select to_char('now', 'HH\\MI\\SS');
to_char
--------
05\10\29

---end-to_char()

------------------------------------------------------------------------------
ORDINAL(int4, text)
	
	* Translate number to ordinal number and return this as text


* Examples: 

template1=> select ordinal(21212, 'TH');
ordinal
-------
21212ND

template1=> select ordinal(21212, 'th');
ordinal
-------
21212nd

---end-ordinal()

------------------------------------------------------------------------------


 


Sat, 16 Oct 1999 15:01:02 +0200 (CEST)
Zakkr <zakkr@zf.jcu.cz>
to_char(), md5()   (long)
Zakkr wrote:
 
  > 2) I have comlete imlementation of MD5 routine for PqSQL 
  >    (ftp://ftp2.zf.jcu.cz/users/zakkr/pg/md5.tar.gz). As base for source cod
      >e
  >    is used code from Debian md5sum. In Debian is this code distributed 
  >    _without_ some restriction under GPL. Is any problem add this code 
  >    (if we want) to PgSQL contrib? 
 
Just to clarify this, this text is from the copyright statement of the
Debain dpkg package, which contains /usr/bin/md5sum:

  /usr/bin/md5sum is compiled from md5.[ch] (written by Colin Plumb in
  1993 and modified by Ian Jackson in 1995) and md5sum.c (written by
  Branko Lankester in 1993 and modified by Colin Plumb in 1993 and Ian
  Jackson in 1995).  The sources and the binary are all in the public
  domain.
-- 
      Vote against SPAM: http://www.politik-digital.de/spam/
                 ========================================
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
               PGP key from public servers; key ID 32B8FAA1
                 ========================================
     "But be ye doers of the word, and not hearers only, 
      deceiving your own selves."              James 1:22 



Sat, 16 Oct 1999 17:27:40 +0100
"Oliver Elphick" <olly@lfix.co.uk>
Re: [HACKERS] to_char(), md5() (long) 


On Sat, 16 Oct 1999, Oliver Elphick wrote:

> Zakkr wrote:
>  
>   > 2) I have comlete imlementation of MD5 routine for PqSQL 
>   >    (ftp://ftp2.zf.jcu.cz/users/zakkr/pg/md5.tar.gz). As base for source cod
>       >e
>   >    is used code from Debian md5sum. In Debian is this code distributed 
>   >    _without_ some restriction under GPL. Is any problem add this code 
>   >    (if we want) to PgSQL contrib? 
>  
> Just to clarify this, this text is from the copyright statement of the
> Debain dpkg package, which contains /usr/bin/md5sum:
> 
>   /usr/bin/md5sum is compiled from md5.[ch] (written by Colin Plumb in
>   1993 and modified by Ian Jackson in 1995) and md5sum.c (written by
>   Branko Lankester in 1993 and modified by Colin Plumb in 1993 and Ian
>   Jackson in 1995).  The sources and the binary are all in the public
>   domain.

 Yes, if I good understand it is not problem (md5sum not has RSA or non-US
restriction (instead of other cryp. sofrware) ..or not? 

							Zakkr
  


Mon, 18 Oct 1999 08:37:49 +0200 (CEST)
Zakkr <zakkr@zf.jcu.cz>
Re: [HACKERS] to_char(), md5() (long) 
Zakkr wrote:
 
  >>   /usr/bin/md5sum is compiled from md5.[ch] (written by Colin Plumb in
  >>   1993 and modified by Ian Jackson in 1995) and md5sum.c (written by
  >>   Branko Lankester in 1993 and modified by Colin Plumb in 1993 and Ian
  >>   Jackson in 1995).  The sources and the binary are all in the public
  >>   domain.
  >
  > Yes, if I good understand it is not problem (md5sum not has RSA or non-US
  >restriction (instead of other cryp. sofrware) ..or not? 
 
`Public domain' means anybody can do whatever they like with it.  The
author has abandoned control altogether.  This is a matter of copyright.  It
is entirely separate from USA's insane export-control regulations and patents. 


-- 
      Vote against SPAM: http://www.politik-digital.de/spam/
                 ========================================
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
               PGP key from public servers; key ID 32B8FAA1
                 ========================================
     "Delight thyself also in the LORD; and he shall give 
      thee the desires of thine heart."          Psalms 37:4



Mon, 18 Oct 1999 12:33:52 +0100
"Oliver Elphick" <olly@lfix.co.uk>
Re: [HACKERS] to_char(), md5() (long) 
The following is the next-to-last paragraph on our main news page:

RedHat RPMs for v6.5.1 on i386 machines are now available at
ftp://postgresql.org/pub/RPMS/ Please report any questions or problems
to pgsql-ports@postgresql.org. For details check out the Latest News. 

RPMs for v6.5.2 are available, built by Lamar, and we need to get
these posted at postgresql.org (they are shipping with the latest RH
release already). Lamar, I dropped the ball on this; where would I
pick up the RPMs?

                      - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Tue, 19 Oct 1999 14:49:35 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Need refresh on main page...


On Tue, 19 Oct 1999, Lamar Owen wrote:

> Vince Vielhaber wrote:
> > Actually that's on our main page, which is just announcements.  The news
> > page (Latest News on the menu bar) gets quite involved.  Would someone
> > care to give me some updated text for that as well?
> 
> "RPM's for PostgreSQL 6.5.2 are now available, and shipped with RedHat
> Linux version 6.1.  Included in these RPMS:
> 

Hmm RedHat, and for Debian (and people which needn't Hat for comp-work:-) exists 
package with 6.5.2?

------------------------------------------------------------------------------
<zakkr@zf.jcu.cz>                                http://home.zf.jcu.cz/~zakkr/

Kim Project:  http://home.zf.jcu.cz/~zakkr/kim/              (process manager)
FTP:          ftp://ftp2.zf.jcu.cz/users/zakkr/              (C/ncurses/PgSQL)
------------------------------------------------------------------------------
                                                   ...and cathedral dilapidate


Tue, 19 Oct 1999 17:13:02 +0200 (CEST)
Zakkr <zakkr@zf.jcu.cz>
Re: [HACKERS] Re: Need refresh on main page...
On Tue, 19 Oct 1999, Thomas Lockhart wrote:

> The following is the next-to-last paragraph on our main news page:
> 
> RedHat RPMs for v6.5.1 on i386 machines are now available at
> ftp://postgresql.org/pub/RPMS/ Please report any questions or problems
> to pgsql-ports@postgresql.org. For details check out the Latest News. 
> 
> RPMs for v6.5.2 are available, built by Lamar, and we need to get
> these posted at postgresql.org (they are shipping with the latest RH
> release already). Lamar, I dropped the ball on this; where would I
> pick up the RPMs?

Actually that's on our main page, which is just announcements.  The news
page (Latest News on the menu bar) gets quite involved.  Would someone
care to give me some updated text for that as well?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
  # include <std/disclaimers.h>       Have you seen http://www.pop4.net?
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Tue, 19 Oct 1999 11:13:27 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: Need refresh on main page...
Thomas Lockhart wrote:
 
> RPMs for v6.5.2 are available, built by Lamar, and we need to get
> these posted at postgresql.org (they are shipping with the latest RH
> release already). Lamar, I dropped the ball on this; where would I
> pick up the RPMs?

There are now many sites -- the best connected of which is rufus.w3.org.

If you use wget, try
wget ftp://rufus.w3.org/linux/redhat/redhat-6.1/SRPMS/SRPMS/postgr*
to get the source rpm.

Binaries for RedHat 6.1 are in 
ftp://rufus.w3.org/linux/redhat/redhat-6.1/i386/RedHat/RPMS/postg*

Binaries for RedHat 6.0 and RedHat 5.2 are only available on my site so
far:
wget -r http://www.ramifordistat.net/postgres/RPMS

All binaries mentioned are Intel.  RedHat 6.1, of course, also shipped
for sparc and Alpha -- rufus is a good mirror.

I would like to hear from someone who will try the RedHat 6.1 RPMS on a
RedHat 6._0_ system -- if they work fine, I'll remove the 6.0 rpms, and
replace with the 6.1 RPM's.  I had already updated my systems, quite
foolishly, to 6.1, when I realized that RPMS built on 6.1 _might_ not
run on 6.0.  I should have run the 6.1 RPMset on 6.0 first, but I
didn't.  6.1 is too nice to downgrade from, IMO.

If, OTOH, they don't work fine, well, I'll cross that bridge when I come
to it.  That bridge will involve me blowing RedHat 6.0 back into one
partition on my dev box, just like 5.2 has its own partition.

If any developers who want to try the RPM's, but do not have RedHat and
don't want to pay $30 for a set of CD's, check out www.cheapbytes.com --
cheapest place on the Internet for Linux and *BSD CD's.  $1.99 US will
get you a RedHat 6.1 CD (plus shipping). Of course, you can download the
ISO images and burn your own CD....

BTW: Only one bug in the 6.5.2-1 RPMS has been reported to Bugzilla
(developer.redhat.com/bugzilla) -- and that was the lack of
postgresql-clients (needless to say, the bug was quickly resolved ;-)).

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tue, 19 Oct 1999 11:18:12 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: Need refresh on main page...
Vince Vielhaber wrote:
> Actually that's on our main page, which is just announcements.  The news
> page (Latest News on the menu bar) gets quite involved.  Would someone
> care to give me some updated text for that as well?

"RPM's for PostgreSQL 6.5.2 are now available, and shipped with RedHat
Linux version 6.1.  Included in these RPMS:

* Functional pgAccess 0.98
* Patches to support the Alpha under RedHat Linux
* The regression tests (postgresql-test*.rpm)
* Updated man pages from Thomas Lockhart
* Patches from Thomas Lockhart to gram.y
* Migration scripts to aid in moving between database file formats
* The PostgreSQL-HOWTO.

To install, simply use 'rpm -i' to install each RPM you want.  A minimal
server installation is postgresql and postgresql-server.  The first time
the init script is run, the database structure will automatically be
created if one doesn't already exist.

To upgrade, simply use 'rpm -U' to upgrade each rpm.  The
postgresql-clients rpm found in versions prior to 6.5 has been split up
into several different packages, and will be removed in the upgrade. 
After performing 'rpm -U', please read the file
'/usr/doc/postgresql-6.5.2/README.rpm' for instructions on completing
the upgrade.

If you make heavy use of large objects and other structures that are
difficult to dump with pg_dump, you will need to make other upgrade
provisions.

More detailed documentation is also available at
http://www.ramifordistat.net"

???

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tue, 19 Oct 1999 11:44:54 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: Need refresh on main page...
On Tue, 19 Oct 1999, Lamar Owen wrote:

> Vince Vielhaber wrote:
> > Actually that's on our main page, which is just announcements.  The news
> > page (Latest News on the menu bar) gets quite involved.  Would someone
> > care to give me some updated text for that as well?
> 
> "RPM's for PostgreSQL 6.5.2 are now available, and shipped with RedHat
> Linux version 6.1.  Included in these RPMS:

Perfect!  Thank you!

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
  # include <std/disclaimers.h>       Have you seen http://www.pop4.net?
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Tue, 19 Oct 1999 11:54:48 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: Need refresh on main page...
> Perfect!  Thank you!

I've fetched the RPMs from rufus.org and from Lamar's own site to give
a complete set of RPMs at ftp://postgresql.org/pub/{RPMS,SRPMS}.

Lamar, there is a slight difference in sizes of srpm files fetched
using wget from rufus.org and from your site:

>From ramisartpuyaartelh:

... 7456019 Sep 27 13:52 postgresql-6.5.2-1.src.rpm

>From rufus (via wget):

... 7456234 Sep 26 23:01 postgresql-6.5.2-1.src.rpm

I've put your srpm on postgresql.org, but I'm not sure if it is the
right choice. Why the difference??

                - Thomas

btw, I didn't know about wget; it solves all the problems I was
worried about wrt updating postgresql.org from your site. Nice
utility...

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Tue, 19 Oct 1999 16:27:51 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Need refresh on main page...
On Tue, 19 Oct 1999, Thomas Lockhart wrote:

> > Perfect!  Thank you!
> 
> I've fetched the RPMs from rufus.org and from Lamar's own site to give
> a complete set of RPMs at ftp://postgresql.org/pub/{RPMS,SRPMS}.

Website's updated as well.

[snip]

> 
> btw, I didn't know about wget; it solves all the problems I was
> worried about wrt updating postgresql.org from your site. Nice
> utility...

Yeah it is.  I use it all the time.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
  # include <std/disclaimers.h>       Have you seen http://www.pop4.net?
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Tue, 19 Oct 1999 12:39:35 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: Need refresh on main page...
Zakkr wrote:
> Hmm RedHat, and for Debian (and people which needn't Hat for comp-work:-) exists
> package with 6.5.2?

I don't know if Oliver has updated the Debian packages (which he
maintains) for PostgreSQL to 6.5.2.

As for RPM's for other than RedHat, I'm working on that problem.

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tue, 19 Oct 1999 14:03:15 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: Need refresh on main page...
Vince Vielhaber wrote:
> > "RPM's for PostgreSQL 6.5.2 are now available, and shipped with RedHat
> > Linux version 6.1.  Included in these RPMS:
> 
> Perfect!  Thank you!

Glad to help.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tue, 19 Oct 1999 14:05:48 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: Need refresh on main page...
Vince Vielhaber wrote:
> 
> On Tue, 19 Oct 1999, Thomas Lockhart wrote:
> > I've fetched the RPMs from rufus.org and from Lamar's own site to give
> > a complete set of RPMs at ftp://postgresql.org/pub/{RPMS,SRPMS}.
> 
> Website's updated as well.

And looks good.
 
> [snip]

> > btw, I didn't know about wget; it solves all the problems I was
> > worried about wrt updating postgresql.org from your site. Nice
> > utility...
 
> Yeah it is.  I use it all the time.

Runs great within cron -- the -q switch is your friend ;-).  I mirror
via cron using wget the update repository on rufus -- another great part
of wget is the ability to infinitely retry (-t 0).  

For some reason I didn't get the reply from Thomas.  I don't _think_ I
had a network glitch (he says while firing up a log analyzer...)...

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tue, 19 Oct 1999 14:11:56 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: Need refresh on main page...
Zakkr wrote:
  >
  >
  >On Tue, 19 Oct 1999, Lamar Owen wrote:
  >
  >> Vince Vielhaber wrote:
  >> > Actually that's on our main page, which is just announcements.  The news
  >> > page (Latest News on the menu bar) gets quite involved.  Would someone
  >> > care to give me some updated text for that as well?
  >> 
  >> "RPM's for PostgreSQL 6.5.2 are now available, and shipped with RedHat
  >> Linux version 6.1.  Included in these RPMS:
  >> 
  >
  >Hmm RedHat, and for Debian (and people which needn't Hat for comp-work:-) ex
      >ists 
  >package with 6.5.2?
 
The 6.5.2-2 packages for Debian have just been installed and should be on
the Debian mirrors within the next day.  They are to be found in the
unstable ("potato") distribution at ftp.debian.org/debian/ (or mirrors)
as follows:

Binary packages for i386:
dists/potato/main/binary-i386/misc/postgresql_6.5.2-2.deb
dists/potato/main/binary-i386/misc/postgresql-client_6.5.2-2.deb
dists/potato/main/binary-i386/misc/postgresql-contrib_6.5.2-2.deb
dists/potato/main/binary-i386/libs/ecpg_6.5.2-2.deb
dists/potato/main/binary-i386/libs/postgresql-pl_6.5.2-2.deb
dists/potato/main/binary-i386/libs/libpgsql2_6.5.2-2.deb
dists/potato/main/binary-i386/devel/postgresql-dev_6.5.2-2.deb
dists/potato/main/binary-all/doc/postgresql-doc_6.5.2-2.deb
dists/potato/main/binary-all/misc/pgaccess_6.5.2-2.deb
dists/potato/main/binary-i386/libs/libpgtcl_6.5.2-2.deb
dists/potato/main/binary-i386/libs/libpgperl_6.5.2-2.deb
dists/potato/main/binary-i386/libs/python-pygresql_6.5.2-2.deb
dists/potato/main/binary-i386/libs/odbc-postgresql_6.5.2-2.deb
dists/potato/main/binary-i386/misc/postgresql-test_6.5.2-2.deb

Source package:
dists/potato/main/source/misc/postgresql_6.5.2.orig.tar.gz
dists/potato/main/source/misc/postgresql_6.5.2-2.diff.gz
dists/potato/main/source/misc/postgresql_6.5.2-2.dsc

Binary packages for other architectures should start to appear shortly;
substitute the appropriate architecture for `i386' in the above paths.

Standard caution:
Note that these packages are not part of the released stable Debian
distribution.  They may have dependencies on other unreleased software,
or other instabilities.  Please take care if you wish to install them.
The updates will eventually make their way into the next released Debian
distribution.

-- 
      Vote against SPAM: http://www.politik-digital.de/spam/
                 ========================================
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
               PGP key from public servers; key ID 32B8FAA1
                 ========================================
     "Commit thy way unto the LORD; trust also in him and 
      he shall bring it to pass."          Psalms 37:5 



Tue, 19 Oct 1999 23:13:35 +0100
"Oliver Elphick" <olly@lfix.co.uk>
Re: [HACKERS] Re: Need refresh on main page... 




On Tue, 19 Oct 1999, Oliver Elphick wrote:

> The 6.5.2-2 packages for Debian have just been installed and should be on
> the Debian mirrors within the next day.  They are to be found in the
> unstable ("potato") distribution at ftp.debian.org/debian/ (or mirrors)
> as follows:

Thank! (I'm installing it now.)


------------------------------------------------------------------------------
<zakkr@zf.jcu.cz>                                http://home.zf.jcu.cz/~zakkr/

Kim Project:  http://home.zf.jcu.cz/~zakkr/kim/              (process manager)
FTP:          ftp://ftp2.zf.jcu.cz/users/zakkr/              (C/ncurses/PgSQL)
------------------------------------------------------------------------------
                                                   ...and cathedral dilapidate


Wed, 20 Oct 1999 09:09:47 +0200 (CEST)
Zakkr <zakkr@zf.jcu.cz>
Re: [HACKERS] Re: Need refresh on main page... 


 Hi,

 current Debian potato pgaccess package is bad. The pre-remove script
(in DEBIAN directory) pgaccess.prerm is *empty*, and apt tool return
error for this. In this script must be (leastways) '#!/bin/sh -e'.

  						Karel 

PS. sorry, it is really my last bugreport today :-)

----------------------------------------------------------------------
Karel Zak <zakkr@zf.jcu.cz>              http://home.zf.jcu.cz/~zakkr/

Docs:        http://docs.linux.cz                    (big docs archive)	
Kim Project: http://home.zf.jcu.cz/~zakkr/kim/        (process manager)
FTP:         ftp://ftp2.zf.jcu.cz/users/zakkr/        (C/ncurses/PgSQL)
-----------------------------------------------------------------------


Fri, 17 Dec 1999 15:28:42 +0100 (CET)
Karel Zak - Zakkr <zakkr@zf.jcu.cz>
bug in Debian's pgaccess package
Karel Zak - Zakkr wrote:
  > current Debian potato pgaccess package is bad. The pre-remove script
  >(in DEBIAN directory) pgaccess.prerm is *empty*, and apt tool return
  >error for this. In this script must be (leastways) '#!/bin/sh -e'.

Packaging issues shouldn't go to the hackers list; this should have been
(and now is) a Debian bug-report.


-- 
      Vote against SPAM: http://www.politik-digital.de/spam/
                 ========================================
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
               PGP key from public servers; key ID 32B8FAA1
                 ========================================
     "For I say, through the grace given unto me, to every 
      man that is among you: Do not think of yourself more 
      highly than you ought, but rather think of yourself 
      with sober judgement, in accordance with the measure 
      of faith God has given you."            Romans 12:3 



Fri, 17 Dec 1999 16:31:29 +0000
"Oliver Elphick" <olly@lfix.co.uk>
Re: [HACKERS] bug in Debian's pgaccess package 
> Karel Zak - Zakkr wrote:
>   > current Debian potato pgaccess package is bad. The pre-remove script
>   >(in DEBIAN directory) pgaccess.prerm is *empty*, and apt tool return
>   >error for this. In this script must be (leastways) '#!/bin/sh -e'.
> 
> Packaging issues shouldn't go to the hackers list; this should have been
> (and now is) a Debian bug-report.

Debian potato pgaccess -- I don't even want to ask what this is. 

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 17 Dec 1999 12:53:45 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] bug in Debian's pgaccess package



Hi,

I am thinking about using postgreSQL to manage large geographic databases
connected to a GIS.
I would really appreciate if someone could give me some answers to those 3
questions :
   what about performances with postgreSQL and large databases,
   the object size limitation (8192 bytes) is really not acceptable for this
   purpose. Is there a way or any hack to overpass it,
   is the geographic index working well.

Thanks.

Xavier.




Thu, 20 Jul 2000 09:42:25 +0200
"Xavier ZIMMERMANN" <xzimmermann@matra-ms2i.fr>
8Ko limitation

>    what about performances with postgreSQL and large databases,
>    the object size limitation (8192 bytes) is really not acceptable for this

 Now you can change this limit in config.h, the possible range is 
8Kb - 32Kb. 

 In new 7.1 version will this limit dead forever (see TOAST project).

 And what is a "large database"? 1, 5 .. 10Gb? If yes, (IMHO) the PostgreSQL 
is good choice.

					Karel


Thu, 20 Jul 2000 10:00:17 +0200 (CEST)
Karel Zak <zakkr@zf.jcu.cz>
Re: [HACKERS] 8Ko limitation
On Thursday 20 July 2000, at 10 h 0, the keyboard of Karel Zak 
<zakkr@zf.jcu.cz> wrote:
 
>  And what is a "large database"? 1, 5 .. 10Gb? If yes, (IMHO) the PostgreSQL 
> is good choice.

Even on Linux? I'm studying a database project where the raw data is 10 to 20 
Gb (it will be in several tables in the same database). Linux has a limit of 2 
Gb for a file (even on 64-bits machine, if I'm correct). A colleague told me 
to use NetBSD instead, because PostgreSQL on a Linux machine cannot host more 
than 2 Gb per database. Any practical experience? (I'm not interested in "It 
should work".)



Thu, 20 Jul 2000 10:35:41 +0200
Stephane Bortzmeyer <bortzmeyer@pasteur.fr>
Re: Re: [HACKERS] 8Ko limitation 
On Thu, Jul 20, 2000 at 10:35:41AM +0200, Stephane Bortzmeyer wrote:
> On Thursday 20 July 2000, at 10 h 0, the keyboard of Karel Zak 
> <zakkr@zf.jcu.cz> wrote:
>  
> >  And what is a "large database"? 1, 5 .. 10Gb? If yes, (IMHO) the PostgreSQL 
> > is good choice.
> 
> Even on Linux? I'm studying a database project where the raw data is 10 to 20 
> Gb (it will be in several tables in the same database). Linux has a limit of 2 
> Gb for a file (even on 64-bits machine, if I'm correct). A colleague told me 
> to use NetBSD instead, because PostgreSQL on a Linux machine cannot host more 
> than 2 Gb per database. Any practical experience? (I'm not interested in "It 
> should work".)

Postgres splits large tables into multiple files.

Experience suggests it tends to split at around 1.1G (at least, that's
what it has done on my last project).

FWIW, the 2Gig limit doesn't exist on 64bit linux, AFAIK (at least, not
with a 64-bit happy libc; I can't remember if the patches made it into
the version we use in Debian).

Jules

-- 
Jules Bean                          |        Any sufficiently advanced 
jules@debian.org                    |  technology is indistinguishable
jules@jellybean.co.uk               |               from a perl script

Thu, 20 Jul 2000 09:52:01 +0100
Jules Bean <jules@jellybean.co.uk>
Re: Re: [HACKERS] 8Ko limitation

On Thu, 20 Jul 2000, Stephane Bortzmeyer wrote:

> On Thursday 20 July 2000, at 10 h 0, the keyboard of Karel Zak 
> <zakkr@zf.jcu.cz> wrote:
>  
> >  And what is a "large database"? 1, 5 .. 10Gb? If yes, (IMHO) the PostgreSQL 
> > is good choice.
> 
> Even on Linux? I'm studying a database project where the raw data is 10 to 20 
> Gb (it will be in several tables in the same database). Linux has a limit of 2 
> Gb for a file (even on 64-bits machine, if I'm correct). A colleague told me 
> to use NetBSD instead, because PostgreSQL on a Linux machine cannot host more 
> than 2 Gb per database. Any practical experience? (I'm not interested in "It 
> should work".)

I must again say: "The PostgreSQL is good choice" :-)

The postgres chunks DB files, not exist 2Gb limit here...

						Karel


Thu, 20 Jul 2000 11:02:50 +0200 (CEST)
Karel Zak <zakkr@zf.jcu.cz>
Re: Re: [HACKERS] 8Ko limitation 
Jules Bean <jules@jellybean.co.uk> writes:
>> A colleague told me to use NetBSD instead, because PostgreSQL on a
>> Linux machine cannot host more than 2 Gb per database. Any practical
>> experience? (I'm not interested in "It should work".)

> Postgres splits large tables into multiple files.

Segmenting into multiple files used to have some bugs, but that was a
few versions back --- I think your colleague's experience is obsolete.
There are lots of people using multi-gig tables now.

It's presently still painful to manage a database that spans multiple
disks, however.  (You can do it if you're willing to move files around
and establish symlinks by hand ... but it's painful.)  There are plans
to make this better, but for now you might want to say that the
practical limit is the size of disk you can buy.  Alternatively, if
your OS can make logical filesystems that span multiple disks, you
can get around the problem that way.

			regards, tom lane

Thu, 20 Jul 2000 10:52:49 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: [HACKERS] 8Ko limitation 
"Justin Hickey" <jhickey@impact1.hpcc.nectec.or.th> writes:
>  Will the geometric data types be TOASTable for 7.1?

Probably ... if I get around to it ... or someone else does
(yes, that's a hint).

			regards, tom lane

Thu, 20 Jul 2000 11:17:59 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] 8Ko limitation 
Hello Karel

On Jul 20, 10:00am, Karel Zak wrote:
> Subject: Re: [HACKERS] 8Ko limitation
>
> >    what about performances with postgreSQL and large databases,
> >    the object size limitation (8192 bytes) is really not acceptable for
this
>
>  Now you can change this limit in config.h, the possible range is
> 8Kb - 32Kb.
>
>  In new 7.1 version will this limit dead forever (see TOAST project).

We use Postgres to store polygons and I asked this same question before. The
reply I got was that the geometric data types were not guaranteed to be
converted to TOASTable data types (they were at the bottom of the list of types
to convert). They hinted that I could help them with this but I have no time.
Has this changed now? Will the geometric data types be TOASTable for 7.1?


-- 
Sincerely,

Jazzman (a.k.a. Justin Hickey)  e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
==================================================================
People who think they know everything are very irritating to those
of us who do.  ---Anonymous

Jazz and Trek Rule!!!
==================================================================

Thu, 20 Jul 2000 16:06:12 +0000
"Justin Hickey" <jhickey@impact1.hpcc.nectec.or.th>
Re: 8Ko limitation
   Even on Linux? I'm studying a database project where the raw data is 10 to 20 
   Gb (it will be in several tables in the same database). Linux has a limit of 2 
   Gb for a file (even on 64-bits machine, if I'm correct). A colleague told me 
   to use NetBSD instead, because PostgreSQL on a Linux machine cannot host more 
   than 2 Gb per database. Any practical experience? (I'm not interested in "It 
   should work".)

Postgresql and NetBSD work fine together.  NetBSD has not had a 2GB
file limit for _many_ years and has raidframe for configuring huge
disks from many small ones (as well as for normal raid stuff).

Cheers,
Brook



Thu, 20 Jul 2000 12:01:30 -0600 (MDT)
Brook Milligan <brook@biology.nmsu.edu>
Re: Re: [HACKERS] 8Ko limitation
> Even on Linux? I'm studying a database project where the raw data is 10 to 20 
> Gb (it will be in several tables in the same database). Linux has a limit of 2 
> Gb for a file (even on 64-bits machine, if I'm correct). A colleague told me 

Quoi?

On my RedHat6.2 system:

/dev/md0              14111856    257828  13137168   2% /raid

> to use NetBSD instead, because PostgreSQL on a Linux machine cannot host more 
> than 2 Gb per database. Any practical experience? (I'm not interested in "It 
> should work".)

For a heavy-duty server, I would probably pick OpenBSD over Linux, but
both will work fine, and both can have filesystems far larger than
2gb.

e

Thu, 20 Jul 2000 14:05:39 -0700 (PDT)
Erich <hh@cyberpass.net>
Re: Re: [HACKERS] 8Ko limitation
On Thursday 20 July 2000, at 14 h 5, the keyboard of Erich <hh@cyberpass.net> 
wrote:

> > Linux has a limit of 2 
> > Gb for a file (even on 64-bits machine, if I'm correct). 
...
> Quoi?
> 
> On my RedHat6.2 system:
> 
> /dev/md0              14111856    257828  13137168   2% /raid
...
> and both can have filesystems far larger than 2gb.

Read the message before replying: I wrote FILE and not FILESYSTEM.



Fri, 21 Jul 2000 09:39:34 +0200
Stephane Bortzmeyer <bortzmeyer@pasteur.fr>
Re: Re: [HACKERS] 8Ko limitation 
Xavier ZIMMERMANN wrote:
> 
> Hi,
> 
> I am thinking about using postgreSQL to manage large geographic databases
> connected to a GIS.
...
>    is the geographic index working well.

AFAIK r-trees ar used for planar geometry. 
perhaps there something in contrib for geographic (spherical)
coordinates.

--------
Hannu

Fri, 21 Jul 2000 14:56:33 +0300
Hannu Krosing <hannu@tm.ee>
Re: [HACKERS] 8Ko limitation