insertable views - not copy-able ?

what about this:
( it would be nice to have it working, specially for copying values from files into table with default fields, having the default fields doing their job or initialising tables using reduced set of columns )

mydb=> create sequence MYSEQ;
CREATE
mydb=> create table MYTAB ( ID int4 default nextval('MYSEQ'), NAME text );
CREATE
mydb=> create view MYVIEW as select name from MYTAB;
CREATE
mydb=> copy MYVIEW from stdin;

First this setup wouldn't work with INSERT too. The INSTEAD
rule for INSERT is missing. Second COPY isn't a rewritable
statement, and it will not become such since only commands
that have a rangetable and a targetlist can be handled by the
rewriter at all.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Oct 18 07:34:30 1999
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA29491
for <pgsql-hackers@postgreSQL.org>;
Mon, 18 Oct 1999 07:33:54 -0400 (EDT) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max03-047.enterprise.net
[194.72.196.47])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id MAA19240;
Mon, 18 Oct 1999 12:33:52 +0100 (GMT/BST)
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id MAA03431;
Mon, 18 Oct 1999 12:33:52 +0100
Message-Id: <199910181133.MAA03431@linda.lfix.co.uk>
X-Mailer: exmh version 2.0.2 2/24/98 (debian)
To: Zakkr <zakkr@zf.jcu.cz>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] to_char(), md5() (long)
In-Reply-To: Message from Zakkr <zakkr@zf.jcu.cz> of "Mon,
18 Oct 1999 08:37:49 +0200."
<Pine.LNX.3.96.991018083324.2759A-100000@ara.zf.jcu.cz>
References: <Pine.LNX.3.96.991018083324.2759A-100000@ara.zf.jcu.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 18 Oct 1999 12:33:52 +0100
From: "Oliver Elphick" <olly@lfix.co.uk>

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

From bouncefilter Mon Oct 18 09:43:32 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA45431
for <pgsql-hackers@postgreSQL.org>;
Mon, 18 Oct 1999 09:42:56 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id NAA18757;
Mon, 18 Oct 1999 13:42:18 GMT
Sender: lockhart@hub.org
Message-ID: <380B23BA.E8B75290@alumni.caltech.edu>
Date: Mon, 18 Oct 1999 13:42:18 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: =?iso-8859-1?Q?St=E9phane?= FILLON <fillons@offratel.nc>
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Tr: Functions documentations
References: <04a901bf17a0$0177d520$a5373ad1@portable>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I am looking for a complete list of functions we have under PostgreSQL.
Where can I found this documentation ?
If there is no documentation, I would be please to write one with samples.
In this case, send me your
experience with source for each functions you have try at my direct e-mail.
And I will update this documentation weekly.

There is a chapter on "Functions" in the Postgres SGML-based
documentation. It is probably not complete, but does cover most of the
major classes of functions. If you would like to update or modify
that, it would then be available in the main docs set.

doc/src/sgml/func.sgml

PS: For my personnal use, I have already make a small CookBook of
PostgreSQL (100 pages) with lots of samples I have found reading
the mailing-list and my own experience.

If you would like to contribute this, I'm sure it could be of help to
others. Our Tutorial and "HowTo" docs are the least actively
maintained and could use an infusion of information. Perhaps your docs
could be a Tutorial or User's Guide?

- Thomas

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

From bouncefilter Mon Oct 18 10:26:36 1999
Received: from venus.wmid.amu.edu.pl (IDENT:root@venus.wmid.amu.edu.pl
[150.254.68.39]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA53028
for <pgsql-hackers@postgresql.org>;
Mon, 18 Oct 1999 10:25:53 -0400 (EDT)
(envelope-from yacol@venus.wmid.amu.edu.pl)
Received: from yacol (pb185.poznan.ppp.tpnet.pl [212.160.11.185])
by venus.wmid.amu.edu.pl (8.9.3/8.9.3) with SMTP id QAA07266
for <pgsql-hackers@postgresql.org>;
Mon, 18 Oct 1999 16:25:37 +0200 (MET DST)
Message-ID: <000101bf1974$b55af100$3200090a@yacol.linux.net>
From: "Jacek Witczak" <yacol@venus.wmid.amu.edu.pl>
To: <pgsql-hackers@postgresql.org>
Subject: problem with PostgreSQL and LAN
Date: Mon, 18 Oct 1999 16:25:53 +0200
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Hi all,
my problem is simple but very frustrating,

I wrote some program under Windows 95 (MS VC++ 4.0).
This program uses MFC ODBC classes (CRecordset and CDatabase) to
cooperate with my PostgreSQL 6.3 (installed on RedHat 5.1 linux) via
psqlodbc driver.
I can connect to my databse, I can scroll, update, insert or delete records.
Everything's fine.
Problem starts when more than one user has access to the database.

Example:

Person A runs my program, connects to PostgreSQL database and opens
tables. Everything works fine.
Person B runs my program,connects to PostgreSQL database and opens
tables. Also everything works fine.
Both persons can scroll records and read their contents without any problem.

Now, let's say, Person A wants to make some modifications (or even add new
record)
to some records in some table. My program's execution stops and waits until
Person B exits application (!!!!!!).

ps ax command on my Linux server shows that there are two postgres processes
running with
some command line options (it's OK since there're 2 persons logged in).
And of course, there's also postmaster process running (with -i command line
option specified).
What's the reason of such a strange behavior? It seems, that postgres locks
entire database
and makes any updates impossible. Could any1 help me with that?
I'd appreciate any help...

yacol

From bouncefilter Mon Oct 18 10:38:36 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA54847
for <pgsql-hackers@postgreSQL.org>;
Mon, 18 Oct 1999 10:37:51 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA25045;
Mon, 18 Oct 1999 10:34:54 -0400 (EDT)
To: t-ishii@sra.co.jp
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sort on huge table
In-reply-to: Your message of Mon, 18 Oct 1999 15:08:59 +0900
<199910180608.PAA01008@srapc451.sra.co.jp>
Date: Mon, 18 Oct 1999 10:34:52 -0400
Message-ID: <25042.940257292@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

If you could try sorting a table larger than 4GB with this code, I'd be
much obliged.

ERROR: ltsWriteBlock: failed to write block 131072 of temporary file
Perhaps out of disk space?

Drat. I'll take a look --- thanks for running the test.

regards, tom lane

From bouncefilter Mon Oct 18 10:39:36 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA54980
for <pgsql-hackers@postgreSQL.org>;
Mon, 18 Oct 1999 10:39:31 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA25073;
Mon, 18 Oct 1999 10:37:55 -0400 (EDT)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] is it possible to use LIMIT and INTERSECT ?
In-reply-to: Your message of Mon, 18 Oct 1999 10:20:28 +0400 (MSD)
<Pine.GSO.3.96.SK.991018101525.11898B-100000@ra>
Date: Mon, 18 Oct 1999 10:37:55 -0400
Message-ID: <25071.940257475@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Oleg Bartunov <oleg@sai.msu.su> writes:

patch was applied smoothly to 6.5.2

select a.msg_id, c.status_set_date, c.title
from Message_Keyword_map a, messages c, keywords d
where c.status_id =1 and d.name ~* 'moon' and a.key_id=d.key_id
and c.msg_id=a.msg_id
intersect
select a.msg_id, a.status_set_date, a.title from messages a
where a.status_id = 1 and a.title ~* 'moon' limit 5;

produces (10 rows)

Hmm. It seemed to work as expected in current --- maybe there is
another bug still lurking in 6.5.*. I'll look when I get a chance.

regards, tom lane

From bouncefilter Mon Oct 18 10:51:37 1999
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA57070
for <pgsql-hackers@postgresql.org>;
Mon, 18 Oct 1999 10:50:33 -0400 (EDT) (envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with ESMTP id SAA02258;
Mon, 18 Oct 1999 18:48:52 +0400 (MSD)
Date: Mon, 18 Oct 1999 18:48:52 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: =?iso-8859-1?Q?St=E9phane_FILLON?= <fillons@offratel.nc>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Tr: Functions documentations
In-Reply-To: <04a901bf17a0$0177d520$a5373ad1@portable>
Message-ID: <Pine.GSO.3.96.SK.991018184747.11898O-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=koi8-r
Content-Transfer-Encoding: 8bit

On Sat, 16 Oct 1999, [iso-8859-1] St�phane FILLON wrote:

Date: Sat, 16 Oct 1999 17:30:56 +1100
From: "[iso-8859-1] St�phane FILLON" <fillons@offratel.nc>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: [HACKERS] Tr: Functions documentations

-----Message d'origine-----
De : St�phane FILLON <fillons@offratel.nc>
� : pgsql-general <pgsql-general@postgresql.org>
Date : samedi 16 octobre 1999 17:30
Objet : Functions documentations

Hi !!

I am looking for a complete list of functions we have under PostgreSQL.

Where can I found this documentation ?

If there is no documentation, I would be please to write one with samples.
In this case, send me your
experience with source for each functions you have try at my direct e-mail.
And I will update this
documentation weekly.

PS: For my personnal use, I have already make a small CookBook of

PostgreSQL

(100 pages) with
lots of samples I have found reading the mailing-list and my own

experience.

Cool, would be glad to see you cookbook in Postgres documentation.
Do you have it online ?

Oleg

Regards,

Stephane FILLON.

************

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

From bouncefilter Mon Oct 18 11:11:37 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA60488
for <pgsql-hackers@postgreSQL.org>;
Mon, 18 Oct 1999 11:11:31 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA25231;
Mon, 18 Oct 1999 11:10:56 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
In-reply-to: Your message of Mon, 18 Oct 1999 14:40:47 +0900
<000c01bf192b$5437e2a0$2801007e@cadzone.tpf.co.jp>
Date: Mon, 18 Oct 1999 11:10:55 -0400
Message-ID: <25228.940259455@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

... I don't see anything fundamentally
wrong with using the existence and size of a data file as useful
information. It's not a substitute for a lock, of course, and there
may be places where we need cross-backend interlocks that we haven't
got now.

We have to lseek() each time to know the number of blocks of a table
file. Isn't it a overhead ?

True, but lseek is pretty cheap as kernel calls go (the kernel just has
to consult the file's inode, which should be in memory already). We're
not going to get the info for free; any other way of keeping track of
it is going to have its own costs. Vadim's been muttering about using
a shared cache for system catalog tuples, which might be a win but I'm
not sure (I'm worried about contention for the cache, especially if it's
protected by just one or a few spinlocks). Anyway, if we did have one
then keeping an accurate block count in the relation's pg_class row
would be a practical alternative.

That's bothered me too. A possible answer would be to do the unlinking
back-to-front (zap the last file first); that'd require a few more lines
of code in md.c, but a crash midway through would then leave a legal
file configuration that another backend could still do something with.

Oops,it's more serious than I have thought.
mdunlink() may only truncates a table file by a crash while unlinking
back-to-front.
A crash while unlinking front-to-back may leave unlinked segments
and they would suddenly appear as segments of the recreated table.
Seems there's no easy fix.

Well, it seems to me that the first misbehavior (incomplete delete becomes
a partial truncate, and you can try again) is a lot better than the
second (incomplete delete leaves an undeletable, unrecreatable table).
Should I go ahead and make delete/truncate work back-to-front, or do you
see a reason why that'd be a bad thing to do?

3. In cygwin port,mdunlink()/mdtruncate() may leave segments of 0
length.

I don't understand what causes this. Can you explain?

You call FileUnlink() after FileTrucnate() to unlink in md.c. If
FileUnlink()
fails there remains segments of 0 length. But it seems not critical in
this issue.

Ah, I see. It's not specific to cygwin then. I think you are right
that it is not critical, at least not if we change to do the operations
back-to-front. Truncating and then failing to delete will still leave
a valid file configuration.

Probably it would require a lot of work to fix correctly.
Postponing real unlink/truncating until commit and creating table
files which correspond to their oids ..... etc ...
It's same as "DROP TABLE inside transations" requires.
Hmm,is it worth the work ?

I'm not eager to do that either (not just because of the low return on
work invested, but because naming table files by OIDs would be a big
handicap for debugging and database admin work). However, I'm not
quite sure why you see it as a solution to the problem of recovering
from a failed md.c operation. The risks would be the same if the
deletion was happening during commit, no? And I'd be a lot *more*
worried about deleting the wrong file during manual cleanup if the
files were named by OID ;-)

regards, tom lane

From bouncefilter Mon Oct 18 15:31:40 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id PAA94360
for <pgsql-hackers@postgreSQL.org>;
Mon, 18 Oct 1999 15:31:21 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11dIPj-0003kLC; Mon, 18 Oct 99 21:25 MET DST
Message-Id: <m11dIPj-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
To: winter@jurai.net (Matthew N. Dodd)
Date: Mon, 18 Oct 1999 21:25:47 +0200 (MET DST)
Cc: maillist@candle.pha.pa.us, wieck@debis.com, scrappy@hub.org,
vev@michvhf.com, lockhart@alumni.caltech.edu, lamar.owen@wgcr.org,
pgsql-hackers@postgreSQL.org, jwieck@debis.com
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <Pine.BSF.4.10.9910130010190.480-100000@sasami.jurai.net> from
"Matthew N. Dodd" at Oct 13, 99 00:10:34 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Matthew N. Dodd wrote:

On Tue, 12 Oct 1999, Bruce Momjian wrote:

I see we don't even need the e-mail address, because you got that in
there too.

All that is missing are mug-shots.

Yepp, you're right. Do a reload and look at my pin (on the
final page I'll be shaved a little better, it's just a quick
grab from my camera taken 20 minutes ago).

I really like that very much, now this is MY entry and not
just some information about me. Thank you very much, Matthew!

It's an 80x80 JPG and only 1931 bytes. A good size to be
recognizable and not overloading the popup.

So would anyone please send me some picture (or just a note
that he doesn't want one). If it's not actually 80x80 ready
to stick in, please send something at least 3x the size so I
can crop and downscale it without much quality loss.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Oct 18 16:37:41 1999
Received: from sasami.jurai.net (winter@sasami.jurai.net [63.67.141.99])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA03526
for <pgsql-hackers@postgreSQL.org>;
Mon, 18 Oct 1999 16:36:49 -0400 (EDT)
(envelope-from winter@jurai.net)
Received: from localhost (winter@localhost)
by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id QAA09884;
Mon, 18 Oct 1999 16:36:44 -0400 (EDT)
Date: Mon, 18 Oct 1999 16:36:43 -0400 (EDT)
From: "Matthew N. Dodd" <winter@jurai.net>
To: Jan Wieck <wieck@debis.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
In-Reply-To: <m11dIPj-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.BSF.4.10.9910181632310.480-100000@sasami.jurai.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

[Cc trimmed.]

On Mon, 18 Oct 1999, Jan Wieck wrote:

Yepp, you're right. Do a reload and look at my pin (on the
final page I'll be shaved a little better, it's just a quick
grab from my camera taken 20 minutes ago).

Very nice! Its good to be able to place names with faces.

I really like that very much, now this is MY entry and not
just some information about me. Thank you very much, Matthew!

It's an 80x80 JPG and only 1931 bytes. A good size to be
recognizable and not overloading the popup.

Indeed.

So would anyone please send me some picture (or just a note
that he doesn't want one). If it's not actually 80x80 ready
to stick in, please send something at least 3x the size so I
can crop and downscale it without much quality loss.

I think people with no pictures should have a default picture... Maybe
'Barney' or something evil like that to encourage them to send in a pic.
:)

Good job though. Any chance you'll clean the code up and release the
package in a form that others can use? I think its a very nice layout and
that other open source projects might like to make use of it.

If its backended into PostgreSQL it might make it easier for users to
manage their own entries. Picture submissions could be handled that way
with no intervention.

Anyhow, I'm rambling.

--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever |

From bouncefilter Mon Oct 18 16:59:41 1999
Received: from stone.congenomics.com (stone.congenomics.com [209.146.50.44])
by hub.org (8.9.3/8.9.3) with SMTP id QAA06414
for <pgsql-hackers@hub.org>; Mon, 18 Oct 1999 16:59:11 -0400 (EDT)
(envelope-from bruc@stone.congenomics.com)
Received: (from bruc@localhost) by stone.congenomics.com
(950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA08508 for
pgsql-hackers@hub.org; Mon, 18 Oct 1999 17:01:20 -0400
From: bruc@stone.congenomics.com (Robert E. Bruccoleri)
Message-Id: <199910182101.RAA08508@stone.congenomics.com>
Subject: Historical post of Marc to support Postgres95 development
To: pgsql-hackers@hub.org
Date: Mon, 18 Oct 1999 17:01:20 -0400 (EDT)
Reply-To: bruc@acm.org
X-Mailer: ELM [version 2.4 PL25 ME8b]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM940280479-8470-0_
Content-Transfer-Encoding: 7bit

--ELM940280479-8470-0_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

+----------------------------------+------------------------------------+
| Robert E. Bruccoleri, Ph.D.      | Phone: 609 737 6383                |
| President, Congenomics, Inc.     | Fax:   609 737 7528                |
| 114 W. Franklin Ave, Suite K1,10 | email: bruc@acm.org                |
| P.O. Box 314                     | URL:   http://www.congen.com/~bruc |
| Pennington, NJ 08534             |                                    |
+----------------------------------+------------------------------------+

--ELM940280479-8470-0_
Content-Type: message/rfc822
Content-Disposition: inline
Content-Description: Forwarded message from Marc G. Fournier
Content-Transfer-Encoding: 7bit

Received: from cliff.bms.com by horta via ESMTP (940816.SGI.8.6.9/930416.SGI)
for <bruc@horta.bms.com> id QAA12043; Tue, 23 Apr 1996 16:43:20 -0400
Received: from shiloh.vnet.net by cliff.bms.com (PMDF V5.0-5 #15142)
id <01I3VZ2L9FDS001KM6@cliff.bms.com> for bruc@horta.bms.com; Tue,
23 Apr 1996 16:42:48 -0500 (EST)
Received: (from daemon@localhost) by shiloh.vnet.net (8.6.13/8.6.12)
id QAA13968 for postgres95-outgoing; Tue, 23 Apr 1996 16:16:34 -0400
Received: from ki.net (root@ki.net [205.150.102.1])
by shiloh.vnet.net (8.6.13/8.6.12) with ESMTP id QAA13963 for
<postgres95@shiloh.vnet.net>; Tue, 23 Apr 1996 16:16:21 -0400
Received: from freebsd.ki.net (root@freebsd.ki.net [205.150.102.51])
by ki.net (8.7.4/8.7.4) with ESMTP id QAA07272; Tue,
23 Apr 1996 16:05:46 -0400 (EDT)
Received: from localhost (scrappy@localhost) by freebsd.ki.net (8.7.5/8.7.5)
with SMTP id QAA23247; Tue, 23 Apr 1996 16:06:11 -0400 (EDT)
Date: Tue, 23 Apr 1996 16:06:10 -0400 (EDT)
From: "Marc G. Fournier" <scrappy@ki.net>
Subject: Re: [PG95]: postgres95 TODO list posted on the web
In-reply-to: <Pine.LNX.3.91.960423103755.4513C-100000@brtgate.brttech.com>
Sender: owner-postgres95@postgres95.vnet.net
To: Chad Robinson <chadr@brttech.com>
Cc: Jolly Chen <jolly@postgres.berkeley.edu>, postgres95@shiloh.vnet.net
Message-id: <Pine.NEB.3.93.960423160423.23204C-100000@freebsd.ki.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Precedence: bulk
X-Authentication-warning: freebsd.ki.net: scrappy owned process doing -bs
Status: RO

On Tue, 23 Apr 1996, Chad Robinson wrote:

On Tue, 23 Apr 1996, Jolly Chen wrote:

I've posted a TODO list on the postgres95 web site
(http://s2k-ftp.CS.Berkeley.EDU:8000/postgres95/www/todo.html)
I've casually sorted the list by priority and I have some editorial
comments on some of them.

If all the items on the TODO list were completed, postgres95 would be
much improved, and would really be a viable replacement for commercial
RDBMSs in some settings. Some of the items require quite a bit of work
and deep knowledge of postgres95 internals, though. We would need a few
contributors with quite a lot of volunteer hours to make this happen
anytime soon. (A large number of contributors each with only a little
bit of time to contribute would not be equivalent)

Some of these things were on my own list to do also. I'd like to start
working on some of them, but the thing is, I'd also like to see a better
distribution form. The last update was several months ago, even though
there are several known `good' patches that need to be applied to fix
various bugs. What are we missing? :-) Do we need a maintainer? We only
have a 28.8 link right now (T1 in a few months) but I'd be happy to provide
at least a basic FTP server with space, and some time to process patches,
updates, and so forth. I can at least be a mirror...

If it helps, I'd be willing to setup a cvs database, including
appropriate accounts for a core few developers that patches can go through.

From there, it wouldn't be too hard to do a weekly "distribution" that is

ftpable.

I don't know enough about the server backend to offer much more
then that :(

Marc G. Fournier scrappy@ki.net
Systems Administrator @ ki.net scrappy@freebsd.org

--ELM940280479-8470-0_--

From bouncefilter Mon Oct 18 17:02:41 1999
Received: from stone.congenomics.com (stone.congenomics.com [209.146.50.44])
by hub.org (8.9.3/8.9.3) with SMTP id RAA06974
for <pgsql-hackers@hub.org>; Mon, 18 Oct 1999 17:01:56 -0400 (EDT)
(envelope-from bruc@stone.congenomics.com)
Received: (from bruc@localhost) by stone.congenomics.com
(950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA08532 for
pgsql-hackers@hub.org; Mon, 18 Oct 1999 17:04:10 -0400
From: bruc@stone.congenomics.com (Robert E. Bruccoleri)
Message-Id: <199910182104.RAA08532@stone.congenomics.com>
Subject: Another historical message from the early days of PostgreSQL
development
To: pgsql-hackers@hub.org
Date: Mon, 18 Oct 1999 17:04:10 -0400 (EDT)
Reply-To: bruc@acm.org
X-Mailer: ELM [version 2.4 PL25 ME8b]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM940280650-8470-1_
Content-Transfer-Encoding: 7bit

--ELM940280650-8470-1_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

+----------------------------------+------------------------------------+
| Robert E. Bruccoleri, Ph.D.      | Phone: 609 737 6383                |
| President, Congenomics, Inc.     | Fax:   609 737 7528                |
| 114 W. Franklin Ave, Suite K1,10 | email: bruc@acm.org                |
| P.O. Box 314                     | URL:   http://www.congen.com/~bruc |
| Pennington, NJ 08534             |                                    |
+----------------------------------+------------------------------------+

--ELM940280650-8470-1_
Content-Type: message/rfc822
Content-Disposition: inline
Content-Description: Forwarded message from Marc G. Fournier
Content-Transfer-Encoding: 7bit

Received: from cliff.bms.com by horta via ESMTP
(951211.SGI.8.6.12.PATCH1042/951211.SGI)
for <bruc@horta.bms.com> id UAA23946; Tue, 9 Jul 1996 20:26:15 -0400
Received: from oozoo.vnet.net by cliff.bms.com (PMDF V5.0-7 #15142)
id <01I6VRBVLWG0004WTX@cliff.bms.com> for bruc@horta.bms.com; Tue,
09 Jul 1996 20:27:25 -0500 (EST)
Received: (from daemon@localhost) by oozoo.vnet.net (8.6.13/8.6.12)
id WAA24932 for postgres95-outgoing; Mon, 08 Jul 1996 22:11:58 -0400
Received: from ki.net (root@ki.net [205.150.102.1])
by oozoo.vnet.net (8.6.13/8.6.12) with ESMTP id WAA24927 for
<postgres95@oozoo.vnet.net>; Mon, 08 Jul 1996 22:11:43 -0400
Received: from localhost (scrappy@localhost) by ki.net (8.7.5/8.7.5)
with SMTP id WAA25842 for <postgres95@postgres95.vnet.com>; Mon,
08 Jul 1996 22:12:20 -0400 (EDT)
Date: Mon, 08 Jul 1996 22:12:19 -0400 (EDT)
From: "Marc G. Fournier" <scrappy@ki.net>
Subject: [PG95]: Developers interested in improving PG95?
Sender: owner-postgres95@oozoo.vnet.net
To: Postgres95 Users <postgres95@oozoo.vnet.net>
Message-id: <Pine.NEB.3.94.960708215315.24869B-100000@ki.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Precedence: bulk
Status: RO

Hi...

Awhile back, there was talk of a TODO list and development
moving forward on Postgres95...at which point in time I volunteered
to put up a cvs archive and sup server so that making updates (and getting
at the "newest source code") was easier to do...

So far as I can see on the list itself, this has fallen to the wayside,
with everyone posting about database corruptions and whatnot...but few
solutions being brought up :( right now, I'm in the middle of cursing over
the fact that I can't seem to get a project I'm working on to be stable on
either a Solaris box or a FreeBSD box (the FreeBSD box is th emore stable of
the two, mind you)...I've just rebuilt the FreeBSD server...

Personally, I think that both Jolly and Andrew have done a fantastic
job of bringing it to its currently level, but they, like most of the ppl on
this list, have full time jobs that sap alot of their time...

...so, unless someone out there has already done this, and
unless Jolly/Andrew tell me I can't (guys?)...I'm going to go ahead with
what I wanted to do a few months ago...setup a development site similar to
what is done with FreeBSD...

First stage will be to get a cvs archive of postgres 1.01 online
tonight, with a sup server so that everyone has access to the source code.

If anyone has any patches they wish to submit based off of 1.01,
please send them to postgres@ki.net and I'll commit those in as soon as cvs
is up and running.

Unless there are any disaggremenets with this (or someone else has
done this that I missed in mail...sorry if I did...)...I'll send out further
data on this as soon as its up and running...

Marc G. Fournier scrappy@ki.net
Systems Administrator @ ki.net scrappy@freebsd.org

--ELM940280650-8470-1_--

From bouncefilter Mon Oct 18 21:03:47 1999
Received: from ext16.sra.co.jp (IDENT:root@ykh28DS42.kng.mesh.ad.jp
[133.205.214.42]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA48350
for <hackers@postgreSQL.org>; Mon, 18 Oct 1999 21:03:07 -0400 (EDT)
(envelope-from t-ishii@ext04.sra.co.jp)
Received: from ext04.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext16.sra.co.jp (8.8.8/8.8.8) with ESMTP id JAA16894;
Tue, 19 Oct 1999 09:55:18 +0900
Message-Id: <199910190055.JAA16894@ext16.sra.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: t-ishii@sra.co.jp, Goran Thyni <goran@kirra.net>,
PostgreSQL-development <hackers@postgreSQL.org>
Subject: Re: [HACKERS] indexable and locale
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Sat, 16 Oct 1999 13:31:01 -0400.
<5492.940095061@sss.pgh.pa.us>
Date: Tue, 19 Oct 1999 09:55:17 +0900
Sender: t-ishii@ext04.sra.co.jp

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

Attached is a patch to the old problem discussed feverly before 6.5.

... I think your pacthes break
non-ascii multi-byte character sets data and should be surrounded by
#ifdef LOCALE rather than replacing current codes surrounded by
#ifndef LOCALE.

I am worried about this patch too. Under MULTIBYTE could it
generate invalid characters?

I assume you are talking about following code fragment in the pacthes:

prefix[prefixlen]++;

This would not generate invalid characters under MULTIBYTE since it skips the
multi-byte characters by:

if ((unsigned) prefix[prefixlen] < 126)

This would not make non-ASCII multi-byte characters indexable,
however.

Also, do all non-ASCII locales sort
codes 0-126 in the same order as ASCII? I didn't think they do,
but I'm not an expert.

As far as I know they do. At least all encodings MULTIBYTE mode can
handle have same code point as ASCII in 0-126 range. They have
following characteristics:

o code point 0x00-0x7f are compatible with ASCII.

o code point over 0x80 are variable length multi-byte characters. For
example, ISO-8859-1 (Germany, Fernch etc...) has the multi-byte
length to always 1, while EUC_JP (Japanese) has 2 to 3.

The approach I was considering for fixing the problem was to use a
loop that would repeatedly try to generate a string greater than the
prefix string. The basic loop step would increment the rightmost
byte as Goran has done (or, if it's already up to the limit, chop
it off and increment the next character position). Then test to
see whether the '<' operator actually believes the result is
greater than the given prefix, and repeat if not. This avoids making
any strong assumptions about the sort order of different character
codes. However, there are two significant issues that would have
to be surmounted to make it work reliably:

Sounds good idea.

1. In MULTIBYTE mode incrementing the rightmost byte might yield
an illegal multibyte character. Some way to prevent or detect this
would be needed, lest it confuse the comparison operator. I think
we have some multibyte routines that could be used to check for
a valid result, but I haven't looked into it.

I don't think this is an issue as long as locale isn't enabled. For
multibyte encodings (Japanese, Chinese etc..) locale is totally
useless and usually I don't enable it.

2. I think there are some locales out there that have context-
sensitive sorting rules, ie, a given character string may sort
differently than you'd expect from considering the characters in
isolation. For example, in German isn't "ss" treated specially?
If "pqrss" does not sort between "pqrs" and "pqrt" then the entire
premise of *both* sides of the LIKE optimization falls apart,
because you can't be sure what will happen when comparing a prefix
string like "pqrs" against longer strings from the database.
I do not know if this is really a problem, nor what we could do
to avoid it if it is.

I'm not sure about it but I am afraid it could be a problem. I think
real soultion would be supporting the standard CREATE COLLATION.
---
Tatsuo Ishii

From bouncefilter Mon Oct 18 20:59:44 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA47679
for <pgsql-hackers@postgreSQL.org>;
Mon, 18 Oct 1999 20:58:54 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id JAA01230; Tue, 19 Oct 1999 09:58:45 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] mdnblocks is an amazing time sink in huge relations
Date: Tue, 19 Oct 1999 10:02:42 +0900
Message-ID: <000201bf19cd$a5771c60$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
In-Reply-To: <25228.940259455@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

... I don't see anything fundamentally
wrong with using the existence and size of a data file as useful
information. It's not a substitute for a lock, of course, and there
may be places where we need cross-backend interlocks that we haven't
got now.

We have to lseek() each time to know the number of blocks of a table
file. Isn't it a overhead ?

True, but lseek is pretty cheap as kernel calls go (the kernel just has
to consult the file's inode, which should be in memory already). We're
not going to get the info for free; any other way of keeping track of
it is going to have its own costs. Vadim's been muttering about using
a shared cache for system catalog tuples, which might be a win but I'm
not sure (I'm worried about contention for the cache, especially if it's
protected by just one or a few spinlocks). Anyway, if we did have one
then keeping an accurate block count in the relation's pg_class row
would be a practical alternative.

Seems it's related to a TODO.
* Shared catalog cache, reduce lseek()'s by caching table size in shared
area

But there would be a problem if we use shared catalog cache.
Being updated system tuples are only visible to an updating backend
and other backends should see committed tuples.
On the other hand,an accurate block count should be visible to all
backends.
Which tuple of a row should we load to catalog cache and update ?

That's bothered me too. A possible answer would be to do the unlinking
back-to-front (zap the last file first); that'd require a few

more lines

of code in md.c, but a crash midway through would then leave a legal
file configuration that another backend could still do something with.

Oops,it's more serious than I have thought.
mdunlink() may only truncates a table file by a crash while unlinking
back-to-front.
A crash while unlinking front-to-back may leave unlinked segments
and they would suddenly appear as segments of the recreated table.
Seems there's no easy fix.

Well, it seems to me that the first misbehavior (incomplete delete becomes
a partial truncate, and you can try again) is a lot better than the
second (incomplete delete leaves an undeletable, unrecreatable table).
Should I go ahead and make delete/truncate work back-to-front, or do you
see a reason why that'd be a bad thing to do?

I also think back-to-front is better.

Probably it would require a lot of work to fix correctly.
Postponing real unlink/truncating until commit and creating table
files which correspond to their oids ..... etc ...
It's same as "DROP TABLE inside transations" requires.
Hmm,is it worth the work ?

I'm not eager to do that either (not just because of the low return on
work invested, but because naming table files by OIDs would be a big
handicap for debugging and database admin work). However, I'm not
quite sure why you see it as a solution to the problem of recovering
from a failed md.c operation. The risks would be the same if the
deletion was happening during commit, no? And I'd be a lot *more*
worried about deleting the wrong file during manual cleanup if the
files were named by OID ;-)

We don't have to delete relation files even after commit.
Backend would never see them and access to the files
corresponding to new oids of (being) recreated relations.
Deletion is necessary only not to consume disk space.

For example vacuum could remove not deleted files.
It may be a PostgreSQL style.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Oct 18 23:12:46 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA64699
for <pgsql-hackers@postgreSQL.org>;
Mon, 18 Oct 1999 23:11:45 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id XAA01691;
Mon, 18 Oct 1999 23:10:55 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
In-reply-to: Your message of Tue, 19 Oct 1999 10:02:42 +0900
<000201bf19cd$a5771c60$2801007e@cadzone.tpf.co.jp>
Date: Mon, 18 Oct 1999 23:10:54 -0400
Message-ID: <1689.940302654@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

a shared cache for system catalog tuples, which might be a win but I'm
not sure (I'm worried about contention for the cache, especially if it's
protected by just one or a few spinlocks). Anyway, if we did have one
then keeping an accurate block count in the relation's pg_class row
would be a practical alternative.

But there would be a problem if we use shared catalog cache.
Being updated system tuples are only visible to an updating backend
and other backends should see committed tuples.
On the other hand,an accurate block count should be visible to all
backends.
Which tuple of a row should we load to catalog cache and update ?

Good point --- rolling back a transaction would cancel changes to the
pg_class row, but it mustn't cause the relation's file to get truncated
(since there could be tuples of other uncommitted transactions in the
newly added block(s)).

This says that having a block count column in pg_class is the Wrong
Thing; we should get rid of relpages entirely. The Right Thing is a
separate data structure in shared memory that stores the current
physical block count for each active relation. The first backend to
touch a given relation would insert an entry, and then subsequent
extensions/truncations/deletions would need to update it. We already
obtain a special lock when extending a relation, so seems like there'd
be no extra locking cost to have a table like this.

Anyone up for actually implementing this ;-) ? I have other things
I want to work on...

Well, it seems to me that the first misbehavior (incomplete delete becomes
a partial truncate, and you can try again) is a lot better than the
second (incomplete delete leaves an undeletable, unrecreatable table).
Should I go ahead and make delete/truncate work back-to-front, or do you
see a reason why that'd be a bad thing to do?

I also think back-to-front is better.

OK, I have a couple other little things I want to do in md.c, so I'll
see what I can do about that. Even with a shared-memory relation
length table, back-to-front truncation would be the safest way to
proceed, so we'll want to make this change in any case.

Deletion is necessary only not to consume disk space.

For example vacuum could remove not deleted files.

Hmm ... interesting idea ... but I can hear the complaints
from users already...

regards, tom lane

From bouncefilter Mon Oct 18 23:18:45 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA65816
for <pgsql-hackers@postgreSQL.org>;
Mon, 18 Oct 1999 23:18:12 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id XAA01726;
Mon, 18 Oct 1999 23:17:38 -0400 (EDT)
To: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sort on huge table
In-reply-to: Your message of Mon, 18 Oct 1999 10:34:52 -0400
<25042.940257292@sss.pgh.pa.us>
Date: Mon, 18 Oct 1999 23:17:37 -0400
Message-ID: <1724.940303057@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I wrote:

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

If you could try sorting a table larger than 4GB with this code, I'd be
much obliged.

ERROR: ltsWriteBlock: failed to write block 131072 of temporary file
Perhaps out of disk space?

Drat. I'll take a look --- thanks for running the test.

That's what I get for not testing the interaction between logtape.c
and buffile.c at a segment boundary --- it didn't work, of course :-(.
I rebuilt with a small RELSEG_SIZE and debugged it. I'm still concerned
about possible integer overflow problems, so please update and try again
with a large file.

regards, tom lane

From bouncefilter Tue Oct 19 00:33:47 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA81287
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 00:33:20 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id AAA21492
for pgsql-hackers@postgreSQL.org; Tue, 19 Oct 1999 00:13:31 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910190413.AAA21492@candle.pha.pa.us>
Subject: funny psql output
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Tue, 19 Oct 1999 00:13:31 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Does this look strange to anyone:

test=> create table kk1 (born date);
CREATE
test=> select * from kk1;
born
----
(0 rows)

test=> insert into kk1 values ('1/1/1990');
INSERT 18588 1
test=> select * from kk1;
born
----------
01-01-1990
(1 row)

Look how 'born' is right-shifted in the column. Any idea why?

-- 
  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

From bouncefilter Tue Oct 19 00:29:47 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA80583
for <pgsql-hackers@hub.org>; Tue, 19 Oct 1999 00:29:45 -0400 (EDT)
(envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id MAA19920;
Tue, 19 Oct 1999 12:29:40 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380BF3B4.2A112AD1@krs.ru>
Date: Tue, 19 Oct 1999 12:29:40 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: bruc@acm.org
CC: pgsql-hackers@hub.org
Subject: Re: [HACKERS] Another historical message from the early days of
PostgreSQL development
References: <199910182104.RAA08532@stone.congenomics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Robert E. Bruccoleri" wrote:

Subject: [PG95]: Developers interested in improving PG95?
Date: Mon, 08 Jul 1996 22:12:19 -0400 (EDT)

^^^^^^^^^^^
Let's consider this as birthday of our project?
-:)

Vadim

From bouncefilter Tue Oct 19 00:41:48 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA83539
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 00:40:52 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id MAA20203;
Tue, 19 Oct 1999 12:40:40 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380BF648.11AE4FE5@krs.ru>
Date: Tue, 19 Oct 1999 12:40:40 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
References: <1689.940302654@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

a shared cache for system catalog tuples, which might be a win but I'm
not sure (I'm worried about contention for the cache, especially if it's
protected by just one or a few spinlocks). Anyway, if we did have one

Commercial DBMSes have this... Isn't it a good reason? -:)

But there would be a problem if we use shared catalog cache.
Being updated system tuples are only visible to an updating backend
and other backends should see committed tuples.
On the other hand,an accurate block count should be visible to all
backends.
Which tuple of a row should we load to catalog cache and update ?

Good point --- rolling back a transaction would cancel changes to the
pg_class row, but it mustn't cause the relation's file to get truncated
(since there could be tuples of other uncommitted transactions in the
newly added block(s)).

This says that having a block count column in pg_class is the Wrong
Thing; we should get rid of relpages entirely. The Right Thing is a
separate data structure in shared memory that stores the current
physical block count for each active relation. The first backend to
touch a given relation would insert an entry, and then subsequent
extensions/truncations/deletions would need to update it. We already
obtain a special lock when extending a relation, so seems like there'd
be no extra locking cost to have a table like this.

I supposed that each backend will still use own catalog
cache (after reading entries from shared one) and synchronize
shared/private caches on commit - e.g. update reltuples!
relpages will be updated immediately after physical changes -
what's problem with this?

Anyone up for actually implementing this ;-) ? I have other things
I want to work on...

And me too -:))

Vadim

From bouncefilter Tue Oct 19 00:43:47 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA84137
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 00:43:36 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id AAA08005;
Tue, 19 Oct 1999 00:42:08 -0400 (EDT)
To: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] is it possible to use LIMIT and INTERSECT ?
In-reply-to: Your message of Mon, 18 Oct 1999 10:37:55 -0400
<25071.940257475@sss.pgh.pa.us>
Date: Tue, 19 Oct 1999 00:42:08 -0400
Message-ID: <8003.940308128@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I wrote:

Hmm. It seemed to work as expected in current --- maybe there is
another bug still lurking in 6.5.*. I'll look when I get a chance.

Yup, this change that was already in current is also needed:

*** src/backend/parser/gram.y.orig	Mon Oct 18 23:59:35 1999
--- src/backend/parser/gram.y	Mon Oct 18 23:55:18 1999
***************
*** 2768,2773 ****
--- 2768,2775 ----
  				  /* finally attach the sort clause */
  				  first_select->sortClause = $2;
  				  first_select->forUpdate = $3;
+ 				  first_select->limitOffset = nth(0, $4);
+ 				  first_select->limitCount = nth(1, $4);
  				  $$ = (Node *)first_select;
  				}		
  				if (((SelectStmt *)$$)->forUpdate != NULL && QueryIsRule)

I have updated both current and REL6_5 branches.

regards, tom lane

From bouncefilter Tue Oct 19 01:06:48 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA90352
for <pgsql-hackers@postgresql.org>;
Tue, 19 Oct 1999 01:06:04 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA08359;
Tue, 19 Oct 1999 01:05:00 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] funny psql output
In-reply-to: Your message of Tue, 19 Oct 1999 00:13:31 -0400 (EDT)
<199910190413.AAA21492@candle.pha.pa.us>
Date: Tue, 19 Oct 1999 01:05:00 -0400
Message-ID: <8357.940309500@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <maillist@candle.pha.pa.us> writes:

test=> insert into kk1 values ('1/1/1990');
INSERT 18588 1
test=> select * from kk1;
born
----------
01-01-1990
(1 row)

Look how 'born' is right-shifted in the column. Any idea why?

I think libpq's print routine is deciding that the column is numeric.
(all digits and minus signs ... and IIRC it's not very picky about
where the minus signs are...)

Perhaps Peter will fix this during his massive rewrite.

regards, tom lane

From bouncefilter Tue Oct 19 01:29:49 1999
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA95924
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 01:29:22 -0400 (EDT) (envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id JAA26594;
Tue, 19 Oct 1999 09:28:55 +0400 (MSD)
Date: Tue, 19 Oct 1999 09:28:55 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] is it possible to use LIMIT and INTERSECT ?
In-Reply-To: <8003.940308128@sss.pgh.pa.us>
Message-ID: <Pine.GSO.3.96.SK.991019092317.8622I-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Thanks Tom,

I synced REL6_5 tree, compile, install but still query

select a.msg_id, c.status_set_date, c.title
from Message_Keyword_map a, messages c, keywords d
where c.status_id =1 and d.name ~* 'sun' and a.key_id=d.key_id
and c.msg_id=a.msg_id
intersect
select a.msg_id, a.status_set_date, a.title
from messages a where a.status_id = 1 and a.title ~* 'sun' limit 10;

produces more than 10 rows !

Regards,

Oleg

On Tue, 19 Oct 1999, Tom Lane wrote:

Date: Tue, 19 Oct 1999 00:42:08 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] is it possible to use LIMIT and INTERSECT ?

I wrote:

Hmm. It seemed to work as expected in current --- maybe there is
another bug still lurking in 6.5.*. I'll look when I get a chance.

Yup, this change that was already in current is also needed:

*** src/backend/parser/gram.y.orig	Mon Oct 18 23:59:35 1999
--- src/backend/parser/gram.y	Mon Oct 18 23:55:18 1999
***************
*** 2768,2773 ****
--- 2768,2775 ----
/* finally attach the sort clause */
first_select->sortClause = $2;
first_select->forUpdate = $3;
+ 				  first_select->limitOffset = nth(0, $4);
+ 				  first_select->limitCount = nth(1, $4);
$$ = (Node *)first_select;
}		
if (((SelectStmt *)$$)->forUpdate != NULL && QueryIsRule)

I have updated both current and REL6_5 branches.

regards, tom lane

************

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

From bouncefilter Tue Oct 19 01:34:48 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA97799
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 01:34:26 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA08434;
Tue, 19 Oct 1999 01:33:10 -0400 (EDT)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] is it possible to use LIMIT and INTERSECT ?
In-reply-to: Your message of Tue, 19 Oct 1999 09:28:55 +0400 (MSD)
<Pine.GSO.3.96.SK.991019092317.8622I-100000@ra>
Date: Tue, 19 Oct 1999 01:33:09 -0400
Message-ID: <8432.940311189@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Oleg Bartunov <oleg@sai.msu.su> writes:

Thanks Tom,
I synced REL6_5 tree, compile, install but still query

select a.msg_id, c.status_set_date, c.title
from Message_Keyword_map a, messages c, keywords d
where c.status_id =1 and d.name ~* 'sun' and a.key_id=d.key_id
and c.msg_id=a.msg_id
intersect
select a.msg_id, a.status_set_date, a.title
from messages a where a.status_id = 1 and a.title ~* 'sun' limit 10;

produces more than 10 rows !

If you'd care to provide a reproducible stand-alone test case I'll look
into it further. I do not feel like trying to reverse-engineer your
table declarations.

regards, tom lane

At 22:56 +0200 on 17/10/1999, =?iso-8859-2?Q?Daniel_P=E9der?= wrote:

what about this:
( it would be nice to have it working, specially for copying values from
files into table with default fields, having the default fields doing
their job or initialising tables using reduced set of columns )

mydb=> create sequence MYSEQ;
CREATE
mydb=> create table MYTAB ( ID int4 default nextval('MYSEQ'), NAME text );
CREATE
mydb=> create view MYVIEW as select name from MYTAB;
CREATE
mydb=> copy MYVIEW from stdin;

Seems this view is neither insertable nor copyable. To make it insertable,
you have to define a rule, you know.

In any case, I don't think it would work for copy - the rule I mean.

IMO, if you want to copy data and have defaults work, you copy the data
into a temporary table with only the necessary fields, and then issue an
insert:

CREATE TEMP TABLE tmp_tab ( name text );
COPY tmp_tab FROM stdin;
jim
john
jack
\.
INSERT INTO mytab (name) SELECT name FROM tmp_tab;
DROP TABLE tmp_tab;

Herouth

--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma

From bouncefilter Tue Oct 19 10:03:53 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA28162
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 10:03:20 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id JAA23790
for pgsql-hackers@postgreSQL.org; Tue, 19 Oct 1999 09:41:49 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910191341.JAA23790@candle.pha.pa.us>
Subject: Readline use in trouble?
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Tue, 19 Oct 1999 09:41:49 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM940340508-23452-0_
Content-Transfer-Encoding: 7bit

--ELM940340508-23452-0_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Here is something I read as part of the Alladin Ghostscript 6.0 beta
release. I must admit I don't understand the logic of the issue. It
seems the issue is that you can link non-GPL to GPL libraries, but you
can't distribute the result. Maybe it doesn't apply to us because we
don't copyright our code.

It seems to suggest that we could be prevented from distributing
readline in the future. Not sure though.

It sounds like the old US crypto restriction where you couldn't
distribute software that had hooks in it to add crypto.

Removal of readline would certainly affect psql users.

The actual file is gs5.94/doc/Make.htm.1

-- 
  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

--ELM940340508-23452-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/bjm/readline"
Content-Transfer-Encoding: 7bit

GNU readline

Aladdin Ghostscript does not include an interface to GNU readline.
Even though the GNU License (GPL) allows linking GPL'ed code (such as
the GNU readline library package) with non-GPL'ed code (such as all
the rest of Ghostscript) if one doesn't distribute the result, the
Free Software Foundation, creators of the GPL, have told us that in
their opinion, the GPL forbids distributing non-GPL'ed code that is
merely intended to be linked with GPL'ed code. We understand that FSF
takes this position in order to prevent the construction of software
that is partly GPL'ed and partly not GPL'ed, even though the GPL does
not in fact literally forbid this (it only forbids distribution of
such software). We think that FSF's position is both legally
questionable and harmful to users, but we do not have the resources to
challenge it, especially since FSF's attorney apparently supports it.
Therefore, even though we added a user-contributed interface to GNU
readline in internal Aladdin Ghostscript version 5.71 and had it
working in version 5.93 (the next-to-last beta version before the 6.0
release), we have removed it from the Aladdin Ghostscript 6.0
distribution.

GNU Ghostscript distributions will include support for GNU readline.
As with other GNU Ghostscript components that are not included in
Aladdin Ghostscript, Aladdin will not attempt to run, link, or even
compile this code, or keep it current across changes in the rest of
Ghostscript. We will, however, welcome bug fixes or updates, and
distribute them with subsequent releases of GNU Ghostscript.

The first GNU Ghostscript distribution that will include GNU readline
support will be GNU Ghostscript 6.0, currently scheduled for release
in the third quarter of 2000. Before that time, we may return the
copyright of Ghostscript's GNU readline interface module, which the
original author assigned to Aladdin Enterprises, to the author, so
that users of GNU Ghostscript will have have access to it. However,
since it requires internal changes that are not and will not be
available in any released GNU Ghostscript version before 6.0, any user
who gets this code and links it with Aladdin Ghostscript 6.0 will,
according to FSF, be violating the intent (though not the letter) of
the GPL.

We have, in fact, put considerable work into making it possible for
Ghostscript to use GNU readline, including the creation and/or
adjustment of internal software interfaces specifically to serve this
purpose. In principle, we should have undone this work in Aladdin
Ghostscript as well, lest FSF object to it too as intended to
facilitate linking Aladdin Ghostscript with GNU readline (as the U.S.
government has been said to do for code that merely provides APIs
where encryption may be added). However, we are willing to take this
risk rather than spend the time to undo the interface changes.

If you have comments or questions about this situation, please feel
free to contact the Free Software Foundation, authors of the GPL and
copyright holders of GNU readline, at gnu@gnu.org, and/or Aladdin
Enterprises, author and copyright holder of Ghostscript, at
ghost@aladdin.com.

--ELM940340508-23452-0_

--ELM940340508-23452-0_--

From bouncefilter Tue Oct 19 10:10:53 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA29914
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 10:10:33 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA09038;
Tue, 19 Oct 1999 10:09:15 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Vadim Mikheev" <vadim@krs.ru>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
In-reply-to: Your message of Tue, 19 Oct 1999 19:03:22 +0900
<000801bf1a19$2d88ae20$2801007e@cadzone.tpf.co.jp>
Date: Tue, 19 Oct 1999 10:09:15 -0400
Message-ID: <9036.940342155@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

1. shared cache holds committed system tuples.
2. private cache holds uncommitted system tuples.
3. relpages of shared cache are updated immediately by
phisical change and corresponding buffer pages are
marked dirty.
4. on commit, the contents of uncommitted tuples except
relpages,reltuples,... are copied to correponding tuples
in shared cache and the combined contents are
committed.
If so,catalog cache invalidation would be no longer needed.
But synchronization of the step 4. may be difficult.

I think the main problem is that relpages and reltuples shouldn't
be kept in pg_class columns at all, because they need to have
very different update behavior from the other pg_class columns.

The rest of pg_class is update-on-commit, and we can lock down any one
row in the normal MVCC way (if transaction A has modified a row and
transaction B also wants to modify it, B waits for A to commit or abort,
so it can know which version of the row to start from). Furthermore,
there can legitimately be several different values of a row in use in
different places: the latest committed, an uncommitted modification, and
one or more old values that are still being used by active transactions
because they were current when those transactions started. (BTW, the
present relcache is pretty bad about maintaining pure MVCC transaction
semantics like this, but it seems clear to me that that's the direction
we want to go in.)

relpages cannot operate this way. To be useful for avoiding lseeks,
relpages *must* change exactly when the physical file changes. It
matters not at all whether the particular transaction that extended the
file ultimately commits or not. Moreover there can be only one correct
value (per relation) across the whole system, because there is only one
length of the relation file.

If we want to take reltuples seriously and try to maintain it
on-the-fly, then I think it needs still a third behavior. Clearly
it cannot be updated using MVCC rules, or we lose all writer
concurrency (if A has added tuples to a rel, B would have to wait
for A to commit before it could update reltuples...). Furthermore
"updating" isn't a simple matter of storing what you think the new
value is; otherwise two transactions adding tuples in parallel would
leave the wrong answer after B commits and overwrites A's value.
I think it would work for each transaction to keep track of a net delta
in reltuples for each table it's changed (total tuples added less total
tuples deleted), and then atomically add that value to the table's
shared reltuples counter during commit. But that still leaves the
problem of how you use the counter during a transaction to get an
accurate answer to the question "If I scan this table now, how many tuples
will I see?" At the time the question is asked, the current shared
counter value might include the effects of transactions that have
committed since your transaction started, and therefore are not visible
under MVCC rules. I think getting the correct answer would involve
making an instantaneous copy of the current counter at the start of
your xact, and then adding your own private net-uncommitted-delta to
the saved shared counter value when asked the question. This doesn't
look real practical --- you'd have to save the reltuples counts of
*all* tables in the database at the start of each xact, on the off
chance that you might need them. Ugh. Perhaps someone has a better
idea. In any case, reltuples clearly needs different mechanisms than
the ordinary fields in pg_class do, because updating it will be a
performance bottleneck otherwise.

If we allow reltuples to be updated only by vacuum-like events, as
it is now, then I think keeping it in pg_class is still OK.

In short, it seems clear to me that relpages should be removed from
pg_class and kept somewhere else if we want to make it more reliable
than it is now, and the same for reltuples (but reltuples doesn't
behave the same as relpages, and probably ought to be handled
differently).

regards, tom lane

From bouncefilter Tue Oct 19 10:14:53 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA30837
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 10:14:24 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA09069;
Tue, 19 Oct 1999 10:13:46 -0400 (EDT)
To: wieck@debis.com (Jan Wieck)
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: New developer globe
In-reply-to: Your message of Tue, 19 Oct 1999 13:28:11 +0200 (MET DST)
<m11dXR5-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Tue, 19 Oct 1999 10:13:45 -0400
Message-ID: <9067.940342425@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

Also I think putting the photos below the globe (at least in addition)
might be better because for people digging around in Europe or the North
American east coast it obscures too much and it's also hard to get an
overview.

I could turn the text in the pages body into a table and add
the images there too. But I absolutely like them in the popup
and will let them in.

When I was looking at the page last night, I could *not* get Netscape
to show me the images in the popups at all; I just got the "unloaded
image" icon. This probably had something to do with the fact that
I normally browse with autoload images off, and had come to the page
in that state. There's no way to click on an image that's inside a
popup to get it to load :-(. But even after I turned on autoload
and reloaded the page, no popup images.

regards, tom lane

From bouncefilter Tue Oct 19 10:17:53 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA31875
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 10:17:45 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA09102;
Tue, 19 Oct 1999 10:17:06 -0400 (EDT)
To: t-ishii@sra.co.jp
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sort on huge table
In-reply-to: Your message of Tue, 19 Oct 1999 17:49:22 +0900
<199910190849.RAA29403@srapc451.sra.co.jp>
Date: Tue, 19 Oct 1999 10:17:06 -0400
Message-ID: <9100.940342626@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

It worked with 2GB+ table but was much slower than before.
Before(with 8MB sort memory): 22 minutes
After(with 8MB sort memory): 1 hour and 5 minutes
After(with 80MB sort memory): 42 minutes.

Oh dear. I had tested it with smaller files and concluded that it was
no slower than before ... I guess there is some effect I'm not seeing
here. Can you tell whether the extra time is computation or I/O (how
much does the runtime of the backend change between old and new code)?

regards, tom lane

From bouncefilter Tue Oct 19 10:27:53 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id KAA34599
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 10:27:51 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11daAs-0003kLC; Tue, 19 Oct 99 16:23 MET DST
Message-Id: <m11daAs-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: New developer globe
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Tue, 19 Oct 1999 16:23:38 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <9067.940342425@sss.pgh.pa.us> from "Tom Lane" at Oct 19,
99 10:13:45 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

wieck@debis.com (Jan Wieck) writes:

Also I think putting the photos below the globe (at least in addition)
might be better because for people digging around in Europe or the North
American east coast it obscures too much and it's also hard to get an
overview.

I could turn the text in the pages body into a table and add
the images there too. But I absolutely like them in the popup
and will let them in.

When I was looking at the page last night, I could *not* get Netscape
to show me the images in the popups at all; I just got the "unloaded
image" icon. This probably had something to do with the fact that
I normally browse with autoload images off, and had come to the page
in that state. There's no way to click on an image that's inside a
popup to get it to load :-(. But even after I turned on autoload
and reloaded the page, no popup images.

Should be better now. I've turned the body into the mentioned
table. IMHO this requires that we get images for ALL
developers, since the current mixing of items with/without is
ugly.

The images referenced in the body are the same as is the
popup. Thus, when you've loaded them (maybe with the general
Images button) they should popup.

Works at least with Netscape4.6 Linux.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Oct 19 10:32:54 1999
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA35840
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 10:32:51 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA23499;
Tue, 19 Oct 1999 14:32:24 GMT
Sender: lockhart@hub.org
Message-ID: <380C80F7.5C5D90F4@alumni.caltech.edu>
Date: Tue, 19 Oct 1999 14:32:23 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
References: <199910191341.JAA23790@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Removal of readline would certainly affect psql users.

afaik the Alladin product is not in the same licensing category as
Postgres (there are restrictions that, for example, prohibit RedHat
from distributing a recent version of gs with their package).

Not to worry...

- Thomas

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

From bouncefilter Tue Oct 19 10:35:54 1999
Received: from fep132.fep.ru (mail@[195.230.89.88])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA36743
for <pgsql-hackers@postgresql.org>;
Tue, 19 Oct 1999 10:35:18 -0400 (EDT) (envelope-from phd@phd.russ.ru)
Received: from localhost [127.0.0.1] (phd)
by fep132.fep.ru with esmtp (Exim 2.05 #1 (Debian))
id 11daKe-0008MQ-00; Tue, 19 Oct 1999 18:33:44 +0400
Date: Tue, 19 Oct 1999 14:33:43 +0000 (GMT)
From: Oleg Broytmann <phd@phd.russ.ru>
X-Sender: phd@fep132.fep.ru
Reply-To: phd2@earthling.net
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <199910191341.JAA23790@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.20.9910191418040.32040-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hello!

On Tue, 19 Oct 1999, Bruce Momjian wrote:

Here is something I read as part of the Alladin Ghostscript 6.0 beta
release. I must admit I don't understand the logic of the issue. It
seems the issue is that you can link non-GPL to GPL libraries, but you
can't distribute the result. Maybe it doesn't apply to us because we
don't copyright our code.

It seems to suggest that we could be prevented from distributing
readline in the future. Not sure though.

It is second or third time I see this, so I think I understand. This is
the way FSF protects GNU-licensed code - you can link with GNU code, but
you cannot distribute non-GNU code in binary form linked with GNU code.
If you want to distribute non-GNU code in binary form only, either you
must NOT to link it with GNU code; or link it with GNU code and provide a
way to user to relink to other versions of GNU code; or just publish your
sources.
The second way means - publish your *.o for all platforms. The way
number 3 means "give all users a way to compile and link it as they want,
with or without GNU code". I think this applied to PostgreSQL - we have
source code published, so I do not expect problems with readline.
Binary-only programs are in GNUtroubles, really. Somewhere on
www.gnu.org I saw a story about a company that made a program, linked it
with libreadline and distributed it in binary-only form. FSF contacted the
company asked to remove libreadline. The company instead published the
whole sources. FSF considered it as a Big Win!
BTW, readline is a special case here - it protected by GNU GPL, which is
very restrictive. Most free/opensource libs are protected with GNU LGPL,
which is less restrictive. GNU readline is the way FSF forces people to
publsih sources!

Sorry, my English is far from perfect, if you do not understand my
explanations - we may raise a discussion here, and I'll try to find a
better words...

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

From bouncefilter Tue Oct 19 10:39:54 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id KAA37858
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 10:39:43 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11daME-0003kLC; Tue, 19 Oct 99 16:35 MET DST
Message-Id: <m11daME-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Readline use in trouble?
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Tue, 19 Oct 1999 16:35:22 +0200 (MET DST)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199910191341.JAA23790@candle.pha.pa.us> from "Bruce Momjian" at
Oct 19, 99 09:41:49 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

Here is something I read as part of the Alladin Ghostscript 6.0 beta
release. I must admit I don't understand the logic of the issue. It
seems the issue is that you can link non-GPL to GPL libraries, but you
can't distribute the result. Maybe it doesn't apply to us because we
don't copyright our code.

It seems to suggest that we could be prevented from distributing
readline in the future. Not sure though.

It sounds like the old US crypto restriction where you couldn't
distribute software that had hooks in it to add crypto.

Removal of readline would certainly affect psql users.

Now the time has come that the FSF has grown that big that
they try to redefine the meaning of "Free". Next they claim
"Free" is their trademark :-(

I think readline isn't our biggest problem. What about if
they notice that our parser can only be compiled when using
bison, and that we ship the generated output for the case
someone doesn't has bison installed?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Oct 19 10:49:54 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA41430
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 10:49:43 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA09239;
Tue, 19 Oct 1999 10:44:01 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
In-reply-to: Your message of Tue, 19 Oct 1999 09:41:49 -0400 (EDT)
<199910191341.JAA23790@candle.pha.pa.us>
Date: Tue, 19 Oct 1999 10:44:01 -0400
Message-ID: <9237.940344241@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <maillist@candle.pha.pa.us> writes:

Here is something I read as part of the Alladin Ghostscript 6.0 beta
release. I must admit I don't understand the logic of the issue. It
seems the issue is that you can link non-GPL to GPL libraries, but you
can't distribute the result. Maybe it doesn't apply to us because we
don't copyright our code.

Huh? We certainly do --- or have you missed that
* Copyright (c) 1994, Regents of the University of California
that's plastered across all the source files?

The GPL does restrict the conditions under which GPL'd code can be
distributed; in particular it can't be distributed as part of a program
that is not all GPL'd (more or less --- I have not read the terms lately).
So, because we use BSD license rather than GNU, we cannot *include in
our distribution* any library that is under GPL.

Any end user who does not intend to redistribute the result can
certainly obtain our distribution and readline and build them together.
So it's no issue for source distributions, but I wonder about RPMs.
Our RPMs do not include the actual libreadline file, do they?

Even though the GNU License (GPL) allows linking GPL'ed code (such as
the GNU readline library package) with non-GPL'ed code (such as all
the rest of Ghostscript) if one doesn't distribute the result, the
Free Software Foundation, creators of the GPL, have told us that in
their opinion, the GPL forbids distributing non-GPL'ed code that is
merely intended to be linked with GPL'ed code.

As stated, this is ridiculous on its face. The FSF has no possible
right to prevent the distribution of software that they didn't write
and that doesn't fall under the GPL.

Although I haven't been paying close attention to the Ghostscript
situation, I suspect that the real story is either that the readline
interface code that someone contributed to Ghostscript was contributed
with GPL terms already attached to it, or that Aladdin is concerned
about being able to distribute full-featured precompiled binaries of
Ghostscript. (BTW, Peter Deutsch has a history of forcing the issue
when he thinks that someone else is being unreasonable, and I suspect
that he's deliberately overreacting in hopes of making FSF change
their position.)

Anyway, this sort of thing is why it's a bad idea to accept any GPL'd
code into Postgres --- the GPL does not play nice with other licenses.
I think the FSF is not doing the free software movement any service
with this foolishness, but they're entitled to distribute their code
with any terms they want, of course.

My inclination is to ignore the issue until and unless we hear a
complaint from the libreadline authors --- and if we do, we yank all
trace of readline support from psql. End of story.

regards, tom lane

From bouncefilter Tue Oct 19 10:50:54 1999
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA41706;
Tue, 19 Oct 1999 10:50:03 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA23546;
Tue, 19 Oct 1999 14:49:35 GMT
Sender: lockhart@hub.org
Message-ID: <380C84FF.40B12272@alumni.caltech.edu>
Date: Tue, 19 Oct 1999 14:49:35 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Vince Vielhaber <vev@michvhf.com>, webmaster@postgresql.org,
Lamar Owen <lamar.owen@wgcr.org>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Need refresh on main page...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

From bouncefilter Tue Oct 19 10:56:54 1999
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA43714
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 10:56:17 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA23556;
Tue, 19 Oct 1999 14:55:47 GMT
Sender: lockhart@hub.org
Message-ID: <380C8672.6F2CA41@alumni.caltech.edu>
Date: Tue, 19 Oct 1999 14:55:46 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Readline use in trouble?
References: <m11daME-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I think readline isn't our biggest problem. What about if
they notice that our parser can only be compiled when using
bison, and that we ship the generated output for the case
someone doesn't has bison installed?

afaik this is explicitly covered as "conforming behavior" in the GNU
license for bison. It was not always so, but the license for bison was
recently updated to allow distributing generated code.

I should point out that rms himself is on speaking terms with us; he
recently referred someone here to ask about Postgres vis a vis Oracle
compatibility. I'm pretty sure we are one of "the good guys" in Open
Source. ;)

- Thomas

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

From bouncefilter Tue Oct 19 11:02:54 1999
Received: from fep132.fep.ru (mail@[195.230.89.88])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA45727
for <pgsql-hackers@postgresql.org>;
Tue, 19 Oct 1999 11:02:27 -0400 (EDT) (envelope-from phd@phd.russ.ru)
Received: from localhost [127.0.0.1] (phd)
by fep132.fep.ru with esmtp (Exim 2.05 #1 (Debian))
id 11dagt-0008PT-00; Tue, 19 Oct 1999 18:56:43 +0400
Date: Tue, 19 Oct 1999 14:56:42 +0000 (GMT)
From: Oleg Broytmann <phd@phd.russ.ru>
X-Sender: phd@fep132.fep.ru
Reply-To: phd2@earthling.net
To: Jan Wieck <wieck@debis.com>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <m11daME-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.LNX.4.20.9910191453380.32316-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Oct 1999, Jan Wieck wrote:

I think readline isn't our biggest problem. What about if
they notice that our parser can only be compiled when using
bison, and that we ship the generated output for the case
someone doesn't has bison installed?

Until they make a significant change in their license we don't need to
worry. GPL specifically states that the RESULTS of GNU-protected programs
are not covered at all. These results can be used in any way you want,
including commercial ways. Only program's code matter.

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.