SELECT DISTINCT question

Started by Oleg Bartunovalmost 27 years ago11 messageshackers

oleg@sai.msu.su

almost 27 years ago

I got a problem with query:

select distinct (date), bytes from access_log;

which works but not as I expect. I thought this query will select
all rows with distinct values of 'date' column, but it get
distinct pairs 'date, bytes' . From documnetation I see

"DISTINCT will eliminate all duplicate rows from the selection.
DISTINCT ON column will eliminate all duplicates in the specified column;
this is equivalent to using GROUP BY column.
ALL will return all candidate rows, including duplicates."

discovery=> select distinct on date,bytes from access_log;
ERROR: parser: parse error at or near ","

Regards,

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

Tom Lane

tgl@sss.pgh.pa.us

almost 27 years ago

In reply to: Oleg Bartunov (#1)

Re: [HACKERS] SELECT DISTINCT question

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

discovery=> select distinct on date,bytes from access_log;
ERROR: parser: parse error at or near ","

The syntax for SELECT DISTINCT ON is just as brain-damaged as the
functionality itself: there's no comma after the column name.
You want

select distinct on date date,bytes from access_log;

The reason the functionality is brain-damaged is that there's no way to
know which tuple out of the set of tuples with a given "date" value will
be the one returned.

SELECT DISTINCT ON is not in SQL92, and I think it shouldn't be in
Postgres either...

regards, tom lane

Import Notes

Reply to msg id not found: YourmessageofSun11Jul1999001639+0400Pine.GSO.3.96.SK.990711000908.2043R-100000@ra | Resolved by subject fallback

Oleg Bartunov

oleg@sai.msu.su

almost 27 years ago

In reply to: Tom Lane (#2)

Re: [SQL] Re: [HACKERS] SELECT DISTINCT question

On Sat, 10 Jul 1999, Tom Lane wrote:

Date: Sat, 10 Jul 1999 17:18:28 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Oleg Bartunov <oleg@sai.msu.su>
Cc: hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: [SQL] Re: [HACKERS] SELECT DISTINCT question

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

discovery=> select distinct on date,bytes from access_log;
ERROR: parser: parse error at or near ","

The syntax for SELECT DISTINCT ON is just as brain-damaged as the
functionality itself: there's no comma after the column name.
You want

select distinct on date date,bytes from access_log;

thanks, this works. But why parser complains about such query:

discovery=> select distinct on a.date a.date, a.bytes from access_log a;
ERROR: parser: parse error at or near "."

In this query I could just omit '.', but in more complex query
I probably could need one.

The reason the functionality is brain-damaged is that there's no way to
know which tuple out of the set of tuples with a given "date" value will
be the one returned.

SELECT DISTINCT ON is not in SQL92, and I think it shouldn't be in
Postgres either...

I'm not an SQL expert, but if it works and this feature is in standard
but only syntax is diffrent, why just not to use standard

select distinct(date), bytes from access_log;

Or I'm missing here ?

Regards,
Oleg

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

Tom Lane

tgl@sss.pgh.pa.us

almost 27 years ago

In reply to: Oleg Bartunov (#3)

Re: [SQL] Re: [HACKERS] SELECT DISTINCT question

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

thanks, this works. But why parser complains about such query:

discovery=> select distinct on a.date a.date, a.bytes from access_log a;
ERROR: parser: parse error at or near "."

Probably the grammar specifies just <column name> and not anything
more complex after DISTINCT ON. It'd be risky to try to accept a
general expression after ON, due to the silly decision to leave out
any terminating punctuation.

SELECT DISTINCT ON is not in SQL92, and I think it shouldn't be in
Postgres either...

I'm not an SQL expert, but if it works and this feature is in standard
but only syntax is diffrent,

No, there is no feature in SQL that allows DISTINCT on a subset of
columns, period. This is not merely a matter of syntax, it's a
fundamental semantic issue.

why just not to use standard

select distinct(date), bytes from access_log;

Or I'm missing here ?

I don't think that does what you expect it to (hint: the
parentheses are redundant).

regards, tom lane

Import Notes

Reply to msg id not found: YourmessageofSun11Jul1999100924+0400Pine.GSO.3.96.SK.990711100405.2043V-100000@ra | Resolved by subject fallback

Hannu Krosing

hannu@tm.ee

almost 27 years ago

In reply to: Oleg Bartunov (#1)

Re: [HACKERS] SELECT DISTINCT question

Oleg Bartunov wrote:

I got a problem with query:

select distinct (date), bytes from access_log;

which works but not as I expect. I thought this query will select
all rows with distinct values of 'date' column, but it get
distinct pairs 'date, bytes' . From documnetation I see

"DISTINCT will eliminate all duplicate rows from the selection.
DISTINCT ON column will eliminate all duplicates in the specified column;
this is equivalent to using GROUP BY column.

If it is equivalent to GROUP BY then it should allow only aggregates
in non-distinct columns, like:

select distinct on date date, sum(bytes) from access_log;

If it does not, then it should be files as a bug imho.

-----------------
Hannu

Tom Lane

tgl@sss.pgh.pa.us

almost 27 years ago

In reply to: Hannu Krosing (#5)

Re: [HACKERS] SELECT DISTINCT question

Hannu Krosing <hannu@trust.ee> writes:

"DISTINCT will eliminate all duplicate rows from the selection.
DISTINCT ON column will eliminate all duplicates in the specified column;
this is equivalent to using GROUP BY column."

If it is equivalent to GROUP BY then it should allow only aggregates
in non-distinct columns, like:
select distinct on date date, sum(bytes) from access_log;
If it does not, then it should be files as a bug imho.

It does not. Whether that is a bug is hard to say, since there is no
standard I know of that says what it *is* supposed to do.

If you look at the select_distinct_on regress test outputs, I bet you
will be even less happy:

QUERY: SELECT DISTINCT ON string4 two, string4, ten
FROM tmp
ORDER BY two using <, string4 using <, ten using <;
two|string4|ten
---+-------+---
0|AAAAxx | 0
0|HHHHxx | 0
0|OOOOxx | 0
0|VVVVxx | 0
1|AAAAxx | 1
1|HHHHxx | 1
1|OOOOxx | 1
1|VVVVxx | 1
(8 rows)

That's not exactly my idea of "distinct" values of string4 ---
but apparently whoever made up the regress test thought it was OK!

Can anyone defend this feature or provide a coherent definition
of what it's supposed to be doing? My urge to rip it out is
growing stronger and stronger...

regards, tom lane

Import Notes

Reply to msg id not found: YourmessageofTue13Jul1999235057+0300378BA6B1.2B226DDB@trust.ee | Resolved by subject fallback

Bruce Momjian

bruce@momjian.us

over 26 years ago

In reply to: Tom Lane (#6)

Re: [SQL] Re: [HACKERS] SELECT DISTINCT question

Tom, any status on this DISTINCT ON ripout?

Hannu Krosing <hannu@trust.ee> writes:

"DISTINCT will eliminate all duplicate rows from the selection.
DISTINCT ON column will eliminate all duplicates in the specified column;
this is equivalent to using GROUP BY column."

If it is equivalent to GROUP BY then it should allow only aggregates
in non-distinct columns, like:
select distinct on date date, sum(bytes) from access_log;
If it does not, then it should be files as a bug imho.

It does not. Whether that is a bug is hard to say, since there is no
standard I know of that says what it *is* supposed to do.

If you look at the select_distinct_on regress test outputs, I bet you
will be even less happy:

QUERY: SELECT DISTINCT ON string4 two, string4, ten
FROM tmp
ORDER BY two using <, string4 using <, ten using <;
two|string4|ten
---+-------+---
0|AAAAxx | 0
0|HHHHxx | 0
0|OOOOxx | 0
0|VVVVxx | 0
1|AAAAxx | 1
1|HHHHxx | 1
1|OOOOxx | 1
1|VVVVxx | 1
(8 rows)

That's not exactly my idea of "distinct" values of string4 ---
but apparently whoever made up the regress test thought it was OK!

Can anyone defend this feature or provide a coherent definition
of what it's supposed to be doing? My urge to rip it out is
growing stronger and stronger...

regards, tom lane

-- 
  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 Thu Sep 23 13:28:57 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA91975
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 13:28:25 -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 NAA19787;
Thu, 23 Sep 1999 13:27:11 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909231727.NAA19787@candle.pha.pa.us>
Subject: Re: [HACKERS] create rule changes table to view ?
In-Reply-To: <Pine.GSO.3.96.SK.990711212334.2043a-100000@ra> from Oleg
Bartunov
at "Jul 11, 1999 09:27:22 pm"
To: Oleg Bartunov <oleg@sai.msu.su>
Date: Thu, 23 Sep 1999 13:27:11 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Can someone comment on this?

I just began to learn rules with 6.5 and notice:
test=> \dt
Database    = test
+------------------+----------------------------------+----------+
|  Owner           |             Relation             |   Type   |
+------------------+----------------------------------+----------+
| megera           | access_log                       | table    |
| megera           | hits                             | table    |
| megera           | junk_qwerty                      | table    |
+------------------+----------------------------------+----------+

test=>  create rule log_hits as on update to hits  do instead insert into hits values ( NEW.msg_id, 1);
CREATE
test=> \dt
Database    = test
+------------------+----------------------------------+----------+
|  Owner           |             Relation             |   Type   |
+------------------+----------------------------------+----------+
| megera           | access_log                       | table    |
| megera           | hits                             | view?    |
| megera           | junk_qwerty                      | table    |
+------------------+----------------------------------+----------+

Table hits now becomes view ?

Regards,

Oleg

-- 
  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 Thu Sep 23 13:36:58 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA93894
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 13:36:17 -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 NAA20235
for pgsql-hackers@postgreSQL.org; Thu, 23 Sep 1999 13:35:51 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909231735.NAA20235@candle.pha.pa.us>
Subject: [HACKERS] 9-key index ? (fwd)
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Thu, 23 Sep 1999 13:35:51 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM938108151-18329-0_
Content-Transfer-Encoding: 7bit

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

I am adding this to the TODO list.

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

--ELM938108151-18329-0_
Content-Type: message/rfc822
Content-Disposition: inline
Content-Description: Forwarded message from Hiroshi Inoue
Content-Transfer-Encoding: 7bit

Received: from hub.org (hub.org [209.167.229.1])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA08452
for <maillist@candle.pha.pa.us>; Tue, 13 Jul 1999 22:30:49 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA31614;
Tue, 13 Jul 1999 22:25:04 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32));
Tue, 13 Jul 1999 22:22:59 +0000 (EDT)
Received: (from majordom@localhost) by hub.org (8.9.3/8.9.3) id WAA31285
for pgsql-hackers-outgoing; Tue, 13 Jul 1999 22:22:58 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to
owner-pgsql-hackers@postgreSQL.org using -f
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 WAA31259
for <pgsql-hackers@postgreSQL.org>;
Tue, 13 Jul 1999 22:22:47 -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 LAA04296 for <pgsql-hackers@postgreSQL.org>;
Wed, 14 Jul 1999 11:22:46 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: [HACKERS] 9-key index ?
Date: Wed, 14 Jul 1999 11:25:09 +0900
Message-ID: <000401becda0$17deee60$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
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
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk

Hi all,

I could create a 9-key index.

create table ix9 (
i1 int4,
i2 int4,
i3 int4,
i4 int4,
i5 int4,
i6 int4,
i7 int4,
i8 int4,
i9 int4,
primary key (i1,i2,i3,i4,i5,i6,i7,i8,i9)
);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'ix9_pkey'
for table 'ix9'
CREATE

\d ix9_pkey

Table    = ix9_pkey
+----------------------------------+----------------------------------+-----
--+
|              Field               |              Type                |
Length|
+----------------------------------+----------------------------------+-----
--+
| i1                               | int4                             |
4 |
| i2                               | int4                             |
4 |
| i3                               | int4                             |
4 |
| i4                               | int4                             |
4 |
| i5                               | int4                             |
4 |
| i6                               | int4                             |
4 |
| i7                               | int4                             |
4 |
| i8                               | int4                             |
4 |
| i9                               | int4                             |
4 |
+----------------------------------+----------------------------------+-----
--+

Is it right ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

--ELM938108151-18329-0_--

From bouncefilter Thu Sep 23 15:09:58 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 PAA13806
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 15:09:52 -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 PAA23863;
Thu, 23 Sep 1999 15:07:18 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909231907.PAA23863@candle.pha.pa.us>
Subject: Re: [HACKERS] VIEW definitions broken in 6.5.0
In-Reply-To: <19990719170634.A30250@wallace.ece.rice.edu> from "Ross J.
Reedstrom" at "Jul 19, 1999 05:06:34 pm"
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Date: Thu, 23 Sep 1999 15:07:18 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org, Jan Wieck <jwieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Jan, or someone, can you comment on this?

Hey hackers -
I don't know if this is fixed in 6.5.1 or not, but the definition field
in the pg_views system table is broken in 6.5.0, and this breaks view
editing in pgaccess. The problem is that table qualifications are left
off the fieldnames in both the SELECT clause and the WHERE clause. Minimal
example given below:

test=> create table t1 (textid int4, nextid int4, words text);
CREATE
test=> create table t2 (nextid int4, words text);
CREATE
test=> create view v1 as select t1.textid,t1.words,t2.words as words2
from t1,t2 where t1.nextid=t2.nextid;
CREATE
test=> insert into t1 values (2,1,'some other text');
INSERT 384454 1
test=> insert into t2 values (1,'joint text');
INSERT 384455 1
test=> insert into t1 values (1,1,'some text');
INSERT 384456 1
test=> select * from v1;
textid|words |words2
------+---------------+----------
2|some other text|joint text
1|some text |joint text
(2 rows)

test=> select definition from pg_views where viewname='v1';
definition
-----------------------------------------------------------------------
SELECT "textid", "words", "words" AS "words2" FROM "t1", "t2" WHERE
"nextid" = "nextid"; (1 row)

test=> SELECT "textid", "words", "words" AS "words2" FROM "t1", "t2"
WHERE "nextid" = "nextid";
ERROR: Column 'words' is ambiguous
test=>

--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

-- 
  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 Thu Sep 23 15:12:06 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA14168
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 15:11:08 -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 PAA24037;
Thu, 23 Sep 1999 15:10:19 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909231910.PAA24037@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_dump quoting bug
In-Reply-To: <19990719172015.B30250@wallace.ece.rice.edu> from "Ross J.
Reedstrom" at "Jul 19, 1999 05:20:15 pm"
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Date: Thu, 23 Sep 1999 15:10:19 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thanks. Fix applied. This will appear in 6.6 and the next 6.5.x release.

One last missing quoting bug in pg_dump:
now that sequence names are properly quoted for field defaults, mixed
case sequence names are generated. These are properly quoted in the
CREATE SEQUENCE lines, but not in the SELECT nextval lines, as per below:

CREATE SEQUENCE "Teams_TeamID_seq" start 10 increment 1 maxvalue
2147483647 minvalue 1 cache 1 ;
SELECT nextval ('Teams_TeamID_seq');

This needs to be:
SELECT nextval ('"Teams_TeamID_seq"');

Patch included below.
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

[Attachment, skipping...]

-- 
  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 Thu Sep 23 16:58:58 1999
Received: from kodu.home.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA33917
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 16:58:26 -0400 (EDT) (envelope-from hannu@tm.ee)
Received: from tm.ee (hannu@localhost [127.0.0.1])
by kodu.home.ee (8.8.7/8.8.7) with ESMTP id AAA00502;
Fri, 24 Sep 1999 00:04:59 +0300
Sender: hannu@kodu.home.ee
Message-ID: <37EA95FB.F6DF530A@tm.ee>
Date: Fri, 24 Sep 1999 00:04:59 +0300
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.2.6 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Adriaan Joubert <a.joubert@albourne.com>
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
References: <Pine.BSF.4.10.9909220246160.38923-100000@thelab.hub.org>
<37E87542.2F8ADA4A@albourne.com>
<37E8F672.9B98E9BF@alumni.caltech.edu>
<37E9E490.1CD9623B@albourne.com>
<37EA31BC.A18A31EE@alumni.caltech.edu>
<37EA3723.B513E03@albourne.com>
<37EA459C.29E2B38D@alumni.caltech.edu>
<37EA5361.59EC106D@albourne.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Adriaan Joubert wrote:

b) seems to imply, rather bizarrely in my opinion, that

B'001100' < B'10'

Maybe you start counting from the wrong end ?

Just use them as you use char()

'AABBAA' < 'BA'

Does it say something in the standard about direction,
is it left-> right or right->left ?

------------
Hannu

Tom Lane

tgl@sss.pgh.pa.us

over 26 years ago

In reply to: Bruce Momjian (#7)

Re: [SQL] Re: [HACKERS] SELECT DISTINCT question

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

Tom, any status on this DISTINCT ON ripout?

I haven't done anything about it, if that's what you mean.

I didn't get any indication of whether anyone else agreed with me
(maybe the lack of loud complaints should be taken as consent?)

regards, tom lane

Import Notes

Reply to msg id not found: YourmessageofThu23Sep1999131818-0400199909231718.NAA19629@candle.pha.pa.us | Resolved by subject fallback

Bruce Momjian

bruce@momjian.us

over 26 years ago

In reply to: Tom Lane (#8)

Re: [SQL] Re: [HACKERS] SELECT DISTINCT question

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

Tom, any status on this DISTINCT ON ripout?

I haven't done anything about it, if that's what you mean.

I didn't get any indication of whether anyone else agreed with me
(maybe the lack of loud complaints should be taken as consent?)

I think so.

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

#10

Bruce Momjian

bruce@momjian.us

over 26 years ago

In reply to: Tom Lane (#8)

Re: [SQL] Re: [HACKERS] SELECT DISTINCT question

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

Tom, any status on this DISTINCT ON ripout?

I haven't done anything about it, if that's what you mean.

I didn't get any indication of whether anyone else agreed with me
(maybe the lack of loud complaints should be taken as consent?)

I will wrap up the mail messages, and put it on the TODO list.

-- 
  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 Thu Sep 23 18:02:01 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA42661;
Thu, 23 Sep 1999 18:01:52 -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 SAA26551;
Thu, 23 Sep 1999 18:01:09 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909232201.SAA26551@candle.pha.pa.us>
Subject: Re: [PORTS] RedHat6.0 & Alpha
In-Reply-To: <3793C0F6.3ECB814E@voicenet.com> from Uncle George at "Jul 19,
1999 08:21:10 pm"
To: Uncle George <gatgul@voicenet.com>
Date: Thu, 23 Sep 1999 18:01:09 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org, pgsql-ports@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Can anyone address the status of this bug?

In the regression test rules.sql there is this SQL command

update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;

Which causes my alpha port to go core. The above line can be reduced to:

update rtest_v1 set a = rtest_t3.a + 20 ;

which also causes the same problem. It seems that the 64 bit address
((Expr*)nodeptr)->oper gets truncated ( high 32 bits ) somewhere along the way.

I was able to locate the errant code in rewriteManip.c:712. but There seems to be a
bigger problem other than eraseing the upper 32bit address. It seems that
FindMatchingNew() returns a node of type T_Expr, rather than the expected type of
T_Var. Once u realize this then u can see why the now MISCAST "(Var *)
*nodePtr)->varlevelsup = this_varlevelsup" will cause a problem. On my alpha this erases
a portion in the address in the T_Expr. On the redhat 5.2/i386 this code seems to be
benign, BUT YOU ARE ERASEING SOMETHING that doesn't belong to to T_Expr !

So what gives?
gat
Maybe an assert() will help in finding some of the miscast returned types? Wuddya think?
sure would catch some of the boo-boo's hanging around

rewriteManip.c:
if (this_varno == info->new_varno &&
this_varlevelsup == sublevels_up)
{
n = FindMatchingNew(targetlist,
((Var *) node)->varattno);
if (n == NULL)
{
if (info->event == CMD_UPDATE)
{
*nodePtr = n = copyObject(node);
((Var *) n)->varno = info->current_varno;
((Var *) n)->varnoold = info->current_varno;
}
else
*nodePtr = make_null(((Var *) node)->vartype);
}
else
{
*nodePtr = copyObject(n);
((Var *) *nodePtr)->varlevelsup = this_varlevelsup; /* This
line zaps the address */
}
}

-- 
  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 Thu Sep 23 18:03:05 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA42765;
Thu, 23 Sep 1999 18:02:06 -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 SAA26559;
Thu, 23 Sep 1999 18:01:33 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909232201.SAA26559@candle.pha.pa.us>
Subject: Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha
In-Reply-To: <28663.932436912@sss.pgh.pa.us> from Tom Lane at "Jul 19,
1999 10:15:12 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 23 Sep 1999 18:01:33 -0400 (EDT)
CC: Uncle George <gatgul@voicenet.com>, Jan Wieck <wieck@debis.com>,
pgsql-hackers@postgreSQL.org, pgsql-ports@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

This seems to be the detail on the bug report.

Uncle George <gatgul@voicenet.com> writes:

In the regression test rules.sql there is this SQL command
update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
Which causes my alpha port to go core.

Yeah. This was reported by Pedro Lobo on 11 June, and we've been
patiently waiting for Jan to decide what to do about it :-(

You could stop the coredump by putting a test into ResolveNew:

{
*nodePtr = copyObject(n);
+ if (IsA(*nodePtr, Var))
((Var *) *nodePtr)->varlevelsup = this_varlevelsup;
}
but what's not so clear is what's supposed to happen when the
replacement item *isn't* a Var. I tried to convince myself that nothing
needed to happen in that case, but wasn't successful. (Presumably the
replacement expression contains no instances of the variable being
replaced, so recursing into it with ResolveNew shouldn't be needed
--- but maybe its varlevelsup values need adjusted?)
regards, tom lane

-- 
  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 Thu Sep 23 18:39:59 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA51405;
Thu, 23 Sep 1999 18:39:27 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id SAA17532;
Thu, 23 Sep 1999 18:39:17 -0400
Message-ID: <37EAAC0A.D979D50D@wgcr.org>
Date: Thu, 23 Sep 1999 18:39:06 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Uncle George <gatgul@voicenet.com>, pgsql-hackers@postgresql.org,
pgsql-ports@postgresql.org
Subject: Re: [PORTS] RedHat6.0 & Alpha
References: <199909232201.SAA26551@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Can anyone address the status of this bug?

[actual bug text snipped...]

Wow, Bruce. That's an old thread. I'll just say this -- 6.5.1 with
Uncle George and Ryan Kirkpatrick's patchset applied passes regression
at RedHat on their alpha development machine (for the RPM distribution).

Whether the current pre-6.6 tree passes regression or not, I can't say.

The author of the original message you replied to is gat -- AKA Uncle
George.

Lamar OWen
WGCR Internet Radio

From bouncefilter Thu Sep 23 19:30:06 1999
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA59498
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 19:29:49 -0400 (EDT)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id JAA23137;
Fri, 24 Sep 1999 09:30:02 +1000
Message-Id: <3.0.5.32.19990924092951.00b3a5d0@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 24 Sep 1999 09:29:51 +1000
To: wieck@debis.com (Jan Wieck)
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: [HACKERS] RI and NULL's
Cc: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
In-Reply-To: <m11UASn-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 17:07 23/09/99 +0200, you wrote:

Assuming NULL's are allowed in FK values (are they?)

I don't think they should be since two null fields are not equal, and the
reason for FK constraints to to require the foregn record exists. Also, I'm
pretty sure PK values should not be null.

like to know what the correct handling of NULL values is. If
an attribute of the FK has the NULL value, must a PK with a
NULL in the corresponding attribute exist or is this
attribute completely left out of the WHERE clause in the
check?

I don't think so. I believe PK values can't be null, so no FK field should
be null.

Other way round - NULL value in attribute of referenced
table. What to delete from FK in the case of ON DELETE
CASCADE?

This problem goes away.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

#11

Sean Mullen

sean@fastinternet.net.au

over 26 years ago

In reply to: Bruce Momjian (#10)

No title

unsubscribe

From bouncefilter Thu Sep 23 20:33:03 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 UAA70569;
Thu, 23 Sep 1999 20:32:52 -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 UAA27117;
Thu, 23 Sep 1999 20:31:47 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Uncle George <gatgul@voicenet.com>, pgsql-hackers@postgreSQL.org,
pgsql-ports@postgreSQL.org
Subject: Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha
In-reply-to: Your message of Thu, 23 Sep 1999 18:01:09 -0400 (EDT)
<199909232201.SAA26551@candle.pha.pa.us>
Date: Thu, 23 Sep 1999 20:31:47 -0400
Message-ID: <27115.938133107@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Can anyone address the status of this bug?

AFAIK it hasn't changed since July --- we've been waiting for Jan
to opine on the proper fix, but he's been busy...

regards, tom lane

From bouncefilter Thu Sep 23 20:38:03 1999
Received: from argh.demon.co.uk (IDENT:grim@argh.demon.co.uk [193.237.6.55])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA71384
for <pgsql-hackers@postgresql.org>;
Thu, 23 Sep 1999 20:37:39 -0400 (EDT)
(envelope-from grim@argh.demon.co.uk)
Received: (from grim@localhost) by argh.demon.co.uk (8.9.3/8.9.3) id BAA02135
for pgsql-hackers@postgresql.org; Fri, 24 Sep 1999 01:41:59 +0100
From: Michael Simms <grim@argh.demon.co.uk>
Message-Id: <199909240041.BAA02135@argh.demon.co.uk>
Subject: Frustration
To: pgsql-hackers@postgresql.org
Date: Fri, 24 Sep 1999 01:41:59 +0100 (BST)
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I will admit I am getting reeeeeallllly frustrated right now. Currently
postgresql is crashing approximately once every 5 minutes on me

template1=> select version();
version
-------------------------------------------------------------------
PostgreSQL 6.5.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66
(1 row)

I am not doing anything except vary basic commands, things like inserts
and updates and nothing involving too many expressions.

Now, I know nobody can debug anything from what I have just said, but I
cannot get a better set of bug reports. I CANT get postgres to send out debug

For example. I start it using:

/usr/bin/postmaster -o "-F -S 10240" -d 3 -S -N 512 -B 3000 -D/var/lib/pgsql/data -o -F > /tmp/postmasterout 2> /tmp/postmastererr

Spot in there I have -d 3 and redirect (this under /bin/sh) to /tmp

Now, after repeated backend crashes, I have:

[postgres@home bin]$ cat /tmp/postmastererr
FindExec: found "/usr/bin/postgres" using argv[0]
binding ShmemCreate(key=52e2c1, size=31684608)
[postgres@home bin]$ cat /tmp/postmasterout
[postgres@home bin]$

Or exactly NOTHING

This is out of the box 6.5.2, no changes made, no changes made in the config
except to make it install into the right place.

I just need to get some debug, so I can actually report something. Am I
doing something very dumb, or SHOULD there be debug here and there isnt?

I am about ready to pull my hair out over this. I NEED to have a stable
database, and crashing EVERY five minutes is not helping me at all {:-(

Also, I seem to remember that someone posted here that when one backend
crashed, it shouldnt close the other backends any more. Well, mine does.

NOTICE: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory.
I have rolled back the current transaction and am going to terminate your database system connection and exit.
Please reconnect to the database system and repeat your query.

I am getting this about every five minutes. I wish I knew what was doing it.
Even if the backend recovered and just perforned the query again, that
would be enough, the overhead of checking to see if the database has crashed
EVERY TIME I start or finish performing a query is a huge overhead.

I can appreciate that the backend that crashed cannot do this, but the others
surely can! Rollback and start again, instead of rollback and panic

Appologies if I sound a bit stressed right now, I was under the impression
I had tested my system, and so I opened it to the public, and now it
is blowing up in my face BADLY.

If someone can tell me WHAT I am doing wrong with getting the debug info,
please please do! I am just watching it blow up again as we speak, and I
must get SOMETHING fixed asap

~Michael

From bouncefilter Thu Sep 23 20:58:03 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 UAA75036
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 20:57:47 -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 UAA27211;
Thu, 23 Sep 1999 20:57:05 -0400 (EDT)
To: Michael Simms <grim@argh.demon.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Frustration
In-reply-to: Your message of Fri, 24 Sep 1999 01:41:59 +0100 (BST)
<199909240041.BAA02135@argh.demon.co.uk>
Date: Thu, 23 Sep 1999 20:57:05 -0400
Message-ID: <27209.938134625@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Michael Simms <grim@argh.demon.co.uk> writes:

Now, I know nobody can debug anything from what I have just said, but
I cannot get a better set of bug reports. I CANT get postgres to send
out debug

/usr/bin/postmaster -o "-F -S 10240" -d 3 -S -N 512 -B 3000 -D/var/lib/pgsql/data -o -F > /tmp/postmasterout 2> /tmp/postmastererr

Don't use the -S switch (the second one, not the one inside -o).

Looking in postmaster.c, I see that causes it to redirect stdout/stderr
to /dev/null (probably not too hot an idea, but that's doubtless been
like that for a *long* time). Instead launch with something like

nohup postmaster switches... </dev/null >logfile 2>errfile &

Good luck figuring out where the real problem is...

regards, tom lane

From bouncefilter Thu Sep 23 21:52:04 1999
Received: from argh.demon.co.uk (IDENT:grim@argh.demon.co.uk [193.237.6.55])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA95786
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 21:51:17 -0400 (EDT)
(envelope-from grim@argh.demon.co.uk)
Received: (from grim@localhost) by argh.demon.co.uk (8.9.3/8.9.3) id CAA02239;
Fri, 24 Sep 1999 02:54:40 +0100
From: Michael Simms <grim@argh.demon.co.uk>
Message-Id: <199909240154.CAA02239@argh.demon.co.uk>
Subject: Re: [HACKERS] Frustration
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Fri, 24 Sep 1999 02:54:39 +0100 (BST)
Cc: grim@argh.demon.co.uk (Michael Simms), pgsql-hackers@postgreSQL.org
In-Reply-To: <27209.938134625@sss.pgh.pa.us> from "Tom Lane" at Sep 23,
1999 08:57:05 PM
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Good luck figuring out where the real problem is...

regards, tom lane

Well, thanks to tom, I know what was wrong, and I have found the problem,
or one of them at least...

FATAL: s_lock(0c9ef824) at bufmgr.c:1106, stuck spinlock. Aborting.

Okee, that segment of code is, well, its some deep down internals that
are as clear as mud to me.

Anyone in the know have an idea what this does?

Just to save you looking, it is included below.

One question, is that does postgresql Inc have a 'normal person' support
level? I ask that cos I was planning on getting some of the commercial
support, and whilst it is a reasonable price to pay for corporations or
people with truckloads of money, I am a humble developer with more
expenses than income, and $600 is just way out of my league {:-(

If not, fair enough, just thought Id ask cos the support I have had from
this list is excellent and I wanted to provide some payback to the
developoment group.

~Michael

/*
* WaitIO -- Block until the IO_IN_PROGRESS flag on 'buf'
* is cleared. Because IO_IN_PROGRESS conflicts are
* expected to be rare, there is only one BufferIO
* lock in the entire system. All processes block
* on this semaphore when they try to use a buffer
* that someone else is faulting in. Whenever a
* process finishes an IO and someone is waiting for
* the buffer, BufferIO is signaled (SignalIO). All
* waiting processes then wake up and check to see
* if their buffer is now ready. This implementation
* is simple, but efficient enough if WaitIO is
* rarely called by multiple processes simultaneously.
*
* ProcSleep atomically releases the spinlock and goes to
* sleep.
*
* Note: there is an easy fix if the queue becomes long.
* save the id of the buffer we are waiting for in
* the queue structure. That way signal can figure
* out which proc to wake up.
*/
#ifdef HAS_TEST_AND_SET
static void
WaitIO(BufferDesc *buf, SPINLOCK spinlock)
{
SpinRelease(spinlock);
S_LOCK(&(buf->io_in_progress_lock));
S_UNLOCK(&(buf->io_in_progress_lock));
SpinAcquire(spinlock);
}

From bouncefilter Fri Sep 24 01:24:06 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA41623
for <pgsql-hackers@postgreSQL.org>;
Fri, 24 Sep 1999 01:23:21 -0400 (EDT)
(envelope-from a.joubert@albourne.com)
Received: from isadora.cy.albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.6X) with ESMTP
id IAA17621; Fri, 24 Sep 1999 08:25:54 +0300 (EET DST)
Received: from albourne.com (localhost [127.0.0.1])
by isadora.cy.albourne.com (8.9.3/8.9.3/Albourne/CYC/1.4) with ESMTP id
IAA32031; Fri, 24 Sep 1999 08:23:19 +0300 (EET DST)
Sender: a.joubert@albourne.com
Message-ID: <37EB0AC6.C608E1A2@albourne.com>
Date: Fri, 24 Sep 1999 08:23:18 +0300
From: Adriaan Joubert <a.joubert@albourne.com>
Organization: APL Financial Services (Overseas) Ltd
X-Mailer: Mozilla 4.61 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: Hannu Krosing <hannu@tm.ee>
CC: Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
References: <Pine.BSF.4.10.9909220246160.38923-100000@thelab.hub.org>
<37E87542.2F8ADA4A@albourne.com>
<37E8F672.9B98E9BF@alumni.caltech.edu>
<37E9E490.1CD9623B@albourne.com>
<37EA31BC.A18A31EE@alumni.caltech.edu>
<37EA3723.B513E03@albourne.com>
<37EA459C.29E2B38D@alumni.caltech.edu>
<37EA5361.59EC106D@albourne.com> <37EA95FB.F6DF530A@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hannu Krosing wrote:

Adriaan Joubert wrote:

b) seems to imply, rather bizarrely in my opinion, that

B'001100' < B'10'

Maybe you start counting from the wrong end ?

Just use them as you use char()

'AABBAA' < 'BA'

Does it say something in the standard about direction,
is it left-> right or right->left ?

No, not that I could find. But in the above example B'001100' < B'10'
whichever end you start counting from, as 1>0. I have no particularly
strong opinion on which way round it should be done -- perhaps we should
just try to be consistent with other databases? Could somebody who has
access to Oracle or Sybase please do a few tests and let me know?

A second problem I encountered last night is that the postgres variable
length types only allow for the length of an array to be stored in
bytes. This means that the number of bits will automatically always be
rounded up to the nearest factor of 8, i.e. you want tp store 3 bits and
you get 8. For ordering and output this is not always going to produce
the correct output, as the bitstrings will get zero-padded. Is there
anywhere else where one could store the exact length of a bit string?

I haven't quite understood what the variable attypmod is. In varchar.c
it looks as if it is the length of the record, but if it is just an
integer identifier, then I could store the exact length in there. In
that case I could handle the difference between 3 and 5 bit strings
correctly. My main worry was that this might be used in other routines
to determine the length of a record.

Adriaan

From bouncefilter Fri Sep 24 02:13:06 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA48288
for <pgsql-hackers@postgreSQL.org>;
Fri, 24 Sep 1999 02:12:19 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id PAA29453
for <pgsql-hackers@postgreSQL.org>;
Fri, 24 Sep 1999 15:12:18 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id PAA29531 for
<pgsql-hackers@postgreSQL.org>; Fri, 24 Sep 1999 15:12:17 +0900 (JST)
Message-Id: <199909240612.PAA29531@srapc451.sra.co.jp>
From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: pgsql-hackers@postgreSQL.org
Subject: int8 and index
Date: Fri, 24 Sep 1999 15:12:17 +0900
Sender: t-ishii@srapc451.sra.co.jp

Do we have problems with int8 indexes? Seems select on an int8 does
not use an index.

This is PostgreSQL 6.5.2 on RedHat 6.0.
--
Tatsuo Ishii

From bouncefilter Fri Sep 24 02:29:06 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 CAA50306
for <pgsql-hackers@postgreSQL.org>;
Fri, 24 Sep 1999 02:28:32 -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 PAA13646; Fri, 24 Sep 1999 15:28:28 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tatsuo Ishii" <t-ishii@sra.co.jp>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] int8 and index
Date: Fri, 24 Sep 1999 15:32:02 +0900
Message-ID: <000d01bf0656$82ebaa60$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <199909240612.PAA29531@srapc451.sra.co.jp>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tatsuo Ishii
Sent: Friday, September 24, 1999 3:12 PM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] int8 and index

Do we have problems with int8 indexes? Seems select on an int8 does
not use an index.

How about select .. from .. where .. = ..::int8; ?

Without ::int8 PostgreSQL doesn't use int8 indexes.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Fri Sep 24 02:37:07 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA51324
for <pgsql-hackers@postgreSQL.org>;
Fri, 24 Sep 1999 02:36:39 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id PAA00893;
Fri, 24 Sep 1999 15:36:37 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id PAA29772;
Fri, 24 Sep 1999 15:36:37 +0900 (JST)
Message-Id: <199909240636.PAA29772@srapc451.sra.co.jp>
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Tatsuo Ishii" <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] int8 and index
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Fri, 24 Sep 1999 15:32:02 JST.
<000d01bf0656$82ebaa60$2801007e@cadzone.tpf.co.jp>
Date: Fri, 24 Sep 1999 15:36:37 +0900
Sender: t-ishii@srapc451.sra.co.jp

Do we have problems with int8 indexes? Seems select on an int8 does
not use an index.

How about select .. from .. where .. = ..::int8; ?

Without ::int8 PostgreSQL doesn't use int8 indexes.

Oops. I forgot about that! Thanks.
--
Tatsuo Ishii

From bouncefilter Fri Sep 24 09:13:04 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA02722;
Fri, 24 Sep 1999 09:11:35 -0400 (EDT)
(envelope-from dpeder@infoset.cz)
Received: from ns.infoset.cz (ns.infoset.cz [194.213.32.210])
by trends.net (8.8.8/8.8.8) with ESMTP id FAA15750;
Fri, 24 Sep 1999 05:52:55 -0400 (EDT)
Received: from WinProxy.anywhere ([62.168.15.178])
by ns.infoset.cz (8.8.7/8.8.7) with SMTP id LAA27707;
Fri, 24 Sep 1999 11:45:02 +0200
Received: from 192.168.1.1 by 192.168.1.3 (WinProxy);
Fri, 24 Sep 1999 11:47:49 +0100
Received: by Dan with Microsoft Mail
id <01BF0682.4F744BC0@Dan>; Fri, 24 Sep 1999 11:45:33 +0200
Message-ID: <01BF0682.4F744BC0@Dan>
From: =?iso-8859-2?Q?Daniel_P=E9der?= <dpeder@infoset.cz>
To: "'pgsql-general@postgresql.org'" <pgsql-general@postgresql.org>
Cc: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: postgres startup script modification (Linux RedHat)
Date: Fri, 24 Sep 1999 11:45:32 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id JAH02786

This modification eleminates the case described below:
If PostgreSQL (probaly with Linux) was shut down wrong way (power off, any other damage, kill, etc... ) it left opened the file(socket) /tmp/.s.PGSQL.5432 . It is found by Postmaster's next start with message:
===
Starting postgresql service: FATAL: StreamServerPort: bind() failed: errno=98
Is another postmaster already running on that port?
If not, remove socket node (/tmp/.s.PGSQL.<portnr>)and retry.
/usr/bin/postmaster: cannot create UNIX stream port
===
so, You are in situation that Linux was completely started, all services are running ok except the postgres - and if You miss it, Your server can be running hours without poperly serving the database.

= = = = =

If You find it usefull, make following modification to the file:

/etc/rc.d/init.d/postgresql

on Your RedHat Linux (other Linux or Unix versions will probably need some changes in locations, filenames etc...)
Begin of the changed lines is marked
# [B] added by daniel.peder@infoset.cz
End is marked
# [E] added by daniel.peder@infoset.cz

other text stuff was left for Your better orientation where put the changes...

so here we are:
======================================================
#!/bin/sh
...
...
[ -f /usr/bin/postmaster ] || exit 0

# See how we were called.
case "$1" in
start)
# [B] added by daniel.peder@infoset.cz
echo -n "Checking status of last postgresql service shutdown: "
psql_socket="/tmp/.s.PGSQL.5432"
if [ -e $psql_socket -a "`pidof postmaster`" = "" ]; then
rm -f $psql_socket
echo "incorrect"
else
echo "correct"
fi
# [E] added by daniel.peder@infoset.cz

echo -n "Starting postgresql service: "
su postgres -c '/usr/bin/postmaster -S -D/var/lib/pgsql'
sleep 1
pid=`pidof postmaster`
echo -n "postmaster [$pid]"
touch /var/lock/subsys/postmaster
echo
;;
stop)
echo -n "Stopping postgresql service: "
killproc postmaster
sleep 2
rm -f /var/lock/subsys/postmaster
echo
;;...
...
======================================================

dpeder@infoset.cz
Daniel Peder
http://shop.culture.cz
From bouncefilter Fri Sep 24 09:11:15 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA02617
for <pgsql-hackers@postgresql.org>;
Fri, 24 Sep 1999 09:11:10 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by trends.net (8.8.8/8.8.8) with ESMTP id FAA15539
for <pgsql-hackers@postgresql.org>;
Fri, 24 Sep 1999 05:45:05 -0400 (EDT)
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 SAA13729; Fri, 24 Sep 1999 18:42:04 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] couldn't rollback cache ?
Date: Fri, 24 Sep 1999 18:45:38 +0900
Message-ID: <000f01bf0671$8ece0240$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

-----Original Message-----
From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
Sent: Wednesday, September 22, 1999 7:12 PM
To: Tom Lane
Cc: pgsql-hackers
Subject: RE: [HACKERS] couldn't rollback cache ?

I thought about the way which neither calls HeapTupleSatis-
fies() in SearchSysCache() nor invalidates syscache entry
by OID.

In this case,we would need the information as follows.

1. To_be_rollbacked info for the backend
A list of being inserted system tuples.
This list is held till end of transaction.
In case of commit,this list is ignored and discarded.
In case of rollback,tuples inserted after the specified
savepoint are rollbacked and discarded. Syscache
and relcache entries for the backend which correspond
to the tuples are invalidated.

2, To_be_invalidated info for the backend
A list of being deleted system tuples.
This list is discarded at every command.
In case of rollback this list is ignored.
Otherwise,syscache and relcache entries for the backend
which correspond to the tuples in this list are invalidated
before execution of each command.

3. To_be_invalidated info for other backends
A list of being deleted system tuples.
This list is held till end of transaction.
In case of commit,this list is sent to other backends and
discarded.
In case of rollback,tuples deleted after the specified savepoint
are discarded.

4. Immediate registrarion of to_be_invalidated relcache for all backends
Currently SI messages aren't sent in case of elog(ERROR/FATAL).
Seems the following commands have to register relcache invali-
dation for all backends just when we call smgrunlink()/smgrtruncate().

DROP TABLE/INDEX
TRUNCATE TABLE(implemented by Mike Mascari)
VACUUM

Comments ?

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Fri Sep 24 09:10:38 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA02148
for <pgsql-hackers@postgresql.org>;
Fri, 24 Sep 1999 09:09:02 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by trends.net (8.8.8/8.8.8) with ESMTP id HAA17704
for <pgsql-hackers@postgresql.org>;
Fri, 24 Sep 1999 07:04:03 -0400 (EDT)
Received: from uria.its.uu.se ([130.238.7.14]:2413 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rupby108795>;
Fri, 24 Sep 1999 13:01:18 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11USjF-0000E0-00; Fri, 24 Sep 1999 12:37:25 +0200
Date: Fri, 24 Sep 1999 12:37:24 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] create rule changes table to view ?
In-Reply-To: <199909231727.NAA19787@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.9909240005280.18581-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

I have noticed and lived with this problem for quite a while.

There's nothing in pg_class that tells a table from a view, they're both
"relations". Since a view is implemented as in effect an empty table with
on select rules on it, psql thinks every table with a rule on it is a
view. This is just the output, nothing on the table changes.

A fix would be to display both tables and views as "relation". As far as I
know there is now 100% deterministic way to tell a table from a view. I
think one fine day Jan is going to change that but for now we don't have
to worry about it.

Peter

On Sep 23, Bruce Momjian mentioned:

Can someone comment on this?

I just began to learn rules with 6.5 and notice:
test=> \dt
Database    = test
+------------------+----------------------------------+----------+
|  Owner           |             Relation             |   Type   |
+------------------+----------------------------------+----------+
| megera           | access_log                       | table    |
| megera           | hits                             | table    |
| megera           | junk_qwerty                      | table    |
+------------------+----------------------------------+----------+

test=>  create rule log_hits as on update to hits  do instead insert into hits values ( NEW.msg_id, 1);
CREATE
test=> \dt
Database    = test
+------------------+----------------------------------+----------+
|  Owner           |             Relation             |   Type   |
+------------------+----------------------------------+----------+
| megera           | access_log                       | table    |
| megera           | hits                             | view?    |
| megera           | junk_qwerty                      | table    |
+------------------+----------------------------------+----------+

Table hits now becomes view ?

Regards,

Oleg

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

From bouncefilter Fri Sep 24 09:09:16 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA02129
for <pgsql-hackers@postgresql.org>;
Fri, 24 Sep 1999 09:08:52 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by trends.net (8.8.8/8.8.8) with ESMTP id HAA17693
for <pgsql-hackers@postgresql.org>;
Fri, 24 Sep 1999 07:03:55 -0400 (EDT)
Received: from uria.its.uu.se ([130.238.7.14]:2414 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rupc/98554>;
Fri, 24 Sep 1999 13:01:21 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2) id 11USk7-0000E2-00
for pgsql-hackers@postgresql.org; Fri, 24 Sep 1999 12:38:19 +0200
Date: Fri, 24 Sep 1999 12:38:19 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgresql.org
Subject: psql issues
Message-ID: <Pine.LNX.4.10.9909241139570.477-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

1) Is it just me or is psql the only application that uses libpq's
PQprint()? I think both parties involved could benefit if the PQprint was
moved to or integrated into psql. Or perhaps a libpqprint as a compromise?

2) Regarding TODO item "Allow psql \copy to allow delimiters": What
precisely is the difference between:
=> \t
=> \o file
=> select * from my_table;
and
=> \copy my_table to file
or, for that matter,
=> copy my_table to 'file';
besides perhaps their internal execution path? The third variant already
allows the use of delimiters (USING DELIMITERS '*'), and so does the first
one (\f). (Speaking of which, does anyone know how to enter in effect \f
<TAB>?)

Correct me if I'm wrong, but I believe the use of PG{get|put}line() for
the \copy would have to be scratched if one would want to use delimiters.

3) Is anyone doing anything major on psql right now or would anyone mind
if I undertake a major code clean up on it? Or is everyone completely
comfortable with 350-line functions with 7 levels of indentation?

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

From bouncefilter Fri Sep 24 09:09:18 1999
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA01911
for <pgsql-hackers@postgresql.org>;
Fri, 24 Sep 1999 09:08:21 -0400 (EDT)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (mail@sfcabop1.nettuno.it
[193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 3.3) with ESMTP id PAA04903;
Fri, 24 Sep 1999 15:06:50 +0200 (MDT)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 11UWj2-0006jT-00; Fri, 24 Sep 1999 14:53:28 +0000
Message-ID: <37EB761F.D7A1105E@sferacarta.com>
Date: Fri, 24 Sep 1999 15:01:19 +0200
From: =?iso-8859-1?Q?Jos=E9?= Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.5 [it] (Win95; I)
X-Accept-Language: it
MIME-Version: 1.0
To: Adriaan Joubert <a.joubert@albourne.com>
CC: Hannu Krosing <hannu@tm.ee>, Postgresql <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
References: <Pine.BSF.4.10.9909220246160.38923-100000@thelab.hub.org>
<37E87542.2F8ADA4A@albourne.com>
<37E8F672.9B98E9BF@alumni.caltech.edu>
<37E9E490.1CD9623B@albourne.com>
<37EA31BC.A18A31EE@alumni.caltech.edu>
<37EA3723.B513E03@albourne.com>
<37EA459C.29E2B38D@alumni.caltech.edu>
<37EA5361.59EC106D@albourne.com> <37EA95FB.F6DF530A@tm.ee>
<37EB0AC6.C608E1A2@albourne.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Adriaan Joubert ha scritto:

Hannu Krosing wrote:

Adriaan Joubert wrote:

b) seems to imply, rather bizarrely in my opinion, that

B'001100' < B'10'

Maybe you start counting from the wrong end ?

Just use them as you use char()

'AABBAA' < 'BA'

Does it say something in the standard about direction,
is it left-> right or right->left ?

No, not that I could find. But in the above example B'001100' < B'10'
whichever end you start counting from, as 1>0. I have no particularly
strong opinion on which way round it should be done -- perhaps we should
just try to be consistent with other databases? Could somebody who has
access to Oracle or Sybase please do a few tests and let me know?

Oracle doesn't have this data type neither Informix. I think it is hard to
find this data type in any database.
I found this feature in the OCELOT database
You can download it from:
http://ourworld.compuserve.com/homepages/OCELOTSQL/
As they say:
"Ocelot makes the only Database Management System (DBMS) that supports the
full ANSI / ISO
SQL Standard (1992), and an always-growing checklist of SQL3 features (also
known as SQL-99)."

A second problem I encountered last night is that the postgres variable

length types only allow for the length of an array to be stored in
bytes. This means that the number of bits will automatically always be
rounded up to the nearest factor of 8, i.e. you want tp store 3 bits and
you get 8. For ordering and output this is not always going to produce
the correct output, as the bitstrings will get zero-padded. Is there
anywhere else where one could store the exact length of a bit string?

I haven't quite understood what the variable attypmod is. In varchar.c
it looks as if it is the length of the record, but if it is just an
integer identifier, then I could store the exact length in there. In
that case I could handle the difference between 3 and 5 bit strings
correctly. My main worry was that this might be used in other routines
to determine the length of a record.

Adriaan

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

From bouncefilter Fri Sep 24 10:21:08 1999
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA14749
for <pgsql-hackers@postgresql.org>;
Fri, 24 Sep 1999 10:20:32 -0400 (EDT)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (mail@sfcabop1.nettuno.it
[193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 3.3) with ESMTP id QAA20424;
Fri, 24 Sep 1999 16:15:48 +0200 (MDT)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 11UX0z-0006kw-00; Fri, 24 Sep 1999 15:12:01 +0000
Message-ID: <37EB7A78.A5AA913@sferacarta.com>
Date: Fri, 24 Sep 1999 15:19:52 +0200
From: =?iso-8859-1?Q?Jos=E9?= Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.5 [it] (Win95; I)
X-Accept-Language: it
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] create rule changes table to view ?
References: <199909231727.NAA19787@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian ha scritto:

Can someone comment on this?

This an old question.
psql suppose that table "test" is a view because it checks for pg_class.relhasrules and it prints "view?"
if the value is TRUE and the value is if there's a rule for the table.
The only way to distinguish a table from a view is the pg_get_viewdef.

Some time ago I suggested to use pg_get_viewdef('tablename') to check for views
to print "view or table" instead of "view?".
I made a patch to my psql and it now recognize views perfectly and I can display
only tables using \d and/or only views using \v

Comments.

I just began to learn rules with 6.5 and notice:
test=> \dt
Database    = test
+------------------+----------------------------------+----------+
|  Owner           |             Relation             |   Type   |
+------------------+----------------------------------+----------+
| megera           | access_log                       | table    |
| megera           | hits                             | table    |
| megera           | junk_qwerty                      | table    |
+------------------+----------------------------------+----------+

test=>  create rule log_hits as on update to hits  do instead insert into hits values ( NEW.msg_id, 1);
CREATE
test=> \dt
Database    = test
+------------------+----------------------------------+----------+
|  Owner           |             Relation             |   Type   |
+------------------+----------------------------------+----------+
| megera           | access_log                       | table    |
| megera           | hits                             | view?    |
| megera           | junk_qwerty                      | table    |
+------------------+----------------------------------+----------+

Table hits now becomes view ?

Regards,

Oleg

--
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 Fri Sep 24 10:24:07 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 KAA16034
for <pgsql-hackers@postgreSQL.org>;
Fri, 24 Sep 1999 10:23:25 -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 OAA27048;
Fri, 24 Sep 1999 14:21:21 GMT
Sender: lockhart@hub.org
Message-ID: <37EB88E0.24A45661@alumni.caltech.edu>
Date: Fri, 24 Sep 1999 14:21:20 +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: Adriaan Joubert <a.joubert@albourne.com>
CC: Hannu Krosing <hannu@tm.ee>, Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
References: <Pine.BSF.4.10.9909220246160.38923-100000@thelab.hub.org>
<37E87542.2F8ADA4A@albourne.com>
<37E8F672.9B98E9BF@alumni.caltech.edu>
<37E9E490.1CD9623B@albourne.com>
<37EA31BC.A18A31EE@alumni.caltech.edu>
<37EA3723.B513E03@albourne.com>
<37EA459C.29E2B38D@alumni.caltech.edu>
<37EA5361.59EC106D@albourne.com> <37EA95FB.F6DF530A@tm.ee>
<37EB0AC6.C608E1A2@albourne.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A second problem I encountered last night is that the postgres variable
length types only allow for the length of an array to be stored in
bytes. This means that the number of bits will automatically always be
rounded up to the nearest factor of 8, i.e. you want tp store 3 bits and
you get 8. For ordering and output this is not always going to produce
the correct output, as the bitstrings will get zero-padded. Is there
anywhere else where one could store the exact length of a bit string?

attypmod has been modified recently to contain two fields (each of 16
bits) in a backward-compatible way. It can hold the size *and*
precision of the numeric data types, and presumably should be used in
a similar manner for your bit type.

The problem is that you need another field which contains a length in
bit units. Assuming that the second field in attypmod can't be used
for this purpose, then istm that you will want to add a field to the
data type itself. The character types have:

length - total size of data, in bytes (4 bytes)
data - body

and you might have

length - total size of data, in bytes (4 bytes)
blen - total size of data, in bits (4 bytes)
data - body

- Thomas

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

From bouncefilter Fri Sep 24 10:30:13 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 KAA17142
for <pgsql-hackers@postgreSQL.org>;
Fri, 24 Sep 1999 10:30:05 -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 KAA05762;
Fri, 24 Sep 1999 10:26:54 -0400 (EDT)
To: Michael Simms <grim@argh.demon.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Frustration
In-reply-to: Your message of Fri, 24 Sep 1999 02:54:39 +0100 (BST)
<199909240154.CAA02239@argh.demon.co.uk>
Date: Fri, 24 Sep 1999 10:26:54 -0400
Message-ID: <5760.938183214@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Michael Simms <grim@argh.demon.co.uk> writes:

Well, thanks to tom, I know what was wrong, and I have found the problem,
or one of them at least...
FATAL: s_lock(0c9ef824) at bufmgr.c:1106, stuck spinlock. Aborting.
Okee, that segment of code is, well, its some deep down internals that
are as clear as mud to me.

Hmph. Apparently, some backend was waiting for some other backend to
finish reading a page in or writing it out, and gave up after deciding
it had waited an unreasonable amount of time (~ 1 minute, which does
seem plenty long enough). Probably, the I/O did in fact finish, but
the waiting backend didn't get the word for some reason.

Is it possible that there's something wrong with the spinlock code on
your hardware? There are a bunch of different spinlock implementations
(assembly code for various hardware) in include/storage/s_lock.h and
backend/storage/buffer/s_lock.c. Some of 'em might not be as well
tested as others. But you're on PC hardware, right? I would've thought
that flavor of the code would be pretty well wrung out.

Another likely explanation is that there's something wrong in
bufmgr.c's logic for setting and releasing the io_in_progress lock ---
but a quick look doesn't show any obvious error, and I would have
thought we'd have found out about any such problem long since.
Since we're not being buried in reports of stuck-spinlock errors,
I'm guessing there is some platform-specific problem on your machine.
No good ideas what it is if it isn't a spinlock failure.

(Finally, are you sure this is the *only* indication of trouble in
the logs? If a backend crashed while holding the spinlock, the other
ones would eventually die with complaints like this, but that wouldn't
make the spinlock code be at fault...)

regards, tom lane

From bouncefilter Fri Sep 24 10:57:08 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 KAA20892
for <hackers@postgresql.org>; Fri, 24 Sep 1999 10:56:33 -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 OAA27135;
Fri, 24 Sep 1999 14:54:58 GMT
Sender: lockhart@hub.org
Message-ID: <37EB90C2.6935454A@alumni.caltech.edu>
Date: Fri, 24 Sep 1999 14:54:58 +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: Dale Lovelace <dale@redhat.com>, Lamar Owen <lamar.owen@wgcr.org>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: PostgreSQL Upgrade Procedure
References: <199909240952.FAA05368@bilbo.meridian.redhat.com>
Content-Type: multipart/mixed; boundary="------------458A4AA633D538139A6FA0AB"

This is a multi-part message in MIME format.
--------------458A4AA633D538139A6FA0AB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

There is a parser bug someone introduced recently which we will fix
for v6.5.3, but I can give you a patch file for this on v6.5.2. I'll
develop it in the next couple of days.

Is it a showstopper?? Send the patch anyway, of course.

"showstopper" in the sense that it was not in v6.5.1? Apparently not.
But it causes a couple of math operators to not be recognized as
operators in some situations (like when defining a new operator :/

Here is a patch. *Not* tested under v6.5.1 or .2, but *all* of the
changes were tested under the current development tree. Since it
patches gram.y, it will cause gram.c to be rebuilt, which we usually
try to avoid but only because not everyone has bison/flex installed.
That isn't the case for your RH system.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
--------------458A4AA633D538139A6FA0AB
Content-Type: text/plain; charset=us-ascii;
name="gram.y.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="gram.y.patch"

*** gram.y.orig	Thu Sep 23 16:30:59 1999
--- gram.y	Fri Sep 24 14:42:53 1999
***************
*** 221,227 ****
  				having_clause
  %type <list>	row_descriptor, row_list, c_list, c_expr
  %type <node>	row_expr
- %type <str>		row_op
  %type <node>	case_expr, case_arg, when_clause, case_default
  %type <list>	when_clause_list
  %type <ival>	sub_type
--- 221,226 ----
***************
*** 970,981 ****
  				{	$$ = nconc( $1, lcons( makeString( "-"), $3)); }
  			| default_expr '/' default_expr
  				{	$$ = nconc( $1, lcons( makeString( "/"), $3)); }
- 			| default_expr '%' default_expr
- 				{	$$ = nconc( $1, lcons( makeString( "%"), $3)); }
  			| default_expr '*' default_expr
  				{	$$ = nconc( $1, lcons( makeString( "*"), $3)); }
  			| default_expr '^' default_expr
  				{	$$ = nconc( $1, lcons( makeString( "^"), $3)); }
  			| default_expr '=' default_expr
  				{	elog(ERROR,"boolean expressions not supported in DEFAULT"); }
  			| default_expr '<' default_expr
--- 969,982 ----
  				{	$$ = nconc( $1, lcons( makeString( "-"), $3)); }
  			| default_expr '/' default_expr
  				{	$$ = nconc( $1, lcons( makeString( "/"), $3)); }
  			| default_expr '*' default_expr
  				{	$$ = nconc( $1, lcons( makeString( "*"), $3)); }
+ 			| default_expr '%' default_expr
+ 				{	$$ = nconc( $1, lcons( makeString( "%"), $3)); }
  			| default_expr '^' default_expr
  				{	$$ = nconc( $1, lcons( makeString( "^"), $3)); }
+ 			| default_expr '|' default_expr
+ 				{	$$ = nconc( $1, lcons( makeString( "|"), $3)); }
  			| default_expr '=' default_expr
  				{	elog(ERROR,"boolean expressions not supported in DEFAULT"); }
  			| default_expr '<' default_expr
***************
*** 1120,1131 ****
  				{	$$ = nconc( $1, lcons( makeString( "-"), $3)); }
  			| constraint_expr '/' constraint_expr
  				{	$$ = nconc( $1, lcons( makeString( "/"), $3)); }
- 			| constraint_expr '%' constraint_expr
- 				{	$$ = nconc( $1, lcons( makeString( "%"), $3)); }
  			| constraint_expr '*' constraint_expr
  				{	$$ = nconc( $1, lcons( makeString( "*"), $3)); }
  			| constraint_expr '^' constraint_expr
  				{	$$ = nconc( $1, lcons( makeString( "^"), $3)); }
  			| constraint_expr '=' constraint_expr
  				{	$$ = nconc( $1, lcons( makeString( "="), $3)); }
  			| constraint_expr '<' constraint_expr
--- 1121,1134 ----
  				{	$$ = nconc( $1, lcons( makeString( "-"), $3)); }
  			| constraint_expr '/' constraint_expr
  				{	$$ = nconc( $1, lcons( makeString( "/"), $3)); }
  			| constraint_expr '*' constraint_expr
  				{	$$ = nconc( $1, lcons( makeString( "*"), $3)); }
+ 			| constraint_expr '%' constraint_expr
+ 				{	$$ = nconc( $1, lcons( makeString( "%"), $3)); }
  			| constraint_expr '^' constraint_expr
  				{	$$ = nconc( $1, lcons( makeString( "^"), $3)); }
+ 			| constraint_expr '|' constraint_expr
+ 				{	$$ = nconc( $1, lcons( makeString( "|"), $3)); }
  			| constraint_expr '=' constraint_expr
  				{	$$ = nconc( $1, lcons( makeString( "="), $3)); }
  			| constraint_expr '<' constraint_expr
***************
*** 2016,2028 ****

all_Op: Op | MathOp;

! MathOp: '+' { $$ = "+"; }
| '-' { $$ = "-"; }
| '*' { $$ = "*"; }
| '/' { $$ = "/"; }
- | '%' { $$ = "%"; }
| '<' { $$ = "<"; }
| '>' { $$ = ">"; }
| '=' { $$ = "="; }
;

--- 2019,2033 ----

all_Op: Op | MathOp;

! MathOp: '+' { $$ = "+"; }
| '-' { $$ = "-"; }
| '*' { $$ = "*"; }
| '/' { $$ = "/"; }
| '<' { $$ = "<"; }
| '>' { $$ = ">"; }
+ | '%' { $$ = "%"; }
+ | '^' { $$ = "^"; }
+ | '|' { $$ = "|"; }
| '=' { $$ = "="; }
;

***************
*** 3528,3534 ****
  /* Expressions using row descriptors
   * Define row_descriptor to allow yacc to break the reduce/reduce conflict
   *  with singleton expressions.
!  * Eliminated lots of code by defining row_op and sub_type clauses.
   * However, can not consolidate EXPR_LINK case with others subselects
   *  due to shift/reduce conflict with the non-subselect clause (the parser
   *  would have to look ahead more than one token to resolve the conflict).
--- 3533,3539 ----
  /* Expressions using row descriptors
   * Define row_descriptor to allow yacc to break the reduce/reduce conflict
   *  with singleton expressions.
!  * Eliminated lots of code by defining sub_type clauses.
   * However, can not consolidate EXPR_LINK case with others subselects
   *  due to shift/reduce conflict with the non-subselect clause (the parser
   *  would have to look ahead more than one token to resolve the conflict).
***************
*** 3554,3560 ****
  					n->subselect = $7;
  					$$ = (Node *)n;
  				}
! 		| '(' row_descriptor ')' row_op sub_type '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = $2;
--- 3559,3565 ----
  					n->subselect = $7;
  					$$ = (Node *)n;
  				}
! 		| '(' row_descriptor ')' all_Op sub_type '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = $2;
***************
*** 3567,3573 ****
  					n->subselect = $7;
  					$$ = (Node *)n;
  				}
! 		| '(' row_descriptor ')' row_op '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = $2;
--- 3572,3578 ----
  					n->subselect = $7;
  					$$ = (Node *)n;
  				}
! 		| '(' row_descriptor ')' all_Op '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = $2;
***************
*** 3580,3586 ****
  					n->subselect = $6;
  					$$ = (Node *)n;
  				}
! 		| '(' row_descriptor ')' row_op '(' row_descriptor ')'
  				{
  					$$ = makeRowExpr($4, $2, $6);
  				}
--- 3585,3591 ----
  					n->subselect = $6;
  					$$ = (Node *)n;
  				}
! 		| '(' row_descriptor ')' all_Op '(' row_descriptor ')'
  				{
  					$$ = makeRowExpr($4, $2, $6);
  				}
***************
*** 3602,3618 ****
  				}
  		;

- row_op:  Op									{ $$ = $1; }
- 		| '<'								{ $$ = "<"; }
- 		| '='								{ $$ = "="; }
- 		| '>'								{ $$ = ">"; }
- 		| '+'								{ $$ = "+"; }
- 		| '-'								{ $$ = "-"; }
- 		| '*'								{ $$ = "*"; }
- 		| '/'								{ $$ = "/"; }
- 		| '%'								{ $$ = "%"; }
- 		;
- 
  sub_type:  ANY								{ $$ = ANY_SUBLINK; }
  		| ALL								{ $$ = ALL_SUBLINK; }
  		;
--- 3607,3612 ----
***************
*** 3658,3669 ****
  				{	$$ = makeA_Expr(OP, "-", $1, $3); }
  		| a_expr '/' a_expr
  				{	$$ = makeA_Expr(OP, "/", $1, $3); }
- 		| a_expr '%' a_expr
- 				{	$$ = makeA_Expr(OP, "%", $1, $3); }
  		| a_expr '*' a_expr
  				{	$$ = makeA_Expr(OP, "*", $1, $3); }
  		| a_expr '^' a_expr
  				{	$$ = makeA_Expr(OP, "^", $1, $3); }
  		| a_expr '<' a_expr
  				{	$$ = makeA_Expr(OP, "<", $1, $3); }
  		| a_expr '>' a_expr
--- 3652,3665 ----
  				{	$$ = makeA_Expr(OP, "-", $1, $3); }
  		| a_expr '/' a_expr
  				{	$$ = makeA_Expr(OP, "/", $1, $3); }
  		| a_expr '*' a_expr
  				{	$$ = makeA_Expr(OP, "*", $1, $3); }
+ 		| a_expr '%' a_expr
+ 				{	$$ = makeA_Expr(OP, "%", $1, $3); }
  		| a_expr '^' a_expr
  				{	$$ = makeA_Expr(OP, "^", $1, $3); }
+ 		| a_expr '|' a_expr
+ 				{	$$ = makeA_Expr(OP, "|", $1, $3); }
  		| a_expr '<' a_expr
  				{	$$ = makeA_Expr(OP, "<", $1, $3); }
  		| a_expr '>' a_expr
***************
*** 4049,4054 ****
--- 4045,4060 ----
  					n->subselect = $4;
  					$$ = (Node *)n;
  				}
+ 		| a_expr '*' '(' SubSelect ')'
+ 				{
+ 					SubLink *n = makeNode(SubLink);
+ 					n->lefthand = lcons($1, NULL);
+ 					n->oper = lcons("*",NIL);
+ 					n->useor = false;
+ 					n->subLinkType = EXPR_SUBLINK;
+ 					n->subselect = $4;
+ 					$$ = (Node *)n;
+ 				}
  		| a_expr '%' '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
***************
*** 4059,4069 ****
  					n->subselect = $4;
  					$$ = (Node *)n;
  				}
! 		| a_expr '*' '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = lcons($1, NULL);
! 					n->oper = lcons("*",NIL);
  					n->useor = false;
  					n->subLinkType = EXPR_SUBLINK;
  					n->subselect = $4;
--- 4065,4085 ----
  					n->subselect = $4;
  					$$ = (Node *)n;
  				}
! 		| a_expr '^' '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = lcons($1, NULL);
! 					n->oper = lcons("^",NIL);
! 					n->useor = false;
! 					n->subLinkType = EXPR_SUBLINK;
! 					n->subselect = $4;
! 					$$ = (Node *)n;
! 				}
! 		| a_expr '|' '(' SubSelect ')'
! 				{
! 					SubLink *n = makeNode(SubLink);
! 					n->lefthand = lcons($1, NULL);
! 					n->oper = lcons("|",NIL);
  					n->useor = false;
  					n->subLinkType = EXPR_SUBLINK;
  					n->subselect = $4;
***************
*** 4139,4144 ****
--- 4155,4170 ----
  					n->subselect = $5;
  					$$ = (Node *)n;
  				}
+ 		| a_expr '*' ANY '(' SubSelect ')'
+ 				{
+ 					SubLink *n = makeNode(SubLink);
+ 					n->lefthand = lcons($1,NIL);
+ 					n->oper = lcons("*",NIL);
+ 					n->useor = false;
+ 					n->subLinkType = ANY_SUBLINK;
+ 					n->subselect = $5;
+ 					$$ = (Node *)n;
+ 				}
  		| a_expr '%' ANY '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
***************
*** 4149,4159 ****
  					n->subselect = $5;
  					$$ = (Node *)n;
  				}
! 		| a_expr '*' ANY '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = lcons($1,NIL);
! 					n->oper = lcons("*",NIL);
  					n->useor = false;
  					n->subLinkType = ANY_SUBLINK;
  					n->subselect = $5;
--- 4175,4195 ----
  					n->subselect = $5;
  					$$ = (Node *)n;
  				}
! 		| a_expr '^' ANY '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = lcons($1,NIL);
! 					n->oper = lcons("^",NIL);
! 					n->useor = false;
! 					n->subLinkType = ANY_SUBLINK;
! 					n->subselect = $5;
! 					$$ = (Node *)n;
! 				}
! 		| a_expr '|' ANY '(' SubSelect ')'
! 				{
! 					SubLink *n = makeNode(SubLink);
! 					n->lefthand = lcons($1,NIL);
! 					n->oper = lcons("|",NIL);
  					n->useor = false;
  					n->subLinkType = ANY_SUBLINK;
  					n->subselect = $5;
***************
*** 4229,4234 ****
--- 4265,4280 ----
  					n->subselect = $5;
  					$$ = (Node *)n;
  				}
+ 		| a_expr '*' ALL '(' SubSelect ')'
+ 				{
+ 					SubLink *n = makeNode(SubLink);
+ 					n->lefthand = lcons($1, NULL);
+ 					n->oper = lcons("*",NIL);
+ 					n->useor = false;
+ 					n->subLinkType = ALL_SUBLINK;
+ 					n->subselect = $5;
+ 					$$ = (Node *)n;
+ 				}
  		| a_expr '%' ALL '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
***************
*** 4239,4249 ****
  					n->subselect = $5;
  					$$ = (Node *)n;
  				}
! 		| a_expr '*' ALL '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = lcons($1, NULL);
! 					n->oper = lcons("*",NIL);
  					n->useor = false;
  					n->subLinkType = ALL_SUBLINK;
  					n->subselect = $5;
--- 4285,4305 ----
  					n->subselect = $5;
  					$$ = (Node *)n;
  				}
! 		| a_expr '^' ALL '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = lcons($1, NULL);
! 					n->oper = lcons("^",NIL);
! 					n->useor = false;
! 					n->subLinkType = ALL_SUBLINK;
! 					n->subselect = $5;
! 					$$ = (Node *)n;
! 				}
! 		| a_expr '|' ALL '(' SubSelect ')'
! 				{
! 					SubLink *n = makeNode(SubLink);
! 					n->lefthand = lcons($1, NULL);
! 					n->oper = lcons("|",NIL);
  					n->useor = false;
  					n->subLinkType = ALL_SUBLINK;
  					n->subselect = $5;
***************
*** 4325,4336 ****
  				{	$$ = makeA_Expr(OP, "-", $1, $3); }
  		| b_expr '/' b_expr
  				{	$$ = makeA_Expr(OP, "/", $1, $3); }
  		| b_expr '%' b_expr
  				{	$$ = makeA_Expr(OP, "%", $1, $3); }
  		| b_expr '^' b_expr
  				{	$$ = makeA_Expr(OP, "^", $1, $3); }
! 		| b_expr '*' b_expr
! 				{	$$ = makeA_Expr(OP, "*", $1, $3); }
  		| ':' b_expr
  				{	$$ = makeA_Expr(OP, ":", NULL, $2); }
  		| ';' b_expr
--- 4381,4394 ----
  				{	$$ = makeA_Expr(OP, "-", $1, $3); }
  		| b_expr '/' b_expr
  				{	$$ = makeA_Expr(OP, "/", $1, $3); }
+ 		| b_expr '*' b_expr
+ 				{	$$ = makeA_Expr(OP, "*", $1, $3); }
  		| b_expr '%' b_expr
  				{	$$ = makeA_Expr(OP, "%", $1, $3); }
  		| b_expr '^' b_expr
  				{	$$ = makeA_Expr(OP, "^", $1, $3); }
! 		| b_expr '|' b_expr
! 				{	$$ = makeA_Expr(OP, "|", $1, $3); }
  		| ':' b_expr
  				{	$$ = makeA_Expr(OP, ":", NULL, $2); }
  		| ';' b_expr
***************
*** 4602,4611 ****
  				{	$$ = makeA_Expr(OP, "-", $1, $3); }
  		| position_expr '/' position_expr
  				{	$$ = makeA_Expr(OP, "/", $1, $3); }
- 		| position_expr '%' position_expr
- 				{	$$ = makeA_Expr(OP, "%", $1, $3); }
  		| position_expr '*' position_expr
  				{	$$ = makeA_Expr(OP, "*", $1, $3); }
  		| '|' position_expr
  				{	$$ = makeA_Expr(OP, "|", NULL, $2); }
  		| position_expr TYPECAST Typename
--- 4660,4673 ----
  				{	$$ = makeA_Expr(OP, "-", $1, $3); }
  		| position_expr '/' position_expr
  				{	$$ = makeA_Expr(OP, "/", $1, $3); }
  		| position_expr '*' position_expr
  				{	$$ = makeA_Expr(OP, "*", $1, $3); }
+ 		| position_expr '%' position_expr
+ 				{	$$ = makeA_Expr(OP, "%", $1, $3); }
+ 		| position_expr '^' position_expr
+ 				{	$$ = makeA_Expr(OP, "^", $1, $3); }
+ 		| position_expr '|' position_expr
+ 				{	$$ = makeA_Expr(OP, "|", $1, $3); }
  		| '|' position_expr
  				{	$$ = makeA_Expr(OP, "|", NULL, $2); }
  		| position_expr TYPECAST Typename

--------------458A4AA633D538139A6FA0AB--

From bouncefilter Fri Sep 24 11:08:08 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 LAA22587
for <pgsql-hackers@postgreSQL.org>;
Fri, 24 Sep 1999 11:07:59 -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 LAA06020;
Fri, 24 Sep 1999 11:06:16 -0400 (EDT)
To: Adriaan Joubert <a.joubert@albourne.com>
cc: Hannu Krosing <hannu@tm.ee>, Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
In-reply-to: Your message of Fri, 24 Sep 1999 08:23:18 +0300
<37EB0AC6.C608E1A2@albourne.com>
Date: Fri, 24 Sep 1999 11:06:15 -0400
Message-ID: <6018.938185575@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Adriaan Joubert <a.joubert@albourne.com> writes:

A second problem I encountered last night is that the postgres variable
length types only allow for the length of an array to be stored in
bytes. This means that the number of bits will automatically always be
rounded up to the nearest factor of 8, i.e. you want tp store 3 bits and
you get 8. For ordering and output this is not always going to produce
the correct output, as the bitstrings will get zero-padded. Is there
anywhere else where one could store the exact length of a bit string?

You will need to put it right in the string, I think. You could
dedicate the first byte of the value of a bitstring (after the required
varlena length word) to indicating how many bits in the last byte are
wasted padding (0-7). That would leave a few spare bits in this header
byte that might or might not have any good use.

I haven't quite understood what the variable attypmod is. In varchar.c
it looks as if it is the length of the record, but if it is just an
integer identifier, then I could store the exact length in there. In
that case I could handle the difference between 3 and 5 bit strings
correctly. My main worry was that this might be used in other routines
to determine the length of a record.

atttypmod is a type-specific modifier: if you are developing a new data
type then you can define it any way you darn please. However, it's not
quite as useful as it first appears, because it is only stored in
connection with a column of a table --- there is no atttypmod associated
with the result of a function, for example. It is primarily useful if
you want to be able to coerce values into a common subformat when they
are stored into a column. For example, fixed-length char(n) types use
atttypmod as the column width so that they can pad or truncate a
supplied string to the right length just before storing. But a
free-standing string value does not have an atttypmod, only a length.
Similar remarks apply to NUMERIC, which uses atttypmod to store the
desired precision for a column, but not to figure out the actual
precision of a value in memory. In short, your datatype representation
needs to be self-identifying without help from atttypmod.

regards, tom lane

From bouncefilter Fri Sep 24 11:09:08 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 LAA22674
for <pgsql-hackers@postgreSQL.org>;
Fri, 24 Sep 1999 11:08:56 -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 LAA06049;
Fri, 24 Sep 1999 11:08:04 -0400 (EDT)
To: t-ishii@sra.co.jp
cc: "Hiroshi Inoue" <Inoue@tpf.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] int8 and index
In-reply-to: Your message of Fri, 24 Sep 1999 15:36:37 +0900
<199909240636.PAA29772@srapc451.sra.co.jp>
Date: Fri, 24 Sep 1999 11:08:03 -0400
Message-ID: <6047.938185683@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

How about select .. from .. where .. = ..::int8; ?

Without ::int8 PostgreSQL doesn't use int8 indexes.

Oops. I forgot about that! Thanks.

Yes, this is on the TODO list (although I think TODO just mentions
the equivalent problem for int2).

regards, tom lane

From bouncefilter Fri Sep 24 11:27:09 1999
Received: from ns.infoset.cz (ns.infoset.cz [194.213.32.210])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA25534
for <pgsql-hackers@postgresql.org>;
Fri, 24 Sep 1999 11:26:46 -0400 (EDT)
(envelope-from dpeder@infoset.cz)
Received: from WinProxy.anywhere ([62.168.15.178])
by ns.infoset.cz (8.8.7/8.8.7) with SMTP id RAA04049
for <pgsql-hackers@postgresql.org>; Fri, 24 Sep 1999 17:25:14 +0200
Received: from 192.168.1.1 by 192.168.1.3 (WinProxy);
Fri, 24 Sep 1999 17:28:13 +0100
Received: by Dan with Microsoft Mail
id <01BF06B1.E09B10A0@Dan>; Fri, 24 Sep 1999 17:26:03 +0200
Message-ID: <01BF06B1.E09B10A0@Dan>
From: =?iso-8859-2?Q?Daniel_P=E9der?= <dpeder@infoset.cz>
To: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: postgres startup script modification (Linux RedHat)
Date: Fri, 24 Sep 1999 17:26:02 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id LAA25583

= = = = =

If You find it usefull, make following modification to the file:

/etc/rc.d/init.d/postgresql

other text stuff was left for Your better orientation where put the changes...

so here we are:
======================================================
#!/bin/sh
...
...
[ -f /usr/bin/postmaster ] || exit 0

dpeder@infoset.cz
Daniel Peder
http://shop.culture.cz
From bouncefilter Fri Sep 24 11:28:08 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA25656
for <pgsql-hackers@postgreSQL.org>;
Fri, 24 Sep 1999 11:27:41 -0400 (EDT)
(envelope-from a.joubert@albourne.com)
Received: from isadora.cy.albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.6X) with ESMTP
id SAA18100; Fri, 24 Sep 1999 18:30:11 +0300 (EET DST)
Received: from albourne.com (localhost [127.0.0.1])
by isadora.cy.albourne.com (8.9.3/8.9.3/Albourne/CYC/1.4) with ESMTP id
SAA00747; Fri, 24 Sep 1999 18:27:36 +0300 (EET DST)
Sender: a.joubert@albourne.com
Message-ID: <37EB9867.E45479C@albourne.com>
Date: Fri, 24 Sep 1999 18:27:36 +0300
From: Adriaan Joubert <a.joubert@albourne.com>
Organization: APL Financial Services (Overseas) Ltd
X-Mailer: Mozilla 4.61 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Hannu Krosing <hannu@tm.ee>, Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
References: <Pine.BSF.4.10.9909220246160.38923-100000@thelab.hub.org>
<37E87542.2F8ADA4A@albourne.com>
<37E8F672.9B98E9BF@alumni.caltech.edu>
<37E9E490.1CD9623B@albourne.com>
<37EA31BC.A18A31EE@alumni.caltech.edu>
<37EA3723.B513E03@albourne.com>
<37EA459C.29E2B38D@alumni.caltech.edu>
<37EA5361.59EC106D@albourne.com> <37EA95FB.F6DF530A@tm.ee>
<37EB0AC6.C608E1A2@albourne.com>
<37EB88E0.24A45661@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

attypmod has been modified recently to contain two fields (each of 16
bits) in a backward-compatible way. It can hold the size *and*
precision of the numeric data types, and presumably should be used in
a similar manner for your bit type.

The problem is that you need another field which contains a length in
bit units. Assuming that the second field in attypmod can't be used
for this purpose, then istm that you will want to add a field to the
data type itself. The character types have:

length - total size of data, in bytes (4 bytes)
data - body

and you might have

length - total size of data, in bytes (4 bytes)
blen - total size of data, in bits (4 bytes)
data - body

OK, I just saw th email from Tom Lane as well. So I will use attypmod as
the length of the bit string in bits, and use an additional byte, as
suggested here, for the actual length.

Jose recommended looking at the Ocelot database and I got it down. Turns
out they have a real big problem with the output of bit strings, but at
least I could figure out how they do the ordering. Looks as if it is
lexicographically from the least significant bit, i.e.

B'1' > B'10' > B'1100'

the only surprising thing was that they then have B'1000' > B'01000',
and my reading of the SQL standard says that it should be the other way
round. So I will just do the comparison from the least significant bit.

Cheers,

Adriaan

From bouncefilter Fri Sep 24 11:31:08 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 LAA26284
for <pgsql-hackers@postgreSQL.org>;
Fri, 24 Sep 1999 11:30:20 -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 LAA06106;
Fri, 24 Sep 1999 11:29:35 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql issues
In-reply-to: Your message of Fri, 24 Sep 1999 12:38:19 +0200 (CEST)
<Pine.LNX.4.10.9909241139570.477-100000@peter-e.yi.org>
Date: Fri, 24 Sep 1999 11:29:34 -0400
Message-ID: <6104.938186974@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

1) Is it just me or is psql the only application that uses libpq's
PQprint()? I think both parties involved could benefit if the PQprint was
moved to or integrated into psql. Or perhaps a libpqprint as a compromise?

The print support in libpq is certainly ugly --- we've got two or three
generations of print subroutines in there, and are maintaining 'em all
because we have no idea what existing applications may depend on each.
I'd be real hesitant to rip any of them out. However, if you can
improve on them, a new fourth-generation subroutine isn't going to
hurt anyone ;-).

I'm not sure whether moving them to a separate library would be worth
the trouble. It might be worth breaking up fe-print.c more, so that
a statically linked app will only pull in the subroutines it's actually
using. But for users of shared libraries this doesn't matter anyway.

2) Regarding TODO item "Allow psql \copy to allow delimiters": What
precisely is the difference between:

=> \copy my_table to file

=> copy my_table to 'file';

Those two are *very significantly* different: the former reads or writes
a file from psql, using the client's access rights (after transporting
the data across the frontend/backend channel, of course). The latter
reads or writes a file from the backend, using the backend's access
rights (and the psql process never even sees the data).

The two processes are not necessarily even on the same machine, so you
may be talking about two completely different filesystems. We restrict
backend copy to the Postgres superuser for obvious security reasons.
Therefore, it'd be real nice if psql's \copy support was more complete.

Correct me if I'm wrong, but I believe the use of PG{get|put}line() for
the \copy would have to be scratched if one would want to use delimiters.

No. get/putline are just the implementation of the data transport step
mentioned above. If psql would send a DELIMITER clause in the COPY TO
STDIN or COPY FROM STDOUT command that it sends to the backend to start
a \copy operation, then the right things would happen. Should be a
pretty localized change. There might be some other COPY options that
would be worth supporting ... I forget.

BTW, I suspect that there may be some bugs in get/putline and/or psql.c
and/or the backend's copy.c that cause the data transport not to be
perfectly 8-bit-clean. In particular, backslash quoting of control
characters needs to be looked at. There is (or should be) a TODO item
about this. If you feel like digging into that area, it'd be useful.

3) Is anyone doing anything major on psql right now or would anyone mind
if I undertake a major code clean up on it? Or is everyone completely
comfortable with 350-line functions with 7 levels of indentation?

Go for it --- it's pretty ugly all right, and far from the fine example
of how to code a Postgres client that it ought to be ;-).

Make sure you start from current CVS sources, because I just finished
hacking up psql (and libpq) to eliminate line length restrictions.
Offhand I don't know of any other major changes pending in that code.
(Anybody want to speak up here and say "I'm doing something"?)

regards, tom lane

From bouncefilter Fri Sep 24 14:38:35 1999
Received: from argh.demon.co.uk (IDENT:grim@argh.demon.co.uk [193.237.6.55])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA11410
for <pgsql-hackers@postgresql.org>;
Fri, 24 Sep 1999 14:38:31 -0400 (EDT)
(envelope-from grim@argh.demon.co.uk)
Received: (from grim@localhost) by argh.demon.co.uk (8.9.3/8.9.3) id TAA04460;
Fri, 24 Sep 1999 19:42:56 +0100
From: Michael Simms <grim@argh.demon.co.uk>
Message-Id: <199909241842.TAA04460@argh.demon.co.uk>
Subject: Re: Frustrated
To: pgsql-hackers@postgresql.org
Date: Fri, 24 Sep 1999 19:42:56 +0100 (BST)
Cc: Re:, Frustrated@argh.demon.co.uk
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

OK, thanks to some probing by Hiroshi, and by the fact that it became
utterly blatantly obvious, I can state as a fact that postgresql was NOT
responsible for the crashes I was seeing last night.

I woke up this morning, intent on finding SOME solution, and I found this

Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 1109780 704964 347461 67% /
/dev/hda1 33149 6140 25297 20% /boot
/dev/hdc1 9515145 3248272 5773207 36% /home
/dev/hdb1 402852 154144 227903 40% /tmp
/dev/sda1 30356106785018642307 43892061535609608 0 100% /var/lib/pgsql

Now, I thought to myself, either my 9.2GB drive has become the size of a
small country, or I have a problem.

Much probing has revealed to me that the nice adapted U2W scsi card that I
installed, has problems under Linux SMP kernels.

As such, I wave the penguin of shame at Adaptec for shoddy drivers. And
I declare that I once again find postgres warm and fuzzy and huggable {:-)

~Michael

ps. Before the problem became too obvious, Hiroshi sent me the following.
It may be useful, I have no idea what it does {:-))

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

Disk full error while writing a block may be one of the cause.
As far as I see,error on block write isn't handled correctly in md.c.

The following patch may help you.
However I didn't test the patch at all.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

*** storage/smgr/md.c.orig      Fri Sep 24 15:01:29 1999
--- storage/smgr/md.c   Fri Sep 24 18:07:31 1999
***************
*** 243,248 ****
--- 243,255 ----
        if ((pos = FileSeek(v->mdfd_vfd, 0L, SEEK_END)) < 0)
                return SM_FAIL;

+       if (pos % BLCKSZ != 0)
+       {
+               pos = BLCKSZ * (pos / BLCKSZ);
+               if (FileSeek(v->mdfd_vfd, pos, SEEK_SET) != pos)
+                       return SM_FAIL;
+       }
+ 
        if (FileWrite(v->mdfd_vfd, buffer, BLCKSZ) != BLCKSZ)
                return SM_FAIL;

***************
*** 1060,1065 ****
{
long len;

!       len = FileSeek(file, 0L, SEEK_END) - 1;
!       return (BlockNumber) ((len < 0) ? 0 : 1 + len / blcksz);
  }
--- 1067,1072 ----
  {
        long            len;

! len = FileSeek(file, 0L, SEEK_END);
! return (BlockNumber) (len / blcksz);
}

From bouncefilter Sat Sep 25 09:09:33 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 JAA32714
for <pgsql-hackers@postgreSQL.org>;
Sat, 25 Sep 1999 09:08:44 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11UrS1-0003kLC; Sat, 25 Sep 99 15:01 MET DST
Message-Id: <m11UrS1-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] create rule changes table to view ?
To: peter_e@gmx.net (Peter Eisentraut)
Date: Sat, 25 Sep 1999 15:01:17 +0200 (MET DST)
Cc: maillist@candle.pha.pa.us, oleg@sai.msu.su, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <Pine.LNX.4.10.9909240005280.18581-100000@peter-e.yi.org> from
"Peter Eisentraut" at Sep 24, 99 12:37:24 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Peter Eisentraut wrote:

A fix would be to display both tables and views as "relation". As far as I
know there is now 100% deterministic way to tell a table from a view. I
think one fine day Jan is going to change that but for now we don't have
to worry about it.

There is currently a 100% failsafe way.

Actually, rules ON SELECT are totally restricted to rules
that are INSTEAD, return a targetlist that's exactly the
relations (views) schema and there could only be one single-
action rule on the SELECT event. These checks are performed
during CREATE RULE.

In short: If there's a rule ON SELECT, then the relation MUST
BE A VIEW.

The detail psql is doing wrong is that it treats any rule as
if it is indicating a view. It must look for SELECT rules
only.

And I'm not planning to take out this restriction again.

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 Sat Sep 25 11:16:29 1999
Received: from lota.izhcom.ru (lota.izhcom.ru [213.24.0.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA37114
for <pgsql-hackers@postgreSQL.org>;
Sat, 25 Sep 1999 11:16:15 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (U122.dialup.udm.net [192.168.53.122])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id UAA88201
for <pgsql-hackers@postgreSQL.org>;
Sat, 25 Sep 1999 20:16:10 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37ECE6E5.B8B0053D@udmnet.ru>
Date: Sat, 25 Sep 1999 20:14:45 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: hackers <pgsql-hackers@postgreSQL.org>
Subject: Profiling?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

How do you profile backend? It complains about 'profile timer expired'
apparently due to waiting on socket. Maybe some compile option is
missing or there is other trick?

--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.

From bouncefilter Sat Sep 25 11:52:30 1999
Received: from thelab.hub.org (nat194.229.mpoweredpc.net [142.177.194.229])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA38826
for <pgsql-hackers@postgresql.org>;
Sat, 25 Sep 1999 11:52:26 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA22000
for <pgsql-hackers@postgresql.org>;
Sat, 25 Sep 1999 12:52:21 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 25 Sep 1999 12:52:20 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: a test ...
Message-ID: <Pine.BSF.4.10.9909251251330.11886-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

something appears to have messed up last night, but have been unable to
find cause...all mai lgoes to the archive, but leaves the system as blank
email? :(

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Sat Sep 25 15:45:32 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA50160
for <pgsql-hackers@postgresql.org>;
Sat, 25 Sep 1999 15:45:12 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:4004 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rvGMw96509>;
Sat, 25 Sep 1999 21:45:00 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2) id 11UxlM-0000Kv-00
for pgsql-hackers@postgresql.org; Sat, 25 Sep 1999 21:45:40 +0200
Date: Sat, 25 Sep 1999 21:45:40 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgresql.org
Subject: psql code to be obducted by alien (me)
Message-ID: <Pine.LNX.4.10.9909252007030.1275-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

As authorized by Tom L. himself and barring any loud protests I will start
a code clean-up on psql sometime within the next few days. So if you are
doing something on it or plan on doing so, please let me know. Among the
things on the agenda are:

* Reduce function size, indentation levels, file sizes

* Make use of latest libpq facilities

* Take care of various TODO items, such as NULL display (perhaps the one
recently submitted by me?), \copy issues, possibly more.

* Allow for implementation of a more sophisticated readline TAB
completion. (Not necessarily the one I recently sent in, if you can come
up with a better one. I'll try to keep it general.)

* Have tables vs. views show up correctly, as explained to me by Jan.

* Various enhancements on HTML display.

* A full bag of other ideas which will probably have to be postponed.

I am also tempted to drop the use of libpq's PQprint so that it can be
phased out, since I suspect hardly anyone else uses it and no one is
really happy with it. One could perhaps put a big #ifdef around that code
then. We'll see what happens. If this development would break your heart,
please yell.

Any other suggestions before I lock myself into my room are welcome.

Peter

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

From bouncefilter Sat Sep 25 16:43:33 1999
Received: from lota.izhcom.ru (lota.izhcom.ru [213.24.0.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA53852
for <pgsql-hackers@postgreSQL.org>;
Sat, 25 Sep 1999 16:43:14 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (U122.dialup.udm.net [192.168.53.122])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id BAA34129
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 01:43:12 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37ED33E1.31BD5D8B@udmnet.ru>
Date: Sun, 26 Sep 1999 01:43:14 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: hackers <pgsql-hackers@postgreSQL.org>
Subject: Profiling?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

How do you profile backend? It complains about 'profile timer expired'
apparently due to waiting on socket. Maybe some compile option is
missing or there is other trick?

--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.

From bouncefilter Sat Sep 25 18:58:35 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 SAA68528
for <pgsql-hackers@postgreSQL.org>;
Sat, 25 Sep 1999 18:58: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 SAA12045;
Sat, 25 Sep 1999 18:57:36 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql code to be obducted by alien (me)
In-reply-to: Your message of Sat, 25 Sep 1999 21:45:40 +0200 (CEST)
<Pine.LNX.4.10.9909252007030.1275-100000@peter-e.yi.org>
Date: Sat, 25 Sep 1999 18:57:35 -0400
Message-ID: <12043.938300255@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

I am also tempted to drop the use of libpq's PQprint so that it can be
phased out, since I suspect hardly anyone else uses it and no one is
really happy with it.

If you write new printing code for psql, please consider making it a
separate module that could be included into libpq so other applications
can use it.

Another part of psql that should be made as independent as possible
is the support for \copy. I recall a number of people asking in the
past how they can read and write tables to files in their own apps.
There's not that much code involved, but psql is such a mess that it's
hard to point to a chunk of code they can borrow.

BTW, something closely related to \copy that's languishing on the TODO
list is the ability to load the contents of a local file into a Large
Object or write the data out again. This would be the equivalent of the
server-side operations lo_import and lo_export, but reading or writing a
file in psql's environment instead of the backend's. Basically a wrapper
around lo_read/lo_write, not much to it but it needs done...

Anyway, I guess the point of all this is that psql should be not only
a useful app in its own right, but a source of how-to examples and
borrowable code for people making their own client apps. I think you
will move it a long way in that direction just by doing cleanup, but
please keep the notion in mind while you work.

regards, tom lane

From bouncefilter Sat Sep 25 21:13: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 VAA72602
for <pgsql-hackers@postgreSQL.org>;
Sat, 25 Sep 1999 21:13:17 -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 VAA17174
for <pgsql-hackers@postgreSQL.org>;
Sat, 25 Sep 1999 21:12:42 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Making proiscachable believable
Date: Sat, 25 Sep 1999 21:12:42 -0400
Message-ID: <17171.938308362@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I am just about to commit Bernard Frankpitt's
constant-expression-reducing code, along with some of the improvements
I suggested a couple days ago. In particular, it will not try to reduce
any op/func not marked "proiscachable" in pg_proc. This renders it a
tad ineffective with the current contents of pg_proc :-( ...

The only functions marked cachable in 6.5.2 are

play=> select proname from pg_proc where proiscachable;
proname
---------
version
hashsel
hashnpage
gistsel
gistnpage
(5 rows)

and to add insult to injury, I believe all five of these markings are
wrong! Functions whose outputs can vary for the same inputs must not
be marked cacheable --- and all of these use data other than their
arguments.

I have been working on modifying pg_proc.h to have believable
cacheability information. What I did was to mark everything cacheable
and then go through and unmark the stuff that shouldn't be
constant-foldable: basically, stuff that fetches data from tables,
stuff that involves datetime conversion, and a few special cases like
nextval() and oidrand().

I am worried that I may have missed some things, and am seeking advice
on how I can check my work.

One thing I did not realize at first was that *none* of the datetime,
date, abstime, timespan, or tinterval operators can safely be marked
cachable. The reason: these datatypes have special data values that
mean "now" (this has nothing to do with what the conversion to/from
text form yields, BTW). Thus, for example, datetimeeq might say
one thing today and another tomorrow for the same input values,
if one of them is "now" and the other is a constant time. Short of
inserting knowledge about these special values into the constant-
folder, we have to mark all the operations on the datatype non-foldable.

Are there any other gotchas like that one?

regards, tom lane

From bouncefilter Sat Sep 25 21:24: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 VAA73022
for <pgsql-hackers@postgreSQL.org>;
Sat, 25 Sep 1999 21:24: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 VAA17339
for <pgsql-hackers@postgreSQL.org>;
Sat, 25 Sep 1999 21:23:41 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: cvs having problems?
Date: Sat, 25 Sep 1999 21:23:41 -0400
Message-ID: <17337.938309021@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Anyone else finding that the postgres CVS server isn't working?
Anything I try to do yields the same failure:

$ cvs log include/optimizer/clauses.h
can't create temporary directory
Permission denied
$

regards, tom lane

From bouncefilter Sat Sep 25 21:51:37 1999
Received: from thelab.hub.org (nat194.229.mpoweredpc.net [142.177.194.229])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA76742
for <pgsql-hackers@postgreSQL.org>;
Sat, 25 Sep 1999 21:50:41 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA25600;
Sat, 25 Sep 1999 22:50:59 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 25 Sep 1999 22:50:58 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] cvs having problems?
In-Reply-To: <17337.938309021@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9909252249430.22201-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Fixed, sorry for delay...we had a problem this mornig with the news
spools on the system, and ended up disabling them while we look further
into it...cvs was pointing its temp directory at /news/tmp, which is the
largest "empty" file system we have, and while things are disabled, it no
longer exists...changed inetd.conf to point at /home/tmp instead, which is
still large...

On Sat, 25 Sep 1999, Tom Lane wrote:

Anyone else finding that the postgres CVS server isn't working?
Anything I try to do yields the same failure:

$ cvs log include/optimizer/clauses.h
can't create temporary directory
Permission denied
$

regards, tom lane

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

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Sun Sep 26 11:57:47 1999
Received: from nadia.s.bawue.de (root@nadia.s.bawue.de [193.197.11.52])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA30749
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 11:57:15 -0400 (EDT)
(envelope-from E.Mergl@bawue.de)
Received: from bawue.de (sls.s.bawue.de [193.197.11.90])
by nadia.s.bawue.de (8.9.3/8.9.3) with ESMTP id RAA12509;
Sun, 26 Sep 1999 17:57:00 +0200 (CEST)
Posted-Date: Sun, 26 Sep 1999 17:57:00 +0200 (CEST)
Sender: mergl@nadia.s.bawue.de
Message-ID: <37EE4247.68D0B492@bawue.de>
Date: Sun, 26 Sep 1999 17:56:55 +0200
From: Edmund Mergl <E.Mergl@bawue.de>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL Hackers Mailinglist <pgsql-hackers@postgreSQL.org>
Subject: libpq.rc for Win32
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit

in src/interfaces/libpq/libpq.rc there is an obvious typo in
first line:

v#include <winver.h>

hence linking with Visual Studio fails with the error-message:

file not found: VS_VERSION_INFO

Edmund

--
Edmund Mergl
mailto:E.Mergl@bawue.de
http://www.bawue.de/~mergl

From bouncefilter Sun Sep 26 20:06:52 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA87842
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 20:06:23 -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 UAA25908;
Sun, 26 Sep 1999 20:05:31 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909270005.UAA25908@candle.pha.pa.us>
Subject: Re: [HACKERS] int8 and index
In-Reply-To: <199909240612.PAA29531@srapc451.sra.co.jp> from Tatsuo Ishii at
"Sep 24, 1999 03:12:17 pm"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Sun, 26 Sep 1999 20:05:31 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Do we have problems with int8 indexes? Seems select on an int8 does
not use an index.

This is PostgreSQL 6.5.2 on RedHat 6.0.

That is strange. We have code to make indexes on int8 now.

-- 
  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 Sun Sep 26 20:10:53 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA88093
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 20:10:41 -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 UAA26148;
Sun, 26 Sep 1999 20:08:56 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909270008.UAA26148@candle.pha.pa.us>
Subject: Re: [HACKERS] create rule changes table to view ?
In-Reply-To: <Pine.LNX.4.10.9909240005280.18581-100000@peter-e.yi.org> from
Peter Eisentraut at "Sep 24, 1999 12:37:24 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 26 Sep 1999 20:08:56 -0400 (EDT)
CC: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have noticed and lived with this problem for quite a while.

There's nothing in pg_class that tells a table from a view, they're both
"relations". Since a view is implemented as in effect an empty table with
on select rules on it, psql thinks every table with a rule on it is a
view. This is just the output, nothing on the table changes.

A fix would be to display both tables and views as "relation". As far as I
know there is now 100% deterministic way to tell a table from a view. I
think one fine day Jan is going to change that but for now we don't have
to worry about it.

OK. Nothing added to TODO list.

-- 
  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 Sun Sep 26 20:11:52 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 UAA88174
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 20:11:50 -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 JAA14202; Mon, 27 Sep 1999 09:10:04 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Michael Simms" <grim@argh.demon.co.uk>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Frustration
Date: Mon, 27 Sep 1999 09:13:38 +0900
Message-ID: <001501bf087d$25ea27a0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <5760.938183214@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
Sent: Friday, September 24, 1999 11:27 PM
To: Michael Simms
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Frustration

Michael Simms <grim@argh.demon.co.uk> writes:

Well, thanks to tom, I know what was wrong, and I have found

the problem,

or one of them at least...
FATAL: s_lock(0c9ef824) at bufmgr.c:1106, stuck spinlock. Aborting.
Okee, that segment of code is, well, its some deep down internals that
are as clear as mud to me.

Hmph. Apparently, some backend was waiting for some other backend to
finish reading a page in or writing it out, and gave up after deciding
it had waited an unreasonable amount of time (~ 1 minute, which does
seem plenty long enough). Probably, the I/O did in fact finish, but
the waiting backend didn't get the word for some reason.

[snip]

Another likely explanation is that there's something wrong in
bufmgr.c's logic for setting and releasing the io_in_progress lock ---
but a quick look doesn't show any obvious error, and I would have
thought we'd have found out about any such problem long since.
Since we're not being buried in reports of stuck-spinlock errors,
I'm guessing there is some platform-specific problem on your machine.
No good ideas what it is if it isn't a spinlock failure.

Different from other spinlocks,io_in_progress spinlock is a per bufpage
spinlock and ProcReleaseSpins() doesn't release the spinlock.
If an error(in md.c in most cases) occured while holding the spinlock
,the spinlock would necessarily freeze.

Michael Simms says
ERROR: cannot read block 641 of server
occured before the spinlock stuck abort.

Probably it is an original cause of the spinlock freeze.

However I don't understand the following status of his machine.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sun Sep 26 20:19:52 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA88923
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 20:19:22 -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 UAA26200;
Sun, 26 Sep 1999 20:17:11 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909270017.UAA26200@candle.pha.pa.us>
Subject: Re: [HACKERS] psql issues
In-Reply-To: <6104.938186974@sss.pgh.pa.us> from Tom Lane at "Sep 24,
1999 11:29:34 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 26 Sep 1999 20:17:11 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Peter Eisentraut <peter_e@gmx.net> writes:

1) Is it just me or is psql the only application that uses libpq's
PQprint()? I think both parties involved could benefit if the PQprint was
moved to or integrated into psql. Or perhaps a libpqprint as a compromise?

The print support in libpq is certainly ugly --- we've got two or three
generations of print subroutines in there, and are maintaining 'em all
because we have no idea what existing applications may depend on each.
I'd be real hesitant to rip any of them out. However, if you can
improve on them, a new fourth-generation subroutine isn't going to
hurt anyone ;-).

Let me add something. I have no problem with #ifdef NOT_USED certain
function bodies, and replacing them with something else like this:

int libfunc()
{
#ifdef NOT_USED
old_lib_code
...
#else
fprintf(stderr,"This function is currently unsupported.\n");
fprintf(stderr,"If you want to use it, contact the bugs mailing list.\n");
exit(1);
#endif

and if we can get through one full release with the code like this, we
can remove the function entirely.

This seems to be the only clean way to remove much old cruft in library
code.

I am sure some of the old code was for the old pgsql 'monitor' program
that we trashed early on, so I doubt people are using any of that print
code.

I'm not sure whether moving them to a separate library would be worth
the trouble. It might be worth breaking up fe-print.c more, so that
a statically linked app will only pull in the subroutines it's actually
using. But for users of shared libraries this doesn't matter anyway.

I agree. Keep it in libpq because it may be useful for someone else.

-- 
  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 Sun Sep 26 20:26:03 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA89822
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 20:25:35 -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 UAA26545;
Sun, 26 Sep 1999 20:24:54 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909270024.UAA26545@candle.pha.pa.us>
Subject: Re: [HACKERS] psql code to be obducted by alien (me)
In-Reply-To: <Pine.LNX.4.10.9909252007030.1275-100000@peter-e.yi.org> from
Peter Eisentraut at "Sep 25, 1999 09:45:40 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 26 Sep 1999 20:24:53 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Happy coding... :-)

As authorized by Tom L. himself and barring any loud protests I will start
a code clean-up on psql sometime within the next few days. So if you are
doing something on it or plan on doing so, please let me know. Among the
things on the agenda are:

* Reduce function size, indentation levels, file sizes

* Make use of latest libpq facilities

* Take care of various TODO items, such as NULL display (perhaps the one
recently submitted by me?), \copy issues, possibly more.

* Allow for implementation of a more sophisticated readline TAB
completion. (Not necessarily the one I recently sent in, if you can come
up with a better one. I'll try to keep it general.)

* Have tables vs. views show up correctly, as explained to me by Jan.

* Various enhancements on HTML display.

* A full bag of other ideas which will probably have to be postponed.

I am also tempted to drop the use of libpq's PQprint so that it can be
phased out, since I suspect hardly anyone else uses it and no one is
really happy with it. One could perhaps put a big #ifdef around that code
then. We'll see what happens. If this development would break your heart,
please yell.

Any other suggestions before I lock myself into my room are welcome.

Peter

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

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

-- 
  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 Sun Sep 26 20:27:52 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA90069
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 20:27:12 -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 UAA26569;
Sun, 26 Sep 1999 20:25:58 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909270025.UAA26569@candle.pha.pa.us>
Subject: Re: [HACKERS] Profiling?
In-Reply-To: <37ED33E1.31BD5D8B@udmnet.ru> from Leon at "Sep 26, 1999 01:43:14
am"
To: Leon <leon@udmnet.ru>
Date: Sun, 26 Sep 1999 20:25:58 -0400 (EDT)
CC: hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yes, I have done it many times. I profile that postgres process, not
the backend. Look for this in Makefile.global:

# Comment out PROFILE to generate a profile version of the binaries
#PROFILE= -p -non_shared

Hi!

How do you profile backend? It complains about 'profile timer expired'
apparently due to waiting on socket. Maybe some compile option is
missing or there is other trick?

--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.

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

-- 
  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 Sun Sep 26 20:33:52 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA93732
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 20:32:50 -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 UAA26783;
Sun, 26 Sep 1999 20:31:26 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909270031.UAA26783@candle.pha.pa.us>
Subject: Re: [HACKERS] libpq.rc for Win32
In-Reply-To: <37EE4247.68D0B492@bawue.de> from Edmund Mergl at "Sep 26, 1999
05:56:55 pm"
To: Edmund Mergl <E.Mergl@bawue.de>
Date: Sun, 26 Sep 1999 20:31:26 -0400 (EDT)
CC: PostgreSQL Hackers Mailinglist <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Fixed. Thanks.

[Charset iso-8859-2 unsupported, filtering to ASCII...]

in src/interfaces/libpq/libpq.rc there is an obvious typo in
first line:

v#include <winver.h>

hence linking with Visual Studio fails with the error-message:

file not found: VS_VERSION_INFO

Edmund

--
Edmund Mergl
mailto:E.Mergl@bawue.de
http://www.bawue.de/~mergl

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

-- 
  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 Sun Sep 26 20:45:57 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA99993
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 20:45:51 -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 UAA27257;
Sun, 26 Sep 1999 20:44:42 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909270044.UAA27257@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
In-Reply-To: <37EB88E0.24A45661@alumni.caltech.edu> from Thomas Lockhart at
"Sep 24, 1999 02:21:20 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Sun, 26 Sep 1999 20:44:42 -0400 (EDT)
CC: Adriaan Joubert <a.joubert@albourne.com>, Hannu Krosing <hannu@tm.ee>,
Postgresql <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

attypmod has been modified recently to contain two fields (each of 16
bits) in a backward-compatible way. It can hold the size *and*
precision of the numeric data types, and presumably should be used in
a similar manner for your bit type.

You can use a union to split atttypmod up into two 8-bit fields and on
16-bit field. Let me know if you need help.

The problem is that you need another field which contains a length in
bit units. Assuming that the second field in attypmod can't be used
for this purpose, then istm that you will want to add a field to the
data type itself. The character types have:

length - total size of data, in bytes (4 bytes)
data - body

and you might have

length - total size of data, in bytes (4 bytes)
blen - total size of data, in bits (4 bytes)
data - body

- Thomas

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

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

-- 
  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 Sun Sep 26 20:49:53 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA00389
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 20:49:32 -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 UAA27320;
Sun, 26 Sep 1999 20:47:05 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909270047.UAA27320@candle.pha.pa.us>
Subject: Re: [HACKERS] int8 and index
In-Reply-To: <6047.938185683@sss.pgh.pa.us> from Tom Lane at "Sep 24,
1999 11:08:03 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 26 Sep 1999 20:47:04 -0400 (EDT)
CC: t-ishii@sra.co.jp, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

How about select .. from .. where .. = ..::int8; ?

Without ::int8 PostgreSQL doesn't use int8 indexes.

Oops. I forgot about that! Thanks.

Yes, this is on the TODO list (although I think TODO just mentions
the equivalent problem for int2).

int8 mention added.

-- 
  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 Sun Sep 26 21:07:57 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 VAA05494
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 21:07:42 -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 KAA14229; Mon, 27 Sep 1999 10:05:19 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>,
"Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <t-ishii@sra.co.jp>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] int8 and index
Date: Mon, 27 Sep 1999 10:08:55 +0900
Message-ID: <001601bf0884$de79e920$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
In-Reply-To: <199909270047.UAA27320@candle.pha.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: Monday, September 27, 1999 9:47 AM
To: Tom Lane
Cc: t-ishii@sra.co.jp; Hiroshi Inoue; pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] int8 and index

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

How about select .. from .. where .. = ..::int8; ?

Without ::int8 PostgreSQL doesn't use int8 indexes.

Oops. I forgot about that! Thanks.

Yes, this is on the TODO list (although I think TODO just mentions
the equivalent problem for int2).

int8 mention added.

There may be a little difference.

int4 -> int8 never fails.
But int4 -> int2 fails if abs(int4) > 32768.

select .. from .. where int2_column = 32769;

should return 0 rows or cause an elog(ERROR) ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sun Sep 26 23:28:29 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA05007
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 23:26:44 -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 XAA01264
for pgsql-hackers@postgreSQL.org; Sun, 26 Sep 1999 23:26:05 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909270326.XAA01264@candle.pha.pa.us>
Subject: Re: [HACKERS] A multi-lang patch for psql 6.5.1 (fwd)
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Sun, 26 Sep 1999 23:26:05 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM938402765-28528-0_
Content-Transfer-Encoding: 7bit

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

I am interested in people's opinions on this patch. Not sure what it is
supposed to do.

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

--ELM938402765-28528-0_
Content-Type: message/rfc822
Content-Disposition: inline
Content-Description: Forwarded message from Cd Chen
Content-Transfer-Encoding: 7bit

Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id NAA10730
for <maillist@candle.pha.pa.us>; Tue, 27 Jul 1999 13:31:29 -0400 (EDT)
Received: from local.cynix.com.tw (IDENT:root@[210.242.57.101]) by
renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA09088 for
<maillist@candle.pha.pa.us>; Tue, 27 Jul 1999 13:18:37 -0400 (EDT)
Received: from cdchen (cdchen.cynix.com.tw [210.242.57.120])
by local.cynix.com.tw (8.9.3/8.9.3) with SMTP id BAA26997
for <maillist@candle.pha.pa.us>; Wed, 28 Jul 1999 01:10:42 +0800
Posted-Date: Wed, 28 Jul 1999 01:10:42 +0800
Date: Wed, 28 Jul 1999 01:16:53 +0800
From: Cd Chen <cdchen@mail.cynix.com.tw>
To: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] A multi-lang patch for psql 6.5.1
In-Reply-To: <199907251951.PAA03335@candle.pha.pa.us>
References: <379B62D13CA.CDE4CDCHEN@mail.about.net.tw>
<199907251951.PAA03335@candle.pha.pa.us>
Message-Id: <379DE98515E.5DD8CDCHEN@mail.cynix.com.tw>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="V2VkLCAyOCBKdWwgMTk5OSAwMToxNjo1MyArMDgwMA=="
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.25.04

--V2VkLCAyOCBKdWwgMTk5OSAwMToxNjo1MyArMDgwMA==
Content-Transfer-Encoding: Quoted-Printable
Content-Type: text/plain

=a6b Sun, 25 Jul 1999 15:51:18 -0400 (EDT) =a8=ba=a4=d1=ae=c9=a1ABruce Momj=
ian <maillist@candle.pha.pa.us> =bcg=b9D:

First, the attached patch was zero length. Second, I am not sure what
this patch was supposed to do. I am not sure we could distribute a
patch for GNU C library as part of PostgreSQL.

oh~~ This is a mistake for me, say sorry to everyone~~ :b

And the attachment was be sent via this email again. :>

--
.....=3d=3d=3d=3d=3d=3d=3d............................. Cd Chen, (=b1=f8=
=bdX=bd=de)
..// =a1s =a1s |............................ =3d=3d=3d=3d=3d=3d=3d=3d=3d=
=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d
..|| =a2=dd =a2=dd <............................ What's Cynix? Cyber Linu=
x.
..|< > |............................ mailto:cdchen@mail.cynix.com.tw
..| | \___/ |............................ http://www.cynix.com.tw/~cdchen
.. |\______/............................. ICQ UIN:3345768

--V2VkLCAyOCBKdWwgMTk5OSAwMToxNjo1MyArMDgwMA==
Content-Type: application/octet-stream; name="MultiLang.patch"
Content-Disposition: attachment;
filename="MultiLang.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtdU5yIHBvc3RncmVzcWwtNi41LjEtb3JpZy9zcmMvYmluL3BnX2R1bXAvTWFrZWZpbGUu
aW4gcG9zdGdyZXNxbC02LjUuMS9zcmMvYmluL3BnX2R1bXAvTWFrZWZpbGUuaW4KLS0tIHBvc3Rn
cmVzcWwtNi41LjEtb3JpZy9zcmMvYmluL3BnX2R1bXAvTWFrZWZpbGUuaW4JU3VuIEphbiAxNyAx
NDoxOTowNSAxOTk5CisrKyBwb3N0Z3Jlc3FsLTYuNS4xL3NyYy9iaW4vcGdfZHVtcC9NYWtlZmls
ZS5pbglNb24gSnVsIDI2IDAxOjIwOjUwIDE5OTkKQEAgLTE4LDYgKzE4LDEwIEBACiAKIENGTEFH
Uys9IC1JJChMSUJQUURJUikKIAorUE9UU1JDRklMRT0gcGdfZHVtcC5jIHBnX2R1bXAuaCBjb21t
b24uYworCitQT1RPQkpGSUxFPSBwZ19kdW1wLnBvdAorCiAjCiAjIEFuZCB3aGVyZSBsaWJwcSBn
b2VzLCBzbyBnb2VzIHRoZSBhdXRoZW50aWNhdGlvbiBzdHVmZi4uLgogIwpAQCAtMjYsNyArMzAs
NyBAQAogQ0ZMQUdTKz0gJChLUkJGTEFHUykKIGVuZGlmCiAKLWFsbDogc3VibWFrZSBwZ19kdW1w
CithbGw6IHN1Ym1ha2UgcGdfZHVtcCBwb3QKIAogcGdfZHVtcDogJChPQkpTKSAkKExJQlBRRElS
KS9saWJwcS5hCiAJJChDQykgLW8gcGdfZHVtcCAtTCQoTElCUFFESVIpICQoT0JKUykgLWxwcSAk
KExERkxBR1MpCkBAIC00Niw4ICs1MCwxNCBAQAogZGVwZW5kIGRlcDoKIAkkKENDKSAtTU0gJChD
RkxBR1MpICouYyA+ZGVwZW5kCiAKLWNsZWFuOiAKK2NsZWFuOiBjbGVhbi1wb3QKIAlybSAtZiBw
Z19kdW1wJChYKSAkKE9CSlMpIAorCitjbGVhbi1wb3Q6CisJcm0gLWYgJChQT1RPQkpGSUxFKQor
Citwb3Q6CisJeGdldHRleHQgLUMgLS1rZXl3b3JkPSJfIiAtbyAkKFBPVE9CSkZJTEUpICQoUE9U
U1JDRklMRSkKIAogaWZlcSAoZGVwZW5kLCQod2lsZGNhcmQgZGVwZW5kKSkKIGluY2x1ZGUgZGVw
ZW5kCmRpZmYgLXVOciBwb3N0Z3Jlc3FsLTYuNS4xLW9yaWcvc3JjL2Jpbi9wZ19kdW1wL2NvbW1v
bi5jIHBvc3RncmVzcWwtNi41LjEvc3JjL2Jpbi9wZ19kdW1wL2NvbW1vbi5jCi0tLSBwb3N0Z3Jl
c3FsLTYuNS4xLW9yaWcvc3JjL2Jpbi9wZ19kdW1wL2NvbW1vbi5jCUZyaSBNYXkgMjggMDA6Mjk6
MDMgMTk5OQorKysgcG9zdGdyZXNxbC02LjUuMS9zcmMvYmluL3BnX2R1bXAvY29tbW9uLmMJU3Vu
IEp1bCAyNSAyMzo0OTozMCAxOTk5CkBAIC0zNiw2ICszNiwxMSBAQAogCiAjaW5jbHVkZSAicGdf
ZHVtcC5oIgogCisjaWZkZWYJVVNFX01VTFRJTEFORworI2RlZmluZQlQQUNLQUdFCSJwZ19kdW1w
IgorI2luY2x1ZGUgIm11bHRpbGFuZy5oIgorI2VuZGlmCisKIHN0YXRpYyBjaGFyICoqZmluZFBh
cmVudHNCeU9pZChUYWJsZUluZm8gKnRiaW5mbywgaW50IG51bVRhYmxlcywKIAkJCQkgSW5oSW5m
byAqaW5oaW5mbywgaW50IG51bUluaGVyaXRzLAogCQkJCSBjb25zdCBjaGFyICpvaWQsCkBAIC02
OSw3ICs3NCw3IEBACiAJfQogCiAJLyogc2hvdWxkIG5ldmVyIGdldCBoZXJlICovCi0JZnByaW50
ZihzdGRlcnIsICJmYWlsZWQgc2FuaXR5IGNoZWNrLCAgdHlwZSB3aXRoIG9pZCAlcyB3YXMgbm90
IGZvdW5kXG4iLAorCWZwcmludGYoc3RkZXJyLCBfKCJmYWlsZWQgc2FuaXR5IGNoZWNrLCAgdHlw
ZSB3aXRoIG9pZCAlcyB3YXMgbm90IGZvdW5kXG4iKSwKIAkJCW9pZCk7CiAJZXhpdCgyKTsKIH0K
QEAgLTk0LDcgKzk5LDcgQEAKIAl9CiAKIAkvKiBzaG91bGQgbmV2ZXIgZ2V0IGhlcmUgKi8KLQlm
cHJpbnRmKHN0ZGVyciwgImZhaWxlZCBzYW5pdHkgY2hlY2ssICBvcHIgd2l0aCBvaWQgJXMgd2Fz
IG5vdCBmb3VuZFxuIiwKKwlmcHJpbnRmKHN0ZGVyciwgXygiZmFpbGVkIHNhbml0eSBjaGVjaywg
IG9wciB3aXRoIG9pZCAlcyB3YXMgbm90IGZvdW5kXG4iKSwKIAkJCW9pZCk7CiAJZXhpdCgyKTsK
IH0KQEAgLTE0NCw3ICsxNDksNyBAQAogCQkJCXsKIAkJCQkJc2VsZkluZCA9IGZpbmRUYWJsZUJ5
T2lkKHRibGluZm8sIG51bVRhYmxlcywgb2lkKTsKIAkJCQkJZnByaW50ZihzdGRlcnIsCi0JCQkJ
CQkJImZhaWxlZCBzYW5pdHkgY2hlY2ssIHBhcmVudCBvaWQgJXMgb2YgdGFibGUgJXMgKG9pZCAl
cykgd2FzIG5vdCBmb3VuZFxuIiwKKwkJCQkJCQlfKCJmYWlsZWQgc2FuaXR5IGNoZWNrLCBwYXJl
bnQgb2lkICVzIG9mIHRhYmxlICVzIChvaWQgJXMpIHdhcyBub3QgZm91bmRcbiIpLAogCQkJCQkJ
CWluaGluZm9baV0uaW5ocGFyZW50LAogCQkJCQkJICAoc2VsZkluZCA+PSAwKSA/IHRibGluZm9b
c2VsZkluZF0ucmVsbmFtZSA6ICIiLAogCQkJCQkJCW9pZCk7CkBAIC0yNDgsNDkgKzI1Myw0OSBA
QAogCU9wckluZm8gICAgKm9wcmluZm8gPSBOVUxMOwogCiAJaWYgKGdfdmVyYm9zZSkKLQkJZnBy
aW50ZihzdGRlcnIsICIlcyByZWFkaW5nIHVzZXItZGVmaW5lZCB0eXBlcyAlc1xuIiwKKwkJZnBy
aW50ZihzdGRlcnIsIF8oIiVzIHJlYWRpbmcgdXNlci1kZWZpbmVkIHR5cGVzICVzXG4iKSwKIAkJ
CQlnX2NvbW1lbnRfc3RhcnQsIGdfY29tbWVudF9lbmQpOwogCXRpbmZvID0gZ2V0VHlwZXMoJm51
bVR5cGVzKTsKIAogCWlmIChnX3ZlcmJvc2UpCi0JCWZwcmludGYoc3RkZXJyLCAiJXMgcmVhZGlu
ZyB1c2VyLWRlZmluZWQgZnVuY3Rpb25zICVzXG4iLAorCQlmcHJpbnRmKHN0ZGVyciwgXygiJXMg
cmVhZGluZyB1c2VyLWRlZmluZWQgZnVuY3Rpb25zICVzXG4iKSwKIAkJCQlnX2NvbW1lbnRfc3Rh
cnQsIGdfY29tbWVudF9lbmQpOwogCWZpbmZvID0gZ2V0RnVuY3MoJm51bUZ1bmNzKTsKIAogCWlm
IChnX3ZlcmJvc2UpCi0JCWZwcmludGYoc3RkZXJyLCAiJXMgcmVhZGluZyB1c2VyLWRlZmluZWQg
YWdncmVnYXRlcyAlc1xuIiwKKwkJZnByaW50ZihzdGRlcnIsIF8oIiVzIHJlYWRpbmcgdXNlci1k
ZWZpbmVkIGFnZ3JlZ2F0ZXMgJXNcbiIpLAogCQkJCWdfY29tbWVudF9zdGFydCwgZ19jb21tZW50
X2VuZCk7CiAJYWdnaW5mbyA9IGdldEFnZ3JlZ2F0ZXMoJm51bUFnZ3JlZ2F0ZXMpOwogCiAJaWYg
KGdfdmVyYm9zZSkKLQkJZnByaW50ZihzdGRlcnIsICIlcyByZWFkaW5nIHVzZXItZGVmaW5lZCBv
cGVyYXRvcnMgJXNcbiIsCisJCWZwcmludGYoc3RkZXJyLCBfKCIlcyByZWFkaW5nIHVzZXItZGVm
aW5lZCBvcGVyYXRvcnMgJXNcbiIpLAogCQkJCWdfY29tbWVudF9zdGFydCwgZ19jb21tZW50X2Vu
ZCk7CiAJb3ByaW5mbyA9IGdldE9wZXJhdG9ycygmbnVtT3BlcmF0b3JzKTsKIAogCWlmIChnX3Zl
cmJvc2UpCi0JCWZwcmludGYoc3RkZXJyLCAiJXMgcmVhZGluZyB1c2VyLWRlZmluZWQgdGFibGVz
ICVzXG4iLAorCQlmcHJpbnRmKHN0ZGVyciwgXygiJXMgcmVhZGluZyB1c2VyLWRlZmluZWQgdGFi
bGVzICVzXG4iKSwKIAkJCQlnX2NvbW1lbnRfc3RhcnQsIGdfY29tbWVudF9lbmQpOwogCXRibGlu
Zm8gPSBnZXRUYWJsZXMoJm51bVRhYmxlcywgZmluZm8sIG51bUZ1bmNzKTsKIAogCWlmIChnX3Zl
cmJvc2UpCi0JCWZwcmludGYoc3RkZXJyLCAiJXMgcmVhZGluZyB0YWJsZSBpbmhlcml0YW5jZSBp
bmZvcm1hdGlvbiAlc1xuIiwKKwkJZnByaW50ZihzdGRlcnIsIF8oIiVzIHJlYWRpbmcgdGFibGUg
aW5oZXJpdGFuY2UgaW5mb3JtYXRpb24gJXNcbiIpLAogCQkJCWdfY29tbWVudF9zdGFydCwgZ19j
b21tZW50X2VuZCk7CiAJaW5oaW5mbyA9IGdldEluaGVyaXRzKCZudW1Jbmhlcml0cyk7CiAKIAlp
ZiAoZ192ZXJib3NlKQotCQlmcHJpbnRmKHN0ZGVyciwgIiVzIGZpbmRpbmcgdGhlIGF0dHJpYnV0
ZSBuYW1lcyBhbmQgdHlwZXMgZm9yIGVhY2ggdGFibGUgJXNcbiIsCisJCWZwcmludGYoc3RkZXJy
LCBfKCIlcyBmaW5kaW5nIHRoZSBhdHRyaWJ1dGUgbmFtZXMgYW5kIHR5cGVzIGZvciBlYWNoIHRh
YmxlICVzXG4iKSwKIAkJCQlnX2NvbW1lbnRfc3RhcnQsIGdfY29tbWVudF9lbmQpOwogCWdldFRh
YmxlQXR0cnModGJsaW5mbywgbnVtVGFibGVzKTsKIAogCWlmIChnX3ZlcmJvc2UpCi0JCWZwcmlu
dGYoc3RkZXJyLCAiJXMgZmxhZ2dpbmcgaW5oZXJpdGVkIGF0dHJpYnV0ZXMgaW4gc3VidGFibGVz
ICVzXG4iLAorCQlmcHJpbnRmKHN0ZGVyciwgXygiJXMgZmxhZ2dpbmcgaW5oZXJpdGVkIGF0dHJp
YnV0ZXMgaW4gc3VidGFibGVzICVzXG4iKSwKIAkJCQlnX2NvbW1lbnRfc3RhcnQsIGdfY29tbWVu
dF9lbmQpOwogCWZsYWdJbmhBdHRycyh0YmxpbmZvLCBudW1UYWJsZXMsIGluaGluZm8sIG51bUlu
aGVyaXRzKTsKIAogCWlmICghdGFibGVuYW1lICYmIGZvdXQpCiAJewogCQlpZiAoZ192ZXJib3Nl
KQotCQkJZnByaW50ZihzdGRlcnIsICIlcyBkdW1waW5nIG91dCB1c2VyLWRlZmluZWQgdHlwZXMg
JXNcbiIsCisJCQlmcHJpbnRmKHN0ZGVyciwgXygiJXMgZHVtcGluZyBvdXQgdXNlci1kZWZpbmVk
IHR5cGVzICVzXG4iKSwKIAkJCQkJZ19jb21tZW50X3N0YXJ0LCBnX2NvbW1lbnRfZW5kKTsKIAkJ
ZHVtcFR5cGVzKGZvdXQsIGZpbmZvLCBudW1GdW5jcywgdGluZm8sIG51bVR5cGVzKTsKIAl9CkBA
IC0yOTgsNyArMzAzLDcgQEAKIAlpZiAoZm91dCkKIAl7CiAJCWlmIChnX3ZlcmJvc2UpCi0JCQlm
cHJpbnRmKHN0ZGVyciwgIiVzIGR1bXBpbmcgb3V0IHRhYmxlcyAlc1xuIiwKKwkJCWZwcmludGYo
c3RkZXJyLCBfKCIlcyBkdW1waW5nIG91dCB0YWJsZXMgJXNcbiIpLAogCQkJCQlnX2NvbW1lbnRf
c3RhcnQsIGdfY29tbWVudF9lbmQpOwogCQlkdW1wVGFibGVzKGZvdXQsIHRibGluZm8sIG51bVRh
YmxlcywgaW5oaW5mbywgbnVtSW5oZXJpdHMsCiAJCQkJICAgdGluZm8sIG51bVR5cGVzLCB0YWJs
ZW5hbWUsIGFjbHNTa2lwKTsKQEAgLTMwNyw3ICszMTIsNyBAQAogCWlmICghdGFibGVuYW1lICYm
IGZvdXQpCiAJewogCQlpZiAoZ192ZXJib3NlKQotCQkJZnByaW50ZihzdGRlcnIsICIlcyBkdW1w
aW5nIG91dCB1c2VyLWRlZmluZWQgcHJvY2VkdXJhbCBsYW5ndWFnZXMgJXNcbiIsCisJCQlmcHJp
bnRmKHN0ZGVyciwgXygiJXMgZHVtcGluZyBvdXQgdXNlci1kZWZpbmVkIHByb2NlZHVyYWwgbGFu
Z3VhZ2VzICVzXG4iKSwKIAkJCQkJZ19jb21tZW50X3N0YXJ0LCBnX2NvbW1lbnRfZW5kKTsKIAkJ
ZHVtcFByb2NMYW5ncyhmb3V0LCBmaW5mbywgbnVtRnVuY3MsIHRpbmZvLCBudW1UeXBlcyk7CiAJ
fQpAQCAtMzE1LDcgKzMyMCw3IEBACiAJaWYgKCF0YWJsZW5hbWUgJiYgZm91dCkKIAl7CiAJCWlm
IChnX3ZlcmJvc2UpCi0JCQlmcHJpbnRmKHN0ZGVyciwgIiVzIGR1bXBpbmcgb3V0IHVzZXItZGVm
aW5lZCBmdW5jdGlvbnMgJXNcbiIsCisJCQlmcHJpbnRmKHN0ZGVyciwgXygiJXMgZHVtcGluZyBv
dXQgdXNlci1kZWZpbmVkIGZ1bmN0aW9ucyAlc1xuIiksCiAJCQkJCWdfY29tbWVudF9zdGFydCwg
Z19jb21tZW50X2VuZCk7CiAJCWR1bXBGdW5jcyhmb3V0LCBmaW5mbywgbnVtRnVuY3MsIHRpbmZv
LCBudW1UeXBlcyk7CiAJfQpAQCAtMzIzLDcgKzMyOCw3IEBACiAJaWYgKCF0YWJsZW5hbWUgJiYg
Zm91dCkKIAl7CiAJCWlmIChnX3ZlcmJvc2UpCi0JCQlmcHJpbnRmKHN0ZGVyciwgIiVzIGR1bXBp
bmcgb3V0IHVzZXItZGVmaW5lZCBhZ2dyZWdhdGVzICVzXG4iLAorCQkJZnByaW50ZihzdGRlcnIs
IF8oIiVzIGR1bXBpbmcgb3V0IHVzZXItZGVmaW5lZCBhZ2dyZWdhdGVzICVzXG4iKSwKIAkJCQkJ
Z19jb21tZW50X3N0YXJ0LCBnX2NvbW1lbnRfZW5kKTsKIAkJZHVtcEFnZ3MoZm91dCwgYWdnaW5m
bywgbnVtQWdncmVnYXRlcywgdGluZm8sIG51bVR5cGVzKTsKIAl9CkBAIC0zMzEsNyArMzM2LDcg
QEAKIAlpZiAoIXRhYmxlbmFtZSAmJiBmb3V0KQogCXsKIAkJaWYgKGdfdmVyYm9zZSkKLQkJCWZw
cmludGYoc3RkZXJyLCAiJXMgZHVtcGluZyBvdXQgdXNlci1kZWZpbmVkIG9wZXJhdG9ycyAlc1xu
IiwKKwkJCWZwcmludGYoc3RkZXJyLCBfKCIlcyBkdW1waW5nIG91dCB1c2VyLWRlZmluZWQgb3Bl
cmF0b3JzICVzXG4iKSwKIAkJCQkJZ19jb21tZW50X3N0YXJ0LCBnX2NvbW1lbnRfZW5kKTsKIAkJ
ZHVtcE9wcnMoZm91dCwgb3ByaW5mbywgbnVtT3BlcmF0b3JzLCB0aW5mbywgbnVtVHlwZXMpOwog
CX0KQEAgLTM1OSwxNCArMzY0LDE0IEBACiAJSW5kSW5mbyAgICAqaW5kaW5mbzsKIAogCWlmIChn
X3ZlcmJvc2UpCi0JCWZwcmludGYoc3RkZXJyLCAiJXMgcmVhZGluZyBpbmRpY2VzIGluZm9ybWF0
aW9uICVzXG4iLAorCQlmcHJpbnRmKHN0ZGVyciwgXygiJXMgcmVhZGluZyBpbmRpY2VzIGluZm9y
bWF0aW9uICVzXG4iKSwKIAkJCQlnX2NvbW1lbnRfc3RhcnQsIGdfY29tbWVudF9lbmQpOwogCWlu
ZGluZm8gPSBnZXRJbmRpY2VzKCZudW1JbmRpY2VzKTsKIAogCWlmIChmb3V0KQogCXsKIAkJaWYg
KGdfdmVyYm9zZSkKLQkJCWZwcmludGYoc3RkZXJyLCAiJXMgZHVtcGluZyBvdXQgaW5kaWNlcyAl
c1xuIiwKKwkJCWZwcmludGYoc3RkZXJyLCBfKCIlcyBkdW1waW5nIG91dCBpbmRpY2VzICVzXG4i
KSwKIAkJCQkJZ19jb21tZW50X3N0YXJ0LCBnX2NvbW1lbnRfZW5kKTsKIAkJZHVtcEluZGljZXMo
Zm91dCwgaW5kaW5mbywgbnVtSW5kaWNlcywgdGJsaW5mbywgbnVtVGFibGVzLCB0YWJsZW5hbWUp
OwogCX0KQEAgLTQwOSw3ICs0MTQsNyBAQAogCQkJaWYgKHBhcmVudEluZCA8IDApCiAJCQl7CiAJ
CQkJLyogc2hvdWxkbid0IGhhcHBlbiB1bmxlc3MgZmluZFBhcmVudHNCeU9pZCBpcyBicm9rZW4g
Ki8KLQkJCQlmcHJpbnRmKHN0ZGVyciwgImZhaWxlZCBzYW5pdHkgY2hlY2ssIHRhYmxlICVzIG5v
dCBmb3VuZCBieSBmbGFnSW5oQXR0cnNcbiIsCisJCQkJZnByaW50ZihzdGRlcnIsIF8oImZhaWxl
ZCBzYW5pdHkgY2hlY2ssIHRhYmxlICVzIG5vdCBmb3VuZCBieSBmbGFnSW5oQXR0cnNcbiIpLAog
CQkJCQkJdGJsaW5mb1tpXS5wYXJlbnRSZWxzW2tdKTsKIAkJCQlleGl0KDIpOwogCQkJfQpkaWZm
IC11TnIgcG9zdGdyZXNxbC02LjUuMS1vcmlnL3NyYy9iaW4vcGdfZHVtcC9wZ19kdW1wLmMgcG9z
dGdyZXNxbC02LjUuMS9zcmMvYmluL3BnX2R1bXAvcGdfZHVtcC5jCi0tLSBwb3N0Z3Jlc3FsLTYu
NS4xLW9yaWcvc3JjL2Jpbi9wZ19kdW1wL3BnX2R1bXAuYwlUaHUgSnVuICAzIDEyOjAxOjE2IDE5
OTkKKysrIHBvc3RncmVzcWwtNi41LjEvc3JjL2Jpbi9wZ19kdW1wL3BnX2R1bXAuYwlNb24gSnVs
IDI2IDAxOjExOjU0IDE5OTkKQEAgLTgyLDYgKzgyLDExIEBACiAKICNpbmNsdWRlICJwZ19kdW1w
LmgiCiAKKyNpZmRlZiBVU0VfTVVMVElMQU5HCisjZGVmaW5lCVBBQ0tBR0UJInBnX2R1bXAiCisj
aW5jbHVkZSAibXVsdGlsYW5nLmgiCisjZW5kaWYKKwogc3RhdGljIHZvaWQgZHVtcFNlcXVlbmNl
KEZJTEUgKmZvdXQsIFRhYmxlSW5mbyB0YmluZm8pOwogc3RhdGljIHZvaWQgZHVtcEFDTChGSUxF
ICpmb3V0LCBUYWJsZUluZm8gdGJpbmZvKTsKIHN0YXRpYyB2b2lkIGR1bXBUcmlnZ2VycyhGSUxF
ICpmb3V0LCBjb25zdCBjaGFyICp0YWJsZW5hbWUsCkBAIC0xMzAsNDEgKzEzNSw0MSBAQAogdXNh
Z2UoY29uc3QgY2hhciAqcHJvZ25hbWUpCiB7CiAJZnByaW50ZihzdGRlcnIsCi0JCQkidXNhZ2U6
ICAlcyBbb3B0aW9uc10gZGJuYW1lXG4iLCBwcm9nbmFtZSk7CisJCQlfKCJ1c2FnZTogICVzIFtv
cHRpb25zXSBkYm5hbWVcbiIpLCBwcm9nbmFtZSk7CiAJZnByaW50ZihzdGRlcnIsCi0JCQkiXHQg
LWEgICAgICAgICAgXHRcdCBkdW1wIG91dCBvbmx5IHRoZSBkYXRhLCBubyBzY2hlbWFcbiIpOwor
CQkJXygiXHQgLWEgICAgICAgICAgXHRcdCBkdW1wIG91dCBvbmx5IHRoZSBkYXRhLCBubyBzY2hl
bWFcbiIpKTsKIAlmcHJpbnRmKHN0ZGVyciwKLQkJCSJcdCAtYyAgICAgICAgICBcdFx0IGNsZWFu
KGRyb3ApIHNjaGVtYSBwcmlvciB0byBjcmVhdGVcbiIpOworCQkJXygiXHQgLWMgICAgICAgICAg
XHRcdCBjbGVhbihkcm9wKSBzY2hlbWEgcHJpb3IgdG8gY3JlYXRlXG4iKSk7CiAJZnByaW50Zihz
dGRlcnIsCi0JCQkiXHQgLWQgICAgICAgICAgXHRcdCBkdW1wIGRhdGEgYXMgcHJvcGVyIGluc2Vy
dCBzdHJpbmdzXG4iKTsKKwkJCV8oIlx0IC1kICAgICAgICAgIFx0XHQgZHVtcCBkYXRhIGFzIHBy
b3BlciBpbnNlcnQgc3RyaW5nc1xuIikpOwogCWZwcmludGYoc3RkZXJyLAotCQkJIlx0IC1EICAg
ICAgICAgIFx0XHQgZHVtcCBkYXRhIGFzIGluc2VydHMiCi0JCQkiIHdpdGggYXR0cmlidXRlIG5h
bWVzXG4iKTsKKwkJCV8oIlx0IC1EICAgICAgICAgIFx0XHQgZHVtcCBkYXRhIGFzIGluc2VydHMi
CisJCQkiIHdpdGggYXR0cmlidXRlIG5hbWVzXG4iKSk7CiAJZnByaW50ZihzdGRlcnIsCi0JCQki
XHQgLWYgZmlsZW5hbWUgXHRcdCBzY3JpcHQgb3V0cHV0IGZpbGVuYW1lXG4iKTsKKwkJCV8oIlx0
IC1mIGZpbGVuYW1lIFx0XHQgc2NyaXB0IG91dHB1dCBmaWxlbmFtZVxuIikpOwogCWZwcmludGYo
c3RkZXJyLAotCQkJIlx0IC1oIGhvc3RuYW1lIFx0XHQgc2VydmVyIGhvc3QgbmFtZVxuIik7CisJ
CQlfKCJcdCAtaCBob3N0bmFtZSBcdFx0IHNlcnZlciBob3N0IG5hbWVcbiIpKTsKIAlmcHJpbnRm
KHN0ZGVyciwKLQkJIlx0IC1uICAgICAgICAgIFx0XHQgc3VwcHJlc3MgbW9zdCBxdW90ZXMgYXJv
dW5kIGlkZW50aWZpZXJzXG4iKTsKKwkJXygiXHQgLW4gICAgICAgICAgXHRcdCBzdXBwcmVzcyBt
b3N0IHF1b3RlcyBhcm91bmQgaWRlbnRpZmllcnNcbiIpKTsKIAlmcHJpbnRmKHN0ZGVyciwKLQkJ
ICAiXHQgLU4gICAgICAgICAgXHRcdCBlbmFibGUgbW9zdCBxdW90ZXMgYXJvdW5kIGlkZW50aWZp
ZXJzXG4iKTsKKwkJICBfKCJcdCAtTiAgICAgICAgICBcdFx0IGVuYWJsZSBtb3N0IHF1b3RlcyBh
cm91bmQgaWRlbnRpZmllcnNcbiIpKTsKIAlmcHJpbnRmKHN0ZGVyciwKLQkJCSJcdCAtbyAgICAg
ICAgICBcdFx0IGR1bXAgb2JqZWN0IGlkJ3MgKG9pZHMpXG4iKTsKKwkJCV8oIlx0IC1vICAgICAg
ICAgIFx0XHQgZHVtcCBvYmplY3QgaWQncyAob2lkcylcbiIpKTsKIAlmcHJpbnRmKHN0ZGVyciwK
LQkJCSJcdCAtcCBwb3J0ICAgICBcdFx0IHNlcnZlciBwb3J0IG51bWJlclxuIik7CisJCQlfKCJc
dCAtcCBwb3J0ICAgICBcdFx0IHNlcnZlciBwb3J0IG51bWJlclxuIikpOwogCWZwcmludGYoc3Rk
ZXJyLAotCQkJIlx0IC1zICAgICAgICAgIFx0XHQgZHVtcCBvdXQgb25seSB0aGUgc2NoZW1hLCBu
byBkYXRhXG4iKTsKKwkJCV8oIlx0IC1zICAgICAgICAgIFx0XHQgZHVtcCBvdXQgb25seSB0aGUg
c2NoZW1hLCBubyBkYXRhXG4iKSk7CiAJZnByaW50ZihzdGRlcnIsCi0JCQkiXHQgLXQgdGFibGUg
ICAgXHRcdCBkdW1wIGZvciB0aGlzIHRhYmxlIG9ubHlcbiIpOworCQkJXygiXHQgLXQgdGFibGUg
ICAgXHRcdCBkdW1wIGZvciB0aGlzIHRhYmxlIG9ubHlcbiIpKTsKIAlmcHJpbnRmKHN0ZGVyciwK
LQkJCSJcdCAtdSAgICAgICAgICBcdFx0IHVzZSBwYXNzd29yZCBhdXRoZW50aWNhdGlvblxuIik7
CisJCQlfKCJcdCAtdSAgICAgICAgICBcdFx0IHVzZSBwYXNzd29yZCBhdXRoZW50aWNhdGlvblxu
IikpOwogCWZwcmludGYoc3RkZXJyLAotCQkJIlx0IC12ICAgICAgICAgIFx0XHQgdmVyYm9zZVxu
Iik7CisJCQlfKCJcdCAtdiAgICAgICAgICBcdFx0IHZlcmJvc2VcbiIpKTsKIAlmcHJpbnRmKHN0
ZGVyciwKLQkJCSJcdCAteiAgICAgICAgICBcdFx0IGR1bXAgQUNMcyAoZ3JhbnQvcmV2b2tlKVxu
Iik7CisJCQlfKCJcdCAteiAgICAgICAgICBcdFx0IGR1bXAgQUNMcyAoZ3JhbnQvcmV2b2tlKVxu
IikpOwogCWZwcmludGYoc3RkZXJyLAotCQkJIlxuSWYgZGJuYW1lIGlzIG5vdCBzdXBwbGllZCwg
dGhlbiB0aGUgREFUQUJBU0UgZW52aXJvbm1lbnQgIgotCQkJInZhcmlhYmxlIHZhbHVlIGlzIHVz
ZWQuXG4iKTsKKwkJCV8oIlxuSWYgZGJuYW1lIGlzIG5vdCBzdXBwbGllZCwgdGhlbiB0aGUgREFU
QUJBU0UgZW52aXJvbm1lbnQgIgorCQkJInZhcmlhYmxlIHZhbHVlIGlzIHVzZWQuXG4iKSk7CiAJ
ZnByaW50ZihzdGRlcnIsICJcbiIpOwogCiAJZXhpdCgxKTsKQEAgLTE5OSw3ICsyMDQsNyBAQAog
CWlmICghcmVzIHx8CiAJCVBRcmVzdWx0U3RhdHVzKHJlcykgIT0gUEdSRVNfVFVQTEVTX09LKQog
CXsKLQkJZnByaW50ZihzdGRlcnIsICJpc1ZpZXdSdWxlKCk6IFNFTEVDVCBmYWlsZWQuICBFeHBs
YW5hdGlvbiBmcm9tIGJhY2tlbmQ6ICclcycuXG4iLCBQUWVycm9yTWVzc2FnZShnX2Nvbm4pKTsK
KwkJZnByaW50ZihzdGRlcnIsIF8oImlzVmlld1J1bGUoKTogU0VMRUNUIGZhaWxlZC4gIEV4cGxh
bmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIpLCBQUWVycm9yTWVzc2FnZShnX2Nvbm4pKTsK
IAkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAl9CiAKQEAgLTIzOCw5ICsyNDMsOSBAQAogCWlmICgh
cmVzIHx8CiAJCVBRcmVzdWx0U3RhdHVzKHJlcykgPT0gUEdSRVNfRkFUQUxfRVJST1IpCiAJewot
CQlmcHJpbnRmKHN0ZGVyciwgIlNRTCBxdWVyeSB0byBkdW1wIHRoZSBjb250ZW50cyBvZiBUYWJs
ZSAnJXMnICIKKwkJZnByaW50ZihzdGRlcnIsIF8oIlNRTCBxdWVyeSB0byBkdW1wIHRoZSBjb250
ZW50cyBvZiBUYWJsZSAnJXMnICIKIAkJCQkiZGlkIG5vdCBleGVjdXRlLiAgRXhwbGFuYXRpb24g
ZnJvbSBiYWNrZW5kOiAnJXMnLlxuIgotCQkJCSJUaGUgcXVlcnkgd2FzOiAnJXMnLlxuIiwKKwkJ
CQkiVGhlIHF1ZXJ5IHdhczogJyVzJy5cbiIpLAogCQkJCWNsYXNzbmFtZSwgUFFlcnJvck1lc3Nh
Z2UoZ19jb25uKSwgcXVlcnkpOwogCQlleGl0X25pY2VseShnX2Nvbm4pOwogCX0KQEAgLTI0OCwx
MCArMjUzLDEwIEBACiAJewogCQlpZiAoUFFyZXN1bHRTdGF0dXMocmVzKSAhPSBQR1JFU19DT1BZ
X09VVCkKIAkJewotCQkJZnByaW50ZihzdGRlcnIsICJTUUwgcXVlcnkgdG8gZHVtcCB0aGUgY29u
dGVudHMgb2YgVGFibGUgJyVzJyAiCisJCQlmcHJpbnRmKHN0ZGVyciwgXygiU1FMIHF1ZXJ5IHRv
IGR1bXAgdGhlIGNvbnRlbnRzIG9mIFRhYmxlICclcycgIgogCQkJCQkiZXhlY3V0ZWQgYWJub3Jt
YWxseS5cbiIKIAkJCQkJIlBRZXhlYygpIHJldHVybmVkIHN0YXR1cyAlZCB3aGVuICVkIHdhcyBl
eHBlY3RlZC5cbiIKLQkJCQkJIlRoZSBxdWVyeSB3YXM6ICclcycuXG4iLAorCQkJCQkiVGhlIHF1
ZXJ5IHdhczogJyVzJy5cbiIpLAogCQkJCSAgY2xhc3NuYW1lLCBQUXJlc3VsdFN0YXR1cyhyZXMp
LCBQR1JFU19DT1BZX09VVCwgcXVlcnkpOwogCQkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAkJfQpA
QCAtMjg5LDExICsyOTQsMTEgQEAKIAkJcmV0ID0gUFFlbmRjb3B5KGdfY29ubik7CiAJCWlmIChy
ZXQgIT0gMCkKIAkJewotCQkJZnByaW50ZihzdGRlcnIsICJTUUwgcXVlcnkgdG8gZHVtcCB0aGUg
Y29udGVudHMgb2YgVGFibGUgJyVzJyAiCisJCQlmcHJpbnRmKHN0ZGVyciwgXygiU1FMIHF1ZXJ5
IHRvIGR1bXAgdGhlIGNvbnRlbnRzIG9mIFRhYmxlICclcycgIgogCQkJCQkiZGlkIG5vdCBleGVj
dXRlIGNvcnJlY3RseS4gIEFmdGVyIHdlIHJlYWQgYWxsIHRoZSAiCiAJCQkJICJ0YWJsZSBjb250
ZW50cyBmcm9tIHRoZSBiYWNrZW5kLCBQUWVuZGNvcHkoKSBmYWlsZWQuICAiCiAJCQkJCSJFeHBs
YW5hdGlvbiBmcm9tIGJhY2tlbmQ6ICclcycuXG4iCi0JCQkJCSJUaGUgcXVlcnkgd2FzOiAnJXMn
LlxuIiwKKwkJCQkJIlRoZSBxdWVyeSB3YXM6ICclcycuXG4iKSwKIAkJCQkJY2xhc3NuYW1lLCBQ
UWVycm9yTWVzc2FnZShnX2Nvbm4pLCBxdWVyeSk7CiAJCQlQUWNsZWFyKHJlcyk7CiAJCQlleGl0
X25pY2VseShnX2Nvbm4pOwpAQCAtMzE4LDcgKzMyMyw3IEBACiAJaWYgKCFyZXMgfHwKIAkJUFFy
ZXN1bHRTdGF0dXMocmVzKSAhPSBQR1JFU19UVVBMRVNfT0spCiAJewotCQlmcHJpbnRmKHN0ZGVy
ciwgImR1bXBDbGFzc2VzKCk6IGNvbW1hbmQgZmFpbGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNr
ZW5kOiAnJXMnLlxuIiwgUFFlcnJvck1lc3NhZ2UoZ19jb25uKSk7CisJCWZwcmludGYoc3RkZXJy
LCBfKCJkdW1wQ2xhc3NlcygpOiBjb21tYW5kIGZhaWxlZC4gIEV4cGxhbmF0aW9uIGZyb20gYmFj
a2VuZDogJyVzJy5cbiIpLCBQUWVycm9yTWVzc2FnZShnX2Nvbm4pKTsKIAkJZXhpdF9uaWNlbHko
Z19jb25uKTsKIAl9CiAJZm9yICh0dXBsZSA9IDA7IHR1cGxlIDwgUFFudHVwbGVzKHJlcyk7IHR1
cGxlKyspCkBAIC00MTUsNyArNDIwLDcgQEAKIAkJYWxsX29ubHkgPSAib25seSI7CiAKIAlpZiAo
Z192ZXJib3NlKQotCQlmcHJpbnRmKHN0ZGVyciwgIiVzIGR1bXBpbmcgb3V0IHRoZSBjb250ZW50
cyBvZiAlcyAlZCB0YWJsZSVzL3NlcXVlbmNlJXMgJXNcbiIsCisJCWZwcmludGYoc3RkZXJyLCBf
KCIlcyBkdW1waW5nIG91dCB0aGUgY29udGVudHMgb2YgJXMgJWQgdGFibGUlcy9zZXF1ZW5jZSVz
ICVzXG4iKSwKIAkJCQlnX2NvbW1lbnRfc3RhcnQsIGFsbF9vbmx5LAogCQkJCShvbmx5dGFibGUg
PT0gTlVMTCkgPyBudW1UYWJsZXMgOiAxLAogCQkJCShvbmx5dGFibGUgPT0gTlVMTCkgPyAicyIg
OiAiIiwgKG9ubHl0YWJsZSA9PSBOVUxMKSA/ICJzIiA6ICIiLApAQCAtNDMxLDcgKzQzNiw3IEBA
CiAJCQlpZiAoIW9ubHl0YWJsZSB8fCAoIXN0cmNtcCh0YmxpbmZvW2ldLnJlbG5hbWUsIG9ubHl0
YWJsZSkpKQogCQkJewogCQkJCWlmIChnX3ZlcmJvc2UpCi0JCQkJCWZwcmludGYoc3RkZXJyLCAi
JXMgZHVtcGluZyBvdXQgc2NoZW1hIG9mIHNlcXVlbmNlICclcycgJXNcbiIsCisJCQkJCWZwcmlu
dGYoc3RkZXJyLCBfKCIlcyBkdW1waW5nIG91dCBzY2hlbWEgb2Ygc2VxdWVuY2UgJyVzJyAlc1xu
IiksCiAJCQkJCSBnX2NvbW1lbnRfc3RhcnQsIHRibGluZm9baV0ucmVsbmFtZSwgZ19jb21tZW50
X2VuZCk7CiAJCQkJYmVjb21lVXNlcihmb3V0LCB0YmxpbmZvW2ldLnVzZW5hbWUpOwogCQkJCWR1
bXBTZXF1ZW5jZShmb3V0LCB0YmxpbmZvW2ldKTsKQEAgLTQ1Myw3ICs0NTgsNyBAQAogCQlpZiAo
IW9ubHl0YWJsZSB8fCAoIXN0cmNtcChjbGFzc25hbWUsIG9ubHl0YWJsZSkpKQogCQl7CiAJCQlp
ZiAoZ192ZXJib3NlKQotCQkJCWZwcmludGYoc3RkZXJyLCAiJXMgZHVtcGluZyBvdXQgdGhlIGNv
bnRlbnRzIG9mIFRhYmxlICclcycgJXNcbiIsCisJCQkJZnByaW50ZihzdGRlcnIsIF8oIiVzIGR1
bXBpbmcgb3V0IHRoZSBjb250ZW50cyBvZiBUYWJsZSAnJXMnICVzXG4iKSwKIAkJCQkJCWdfY29t
bWVudF9zdGFydCwgY2xhc3NuYW1lLCBnX2NvbW1lbnRfZW5kKTsKIAogCQkJYmVjb21lVXNlcihm
b3V0LCB0YmxpbmZvW2ldLnVzZW5hbWUpOwpAQCAtNDkzLDcgKzQ5OCw3IEBACiAJaWYgKGxlbmd0
aCA+IDAgJiYgdXNlcm5hbWVbbGVuZ3RoIC0gMV0gPT0gJ1xuJykKIAkJdXNlcm5hbWVbbGVuZ3Ro
IC0gMV0gPSAnXDAnOwogCi0JcHJpbnRmKCJQYXNzd29yZDogIik7CisJcHJpbnRmKF8oIlBhc3N3
b3JkOiAiKSk7CiAjaWZkZWYgSEFWRV9URVJNSU9TX0gKIAl0Y2dldGF0dHIoMCwgJnQpOwogCXRf
b3JpZyA9IHQ7CkBAIC01NDAsNiArNTQ1LDEwIEBACiAJY2hhcgkJcGFzc3dvcmRbMTAwXTsKIAli
b29sCQl1c2VfcGFzc3dvcmQgPSBmYWxzZTsKIAorI2lmZGVmCVVTRV9NVUxUSUxBTkcKKwlJbml0
TXVsdGlMYW5nKFBBQ0tBR0UsIExPQ0FMRURJUik7CisjZW5kaWYKKwogCWdfdmVyYm9zZSA9IGZh
bHNlOwogCWZvcmNlX3F1b3RlcyA9IHRydWU7CiAJZHJvcFNjaGVtYSA9IGZhbHNlOwpAQCAtNjMw
LDcgKzYzOSw3IEBACiAJCQkJYnJlYWs7CiAJCQljYXNlICd6JzoJCQkvKiBPbGQgQUNMIG9wdGlv
biBiam0gMTk5OS8wNS8yNyAqLwogCQkJCWZwcmludGYoc3RkZXJyLAotCQkJCSAiJXM6IFRoZSAt
eiBvcHRpb24oZHVtcCBBQ0xzKSBpcyBub3cgdGhlIGRlZmF1bHQsIGNvbnRpbnVpbmcuXG4iLAor
CQkJCSBfKCIlczogVGhlIC16IG9wdGlvbihkdW1wIEFDTHMpIGlzIG5vdyB0aGUgZGVmYXVsdCwg
Y29udGludWluZy5cbiIpLAogCQkJCQlwcm9nbmFtZSk7CiAJCQkJYnJlYWs7CiAJCQlkZWZhdWx0
OgpAQCAtNjQyLDcgKzY1MSw3IEBACiAJaWYgKGR1bXBEYXRhID09IHRydWUgJiYgb2lkcyA9PSB0
cnVlKQogCXsKIAkJZnByaW50ZihzdGRlcnIsCi0JCQkgIiVzOiBJTlNFUlQncyBjYW4gbm90IHNl
dCBvaWRzLCBzbyBJTlNFUlQgYW5kIE9JRCBvcHRpb25zIGNhbiBub3QgYmUgdXNlZCB0b2dldGhl
ci5cbiIsCisJCQkgXygiJXM6IElOU0VSVCdzIGNhbiBub3Qgc2V0IG9pZHMsIHNvIElOU0VSVCBh
bmQgT0lEIG9wdGlvbnMgY2FuIG5vdCBiZSB1c2VkIHRvZ2V0aGVyLlxuIiksCiAJCQkJcHJvZ25h
bWUpOwogCQlleGl0KDIpOwogCX0KQEAgLTY2MCw3ICs2NjksNyBAQAogCQlpZiAoZ19mb3V0ID09
IE5VTEwpCiAJCXsKIAkJCWZwcmludGYoc3RkZXJyLAotCQkJCSAiJXM6IGNvdWxkIG5vdCBvcGVu
IG91dHB1dCBmaWxlIG5hbWVkICVzIGZvciB3cml0aW5nXG4iLAorCQkJCV8oIiVzOiBjb3VsZCBu
b3Qgb3BlbiBvdXRwdXQgZmlsZSBuYW1lZCAlcyBmb3Igd3JpdGluZ1xuIiksCiAJCQkJCXByb2du
YW1lLCBmaWxlbmFtZSk7CiAJCQlleGl0KDIpOwogCQl9CkBAIC02NzAsNyArNjc5LDcgQEAKIAlp
ZiAoIShkYm5hbWUgPSBhcmd2W29wdGluZF0pICYmCiAJCSEoZGJuYW1lID0gZ2V0ZW52KCJEQVRB
QkFTRSIpKSkKIAl7Ci0JCWZwcmludGYoc3RkZXJyLCAiJXM6IG5vIGRhdGFiYXNlIG5hbWUgc3Bl
Y2lmaWVkXG4iLCBwcm9nbmFtZSk7CisJCWZwcmludGYoc3RkZXJyLCBfKCIlczogbm8gZGF0YWJh
c2UgbmFtZSBzcGVjaWZpZWRcbiIpLCBwcm9nbmFtZSk7CiAJCWV4aXQoMik7CiAJfQogCkBAIC03
MDYsNyArNzE1LDcgQEAKIAkvKiBjaGVjayB0byBzZWUgdGhhdCB0aGUgYmFja2VuZCBjb25uZWN0
aW9uIHdhcyBzdWNjZXNzZnVsbHkgbWFkZSAqLwogCWlmIChQUXN0YXR1cyhnX2Nvbm4pID09IENP
Tk5FQ1RJT05fQkFEKQogCXsKLQkJZnByaW50ZihzdGRlcnIsICJDb25uZWN0aW9uIHRvIGRhdGFi
YXNlICclcycgZmFpbGVkLlxuIiwgZGJuYW1lKTsKKwkJZnByaW50ZihzdGRlcnIsIF8oIkNvbm5l
Y3Rpb24gdG8gZGF0YWJhc2UgJyVzJyBmYWlsZWQuXG4iKSwgZGJuYW1lKTsKIAkJZnByaW50Zihz
dGRlcnIsICIlc1xuIiwgUFFlcnJvck1lc3NhZ2UoZ19jb25uKSk7CiAJCWV4aXRfbmljZWx5KGdf
Y29ubik7CiAJfQpAQCAtNzIwLDE0ICs3MjksMTQgQEAKIAkJcmVzID0gUFFleGVjKGdfY29ubiwg
ImJlZ2luIik7CiAJCWlmICghcmVzIHx8IFBRcmVzdWx0U3RhdHVzKHJlcykgIT0gUEdSRVNfQ09N
TUFORF9PSykKIAkJewotCQkJZnByaW50ZihzdGRlcnIsICJCRUdJTiBjb21tYW5kIGZhaWxlZC4g
IEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIsIFBRZXJyb3JNZXNzYWdlKGdfY29u
bikpOworCQkJZnByaW50ZihzdGRlcnIsIF8oIkJFR0lOIGNvbW1hbmQgZmFpbGVkLiAgRXhwbGFu
YXRpb24gZnJvbSBiYWNrZW5kOiAnJXMnLlxuIiksIFBRZXJyb3JNZXNzYWdlKGdfY29ubikpOwog
CQkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAkJfQogCQlQUWNsZWFyKHJlcyk7CiAJCXJlcyA9IFBR
ZXhlYyhnX2Nvbm4sICJzZXQgdHJhbnNhY3Rpb24gaXNvbGF0aW9uIGxldmVsIHNlcmlhbGl6YWJs
ZSIpOwogCQlpZiAoIXJlcyB8fCBQUXJlc3VsdFN0YXR1cyhyZXMpICE9IFBHUkVTX0NPTU1BTkRf
T0spCiAJCXsKLQkJCWZwcmludGYoc3RkZXJyLCAiU0VUIFRSQU5TQUNUSU9OIGNvbW1hbmQgZmFp
bGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5kOiAnJXMnLlxuIiwgUFFlcnJvck1lc3NhZ2Uo
Z19jb25uKSk7CisJCQlmcHJpbnRmKHN0ZGVyciwgXygiU0VUIFRSQU5TQUNUSU9OIGNvbW1hbmQg
ZmFpbGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5kOiAnJXMnLlxuIiksIFBRZXJyb3JNZXNz
YWdlKGdfY29ubikpOwogCQkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAkJfQogCQlQUWNsZWFyKHJl
cyk7CkBAIC03NDAsNyArNzQ5LDcgQEAKIAlpZiAoIWRhdGFPbmx5KQogCXsKIAkJaWYgKGdfdmVy
Ym9zZSkKLQkJCWZwcmludGYoc3RkZXJyLCAiJXMgbGFzdCBidWlsdGluIG9pZCBpcyAldSAlc1xu
IiwKKwkJCWZwcmludGYoc3RkZXJyLCBfKCIlcyBsYXN0IGJ1aWx0aW4gb2lkIGlzICV1ICVzXG4i
KSwKIAkJCQkJZ19jb21tZW50X3N0YXJ0LCBnX2xhc3RfYnVpbHRpbl9vaWQsIGdfY29tbWVudF9l
bmQpOwogCQl0YmxpbmZvID0gZHVtcFNjaGVtYShnX2ZvdXQsICZudW1UYWJsZXMsIHRhYmxlbmFt
ZSwgYWNsc1NraXApOwogCX0KQEAgLTgyMCw3ICs4MjksNyBAQAogCWlmICghcmVzIHx8CiAJCVBR
cmVzdWx0U3RhdHVzKHJlcykgIT0gUEdSRVNfVFVQTEVTX09LKQogCXsKLQkJZnByaW50ZihzdGRl
cnIsICJnZXRUeXBlcygpOiBTRUxFQ1QgZmFpbGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5k
OiAnJXMnLlxuIiwgUFFlcnJvck1lc3NhZ2UoZ19jb25uKSk7CisJCWZwcmludGYoc3RkZXJyLCBf
KCJnZXRUeXBlcygpOiBTRUxFQ1QgZmFpbGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5kOiAn
JXMnLlxuIiksIFBRZXJyb3JNZXNzYWdlKGdfY29ubikpOwogCQlleGl0X25pY2VseShnX2Nvbm4p
OwogCX0KIApAQCAtOTMyLDcgKzk0MSw3IEBACiAJaWYgKCFyZXMgfHwKIAkJUFFyZXN1bHRTdGF0
dXMocmVzKSAhPSBQR1JFU19UVVBMRVNfT0spCiAJewotCQlmcHJpbnRmKHN0ZGVyciwgImdldE9w
ZXJhdG9ycygpOiBTRUxFQ1QgZmFpbGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5kOiAnJXMn
LlxuIiwgUFFlcnJvck1lc3NhZ2UoZ19jb25uKSk7CisJCWZwcmludGYoc3RkZXJyLCBfKCJnZXRP
cGVyYXRvcnMoKTogU0VMRUNUIGZhaWxlZC4gIEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVz
Jy5cbiIpLCBQUWVycm9yTWVzc2FnZShnX2Nvbm4pKTsKIAkJZXhpdF9uaWNlbHkoZ19jb25uKTsK
IAl9CiAKQEAgLTEyNTgsNyArMTI2Nyw3IEBACiAJaWYgKCFyZXMgfHwKIAkJUFFyZXN1bHRTdGF0
dXMocmVzKSAhPSBQR1JFU19UVVBMRVNfT0spCiAJewotCQlmcHJpbnRmKHN0ZGVyciwgImdldEFn
Z3JlZ2F0ZXMoKTogU0VMRUNUIGZhaWxlZC4gIEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVz
Jy5cbiIsIFBRZXJyb3JNZXNzYWdlKGdfY29ubikpOworCQlmcHJpbnRmKHN0ZGVyciwgXygiZ2V0
QWdncmVnYXRlcygpOiBTRUxFQ1QgZmFpbGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5kOiAn
JXMnLlxuIiksIFBRZXJyb3JNZXNzYWdlKGdfY29ubikpOwogCQlleGl0X25pY2VseShnX2Nvbm4p
OwogCX0KIApAQCAtMTM0MSw3ICsxMzUwLDcgQEAKIAlpZiAoIXJlcyB8fAogCQlQUXJlc3VsdFN0
YXR1cyhyZXMpICE9IFBHUkVTX1RVUExFU19PSykKIAl7Ci0JCWZwcmludGYoc3RkZXJyLCAiZ2V0
RnVuY3MoKTogU0VMRUNUIGZhaWxlZC4gIEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5c
biIsIFBRZXJyb3JNZXNzYWdlKGdfY29ubikpOworCQlmcHJpbnRmKHN0ZGVyciwgXygiZ2V0RnVu
Y3MoKTogU0VMRUNUIGZhaWxlZC4gIEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIp
LCBQUWVycm9yTWVzc2FnZShnX2Nvbm4pKTsKIAkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAl9CiAK
QEAgLTE0MzYsNyArMTQ0NSw3IEBACiAJaWYgKCFyZXMgfHwKIAkJUFFyZXN1bHRTdGF0dXMocmVz
KSAhPSBQR1JFU19UVVBMRVNfT0spCiAJewotCQlmcHJpbnRmKHN0ZGVyciwgImdldFRhYmxlcygp
OiBTRUxFQ1QgZmFpbGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5kOiAnJXMnLlxuIiwgUFFl
cnJvck1lc3NhZ2UoZ19jb25uKSk7CisJCWZwcmludGYoc3RkZXJyLCBfKCJnZXRUYWJsZXMoKTog
U0VMRUNUIGZhaWxlZC4gIEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIpLCBQUWVy
cm9yTWVzc2FnZShnX2Nvbm4pKTsKIAkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAl9CiAKQEAgLTE0
NzUsOCArMTQ4NCw4IEBACiAJCQlpbnQJCQludHVwczI7CiAKIAkJCWlmIChnX3ZlcmJvc2UpCi0J
CQkJZnByaW50ZihzdGRlcnIsICIlcyBleGNsdWRpbmcgaW5oZXJpdGVkIENIRUNLIGNvbnN0cmFp
bnRzICIKLQkJCQkJCSJmb3IgcmVsYXRpb246ICclcycgJXNcbiIsCisJCQkJZnByaW50ZihzdGRl
cnIsIF8oIiVzIGV4Y2x1ZGluZyBpbmhlcml0ZWQgQ0hFQ0sgY29uc3RyYWludHMgIgorCQkJCQkJ
ImZvciByZWxhdGlvbjogJyVzJyAlc1xuIiksCiAJCQkJCQlnX2NvbW1lbnRfc3RhcnQsCiAJCQkJ
CQl0YmxpbmZvW2ldLnJlbG5hbWUsCiAJCQkJCQlnX2NvbW1lbnRfZW5kKTsKQEAgLTE0OTQsMTUg
KzE1MDMsMTUgQEAKIAkJCWlmICghcmVzMiB8fAogCQkJCVBRcmVzdWx0U3RhdHVzKHJlczIpICE9
IFBHUkVTX1RVUExFU19PSykKIAkJCXsKLQkJCQlmcHJpbnRmKHN0ZGVyciwgImdldFRhYmxlcygp
OiBTRUxFQ1QgKGZvciBpbmhlcml0ZWQgQ0hFQ0spIGZhaWxlZC4gIEV4cGxhbmF0aW9uIGZyb20g
YmFja2VuZDogJyVzJy5cbiIsIFBRZXJyb3JNZXNzYWdlKGdfY29ubikpOworCQkJCWZwcmludGYo
c3RkZXJyLCBfKCJnZXRUYWJsZXMoKTogU0VMRUNUIChmb3IgaW5oZXJpdGVkIENIRUNLKSBmYWls
ZWQuICBFeHBsYW5hdGlvbiBmcm9tIGJhY2tlbmQ6ICclcycuXG4iKSwgUFFlcnJvck1lc3NhZ2Uo
Z19jb25uKSk7CiAJCQkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAkJCX0KIAkJCW50dXBzMiA9IFBR
bnR1cGxlcyhyZXMyKTsKIAkJCXRibGluZm9baV0ubmNoZWNrIC09IG50dXBzMjsKIAkJCWlmICh0
YmxpbmZvW2ldLm5jaGVjayA8IDApCiAJCQl7Ci0JCQkJZnByaW50ZihzdGRlcnIsICJnZXRUYWJs
ZXMoKTogZm91bmQgbW9yZSBpbmhlcml0ZWQgQ0hFQ0tzIHRoYW4gdG90YWwgZm9yICIKLQkJCQkJ
CSJyZWxhdGlvbiAlc1xuIiwKKwkJCQlmcHJpbnRmKHN0ZGVyciwgXygiZ2V0VGFibGVzKCk6IGZv
dW5kIG1vcmUgaW5oZXJpdGVkIENIRUNLcyB0aGFuIHRvdGFsIGZvciAiCisJCQkJCQkicmVsYXRp
b24gJXNcbiIpLAogCQkJCQkJdGJsaW5mb1tpXS5yZWxuYW1lKTsKIAkJCQlleGl0X25pY2VseShn
X2Nvbm4pOwogCQkJfQpAQCAtMTUxOSw3ICsxNTI4LDcgQEAKIAkJCWludAkJCWkyOwogCiAJCQlp
ZiAoZ192ZXJib3NlKQotCQkJCWZwcmludGYoc3RkZXJyLCAiJXMgZmluZGluZyBDSEVDSyBjb25z
dHJhaW50cyBmb3IgcmVsYXRpb246ICclcycgJXNcbiIsCisJCQkJZnByaW50ZihzdGRlcnIsIF8o
IiVzIGZpbmRpbmcgQ0hFQ0sgY29uc3RyYWludHMgZm9yIHJlbGF0aW9uOiAnJXMnICVzXG4iKSwK
IAkJCQkJCWdfY29tbWVudF9zdGFydCwKIAkJCQkJCXRibGluZm9baV0ucmVsbmFtZSwKIAkJCQkJ
CWdfY29tbWVudF9lbmQpOwpAQCAtMTUzNywxMyArMTU0NiwxMyBAQAogCQkJaWYgKCFyZXMyIHx8
CiAJCQkJUFFyZXN1bHRTdGF0dXMocmVzMikgIT0gUEdSRVNfVFVQTEVTX09LKQogCQkJewotCQkJ
CWZwcmludGYoc3RkZXJyLCAiZ2V0VGFibGVzKCk6IFNFTEVDVCAoZm9yIENIRUNLKSBmYWlsZWQu
ICBFeHBsYW5hdGlvbiBmcm9tIGJhY2tlbmQ6ICclcycuXG4iLCBQUWVycm9yTWVzc2FnZShnX2Nv
bm4pKTsKKwkJCQlmcHJpbnRmKHN0ZGVyciwgXygiZ2V0VGFibGVzKCk6IFNFTEVDVCAoZm9yIENI
RUNLKSBmYWlsZWQuICBFeHBsYW5hdGlvbiBmcm9tIGJhY2tlbmQ6ICclcycuXG4iKSwgUFFlcnJv
ck1lc3NhZ2UoZ19jb25uKSk7CiAJCQkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAkJCX0KIAkJCW50
dXBzMiA9IFBRbnR1cGxlcyhyZXMyKTsKIAkJCWlmIChudHVwczIgIT0gdGJsaW5mb1tpXS5uY2hl
Y2spCiAJCQl7Ci0JCQkJZnByaW50ZihzdGRlcnIsICJnZXRUYWJsZXMoKTogcmVsYXRpb24gJyVz
JzogJWQgQ0hFQ0tzIHdlcmUgZXhwZWN0ZWQsIGJ1dCBnb3QgJWRcbiIsCisJCQkJZnByaW50Zihz
dGRlcnIsIF8oImdldFRhYmxlcygpOiByZWxhdGlvbiAnJXMnOiAlZCBDSEVDS3Mgd2VyZSBleHBl
Y3RlZCwgYnV0IGdvdCAlZFxuIiksCiAJCQkJCQl0YmxpbmZvW2ldLnJlbG5hbWUsIHRibGluZm9b
aV0ubmNoZWNrLCBudHVwczIpOwogCQkJCWV4aXRfbmljZWx5KGdfY29ubik7CiAJCQl9CkBAIC0x
NTc5LDcgKzE1ODgsNyBAQAogCQkJaW50CQkJaTI7CiAKIAkJCWlmIChnX3ZlcmJvc2UpCi0JCQkJ
ZnByaW50ZihzdGRlcnIsICIlcyBmaW5kaW5nIFRyaWdnZXJzIGZvciByZWxhdGlvbjogJyVzJyAl
c1xuIiwKKwkJCQlmcHJpbnRmKHN0ZGVyciwgXygiJXMgZmluZGluZyBUcmlnZ2VycyBmb3IgcmVs
YXRpb246ICclcycgJXNcbiIpLAogCQkJCQkJZ19jb21tZW50X3N0YXJ0LAogCQkJCQkJdGJsaW5m
b1tpXS5yZWxuYW1lLAogCQkJCQkJZ19jb21tZW50X2VuZCk7CkBAIC0xNTkyLDEzICsxNjAxLDEz
IEBACiAJCQlpZiAoIXJlczIgfHwKIAkJCQlQUXJlc3VsdFN0YXR1cyhyZXMyKSAhPSBQR1JFU19U
VVBMRVNfT0spCiAJCQl7Ci0JCQkJZnByaW50ZihzdGRlcnIsICJnZXRUYWJsZXMoKTogU0VMRUNU
IChmb3IgVFJJR0dFUikgZmFpbGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5kOiAnJXMnLlxu
IiwgUFFlcnJvck1lc3NhZ2UoZ19jb25uKSk7CisJCQkJZnByaW50ZihzdGRlcnIsIF8oImdldFRh
YmxlcygpOiBTRUxFQ1QgKGZvciBUUklHR0VSKSBmYWlsZWQuICBFeHBsYW5hdGlvbiBmcm9tIGJh
Y2tlbmQ6ICclcycuXG4iKSwgUFFlcnJvck1lc3NhZ2UoZ19jb25uKSk7CiAJCQkJZXhpdF9uaWNl
bHkoZ19jb25uKTsKIAkJCX0KIAkJCW50dXBzMiA9IFBRbnR1cGxlcyhyZXMyKTsKIAkJCWlmIChu
dHVwczIgIT0gdGJsaW5mb1tpXS5udHJpZykKIAkJCXsKLQkJCQlmcHJpbnRmKHN0ZGVyciwgImdl
dFRhYmxlcygpOiByZWxhdGlvbiAnJXMnOiAlZCBUcmlnZ2VycyB3ZXJlIGV4cGVjdGVkLCBidXQg
Z290ICVkXG4iLAorCQkJCWZwcmludGYoc3RkZXJyLCBfKCJnZXRUYWJsZXMoKTogcmVsYXRpb24g
JyVzJzogJWQgVHJpZ2dlcnMgd2VyZSBleHBlY3RlZCwgYnV0IGdvdCAlZFxuIiksCiAJCQkJCQl0
YmxpbmZvW2ldLnJlbG5hbWUsIHRibGluZm9baV0ubnRyaWcsIG50dXBzMik7CiAJCQkJZXhpdF9u
aWNlbHkoZ19jb25uKTsKIAkJCX0KQEAgLTE2MjcsNyArMTYzNiw3IEBACiAJCQkJfQogCQkJCWlm
IChmaW5keCA9PSBudW1GdW5jcykKIAkJCQl7Ci0JCQkJCWZwcmludGYoc3RkZXJyLCAiZ2V0VGFi
bGVzKCk6IHJlbGF0aW9uICclcyc6IGNhbm5vdCBmaW5kIGZ1bmN0aW9uIHdpdGggb2lkICVzIGZv
ciB0cmlnZ2VyICVzXG4iLAorCQkJCQlmcHJpbnRmKHN0ZGVyciwgXygiZ2V0VGFibGVzKCk6IHJl
bGF0aW9uICclcyc6IGNhbm5vdCBmaW5kIGZ1bmN0aW9uIHdpdGggb2lkICVzIGZvciB0cmlnZ2Vy
ICVzXG4iKSwKIAkJCQkJCQl0YmxpbmZvW2ldLnJlbG5hbWUsIHRnZnVuYywgUFFnZXR2YWx1ZShy
ZXMyLCBpMiwgaV90Z25hbWUpKTsKIAkJCQkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAkJCQl9CkBA
IC0xNjgzLDcgKzE2OTIsNyBAQAogCQkJCQkJcCA9IHN0cmNocihwLCAnXFwnKTsKIAkJCQkJCWlm
IChwID09IE5VTEwpCiAJCQkJCQl7Ci0JCQkJCQkJZnByaW50ZihzdGRlcnIsICJnZXRUYWJsZXMo
KTogcmVsYXRpb24gJyVzJzogYmFkIGFyZ3VtZW50IHN0cmluZyAoJXMpIGZvciB0cmlnZ2VyICcl
cydcbiIsCisJCQkJCQkJZnByaW50ZihzdGRlcnIsIF8oImdldFRhYmxlcygpOiByZWxhdGlvbiAn
JXMnOiBiYWQgYXJndW1lbnQgc3RyaW5nICglcykgZm9yIHRyaWdnZXIgJyVzJ1xuIiksCiAJCQkJ
CQkJCQl0YmxpbmZvW2ldLnJlbG5hbWUsCiAJCQkJCQkJCQlQUWdldHZhbHVlKHJlczIsIGkyLCBp
X3RnYXJncyksCiAJCQkJCQkJCQlQUWdldHZhbHVlKHJlczIsIGkyLCBpX3RnbmFtZSkpOwpAQCAt
MTc1NCw3ICsxNzYzLDcgQEAKIAlpZiAoIXJlcyB8fAogCQlQUXJlc3VsdFN0YXR1cyhyZXMpICE9
IFBHUkVTX1RVUExFU19PSykKIAl7Ci0JCWZwcmludGYoc3RkZXJyLCAiZ2V0SW5oZXJpdHMoKTog
U0VMRUNUIGZhaWxlZC4gIEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIsIFBRZXJy
b3JNZXNzYWdlKGdfY29ubikpOworCQlmcHJpbnRmKHN0ZGVyciwgXygiZ2V0SW5oZXJpdHMoKTog
U0VMRUNUIGZhaWxlZC4gIEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIpLCBQUWVy
cm9yTWVzc2FnZShnX2Nvbm4pKTsKIAkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAl9CiAKQEAgLTE4
MTUsNyArMTgyNCw3IEBACiAJCSAqIGxhdGVyCiAJCSAqLwogCQlpZiAoZ192ZXJib3NlKQotCQkJ
ZnByaW50ZihzdGRlcnIsICIlcyBmaW5kaW5nIHRoZSBhdHRycyBhbmQgdHlwZXMgZm9yIHRhYmxl
OiAnJXMnICVzXG4iLAorCQkJZnByaW50ZihzdGRlcnIsIF8oIiVzIGZpbmRpbmcgdGhlIGF0dHJz
IGFuZCB0eXBlcyBmb3IgdGFibGU6ICclcycgJXNcbiIpLAogCQkJCQlnX2NvbW1lbnRfc3RhcnQs
CiAJCQkJCXRibGluZm9baV0ucmVsbmFtZSwKIAkJCQkJZ19jb21tZW50X2VuZCk7CkBAIC0xODMw
LDcgKzE4MzksNyBAQAogCQlpZiAoIXJlcyB8fAogCQkJUFFyZXN1bHRTdGF0dXMocmVzKSAhPSBQ
R1JFU19UVVBMRVNfT0spCiAJCXsKLQkJCWZwcmludGYoc3RkZXJyLCAiZ2V0VGFibGVBdHRycygp
OiBTRUxFQ1QgZmFpbGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5kOiAnJXMnLlxuIiwgUFFl
cnJvck1lc3NhZ2UoZ19jb25uKSk7CisJCQlmcHJpbnRmKHN0ZGVyciwgXygiZ2V0VGFibGVBdHRy
cygpOiBTRUxFQ1QgZmFpbGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5kOiAnJXMnLlxuIiks
IFBRZXJyb3JNZXNzYWdlKGdfY29ubikpOwogCQkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAkJfQog
CkBAIC0xODY0LDcgKzE4NzMsNyBAQAogCQkJCVBHcmVzdWx0ICAgKnJlczI7CiAKIAkJCQlpZiAo
Z192ZXJib3NlKQotCQkJCQlmcHJpbnRmKHN0ZGVyciwgIiVzIGZpbmRpbmcgREVGQVVMVCBleHBy
ZXNzaW9uIGZvciBhdHRyOiAnJXMnICVzXG4iLAorCQkJCQlmcHJpbnRmKHN0ZGVyciwgXygiJXMg
ZmluZGluZyBERUZBVUxUIGV4cHJlc3Npb24gZm9yIGF0dHI6ICclcycgJXNcbiIpLAogCQkJCQkJ
CWdfY29tbWVudF9zdGFydCwKIAkJCQkJCQl0YmxpbmZvW2ldLmF0dG5hbWVzW2pdLAogCQkJCQkJ
CWdfY29tbWVudF9lbmQpOwpAQCAtMTg3Niw3ICsxODg1LDcgQEAKIAkJCQlpZiAoIXJlczIgfHwK
IAkJCQkJUFFyZXN1bHRTdGF0dXMocmVzMikgIT0gUEdSRVNfVFVQTEVTX09LKQogCQkJCXsKLQkJ
CQkJZnByaW50ZihzdGRlcnIsICJnZXRUYWJsZUF0dHJzKCk6IFNFTEVDVCAoZm9yIERFRkFVTFQp
IGZhaWxlZC4gIEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIsIFBRZXJyb3JNZXNz
YWdlKGdfY29ubikpOworCQkJCQlmcHJpbnRmKHN0ZGVyciwgXygiZ2V0VGFibGVBdHRycygpOiBT
RUxFQ1QgKGZvciBERUZBVUxUKSBmYWlsZWQuICBFeHBsYW5hdGlvbiBmcm9tIGJhY2tlbmQ6ICcl
cycuXG4iKSwgUFFlcnJvck1lc3NhZ2UoZ19jb25uKSk7CiAJCQkJCWV4aXRfbmljZWx5KGdfY29u
bik7CiAJCQkJfQogCQkJCXRibGluZm9baV0uYWRlZl9leHByW2pdID0gc3RyZHVwKFBRZ2V0dmFs
dWUocmVzMiwgMCwgUFFmbnVtYmVyKHJlczIsICJhZHNyYyIpKSk7CkBAIC0xOTM5LDcgKzE5NDgs
NyBAQAogCWlmICghcmVzIHx8CiAJCVBRcmVzdWx0U3RhdHVzKHJlcykgIT0gUEdSRVNfVFVQTEVT
X09LKQogCXsKLQkJZnByaW50ZihzdGRlcnIsICJnZXRJbmRpY2VzKCk6IFNFTEVDVCBmYWlsZWQu
ICBFeHBsYW5hdGlvbiBmcm9tIGJhY2tlbmQ6ICclcycuXG4iLCBQUWVycm9yTWVzc2FnZShnX2Nv
bm4pKTsKKwkJZnByaW50ZihzdGRlcnIsIF8oImdldEluZGljZXMoKTogU0VMRUNUIGZhaWxlZC4g
IEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIpLCBQUWVycm9yTWVzc2FnZShnX2Nv
bm4pKTsKIAkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAl9CiAKQEAgLTIwODIsNyArMjA5MSw3IEBA
CiAJaWYgKCFyZXMgfHwKIAkJUFFyZXN1bHRTdGF0dXMocmVzKSAhPSBQR1JFU19UVVBMRVNfT0sp
CiAJewotCQlmcHJpbnRmKHN0ZGVyciwgImR1bXBQcm9jTGFuZ3MoKTogU0VMRUNUIGZhaWxlZC4g
IEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIsIFBRZXJyb3JNZXNzYWdlKGdfY29u
bikpOworCQlmcHJpbnRmKHN0ZGVyciwgXygiZHVtcFByb2NMYW5ncygpOiBTRUxFQ1QgZmFpbGVk
LiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5kOiAnJXMnLlxuIiksIFBRZXJyb3JNZXNzYWdlKGdf
Y29ubikpOwogCQlleGl0X25pY2VseShnX2Nvbm4pOwogCX0KIAludHVwcyA9IFBRbnR1cGxlcyhy
ZXMpOwpAQCAtMjEwMiw3ICsyMTExLDcgQEAKIAkJfQogCQlpZiAoZmlkeCA+PSBudW1GdW5jcykK
IAkJewotCQkJZnByaW50ZihzdGRlcnIsICJkdW1wUHJvY0xhbmdzKCk6IGhhbmRsZXIgcHJvY2Vk
dXJlIGZvciBsYW5ndWFnZSAlcyBub3QgZm91bmRcbiIsIFBRZ2V0dmFsdWUocmVzLCBpLCBpX2xh
bm5hbWUpKTsKKwkJCWZwcmludGYoc3RkZXJyLCBfKCJkdW1wUHJvY0xhbmdzKCk6IGhhbmRsZXIg
cHJvY2VkdXJlIGZvciBsYW5ndWFnZSAlcyBub3QgZm91bmRcbiIpLCBQUWdldHZhbHVlKHJlcywg
aSwgaV9sYW5uYW1lKSk7CiAJCQlleGl0X25pY2VseShnX2Nvbm4pOwogCQl9CiAKQEAgLTIxOTYs
MTQgKzIyMDUsMTQgQEAKIAkJaWYgKCFyZXMgfHwKIAkJCVBRcmVzdWx0U3RhdHVzKHJlcykgIT0g
UEdSRVNfVFVQTEVTX09LKQogCQl7Ci0JCQlmcHJpbnRmKHN0ZGVyciwgImR1bXBPbmVGdW5jKCk6
IFNFTEVDVCBmb3IgcHJvY2VkdXJhbCBsYW5ndWFnZSBmYWlsZWQuICBFeHBsYW5hdGlvbiBmcm9t
IGJhY2tlbmQ6ICclcycuXG4iLCBQUWVycm9yTWVzc2FnZShnX2Nvbm4pKTsKKwkJCWZwcmludGYo
c3RkZXJyLCBfKCJkdW1wT25lRnVuYygpOiBTRUxFQ1QgZm9yIHByb2NlZHVyYWwgbGFuZ3VhZ2Ug
ZmFpbGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5kOiAnJXMnLlxuIiksIFBRZXJyb3JNZXNz
YWdlKGdfY29ubikpOwogCQkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAkJfQogCQlubGFuZ3MgPSBQ
UW50dXBsZXMocmVzKTsKIAogCQlpZiAobmxhbmdzICE9IDEpCiAJCXsKLQkJCWZwcmludGYoc3Rk
ZXJyLCAiZHVtcE9uZUZ1bmMoKTogcHJvY2VkdXJhbCBsYW5ndWFnZSBmb3IgZnVuY3Rpb24gJXMg
bm90IGZvdW5kXG4iLCBmaW5mb1tpXS5wcm9uYW1lKTsKKwkJCWZwcmludGYoc3RkZXJyLCBfKCJk
dW1wT25lRnVuYygpOiBwcm9jZWR1cmFsIGxhbmd1YWdlIGZvciBmdW5jdGlvbiAlcyBub3QgZm91
bmRcbiIpLCBmaW5mb1tpXS5wcm9uYW1lKTsKIAkJCWV4aXRfbmljZWx5KGdfY29ubik7CiAJCX0K
IApAQCAtMjU1OSw3ICsyNTY4LDcgQEAKIAkJZXFwb3MgPSBzdHJjaHIodG9rLCAnPScpOwogCQlp
ZiAoIWVxcG9zKQogCQl7Ci0JCQlmcHJpbnRmKHN0ZGVyciwgIkNvdWxkIG5vdCBwYXJzZSBBQ0wg
bGlzdCBmb3IgJyVzJy4uLkV4aXRpbmchXG4iLAorCQkJZnByaW50ZihzdGRlcnIsIF8oIkNvdWxk
IG5vdCBwYXJzZSBBQ0wgbGlzdCBmb3IgJyVzJy4uLkV4aXRpbmchXG4iKSwKIAkJCQkJdGJpbmZv
LnJlbG5hbWUpOwogCQkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAkJfQpAQCAtMjgwNSw3ICsyODE0
LDcgQEAKIAkJCQkJCQkJICAgaW5kaW5mb1tpXS5pbmRyZWxuYW1lKTsKIAkJaWYgKHRhYmxlSW5k
IDwgMCkKIAkJewotCQkJZnByaW50ZihzdGRlcnIsICJmYWlsZWQgc2FuaXR5IGNoZWNrLCB0YWJs
ZSAlcyB3YXMgbm90IGZvdW5kXG4iLAorCQkJZnByaW50ZihzdGRlcnIsIF8oImZhaWxlZCBzYW5p
dHkgY2hlY2ssIHRhYmxlICVzIHdhcyBub3QgZm91bmRcbiIpLAogCQkJCQlpbmRpbmZvW2ldLmlu
ZHJlbG5hbWUpOwogCQkJZXhpdCgyKTsKIAkJfQpAQCAtMjgyOCw3ICsyODM3LDcgQEAKIAkJCXJl
cyA9IFBRZXhlYyhnX2Nvbm4sIHEpOwogCQkJaWYgKCFyZXMgfHwgUFFyZXN1bHRTdGF0dXMocmVz
KSAhPSBQR1JFU19UVVBMRVNfT0spCiAJCQl7Ci0JCQkJZnByaW50ZihzdGRlcnIsICJkdW1wSW5k
aWNlcygpOiBTRUxFQ1QgKGZ1bmNuYW1lKSBmYWlsZWQuICBFeHBsYW5hdGlvbiBmcm9tIGJhY2tl
bmQ6ICclcycuXG4iLCBQUWVycm9yTWVzc2FnZShnX2Nvbm4pKTsKKwkJCQlmcHJpbnRmKHN0ZGVy
ciwgXygiZHVtcEluZGljZXMoKTogU0VMRUNUIChmdW5jbmFtZSkgZmFpbGVkLiAgRXhwbGFuYXRp
b24gZnJvbSBiYWNrZW5kOiAnJXMnLlxuIiksIFBRZXJyb3JNZXNzYWdlKGdfY29ubikpOwogCQkJ
CWV4aXRfbmljZWx5KGdfY29ubik7CiAJCQl9CiAJCQlmdW5jbmFtZSA9IHN0cmR1cChQUWdldHZh
bHVlKHJlcywgMCwKQEAgLTI4NDksNyArMjg1OCw3IEBACiAJCQlyZXMgPSBQUWV4ZWMoZ19jb25u
LCBxKTsKIAkJCWlmICghcmVzIHx8IFBRcmVzdWx0U3RhdHVzKHJlcykgIT0gUEdSRVNfVFVQTEVT
X09LKQogCQkJewotCQkJCWZwcmludGYoc3RkZXJyLCAiZHVtcEluZGljZXMoKTogU0VMRUNUIChj
bGFzc25hbWUpIGZhaWxlZC4gIEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIsIFBR
ZXJyb3JNZXNzYWdlKGdfY29ubikpOworCQkJCWZwcmludGYoc3RkZXJyLCBfKCJkdW1wSW5kaWNl
cygpOiBTRUxFQ1QgKGNsYXNzbmFtZSkgZmFpbGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5k
OiAnJXMnLlxuIiksIFBRZXJyb3JNZXNzYWdlKGdfY29ubikpOwogCQkJCWV4aXRfbmljZWx5KGdf
Y29ubik7CiAJCQl9CiAJCQljbGFzc25hbWVbbmNsYXNzXSA9IHN0cmR1cChQUWdldHZhbHVlKHJl
cywgMCwKQEAgLTI4NTksOCArMjg2OCw4IEBACiAKIAkJaWYgKGZ1bmNuYW1lICYmIG5jbGFzcyAh
PSAxKQogCQl7Ci0JCQlmcHJpbnRmKHN0ZGVyciwgImR1bXBJbmRpY2VzKCk6IE11c3QgYmUgZXhh
Y3RseSBvbmUgT3BDbGFzcyAiCi0JCQkJCSJmb3IgZnVuY3Rpb25hbCBpbmRleCAlc1xuIiwgaW5k
aW5mb1tpXS5pbmRleHJlbG5hbWUpOworCQkJZnByaW50ZihzdGRlcnIsIF8oImR1bXBJbmRpY2Vz
KCk6IE11c3QgYmUgZXhhY3RseSBvbmUgT3BDbGFzcyAiCisJCQkJCSJmb3IgZnVuY3Rpb25hbCBp
bmRleCAlc1xuIiksIGluZGluZm9baV0uaW5kZXhyZWxuYW1lKTsKIAkJCWV4aXRfbmljZWx5KGdf
Y29ubik7CiAJCX0KIApAQCAtMjg4NCw4ICsyODkzLDggQEAKIAkJCXsKIAkJCQlpZiAoayA+PSBu
Y2xhc3MpCiAJCQkJewotCQkJCQlmcHJpbnRmKHN0ZGVyciwgImR1bXBJbmRpY2VzKCk6IE9wQ2xh
c3Mgbm90IGZvdW5kIGZvciAiCi0JCQkJCQkJImF0dHJpYnV0ZSAnJXMnIG9mIGluZGV4ICclcydc
biIsCisJCQkJCWZwcmludGYoc3RkZXJyLCBfKCJkdW1wSW5kaWNlcygpOiBPcENsYXNzIG5vdCBm
b3VuZCBmb3IgIgorCQkJCQkJCSJhdHRyaWJ1dGUgJyVzJyBvZiBpbmRleCAnJXMnXG4iKSwKIAkJ
CQkJCQlhdHRuYW1lLCBpbmRpbmZvW2ldLmluZGV4cmVsbmFtZSk7CiAJCQkJCWV4aXRfbmljZWx5
KGdfY29ubik7CiAJCQkJfQpAQCAtMzAxNiw3ICszMDI1LDcgQEAKIAlpZiAoIXJlcyB8fAogCQlQ
UXJlc3VsdFN0YXR1cyhyZXMpICE9IFBHUkVTX0NPTU1BTkRfT0spCiAJewotCQlmcHJpbnRmKHN0
ZGVyciwgIkNhbiBub3QgY3JlYXRlIHBnZHVtcF9vaWQgdGFibGUuICBFeHBsYW5hdGlvbiBmcm9t
IGJhY2tlbmQ6ICclcycuXG4iLCBQUWVycm9yTWVzc2FnZShnX2Nvbm4pKTsKKwkJZnByaW50Zihz
dGRlcnIsIF8oIkNhbiBub3QgY3JlYXRlIHBnZHVtcF9vaWQgdGFibGUuICBFeHBsYW5hdGlvbiBm
cm9tIGJhY2tlbmQ6ICclcycuXG4iKSwgUFFlcnJvck1lc3NhZ2UoZ19jb25uKSk7CiAJCWV4aXRf
bmljZWx5KGdfY29ubik7CiAJfQogCVBRY2xlYXIocmVzKTsKQEAgLTMwMjQsMTMgKzMwMzMsMTMg
QEAKIAlpZiAoIXJlcyB8fAogCQlQUXJlc3VsdFN0YXR1cyhyZXMpICE9IFBHUkVTX0NPTU1BTkRf
T0spCiAJewotCQlmcHJpbnRmKHN0ZGVyciwgIkNhbiBub3QgaW5zZXJ0IGludG8gcGdkdW1wX29p
ZCB0YWJsZS4gIEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIsIFBRZXJyb3JNZXNz
YWdlKGdfY29ubikpOworCQlmcHJpbnRmKHN0ZGVyciwgXygiQ2FuIG5vdCBpbnNlcnQgaW50byBw
Z2R1bXBfb2lkIHRhYmxlLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5kOiAnJXMnLlxuIiksIFBR
ZXJyb3JNZXNzYWdlKGdfY29ubikpOwogCQlleGl0X25pY2VseShnX2Nvbm4pOwogCX0KIAltYXhf
b2lkID0gYXRvbChQUW9pZFN0YXR1cyhyZXMpKTsKIAlpZiAobWF4X29pZCA9PSAwKQogCXsKLQkJ
ZnByaW50ZihzdGRlcnIsICJJbnZhbGlkIG1heCBpZCBpbiBzZXRNYXhPaWRcbiIpOworCQlmcHJp
bnRmKHN0ZGVyciwgXygiSW52YWxpZCBtYXggaWQgaW4gc2V0TWF4T2lkXG4iKSk7CiAJCWV4aXRf
bmljZWx5KGdfY29ubik7CiAJfQogCVBRY2xlYXIocmVzKTsKQEAgLTMwMzgsNyArMzA0Nyw3IEBA
CiAJaWYgKCFyZXMgfHwKIAkJUFFyZXN1bHRTdGF0dXMocmVzKSAhPSBQR1JFU19DT01NQU5EX09L
KQogCXsKLQkJZnByaW50ZihzdGRlcnIsICJDYW4gbm90IGRyb3AgcGdkdW1wX29pZCB0YWJsZS4g
IEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIsIFBRZXJyb3JNZXNzYWdlKGdfY29u
bikpOworCQlmcHJpbnRmKHN0ZGVyciwgXygiQ2FuIG5vdCBkcm9wIHBnZHVtcF9vaWQgdGFibGUu
ICBFeHBsYW5hdGlvbiBmcm9tIGJhY2tlbmQ6ICclcycuXG4iKSwgUFFlcnJvck1lc3NhZ2UoZ19j
b25uKSk7CiAJCWV4aXRfbmljZWx5KGdfY29ubik7CiAJfQogCVBRY2xlYXIocmVzKTsKQEAgLTMw
NzEsMTQgKzMwODAsMTQgQEAKIAlpZiAocmVzID09IE5VTEwgfHwKIAkJUFFyZXN1bHRTdGF0dXMo
cmVzKSAhPSBQR1JFU19UVVBMRVNfT0spCiAJewotCQlmcHJpbnRmKHN0ZGVyciwgInBnX2R1bXAg
ZXJyb3IgaW4gZmluZGluZyB0aGUgdGVtcGxhdGUxIGRhdGFiYXNlLiAgRXhwbGFuYXRpb24gZnJv
bSBiYWNrZW5kOiAnJXMnLlxuIiwgUFFlcnJvck1lc3NhZ2UoZ19jb25uKSk7CisJCWZwcmludGYo
c3RkZXJyLCBfKCJwZ19kdW1wIGVycm9yIGluIGZpbmRpbmcgdGhlIHRlbXBsYXRlMSBkYXRhYmFz
ZS4gIEV4cGxhbmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIpLCBQUWVycm9yTWVzc2FnZShn
X2Nvbm4pKTsKIAkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAl9CiAJbnR1cHMgPSBQUW50dXBsZXMo
cmVzKTsKIAlpZiAobnR1cHMgIT0gMSkKIAl7Ci0JCWZwcmludGYoc3RkZXJyLCAicGdfZHVtcDog
Y291bGRuJ3QgZmluZCB0aGUgdGVtcGxhdGUxIGRhdGFiYXNlLiAgIgotCQkJCSJZb3UgYXJlIHJl
YWxseSBob3NlZC5cbkdpdmluZyB1cC5cbiIpOworCQlmcHJpbnRmKHN0ZGVyciwgXygicGdfZHVt
cDogY291bGRuJ3QgZmluZCB0aGUgdGVtcGxhdGUxIGRhdGFiYXNlLiAgIgorCQkJCSJZb3UgYXJl
IHJlYWxseSBob3NlZC5cbkdpdmluZyB1cC5cbiIpKTsKIAkJZXhpdF9uaWNlbHkoZ19jb25uKTsK
IAl9CiAJbGFzdF9vaWQgPSBhdG9pKFBRZ2V0dmFsdWUocmVzLCAwLCBQUWZudW1iZXIocmVzLCAi
b2lkIikpKTsKQEAgLTMxNDQsMjEgKzMxNTMsMjEgQEAKIAlyZXMgPSBQUWV4ZWMoZ19jb25uLCBx
dWVyeSk7CiAJaWYgKCFyZXMgfHwgUFFyZXN1bHRTdGF0dXMocmVzKSAhPSBQR1JFU19UVVBMRVNf
T0spCiAJewotCQlmcHJpbnRmKHN0ZGVyciwgImR1bXBTZXF1ZW5jZSglcyk6IFNFTEVDVCBmYWls
ZWQuICBFeHBsYW5hdGlvbiBmcm9tIGJhY2tlbmQ6ICclcycuXG4iLCB0YmluZm8ucmVsbmFtZSwg
UFFlcnJvck1lc3NhZ2UoZ19jb25uKSk7CisJCWZwcmludGYoc3RkZXJyLCBfKCJkdW1wU2VxdWVu
Y2UoJXMpOiBTRUxFQ1QgZmFpbGVkLiAgRXhwbGFuYXRpb24gZnJvbSBiYWNrZW5kOiAnJXMnLlxu
IiksIHRiaW5mby5yZWxuYW1lLCBQUWVycm9yTWVzc2FnZShnX2Nvbm4pKTsKIAkJZXhpdF9uaWNl
bHkoZ19jb25uKTsKIAl9CiAKIAlpZiAoUFFudHVwbGVzKHJlcykgIT0gMSkKIAl7Ci0JCWZwcmlu
dGYoc3RkZXJyLCAiZHVtcFNlcXVlbmNlKCVzKTogJWQgKCE9IDEpIHR1cGxlcyByZXR1cm5lZCBi
eSBTRUxFQ1RcbiIsCisJCWZwcmludGYoc3RkZXJyLCBfKCJkdW1wU2VxdWVuY2UoJXMpOiAlZCAo
IT0gMSkgdHVwbGVzIHJldHVybmVkIGJ5IFNFTEVDVFxuIiksCiAJCQkJdGJpbmZvLnJlbG5hbWUs
IFBRbnR1cGxlcyhyZXMpKTsKIAkJZXhpdF9uaWNlbHkoZ19jb25uKTsKIAl9CiAKIAlpZiAoc3Ry
Y21wKFBRZ2V0dmFsdWUocmVzLCAwLCAwKSwgdGJpbmZvLnJlbG5hbWUpICE9IDApCiAJewotCQlm
cHJpbnRmKHN0ZGVyciwgImR1bXBTZXF1ZW5jZSglcyk6IGRpZmZlcmVudCBzZXF1ZW5jZSBuYW1l
ICIKLQkJCQkicmV0dXJuZWQgYnkgU0VMRUNUOiAlc1xuIiwKKwkJZnByaW50ZihzdGRlcnIsIF8o
ImR1bXBTZXF1ZW5jZSglcyk6IGRpZmZlcmVudCBzZXF1ZW5jZSBuYW1lICIKKwkJCQkicmV0dXJu
ZWQgYnkgU0VMRUNUOiAlc1xuIiksCiAJCQkJdGJpbmZvLnJlbG5hbWUsIFBRZ2V0dmFsdWUocmVz
LCAwLCAwKSk7CiAJCWV4aXRfbmljZWx5KGdfY29ubik7CiAJfQpAQCAtMzIwNyw3ICszMjE2LDcg
QEAKIAkJCQlqOwogCiAJaWYgKGdfdmVyYm9zZSkKLQkJZnByaW50ZihzdGRlcnIsICIlcyBkdW1w
aW5nIG91dCB0cmlnZ2VycyAlc1xuIiwKKwkJZnByaW50ZihzdGRlcnIsIF8oIiVzIGR1bXBpbmcg
b3V0IHRyaWdnZXJzICVzXG4iKSwKIAkJCQlnX2NvbW1lbnRfc3RhcnQsIGdfY29tbWVudF9lbmQp
OwogCiAJZm9yIChpID0gMDsgaSA8IG51bVRhYmxlczsgaSsrKQpAQCAtMzIzNiw3ICszMjQ1LDcg
QEAKIAlpbnQJCQlpX2RlZmluaXRpb247CiAKIAlpZiAoZ192ZXJib3NlKQotCQlmcHJpbnRmKHN0
ZGVyciwgIiVzIGR1bXBpbmcgb3V0IHJ1bGVzICVzXG4iLAorCQlmcHJpbnRmKHN0ZGVyciwgXygi
JXMgZHVtcGluZyBvdXQgcnVsZXMgJXNcbiIpLAogCQkJCWdfY29tbWVudF9zdGFydCwgZ19jb21t
ZW50X2VuZCk7CiAKIAkvKgpAQCAtMzI2MCw3ICszMjY5LDcgQEAKIAkJaWYgKCFyZXMgfHwKIAkJ
CVBRcmVzdWx0U3RhdHVzKHJlcykgIT0gUEdSRVNfVFVQTEVTX09LKQogCQl7Ci0JCQlmcHJpbnRm
KHN0ZGVyciwgImR1bXBSdWxlcygpOiBTRUxFQ1QgZmFpbGVkIGZvciB0YWJsZSAlcy4gIEV4cGxh
bmF0aW9uIGZyb20gYmFja2VuZDogJyVzJy5cbiIsCisJCQlmcHJpbnRmKHN0ZGVyciwgXygiZHVt
cFJ1bGVzKCk6IFNFTEVDVCBmYWlsZWQgZm9yIHRhYmxlICVzLiAgRXhwbGFuYXRpb24gZnJvbSBi
YWNrZW5kOiAnJXMnLlxuIiksCiAJCQkJCXRibGluZm9bdF0ucmVsbmFtZSwgUFFlcnJvck1lc3Nh
Z2UoZ19jb25uKSk7CiAJCQlleGl0X25pY2VseShnX2Nvbm4pOwogCQl9CmRpZmYgLXVOciBwb3N0
Z3Jlc3FsLTYuNS4xLW9yaWcvc3JjL2Jpbi9wZ19lbmNvZGluZy9NYWtlZmlsZSBwb3N0Z3Jlc3Fs
LTYuNS4xL3NyYy9iaW4vcGdfZW5jb2RpbmcvTWFrZWZpbGUKLS0tIHBvc3RncmVzcWwtNi41LjEt
b3JpZy9zcmMvYmluL3BnX2VuY29kaW5nL01ha2VmaWxlCVNhdCBKdW4gIDUgMTg6Mjc6MzEgMTk5
OQorKysgcG9zdGdyZXNxbC02LjUuMS9zcmMvYmluL3BnX2VuY29kaW5nL01ha2VmaWxlCU1vbiBK
dWwgMjYgMDE6MTQ6MTcgMTk5OQpAQCAtMTcsNyArMTcsMTIgQEAKIAogQ0ZMQUdTKz0gJChNQkZM
QUdTKSAtSSQoU1JDRElSKS9pbmNsdWRlCiAKLWFsbDogcGdfZW5jb2RpbmcKK1BPVFNSQ0ZJTEU9
IHBnX2VuY29kaW5nLmMKKworUE9UT0JKRklMRT0gcGdfZW5jb2RpbmcucG90CisKKworYWxsOiBw
Z19lbmNvZGluZyBwb3QKIAogcGdfZW5jb2Rpbmc6ICQoT0JKUykgJChMSUJQUURJUikvbGlicHEu
YQogCSQoQ0MpIC1vIHBnX2VuY29kaW5nICQoT0JKUykgLUwkKExJQlBRRElSKSAtbHBxICQoTERG
TEFHUykKQEAgLTI4LDggKzMzLDE0IEBACiBkZXBlbmQgZGVwOgogCSQoQ0MpIC1NTSAkKENGTEFH
UykgKi5jID5kZXBlbmQKIAotY2xlYW46IAorY2xlYW46IGNsZWFuLXBvdAogCXJtIC1mIHBnX2Vu
Y29kaW5nIHBnX2VuY29kaW5nLm8KKworY2xlYW4tcG90OgorCXJtIC1mICQoUE9UT0JKRklMRSkK
KworcG90OgorCXhnZXR0ZXh0IC0ta2V5d29yZD0iXyIgLUMgLW8gJChQT1RPQkpGSUxFKSAkKFBP
VFNSQ0ZJTEUpCiAKIGlmZXEgKGRlcGVuZCwkKHdpbGRjYXJkIGRlcGVuZCkpCiBpbmNsdWRlIGRl
cGVuZApkaWZmIC11TnIgcG9zdGdyZXNxbC02LjUuMS1vcmlnL3NyYy9iaW4vcGdfZW5jb2Rpbmcv
cGdfZW5jb2RpbmcuYyBwb3N0Z3Jlc3FsLTYuNS4xL3NyYy9iaW4vcGdfZW5jb2RpbmcvcGdfZW5j
b2RpbmcuYwotLS0gcG9zdGdyZXNxbC02LjUuMS1vcmlnL3NyYy9iaW4vcGdfZW5jb2RpbmcvcGdf
ZW5jb2RpbmcuYwlTdW4gRmViIDE0IDA3OjIwOjI2IDE5OTkKKysrIHBvc3RncmVzcWwtNi41LjEv
c3JjL2Jpbi9wZ19lbmNvZGluZy9wZ19lbmNvZGluZy5jCU1vbiBKdWwgMjYgMDE6MTI6NTMgMTk5
OQpAQCAtMTMsOSArMTMsMTYgQEAKICAqLwogI2luY2x1ZGUgPHN0ZGxpYi5oPgogI2luY2x1ZGUg
PHN0ZGlvLmg+CisKICNpbmNsdWRlICJwb3N0Z3Jlcy5oIgogI2luY2x1ZGUgIm1iL3BnX3djaGFy
LmgiCiAKKyNpZmRlZiBVU0VfTVVMVElMQU5HCisjZGVmaW5lCVBBQ0tBR0UJInBnX2VuY29kaW5n
IgorI2luY2x1ZGUgIm11bHRpbGFuZy5oIgorI2VuZGlmCisKKwogc3RhdGljIHZvaWQgdXNhZ2Uo
dm9pZCk7CiAKIGludApAQCAtMjUsNiArMzIsMTAgQEAKIAljaGFyCSAgICpwOwogCWludAkJCXJ0
bjsKIAorI2lmZGVmCVVTRV9NVUxUSUxBTkcKKwlJbml0TXVsdGlMYW5nKFBBQ0tBR0UsIExPQ0FM
RURJUik7CisjZW5kaWYKKwogCWlmIChhcmdjIDwgMikKIAl7CiAJCXVzYWdlKCk7CkBAIC00OCw1
ICs1OSw1IEBACiBzdGF0aWMgdm9pZAogdXNhZ2UoKQogewotCWZwcmludGYoc3RkZXJyLCAicGdf
ZW5jb2Rpbmc6IGVuY29kaW5nX25hbWUgfCBlbmNvZGluZ19udW1iZXJcbiIpOworCWZwcmludGYo
c3RkZXJyLCBfKCJwZ19lbmNvZGluZzogZW5jb2RpbmdfbmFtZSB8IGVuY29kaW5nX251bWJlclxu
IikpOwogfQpkaWZmIC11TnIgcG9zdGdyZXNxbC02LjUuMS1vcmlnL3NyYy9iaW4vcGdfaWQvTWFr
ZWZpbGUgcG9zdGdyZXNxbC02LjUuMS9zcmMvYmluL3BnX2lkL01ha2VmaWxlCi0tLSBwb3N0Z3Jl
c3FsLTYuNS4xLW9yaWcvc3JjL2Jpbi9wZ19pZC9NYWtlZmlsZQlTdW4gSmFuIDE3IDE0OjE5OjEw
IDE5OTkKKysrIHBvc3RncmVzcWwtNi41LjEvc3JjL2Jpbi9wZ19pZC9NYWtlZmlsZQlNb24gSnVs
IDI2IDAxOjE2OjMyIDE5OTkKQEAgLTE2LDYgKzE2LDEwIEBACiAKIE9CSlM9IHBnX2lkLm8KIAor
UE9UU1JDRklMRT0gcGdfaWQuYworCitQT1RPQkpGSUxFPSBwZ19pZC5wb3QKKwogIwogIyBBbmQg
d2hlcmUgbGlicHEgZ29lcywgc28gZ29lcyB0aGUgYXV0aGVudGljYXRpb24gc3R1ZmYuLi4KICMK
QEAgLTI0LDcgKzI4LDcgQEAKIENGTEFHUys9ICQoS1JCRkxBR1MpCiBlbmRpZgogCi1hbGw6IHBn
X2lkCithbGw6IHBnX2lkIHBvdAogCiBwZ19pZDogJChPQkpTKSAkKExJQlBRRElSKS9saWJwcS5h
CiAJJChDQykgLW8gcGdfaWQgLUwkKExJQlBRRElSKSAkKE9CSlMpIC1scHEgJChMREZMQUdTKQpA
QCAtMzgsOCArNDIsMTQgQEAKIGRlcGVuZCBkZXA6CiAJJChDQykgLU1NICQoQ0ZMQUdTKSAqLmMg
PmRlcGVuZAogCi1jbGVhbjogCitjbGVhbjogY2xlYW4tcG90CiAJcm0gLWYgcGdfaWQkKFgpICQo
T0JKUykgCisKK2NsZWFuLXBvdDoKKwlybSAtZiAkKFBPVE9CSkZJTEUpCisKK3BvdDoKKwl4Z2V0
dGV4dCAtQyAtLWtleXdvcmQ9Il8iIC1vICQoUE9UT0JKRklMRSkgJChQT1RTUkNGSUxFKQogCiBp
ZmVxIChkZXBlbmQsJCh3aWxkY2FyZCBkZXBlbmQpKQogaW5jbHVkZSBkZXBlbmQKZGlmZiAtdU5y
IHBvc3RncmVzcWwtNi41LjEtb3JpZy9zcmMvYmluL3BnX2lkL3BnX2lkLmMgcG9zdGdyZXNxbC02
LjUuMS9zcmMvYmluL3BnX2lkL3BnX2lkLmMKLS0tIHBvc3RncmVzcWwtNi41LjEtb3JpZy9zcmMv
YmluL3BnX2lkL3BnX2lkLmMJU3VuIEZlYiAxNCAwNzoyMDoyOSAxOTk5CisrKyBwb3N0Z3Jlc3Fs
LTYuNS4xL3NyYy9iaW4vcGdfaWQvcGdfaWQuYwlNb24gSnVsIDI2IDAxOjE2OjUxIDE5OTkKQEAg
LTIyLDYgKzIyLDEzIEBACiAjaW5jbHVkZSA8Z2V0b3B0Lmg+CiAjZW5kaWYKIAorI2luY2x1ZGUg
ImNvbmZpZy5oIgorCisjaWZkZWYgVVNFX01VTFRJTEFORworI2RlZmluZSBQQUNLQUdFCSJwZ19p
ZCIKKyNpbmNsdWRlICJtdWx0aWxhbmcuaCIKKyNlbmRpZgorCiBpbnQKIG1haW4oaW50IGFyZ2Ms
IGNoYXIgKiphcmd2KQogewpAQCAtMjksMTIgKzM2LDE2IEBACiAJaW50CQkJY2g7CiAJZXh0ZXJu
IGludAlvcHRpbmQ7CiAKKyNpZmRlZglVU0VfTVVMVElMQU5HCisJSW5pdE11bHRpTGFuZyhQQUNL
QUdFLCBMT0NBTEVESVIpOworI2VuZGlmCisKIAl3aGlsZSAoKGNoID0gZ2V0b3B0KGFyZ2MsIGFy
Z3YsICIiKSkgIT0gRU9GKQogCQlzd2l0Y2ggKGNoKQogCQl7CiAJCQljYXNlICc/JzoKIAkJCWRl
ZmF1bHQ6Ci0JCQkJZnByaW50ZihzdGRlcnIsICJ1c2FnZTogcGdfaWQgW2xvZ2luXVxuIik7CisJ
CQkJZnByaW50ZihzdGRlcnIsIF8oInVzYWdlOiBwZ19pZCBbbG9naW5dXG4iKSk7CiAJCQkJZXhp
dCgxKTsKIAkJfQogCWFyZ2MgLT0gb3B0aW5kOwpAQCAtNDQsMTIgKzU1LDEyIEBACiAJewogCQlp
ZiAoYXJnYyA+IDEpCiAJCXsKLQkJCWZwcmludGYoc3RkZXJyLCAidXNhZ2U6IHBnX2lkIFtsb2dp
bl1cbiIpOworCQkJZnByaW50ZihzdGRlcnIsIF8oInVzYWdlOiBwZ19pZCBbbG9naW5dXG4iKSk7
CiAJCQlleGl0KDEpOwogCQl9CiAJCWlmICgocHcgPSBnZXRwd25hbShhcmd2WzBdKSkgPT0gTlVM
TCkKIAkJewotCQkJcHJpbnRmKCJOT1VTRVJcbiIpOworCQkJcHJpbnRmKF8oIk5PVVNFUlxuIikp
OwogCQkJZXhpdCgxKTsKIAkJfQogCQlwcmludGYoIiVsZFxuIiwgKGxvbmcpIHB3LT5wd191aWQp
OwpkaWZmIC11TnIgcG9zdGdyZXNxbC02LjUuMS1vcmlnL3NyYy9iaW4vcGdfcGFzc3dkL01ha2Vm
aWxlIHBvc3RncmVzcWwtNi41LjEvc3JjL2Jpbi9wZ19wYXNzd2QvTWFrZWZpbGUKLS0tIHBvc3Rn
cmVzcWwtNi41LjEtb3JpZy9zcmMvYmluL3BnX3Bhc3N3ZC9NYWtlZmlsZQlTdW4gSmFuIDE3IDE0
OjE5OjEzIDE5OTkKKysrIHBvc3RncmVzcWwtNi41LjEvc3JjL2Jpbi9wZ19wYXNzd2QvTWFrZWZp
bGUJTW9uIEp1bCAyNiAwMToxOTo1NSAxOTk5CkBAIC05LDcgKzksMTEgQEAKIAogT0JKUz0gcGdf
cGFzc3dkLm8KIAotYWxsOiBwZ19wYXNzd2QKK1BPVFNSQ0ZJTEU9IHBnX3Bhc3N3ZC5jCisKK1BP
VE9CSkZJTEU9IHBnX3Bhc3N3ZC5wb3QKKworYWxsOiBwZ19wYXNzd2QgcG90CiAKIHBnX3Bhc3N3
ZDogJChPQkpTKQogCSQoQ0MpIC1vIHBnX3Bhc3N3ZCAkKE9CSlMpICQoTERGTEFHUykKQEAgLTI0
LDggKzI4LDE0IEBACiBkZXBlbmQgZGVwOgogCSQoQ0MpIC1NTSAkKENGTEFHUykgKi5jID5kZXBl
bmQKIAotY2xlYW46CitjbGVhbjogY2xlYW4tcG90CiAJcm0gLWYgcGdfcGFzc3dkJChYKSAkKE9C
SlMpCisKK2NsZWFuLXBvdDoKKwlybSAtZiAkKFBPVE9CSkZJTEUpCisKK3BvdDoKKwl4Z2V0dGV4
dCAtQyAtLWtleXdvcmQ9Il8iIC1vICQoUE9UT0JKRklMRSkgJChQT1RTUkNGSUxFKQogCiBpZmVx
IChkZXBlbmQsJCh3aWxkY2FyZCBkZXBlbmQpKQogaW5jbHVkZSBkZXBlbmQKZGlmZiAtdU5yIHBv
c3RncmVzcWwtNi41LjEtb3JpZy9zcmMvYmluL3BnX3Bhc3N3ZC9wZ19wYXNzd2QuYyBwb3N0Z3Jl
c3FsLTYuNS4xL3NyYy9iaW4vcGdfcGFzc3dkL3BnX3Bhc3N3ZC5jCi0tLSBwb3N0Z3Jlc3FsLTYu
NS4xLW9yaWcvc3JjL2Jpbi9wZ19wYXNzd2QvcGdfcGFzc3dkLmMJV2VkIE1heSAyNiAyMDo1Njox
MSAxOTk5CisrKyBwb3N0Z3Jlc3FsLTYuNS4xL3NyYy9iaW4vcGdfcGFzc3dkL3BnX3Bhc3N3ZC5j
CU1vbiBKdWwgMjYgMDE6MTg6MzYgMTk5OQpAQCAtMSw4ICsxLDE1IEBACiAvKgogICogQCgjKSBw
Z19wYXNzd2QuYyAxLjggMDk6MTM6MTYgOTcvMDcvMDIJCVkuIEljaGlrYXdhCiAgKi8KKwogI2lu
Y2x1ZGUgInBvc3RncmVzLmgiCiAKKworI2lmZGVmCVVTRV9NVUxUSUxBTkcKKyNkZWZpbmUJUEFD
S0FHRQkicGdfcGFzc3dkIgorI2luY2x1ZGUgIm11bHRpbGFuZy5oIgorI2VuZGlmCisKICNpbmNs
dWRlIDxzdGRpby5oPgogI2luY2x1ZGUgPHN0ZGxpYi5oPgogI2lmIGRlZmluZWQoSEFWRV9TVFJJ
TkdfSCkKQEAgLTM3LDcgKzQ0LDcgQEAKIHN0YXRpYyB2b2lkCiB1c2FnZShGSUxFICpzdHJlYW0p
CiB7Ci0JZnByaW50ZihzdHJlYW0sICJVc2FnZTogJXMgPHBhc3N3b3JkIGZpbGU+XG4iLCBjb21u
YW1lKTsKKwlmcHJpbnRmKHN0cmVhbSwgXygiVXNhZ2U6ICVzIDxwYXNzd29yZCBmaWxlPlxuIiks
IGNvbW5hbWUpOwogfQogCiB0eXBlZGVmIHN0cnVjdApAQCAtNzEsNyArNzgsNyBAQAogCXsKIAkJ
aWYgKGVycm5vID09IEVOT0VOVCkKIAkJewotCQkJcHJpbnRmKCJGaWxlIFwiJXNcIiBkb2VzIG5v
dCBleGlzdC4gIENyZWF0ZT8gKHkvbik6ICIsIGZpbGVuYW1lKTsKKwkJCXByaW50ZihfKCJGaWxl
IFwiJXNcIiBkb2VzIG5vdCBleGlzdC4gIENyZWF0ZT8gKHkvbik6ICIpLCBmaWxlbmFtZSk7CiAJ
CQlmZmx1c2goc3Rkb3V0KTsKIAkJCWZnZXRzKGFucywgMTI4LCBzdGRpbik7CiAJCQlzd2l0Y2gg
KGFuc1swXSkKQEAgLTExNCw3ICsxMjEsNyBAQAogCQkJbGluZVtsIC0gMV0gPSAnXDAnOwogCQll
bHNlCiAJCXsJCQkJCQkvKiB0b28gbG9uZyAqLwotCQkJZnByaW50ZihzdGRlcnIsICIlczogbGlu
ZSAlZDogbGluZSB0b28gbG9uZy5cbiIsCisJCQlmcHJpbnRmKHN0ZGVyciwgXygiJXM6IGxpbmUg
JWQ6IGxpbmUgdG9vIGxvbmcuXG4iKSwKIAkJCQkJZmlsZW5hbWUsIG5wd2RzICsgMSk7CiAJCQll
eGl0KDEpOwogCQl9CkBAIC0xMjMsMTQgKzEzMCwxNCBAQAogCQlwID0gbGluZTsKIAkJaWYgKChx
ID0gc3RyY2hyKHAsICc6JykpID09IE5VTEwpCiAJCXsKLQkJCWZwcmludGYoc3RkZXJyLCAiJXM6
IGxpbmUgJWQ6IGlsbGVnYWwgZm9ybWF0LlxuIiwKKwkJCWZwcmludGYoc3RkZXJyLCBfKCIlczog
bGluZSAlZDogaWxsZWdhbCBmb3JtYXQuXG4iKSwKIAkJCQkJZmlsZW5hbWUsIG5wd2RzICsgMSk7
CiAJCQlleGl0KDEpOwogCQl9CiAJCSoocSsrKSA9ICdcMCc7CiAJCWlmIChzdHJsZW4ocCkgPT0g
MCkKIAkJewotCQkJZnByaW50ZihzdGRlcnIsICIlczogbGluZSAlZDogbnVsbCB1c2VyIG5hbWUu
XG4iLAorCQkJZnByaW50ZihzdGRlcnIsIF8oIiVzOiBsaW5lICVkOiBudWxsIHVzZXIgbmFtZS5c
biIpLAogCQkJCQlmaWxlbmFtZSwgbnB3ZHMgKyAxKTsKIAkJCWV4aXQoMSk7CiAJCX0KQEAgLTE0
MSw3ICsxNDgsNyBAQAogCQl7CiAJCQlpZiAoc3RyY21wKHB3ZHNbaV0udW5hbWUsIHB3ZHNbbnB3
ZHNdLnVuYW1lKSA9PSAwKQogCQkJewotCQkJCWZwcmludGYoc3RkZXJyLCAiJXM6IGR1cGxpY2F0
ZWQgZW50cnkuXG4iLCBwd2RzW25wd2RzXS51bmFtZSk7CisJCQkJZnByaW50ZihzdGRlcnIsIF8o
IiVzOiBkdXBsaWNhdGVkIGVudHJ5LlxuIiksIHB3ZHNbbnB3ZHNdLnVuYW1lKTsKIAkJCQlleGl0
KDEpOwogCQkJfQogCQl9CkBAIC0xNjAsNyArMTY3LDcgQEAKIAkJCSoocSsrKSA9ICdcMCc7CiAJ
CWlmIChzdHJsZW4ocCkgIT0gMTMpCiAJCXsKLQkJCWZwcmludGYoc3RkZXJyLCAiV0FSTklORzog
JXM6IGxpbmUgJWQ6IGlsbGVnYWwgcGFzc3dvcmQgbGVuZ3RoLlxuIiwKKwkJCWZwcmludGYoc3Rk
ZXJyLCBfKCJXQVJOSU5HOiAlczogbGluZSAlZDogaWxsZWdhbCBwYXNzd29yZCBsZW5ndGguXG4i
KSwKIAkJCQkJZmlsZW5hbWUsIG5wd2RzICsgMSk7CiAJCX0KIAkJcHdkc1tucHdkc10ucHdkID0g
c3RyZHVwKHApOwpAQCAtMjQ3LDcgKzI1NCw3IEBACiAJLyogc2hvdyBpdCAqLwogCiAJLyoKLQkg
KiBmcHJpbnRmKHN0ZGVyciwgImtleSA9ICVzLCBzYWx0ID0gJXMsIHBhc3N3b3JkID0gJXNcbiIs
IGtleSwgc2FsdCwKKwkgKiBmcHJpbnRmKHN0ZGVyciwgXygia2V5ID0gJXMsIHNhbHQgPSAlcywg
cGFzc3dvcmQgPSAlc1xuIiksIGtleSwgc2FsdCwKIAkgKiBwYXNzd2QpOwogCSAqLwogfQpAQCAt
MjczLDcgKzI4MCw3IEBACiB7CiAJaW50CQkJbGVuZ3RoOwogCi0JcHJpbnRmKCJVc2VybmFtZTog
Iik7CisJcHJpbnRmKF8oIlVzZXJuYW1lOiAiKSk7CiAJZmdldHModXNlcm5hbWUsIDksIHN0ZGlu
KTsKIAlsZW5ndGggPSBzdHJsZW4odXNlcm5hbWUpOwogCkBAIC0zNDIsNiArMzQ5LDEwIEBACiAJ
Y2hhcgkJZV9wYXNzd2RbMTRdOwogCWludAkJCWk7CiAKKyNpZmRlZglVU0VfTVVMVElMQU5HCisJ
SW5pdE11bHRpTGFuZyhQQUNLQUdFLCBMT0NBTEVESVIpOworI2VuZGlmCisKIAljb21uYW1lID0g
YXJndlswXTsKIAlpZiAoYXJnYyAhPSAyKQogCXsKQEAgLTM1NSwxMSArMzY2LDExIEBACiAKIAkv
KiBhc2sgZm9yIHRoZSB1c2VyIG5hbWUgYW5kIHRoZSBwYXNzd29yZCAqLwogCXByb21wdF9mb3Jf
dXNlcm5hbWUodXNlcm5hbWUpOwotCXByb21wdF9mb3JfcGFzc3dvcmQoIk5ldyBwYXNzd29yZDog
Iiwga2V5KTsKLQlwcm9tcHRfZm9yX3Bhc3N3b3JkKCJSZS1lbnRlciBuZXcgcGFzc3dvcmQ6ICIs
IGtleTIpOworCXByb21wdF9mb3JfcGFzc3dvcmQoXygiTmV3IHBhc3N3b3JkOiAiKSwga2V5KTsK
Kwlwcm9tcHRfZm9yX3Bhc3N3b3JkKF8oIlJlLWVudGVyIG5ldyBwYXNzd29yZDogIiksIGtleTIp
OwogCWlmIChzdHJuY21wKGtleSwga2V5MiwgOCkgIT0gMCkKIAl7Ci0JCWZwcmludGYoc3RkZXJy
LCAiUGFzc3dvcmQgbWlzbWF0Y2guXG4iKTsKKwkJZnByaW50ZihzdGRlcnIsIF8oIlBhc3N3b3Jk
IG1pc21hdGNoLlxuIikpOwogCQlleGl0KDEpOwogCX0KIAlzYWx0WzBdID0gJ1wwJzsKQEAgLTM3
OCw3ICszODksNyBAQAogCXsJCQkJCQkJLyogZGlkIG5vdCBleGlzdCAqLwogCQlpZiAobnB3ZHMg
PT0gTUFYUFdEUykKIAkJewotCQkJZnByaW50ZihzdGRlcnIsICIlczogY2Fubm90IGhhbmRsZSBz
byBtYXkgZW50cmllcy5cbiIsIGNvbW5hbWUpOworCQkJZnByaW50ZihzdGRlcnIsIF8oIiVzOiBj
YW5ub3QgaGFuZGxlIHNvIG1heSBlbnRyaWVzLlxuIiksIGNvbW5hbWUpOwogCQkJZXhpdCgxKTsK
IAkJfQogCQlwd2RzW25wd2RzXS51bmFtZSA9IHN0cmR1cCh1c2VybmFtZSk7CmRpZmYgLXVOciBw
b3N0Z3Jlc3FsLTYuNS4xLW9yaWcvc3JjL2Jpbi9wZ192ZXJzaW9uL01ha2VmaWxlLmluIHBvc3Rn
cmVzcWwtNi41LjEvc3JjL2Jpbi9wZ192ZXJzaW9uL01ha2VmaWxlLmluCi0tLSBwb3N0Z3Jlc3Fs
LTYuNS4xLW9yaWcvc3JjL2Jpbi9wZ192ZXJzaW9uL01ha2VmaWxlLmluCVN1biBKYW4gMTcgMTQ6
MTk6MTQgMTk5OQorKysgcG9zdGdyZXNxbC02LjUuMS9zcmMvYmluL3BnX3ZlcnNpb24vTWFrZWZp
bGUuaW4JTW9uIEp1bCAyNiAwMTowODozOCAxOTk5CkBAIC0xOCw3ICsxOCwxMyBAQAogCiBDRkxB
R1MrPSAtSSQoU1JDRElSKS9pbmNsdWRlCiAKLWFsbDogcGdfdmVyc2lvbgorCitQT1RTUkNGSUxF
PQlwZ192ZXJzaW9uLmMKKworUE9UT0JKRklMRT0JcGdfdmVyc2lvbi5wb3QKKworCithbGw6IHBn
X3ZlcnNpb24gcG90CiAKIHBnX3ZlcnNpb246IHN1Ym1ha2UgJChPQkpTKQogCSQoQ0MpIC1vIHBn
X3ZlcnNpb24gJChPQkpTKSAkKExERkxBR1MpCkBAIC0zMyw4ICszOSwxNCBAQAogZGVwZW5kIGRl
cDoKIAkkKENDKSAtTU0gJChDRkxBR1MpICouYyA+ZGVwZW5kCiAKLWNsZWFuOiAKK2NsZWFuOiBj
bGVhbi1wb3QKIAlybSAtZiBwZ192ZXJzaW9uJChYKSBwZ192ZXJzaW9uLm8KKworY2xlYW4tcG90
OgorCXJtIC1mICQoUE9UT0JKRklMRSkKKworcG90OgorCXhnZXR0ZXh0IC1DIC0ta2V5d29yZD0i
XyIgLW8gJChQT1RPQkpGSUxFKSAkKFBPVFNSQ0ZJTEUpCiAKIGlmZXEgKGRlcGVuZCwkKHdpbGRj
YXJkIGRlcGVuZCkpCiBpbmNsdWRlIGRlcGVuZApkaWZmIC11TnIgcG9zdGdyZXNxbC02LjUuMS1v
cmlnL3NyYy9iaW4vcGdfdmVyc2lvbi9wZ192ZXJzaW9uLmMgcG9zdGdyZXNxbC02LjUuMS9zcmMv
YmluL3BnX3ZlcnNpb24vcGdfdmVyc2lvbi5jCi0tLSBwb3N0Z3Jlc3FsLTYuNS4xLW9yaWcvc3Jj
L2Jpbi9wZ192ZXJzaW9uL3BnX3ZlcnNpb24uYwlTdW4gRmViIDE0IDA3OjIwOjMyIDE5OTkKKysr
IHBvc3RncmVzcWwtNi41LjEvc3JjL2Jpbi9wZ192ZXJzaW9uL3BnX3ZlcnNpb24uYwlNb24gSnVs
IDI2IDAwOjU2OjM0IDE5OTkKQEAgLTE0LDYgKzE0LDEzIEBACiAjaW5jbHVkZSA8c3RkbGliLmg+
CiAjaW5jbHVkZSA8c3RkaW8uaD4KIAorI2luY2x1ZGUgImNvbmZpZy5oIgorCisjaWZkZWYJVVNF
X01VTFRJTEFORworI2RlZmluZSBQQUNLQUdFICJwZ192ZXJzaW9uIgorI2luY2x1ZGUgIm11bHRp
bGFuZy5oIgorI2VuZGlmCisKICNpbmNsdWRlICJ2ZXJzaW9uLmgiCQkJLyogaW50ZXJmYWNlIHRv
IFNldFBnVmVyc2lvbiAqLwogCiAKQEAgLTI1LDE3ICszMiwyMSBAQAogCWNoYXIJICAgKnJlYXNv
bjsJCQkvKiBSZWFzb24gdGhhdCBTZXRQZ1ZlcnNpb24gZmFpbGVkLCBOVUxMCiAJCQkJCQkJCSAq
IGlmIGl0IGRpZG4ndC4gKi8KIAorI2lmZGVmCVVTRV9NVUxUSUxBTkcKKwlJbml0TXVsdGlMYW5n
KFBBQ0tBR0UsIExPQ0FMRURJUik7CisjZW5kaWYKKwogCWlmIChhcmdjIDwgMikKIAl7Ci0JCWZw
cmludGYoc3RkZXJyLCAicGdfdmVyc2lvbjogbWlzc2luZyBhcmd1bWVudFxuIik7CisJCWZwcmlu
dGYoc3RkZXJyLCBfKCJwZ192ZXJzaW9uOiBtaXNzaW5nIGFyZ3VtZW50XG4iKSk7CiAJCWV4aXQo
MSk7CiAJfQogCVNldFBnVmVyc2lvbihhcmd2WzFdLCAmcmVhc29uKTsKIAlpZiAocmVhc29uKQog
CXsKIAkJZnByaW50ZihzdGRlcnIsCi0JCQkJInBnX3ZlcnNpb24gaXMgdW5hYmxlIHRvIGNyZWF0
ZSB0aGUgUEdfVkVSU0lPTiBmaWxlLiAiCi0JCQkJIlNldFBnVmVyc2lvbiBnYXZlIHRoaXMgcmVh
c29uOiAlc1xuIiwKKwkJCQlfKCJwZ192ZXJzaW9uIGlzIHVuYWJsZSB0byBjcmVhdGUgdGhlIFBH
X1ZFUlNJT04gZmlsZS4gIgorCQkJCSJTZXRQZ1ZlcnNpb24gZ2F2ZSB0aGlzIHJlYXNvbjogJXNc
biIpLAogCQkJCXJlYXNvbik7CiAJCXJldGNvZGUgPSAxMDsKIAl9CmRpZmYgLXVOciBwb3N0Z3Jl
c3FsLTYuNS4xLW9yaWcvc3JjL2Jpbi9wZ192ZXJzaW9uL3BnX3ZlcnNpb24ucG90IHBvc3RncmVz
cWwtNi41LjEvc3JjL2Jpbi9wZ192ZXJzaW9uL3BnX3ZlcnNpb24ucG90Ci0tLSBwb3N0Z3Jlc3Fs
LTYuNS4xLW9yaWcvc3JjL2Jpbi9wZ192ZXJzaW9uL3BnX3ZlcnNpb24ucG90CVRodSBKYW4gIDEg
MDg6MDA6MDAgMTk3MAorKysgcG9zdGdyZXNxbC02LjUuMS9zcmMvYmluL3BnX3ZlcnNpb24vcGdf
dmVyc2lvbi5wb3QJTW9uIEp1bCAyNiAwMTowMzo0MSAxOTk5CkBAIC0wLDAgKzEsMjYgQEAKKyMg
U09NRSBERVNDUklQVElWRSBUSVRMRS4KKyMgQ29weXJpZ2h0IChDKSBZRUFSIEZyZWUgU29mdHdh
cmUgRm91bmRhdGlvbiwgSW5jLgorIyBGSVJTVCBBVVRIT1IgPEVNQUlMQEFERFJFU1M+LCBZRUFS
LgorIworIywgZnV6enkKK21zZ2lkICIiCittc2dzdHIgIiIKKyJQcm9qZWN0LUlkLVZlcnNpb246
IHBnX3ZlcnNpb25cbiIKKyJQT1QtQ3JlYXRpb24tRGF0ZTogMTk5OS0wNy0yNiAwMDo1OSswODAw
XG4iCisiUE8tUmV2aXNpb24tRGF0ZTogMTk5OS0wNy0yNiAwMTowMCswODAwXG4iCisiTGFzdC1U
cmFuc2xhdG9yOiBDZCBDaGVuIDxjZGNoZW5AbWFpbC5jeW5peC5jb20udHc+XG4iCisiTGFuZ3Vh
Z2UtVGVhbTogQ2hpbmVzZSA8emhAbGkub3JnPlxuIgorIk1JTUUtVmVyc2lvbjogMS4wXG4iCisi
Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PUJpZzVcbiIKKyJDb250ZW50LVRyYW5z
ZmVyLUVuY29kaW5nOiA4Qml0XG4iCisKKyM6IHBnX3ZlcnNpb24uYzo0MQorbXNnaWQgInBnX3Zl
cnNpb246IG1pc3NpbmcgYXJndW1lbnRcbiIKK21zZ3N0ciAicGdfdmVyc2lvbjogpN68xqSjqKxc
biIKKworIzogcGdfdmVyc2lvbi5jOjQ4CisjLCBjLWZvcm1hdAorbXNnaWQgIiIKKyJwZ192ZXJz
aW9uIGlzIHVuYWJsZSB0byBjcmVhdGUgdGhlIFBHX1ZFUlNJT04gZmlsZS4gU2V0UGdWZXJzaW9u
IGdhdmUgdGhpcyAiCisicmVhc29uOiAlc1xuIgorbXNnc3RyICJwZ192ZXJzaW9uILVMqmur2KXf
IFBHX1ZFUlNJT04gwMmu16FDU2VyUGdWZXJzaW9uIKq6snql0axPOiAlc1xuIgpkaWZmIC11TnIg
cG9zdGdyZXNxbC02LjUuMS1vcmlnL3NyYy9iaW4vcHNxbC9NYWtlZmlsZS5pbiBwb3N0Z3Jlc3Fs
LTYuNS4xL3NyYy9iaW4vcHNxbC9NYWtlZmlsZS5pbgotLS0gcG9zdGdyZXNxbC02LjUuMS1vcmln
L3NyYy9iaW4vcHNxbC9NYWtlZmlsZS5pbglTdW4gSmFuIDE3IDE0OjE5OjE5IDE5OTkKKysrIHBv
c3RncmVzcWwtNi41LjEvc3JjL2Jpbi9wc3FsL01ha2VmaWxlLmluCU1vbiBKdWwgMjYgMDE6MjM6
MTkgMTk5OQpAQCAtMzAsNyArMzAsMTIgQEAKIAogT0JKUz0gcHNxbC5vIHN0cmluZ3V0aWxzLm8g
QFNUUkRVUEAgQFNUUkVSUk9SMkAKIAotYWxsOiBzdWJtYWtlIHBzcWwKKworUE9UU1JDRklMRT0g
cHNxbC5jIHBzcWxIZWxwLmggc3RyaW5ndXRpbHMuYyBzdHJpbmd1dGlscy5oCisKK1BPVE9CSkZJ
TEU9IHBzcWwucG90CisKK2FsbDogc3VibWFrZSBwc3FsIHBvdAogCiBwc3FsOiAkKE9CSlMpICQo
TElCUFFESVIpL2xpYnBxLmEKIAkkKENDKSAtbyBwc3FsIC1MJChMSUJQUURJUikgJChPQkpTKSAt
bHBxICQoTERGTEFHUykKQEAgLTQ4LDggKzUzLDE0IEBACiBkZXBlbmQgZGVwOgogCSQoQ0MpIC1N
TSAkKENGTEFHUykgKi5jID5kZXBlbmQKIAotY2xlYW46IAorY2xlYW46IGNsZWFuLXBvdAogCXJt
IC1mIHBzcWwkKFgpICQoT0JKUykgCisKK2NsZWFuLXBvdDoKKwlybSAtZiAkKFBPVE9CSkZJTEUp
CisKK3BvdDoKKwl4Z2V0dGV4dCAtQyAtLWtleXdvcmQ9Il8iIC1vICQoUE9UT0JKRklMRSkgJChQ
T1RTUkNGSUxFKQogCiBpZmVxIChkZXBlbmQsJCh3aWxkY2FyZCBkZXBlbmQpKQogaW5jbHVkZSBk
ZXBlbmQKZGlmZiAtdU5yIHBvc3RncmVzcWwtNi41LjEtb3JpZy9zcmMvYmluL3BzcWwvbWVzc2Fn
ZXMucG8gcG9zdGdyZXNxbC02LjUuMS9zcmMvYmluL3BzcWwvbWVzc2FnZXMucG8KLS0tIHBvc3Rn
cmVzcWwtNi41LjEtb3JpZy9zcmMvYmluL3BzcWwvbWVzc2FnZXMucG8JVGh1IEphbiAgMSAwODow
MDowMCAxOTcwCisrKyBwb3N0Z3Jlc3FsLTYuNS4xL3NyYy9iaW4vcHNxbC9tZXNzYWdlcy5wbwlT
dW4gSnVsIDI1IDIyOjU1OjQ5IDE5OTkKQEAgLTAsMCArMSwzNzQgQEAKKyMgU09NRSBERVNDUklQ
VElWRSBUSVRMRS4KKyMgQ29weXJpZ2h0IChDKSBZRUFSIEZyZWUgU29mdHdhcmUgRm91bmRhdGlv
biwgSW5jLgorIyBGSVJTVCBBVVRIT1IgPEVNQUlMQEFERFJFU1M+LCBZRUFSLgorIworIywgZnV6
enkKK21zZ2lkICIiCittc2dzdHIgIiIKKyJQcm9qZWN0LUlkLVZlcnNpb246IFBBQ0tBR0UgVkVS
U0lPTlxuIgorIlBPVC1DcmVhdGlvbi1EYXRlOiAxOTk5LTA3LTI1IDIyOjU1KzA4MDBcbiIKKyJQ
Ty1SZXZpc2lvbi1EYXRlOiBZRUFSLU1PLURBIEhPOk1JK1pPTkVcbiIKKyJMYXN0LVRyYW5zbGF0
b3I6IEZVTEwgTkFNRSA8RU1BSUxAQUREUkVTUz5cbiIKKyJMYW5ndWFnZS1UZWFtOiBMQU5HVUFH
RSA8TExAbGkub3JnPlxuIgorIk1JTUUtVmVyc2lvbjogMS4wXG4iCisiQ29udGVudC1UeXBlOiB0
ZXh0L3BsYWluOyBjaGFyc2V0PUNIQVJTRVRcbiIKKyJDb250ZW50LVRyYW5zZmVyLUVuY29kaW5n
OiBFTkNPRElOR1xuIgorCisjOiBwc3FsSGVscC5oOjIyCittc2dpZCAiYWJvcnQgdGhlIGN1cnJl
bnQgdHJhbnNhY3Rpb24iCittc2dzdHIgIiIKKworIzogcHNxbEhlbHAuaDoyMworbXNnaWQgIlx0
YWJvcnQgW3RyYW5zYWN0aW9ufHdvcmtdOyIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVscC5oOjI2
Cittc2dpZCAiYWRkL3JlbmFtZSBhdHRyaWJ1dGVzLCByZW5hbWUgdGFibGVzIgorbXNnc3RyICIi
CisKKyM6IHBzcWxIZWxwLmg6MjcKK21zZ2lkICIiCisiXHRBTFRFUiBUQUJMRSBjbGFzc19uYW1l
IFsqXSBBREQgQ09MVU1OIGF0dHIgdHlwZVxuIgorIlx0QUxURVIgVEFCTEUgY2xhc3NfbmFtZSBb
Kl0gUkVOQU1FIFtDT0xVTU5dIGF0dHIxIFRPIGF0dHIyXG4iCisiXHRBTFRFUiBUQUJMRSBjbGFz
c19uYW1lMSBSRU5BTUUgVE8gY2xhc3NfbmFtZTIiCittc2dzdHIgIiIKKworIzogcHNxbEhlbHAu
aDozMgorbXNnaWQgImFsdGVyIHN5c3RlbSBpbmZvcm1hdGlvbiBmb3IgYSB1c2VyIgorbXNnc3Ry
ICIiCisKKyM6IHBzcWxIZWxwLmg6MzMKK21zZ2lkICIiCisiXHRBTFRFUiBVU0VSIHVzZXJfbmFt
ZVxuIgorIlx0W1dJVEggUEFTU1dPUkQgcGFzc3dvcmRdXG4iCisiXHRbQ1JFQVRFREIgfCBOT0ND
UkVBVEVEQl1cbiIKKyJcdFtDUkVBVEVVU0VSIHwgTk9DUkVBVEVVU0VSXVxuIgorIlx0W0lOIEdS
T1VQIGdyb3VwXzEsIC4uLmdyb3VwTl1cbiIKKyJcdFtWQUxJRCBVTlRJTCAnYWJzdGltZSddOyIK
K21zZ3N0ciAiIgorCisjOiBwc3FsSGVscC5oOjQxCittc2dpZCAiYmVnaW4gYSBuZXcgdHJhbnNh
Y3Rpb24iCittc2dzdHIgIiIKKworIzogcHNxbEhlbHAuaDo0MgorbXNnaWQgIlx0QkVHSU4gW1dP
Ukt8VFJBTlNBQ1RJT05dOyIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVscC5oOjQ1Cittc2dpZCAi
Y3JlYXRlIGEgY2x1c3RlcmVkIGluZGV4IChmcm9tIGFuIGV4aXN0aW5nIGluZGV4KSIKK21zZ3N0
ciAiIgorCisjOiBwc3FsSGVscC5oOjQ2Cittc2dpZCAiXHRDTFVTVEVSIGluZGV4X25hbWUgT04g
cmVsYXRpb25fbmFtZSIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVscC5oOjQ5Cittc2dpZCAiY2xv
c2UgYW4gZXhpc3RpbmcgY3Vyc29yIChjdXJzb3IpIgorbXNnc3RyICIiCisKKyM6IHBzcWxIZWxw
Lmg6NTAKK21zZ2lkICJcdENMT1NFIGN1cnNvcm5hbWU7IgorbXNnc3RyICIiCisKKyM6IHBzcWxI
ZWxwLmg6NTMKK21zZ2lkICJjb21taXQgYSB0cmFuc2FjdGlvbiIKK21zZ3N0ciAiIgorCisjOiBw
c3FsSGVscC5oOjU0Cittc2dpZCAiXHRDT01NSVQgW1dPUkt8VFJBTlNBQ1RJT05dIgorbXNnc3Ry
ICIiCisKKyM6IHBzcWxIZWxwLmg6NTcKK21zZ2lkICJjb3B5IGRhdGEgdG8gYW5kIGZyb20gYSB0
YWJsZSIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVscC5oOjU4Cittc2dpZCAiIgorIlx0Q09QWSBb
QklOQVJZXSBjbGFzc19uYW1lIFtXSVRIIE9JRFNdXG4iCisiXHRUT3xGUk9NIGZpbGVuYW1lfFNU
RElOfFNURE9VVCBbVVNJTkcgREVMSU1JVEVSUyAnZGVsaW0nXTsiCittc2dzdHIgIiIKKworIzog
cHNxbEhlbHAuaDo2MiBwc3FsSGVscC5oOjE4NAorbXNnaWQgIlBsZWFzZSBiZSBtb3JlIHNwZWNp
ZmljOiIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVscC5oOjc2Cittc2dpZCAiZGVmaW5lIGFuIGFn
Z3JlZ2F0ZSBmdW5jdGlvbiIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVscC5oOjc3Cittc2dpZCAi
IgorIlx0Q1JFQVRFIEFHR1JFR0FURSBhZ2dfbmFtZSBbQVNdIChCQVNFVFlQRSA9IGRhdGFfdHlw
ZSwgXG4iCisiXHRbU0ZVTkMxID0gc2Z1bmNfMSwgU1RZUEUxID0gc2Z1bmMxX3JldHVybl90eXBl
XVxuIgorIlx0W1NGVU5DMiA9IHNmdW5jXzIsIFNUWVBFMiA9IHNmdW5jMl9yZXR1cm5fdHlwZV1c
biIKKyJcdFssRklOQUxGVU5DID0gZmluYWwtZnVuY3Rpb25dXG4iCisiXHRbLElOSVRDT05EMSA9
IGluaXRpYWwtY29uZDFdWyxJTklUQ09ORDIgPSBpbml0aWFsLWNvbmQyXSk7IgorbXNnc3RyICIi
CisKKyM6IHBzcWxIZWxwLmg6ODQKK21zZ2lkICJjcmVhdGUgYSBkYXRhYmFzZSIKK21zZ3N0ciAi
IgorCisjOiBwc3FsSGVscC5oOjg1Cittc2dpZCAiXHRDUkVBVEUgREFUQUJBU0UgZGJuYW1lIFtX
SVRIIExPQ0FUSU9OID0gJ2RicGF0aCddIgorbXNnc3RyICIiCisKKyM6IHBzcWxIZWxwLmg6ODgK
K21zZ2lkICJjcmVhdGUgYSB1c2VyLWRlZmluZWQgZnVuY3Rpb24iCittc2dzdHIgIiIKKworIzog
cHNxbEhlbHAuaDo4OQorbXNnaWQgIiIKKyJcdENSRUFURSBGVU5DVElPTiBmdW5jdGlvbl9uYW1l
IChbdHlwZTEsIC4uLnR5cGVOXSkgUkVUVVJOUyByZXR1cm5fdHlwZVxuIgorIlx0QVMgJ29iamVj
dF9maWxlbmFtZSd8J3NxbC1xdWVyaWVzJ3wnYnVpbHRpbl9mdW5jdGlvbl9uYW1lJ1xuIgorIlx0
TEFOR1VBR0UgJ2MnfCdzcWwnfCdpbnRlcm5hbCc7IgorbXNnc3RyICIiCisKKyM6IHBzcWxIZWxw
Lmg6OTQKK21zZ2lkICJjb25zdHJ1Y3QgYW4gaW5kZXgiCittc2dzdHIgIiIKKworIzogcHNxbEhl
bHAuaDo5NQorbXNnaWQgIiIKKyJcdENSRUFURSBbVU5JUVVFXSBJTkRFWCBpbmRleG5hbWUgT04g
Y2xhc3NfbmFtZSBbVVNJTkcgYWNjZXNzX21ldGhvZF1cbiIKKyIoIGF0dHIxIFt0eXBlX2NsYXNz
MV0sIC4uLmF0dHJOIHwgZnVuY25hbWUoYXR0cjEsIC4uLikgW3R5cGVfY2xhc3NdICk7IgorbXNn
c3RyICIiCisKKyM6IHBzcWxIZWxwLmg6OTkKK21zZ2lkICJjcmVhdGUgYSB1c2VyLWRlZmluZWQg
b3BlcmF0b3IiCittc2dzdHIgIiIKKworIzogcHNxbEhlbHAuaDoxMDAKK21zZ2lkICIiCisiXHRD
UkVBVEUgT1BFUkFUT1Igb3BlcmF0b3JfbmFtZSAoXG4iCisiXHRbTEVGVEFSRyA9IHR5cGUxXVss
UklHSFRBUkcgPSB0eXBlMl1cbiIKKyJcdCxQUk9DRURVUkUgPSBmdW5jX25hbWUsXG4iCisiXHRb
LENPTU1VVEFUT1IgPSBjb21fb3BdWyxORUdBVE9SID0gbmVnX29wXVxuIgorIlx0WyxSRVNUUklD
VCA9IHJlc19wcm9jXVssSk9JTiA9IGpvaW5fcHJvY11bLEhBU0hFU11cbiIKKyJcdFssU09SVDEg
PSBsZWZ0X3NvcnRfb3BdWyxTT1JUMiA9IHJpZ2h0X3NvcnRfb3BdKTsiCittc2dzdHIgIiIKKwor
IzogcHNxbEhlbHAuaDoxMDgKK21zZ2lkICJkZWZpbmUgYSBuZXcgcnVsZSIKK21zZ3N0ciAiIgor
CisjOiBwc3FsSGVscC5oOjEwOQorbXNnaWQgIiIKKyJcdENSRUFURSBSVUxFIHJ1bGVfbmFtZSBB
UyBPTlxuIgorIlx0eyBTRUxFQ1QgfCBVUERBVEUgfCBERUxFVEUgfCBJTlNFUlQgfVxuIgorIlx0
VE8gb2JqZWN0IFtXSEVSRSBxdWFsXVxuIgorIlx0RE8gW0lOU1RFQURdIFthY3Rpb258Tk9USElO
R3xbYWN0aW9uc11dOyIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVscC5oOjExNQorbXNnaWQgImNy
ZWF0ZSBhIG5ldyBzZXF1ZW5jZSBudW1iZXIgZ2VuZXJhdG9yIgorbXNnc3RyICIiCisKKyM6IHBz
cWxIZWxwLmg6MTE2Cittc2dpZCAiIgorIlx0Q1JFQVRFIFNFUVVFTkNFIHNlcXVlbmNlX25hbWVc
biIKKyJcdFtJTkNSRU1FTlQgbnVtYmVyXVxuIgorIlx0W1NUQVJUIG51bWJlcl1cbiIKKyJcdFtN
SU5WQUxVRSBudW1iZXJdXG4iCisiXHRbTUFYVkFMVUUgbnVtYmVyXVxuIgorIlx0W0NBQ0hFIG51
bWJlcl1cbiIKKyJcdFtDWUNMRV07IgorbXNnc3RyICIiCisKKyM6IHBzcWxIZWxwLmg6MTI1Citt
c2dpZCAiY3JlYXRlIGEgbmV3IHRhYmxlIgorbXNnc3RyICIiCisKKyM6IHBzcWxIZWxwLmg6MTI2
Cittc2dpZCAiIgorIlx0Q1JFQVRFIFtURU1QXSBUQUJMRSBjbGFzc19uYW1lXG4iCisiXHQoYXR0
cjEgdHlwZTEgW0RFRkFVTFQgZXhwcmVzc2lvbl0gW05PVCBOVUxMXSwgLi4uYXR0ck5cbiIKKyJc
dFtbQ09OU1RSQUlOVCBuYW1lXSBDSEVDSyBjb25kaXRpb24xLCAuLi5jb25kaXRpb25OXSApXG4i
CisiXHRbSU5IRVJJVFMgKGNsYXNzX25hbWUxLCAuLi5jbGFzc19uYW1lTilcbiIKKyI7IgorbXNn
c3RyICIiCisKKyM6IHBzcWxIZWxwLmg6MTMzCittc2dpZCAiY3JlYXRlIGEgbmV3IHRyaWdnZXIi
Cittc2dzdHIgIiIKKworIzogcHNxbEhlbHAuaDoxMzQKK21zZ2lkICIiCisiXHRDUkVBVEUgVFJJ
R0dFUiB0cmlnZ2VyX25hbWUgQUZURVJ8QkVGT1JFIGV2ZW50MSBbT1IgZXZlbnQyIFtPUiBldmVu
dDNdIF1cbiIKKyJcdE9OIGNsYXNzX25hbWUgRk9SIEVBQ0ggUk9XfFNUQVRFTUVOVFxuIgorIlx0
RVhFQ1VURSBQUk9DRURVUkUgZnVuY19uYW1lIChbYXJndW1lbnRzXSlcbiIKKyJcbiIKKyJcdGV2
ZW50WCBpcyBvbmUgb2YgSU5TRVJULCBERUxFVEUsIFVQREFURSIKK21zZ3N0ciAiIgorCisjOiBw
c3FsSGVscC5oOjE0MQorbXNnaWQgImNyZWF0ZSBhIG5ldyB1c2VyLWRlZmluZWQgYmFzZSBkYXRh
IHR5cGUiCittc2dzdHIgIiIKKworIzogcHNxbEhlbHAuaDoxNDIKK21zZ2lkICIiCisiXHRDUkVB
VEUgVFlQRSB0eXBlbmFtZSAoXG4iCisiXHRJTlRFUk5BTExFTkdUSCA9IChudW1iZXJ8VkFSSUFC
TEUpLFxuIgorIlx0W0VYVEVSTkFMTEVOR1RIID0gKG51bWJlcnxWQVJJQUJMRSksXVxuIgorIlx0
SU5QVVQgPSBpbnB1dF9mdW5jdGlvbiwgT1VUUFVUID0gb3V0cHV0X2Z1bmN0aW9uXG4iCisiXHRb
LEVMRU1FTlQgPSB0eXBlbmFtZV1bLERFTElNSVRFUiA9IGNoYXJhY3Rlcl1bLERFRkFVTFQ9Jzxz
dHJpbmc+J11cbiIKKyJcdFssU0VORCA9IHNlbmRfZnVuY3Rpb25dWyxSRUNFSVZFID0gcmVjZWl2
ZV9mdW5jdGlvbl1bLFBBU1NFREJZVkFMVUVdKTsiCittc2dzdHIgIiIKKworIzogcHNxbEhlbHAu
aDoxNTAKK21zZ2lkICJjcmVhdGUgYSBuZXcgdXNlciIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVs
cC5oOjE1MQorbXNnaWQgIiIKKyJcdENSRUFURSBVU0VSIHVzZXJfbmFtZVxuIgorIlx0W1dJVEgg
UEFTU1dPUkQgcGFzc3dvcmRdXG4iCisiXHRbQ1JFQVRFREIgfCBOT0NSRUFURURCXVxuIgorIlx0
W0NSRUFURVVTRVIgfCBOT0NSRUFURVVTRVJdXG4iCisiXHRbSU4gR1JPVVAgZ3JvdXAxLCAuLi5n
cm91cE5dXG4iCisiXHRbVkFMSUQgVU5USUwgJ2Fic3RpbWUnXTsiCittc2dzdHIgIiIKKworIzog
cHNxbEhlbHAuaDoxNTkKK21zZ2lkICJjcmVhdGUgYSB2aWV3IgorbXNnc3RyICIiCisKKyM6IHBz
cWxIZWxwLmg6MTYwCittc2dpZCAiIgorIlx0Q1JFQVRFIFZJRVcgdmlld19uYW1lIEFTXG4iCisi
XHRTRUxFQ1QgW0RJU1RJTkNUIFtPTiBhdHRyTl1dXG4iCisiXHRleHByMSBbQVMgYXR0cjFdLCAu
Li5leHByTlxuIgorIlx0W0ZST00gZnJvbV9saXN0XVxuIgorIlx0W1dIRVJFIHF1YWxdXG4iCisi
XHRbR1JPVVAgQlkgZ3JvdXBfbGlzdF07IgorbXNnc3RyICIiCisKKyM6IHBzcWxIZWxwLmg6MTY4
Cittc2dpZCAic2V0IHVwIGEgY3Vyc29yIgorbXNnc3RyICIiCisKKyM6IHBzcWxIZWxwLmg6MTY5
Cittc2dpZCAiIgorIlx0REVDTEFSRSBjdXJzb3JuYW1lIFtCSU5BUlldIENVUlNPUiBGT1JcbiIK
KyJcdFNFTEVDVCBbRElTVElOQ1QgW09OIGF0dHJOXV1cbiIKKyJcdGV4cHIxIFtBUyBhdHRyMV0s
IC4uLmV4cHJOXG4iCisiXHRbRlJPTSBmcm9tX2xpc3RdXG4iCisiXHRbV0hFUkUgcXVhbF1cbiIK
KyJcdFtHUk9VUCBCWSBncm91cF9saXN0XVxuIgorIlx0W0hBVklORyBoYXZpbmdfY2xhdXNlXVxu
IgorIlx0W09SREVSIEJZIGF0dHIxIFtVU0lORyBvcDFdLCAuLi5hdHRyTl1cbiIKKyJcdFsgeyBV
TklPTiBbQUxMXSB8IElOVEVSU0VDVCB8IEVYQ0VQVCB9IFNFTEVDVCAuLi5dOyIKK21zZ3N0ciAi
IgorCisjOiBwc3FsSGVscC5oOjE4MAorbXNnaWQgImRlbGV0ZSB0dXBsZXMiCittc2dzdHIgIiIK
KworIzogcHNxbEhlbHAuaDoxODEKK21zZ2lkICJcdERFTEVURSBGUk9NIGNsYXNzX25hbWUgW1dI
RVJFIHF1YWxdOyIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVscC5oOjE5OAorbXNnaWQgInJlbW92
ZSBhbiBhZ2dyZWdhdGUgZnVuY3Rpb24iCittc2dzdHIgIiIKKworIzogcHNxbEhlbHAuaDoxOTkK
K21zZ2lkICJcdERST1AgQUdHUkVHQVRFIGFnZ19uYW1lIGFnZ190eXBlfCo7IgorbXNnc3RyICIi
CisKKyM6IHBzcWxIZWxwLmg6MjAyCittc2dpZCAicmVtb3ZlIGEgZGF0YWJhc2UiCittc2dzdHIg
IiIKKworIzogcHNxbEhlbHAuaDoyMDMKK21zZ2lkICJcdERST1AgREFUQUJBU0UgZGJuYW1lIgor
bXNnc3RyICIiCisKKyM6IHBzcWxIZWxwLmg6MjA2Cittc2dpZCAicmVtb3ZlIGEgdXNlci1kZWZp
bmVkIGZ1bmN0aW9uIgorbXNnc3RyICIiCisKKyM6IHBzcWxIZWxwLmg6MjA3Cittc2dpZCAiXHRE
Uk9QIEZVTkNUSU9OIGZ1bmNuYW1lIChbdHlwZTEsIC4uLnR5cGVOXSk7IgorbXNnc3RyICIiCisK
KyM6IHBzcWxIZWxwLmg6MjEwCittc2dpZCAicmVtb3ZlIGFuIGV4aXN0aW5nIGluZGV4IgorbXNn
c3RyICIiCisKKyM6IHBzcWxIZWxwLmg6MjExCittc2dpZCAiXHREUk9QIElOREVYIGluZGV4bmFt
ZTsiCittc2dzdHIgIiIKKworIzogcHNxbEhlbHAuaDoyMTQKK21zZ2lkICJyZW1vdmUgYSB1c2Vy
LWRlZmluZWQgb3BlcmF0b3IiCittc2dzdHIgIiIKKworIzogcHNxbEhlbHAuaDoyMTUKK21zZ2lk
ICJcdERST1AgT1BFUkFUT1Igb3BlcmF0b3JfbmFtZSAoW2x0eXBlfE5PTkVdLFtSVFlQRXxub25l
XSk7IgorbXNnc3RyICIiCisKKyM6IHBzcWxIZWxwLmg6MjE4Cittc2dpZCAicmVtb3ZlIGEgcnVs
ZSIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVscC5oOjIxOQorbXNnaWQgIlx0RFJPUCBSVUxFIHJ1
bGVuYW1lOyIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVscC5oOjIyMgorbXNnaWQgInJlbW92ZSBh
IHNlcXVlbmNlIG51bWJlciBnZW5lcmF0b3IiCittc2dzdHIgIiIKKworIzogcHNxbEhlbHAuaDoy
MjMKK21zZ2lkICJcdERST1AgU0VRVUVOQ0Ugc2VxdWVuY2VfbmFtZVssIC4uLnNlcXVlbmNlX25h
bWVOXTsiCittc2dzdHIgIiIKKworIzogcHNxbEhlbHAuaDoyMjYKK21zZ2lkICJyZW1vdmUgYSB0
YWJsZSIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVscC5oOjIyNworbXNnaWQgIlx0RFJPUCBUQUJM
RSBjbGFzc19uYW1lMSwgLi4uY2xhc3NfbmFtZU47IgorbXNnc3RyICIiCisKKyM6IHBzcWxIZWxw
Lmg6MjMwCittc2dpZCAicmVtb3ZlIGEgdHJpZ2dlciIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVs
cC5oOjIzMQorbXNnaWQgIlx0RFJPUCBUUklHR0VSIHRyaWdnZXJfbmFtZSBPTiBjbGFzc19uYW1l
OyIKK21zZ3N0ciAiIgorCisjOiBwc3FsSGVscC5oOjIzNAorbXNnaWQgInJlbW92ZSBhIHVzZXIt
ZGVmaW5lZCBiYXNlIHR5cGUiCittc2dzdHIgIiIKKworIzogcHNxbEhlbHAuaDoyMzUKK21zZ2lk
ICJcdERST1AgVFlQRSB0eXBlbmFtZTsiCittc2dzdHIgIiIKKworIzogcHNxbEhlbHAuaDoyMzgK
K21zZ2lkICJyZW1vdmUgYSB1c2VyIGZyb20gdGhlIHN5c3RlbSIKK21zZ3N0ciAiIgorCisjOiBw
c3FsSGVscC5oOjIzOQorbXNnaWQgIlx0RFJPUCBVU0VSIHVzZXJfbmFtZTsiCittc2dzdHIgIiIK
KworIzogcHNxbEhlbHAuaDoyNDIKK21zZ2lkICJyZW1vdmUgYSB2aWV3IgorbXNnc3RyICIiCisK
KyM6IHBzcWxIZWxwLmg6MjQzCittc2dpZCAiXHREUk9QIFZJRVcgdmlld19uYW1lIgorbXNnc3Ry
ICIiCisKKyM6IHBzcWxIZWxwLmg6MjQ2Cittc2dpZCAiZW5kIHRoZSBjdXJyZW50IHRyYW5zYWN0
aW9uIgorbXNnc3RyICIiCisKKyM6IHBzcWxIZWxwLmg6MjQ3Cittc2dpZCAiXHRFTkQgW1dPUkt8
VFJBTlNBQ1RJT05dOyIKK21zZ3N0ciAiIgpkaWZmIC11TnIgcG9zdGdyZXNxbC02LjUuMS1vcmln
L3NyYy9iaW4vcHNxbC9wc3FsLmMgcG9zdGdyZXNxbC02LjUuMS9zcmMvYmluL3BzcWwvcHNxbC5j
Ci0tLSBwb3N0Z3Jlc3FsLTYuNS4xLW9yaWcvc3JjL2Jpbi9wc3FsL3BzcWwuYwlTYXQgSnVuICA1
IDA1OjIxOjEzIDE5OTkKKysrIHBvc3RncmVzcWwtNi41LjEvc3JjL2Jpbi9wc3FsL3BzcWwuYwlT
dW4gSnVsIDI1IDE2OjAwOjUwIDE5OTkKQEAgLTY4LDYgKzY4LDcgQEAKICNlbmRpZgogCiAKKwog
I2lmZGVmIFdJTjMyCiAjZGVmaW5lIHBvcGVuKHgseSkgX3BvcGVuKHgseSkKICNkZWZpbmUgcGNs
b3NlKHgpIF9wY2xvc2UoeCkKQEAgLTIwMCwyOCArMjAxLDI4IEBACiBzdGF0aWMgdm9pZAogdXNh
Z2UoY2hhciAqcHJvZ25hbWUpCiB7Ci0JZnByaW50ZihzdGRlcnIsICJVc2FnZTogJXMgW29wdGlv
bnNdIFtkYm5hbWVdXG4iLCBwcm9nbmFtZSk7Ci0JZnByaW50ZihzdGRlcnIsICJcdCAtYSBhdXRo
c3ZjICAgICAgICAgICAgICBzZXQgYXV0aGVudGljYXRpb24gc2VydmljZVxuIik7Ci0JZnByaW50
ZihzdGRlcnIsICJcdCAtQSAgICAgICAgICAgICAgICAgICAgICB0dXJuIG9mZiBhbGlnbm1lbnQg
d2hlbiBwcmludGluZyBvdXQgYXR0cmlidXRlc1xuIik7Ci0JZnByaW50ZihzdGRlcnIsICJcdCAt
YyBxdWVyeSAgICAgICAgICAgICAgICBydW4gc2luZ2xlIHF1ZXJ5IChzbGFzaCBjb21tYW5kcyB0
b28pXG4iKTsKLQlmcHJpbnRmKHN0ZGVyciwgIlx0IC1kIGRiTmFtZSAgICAgICAgICAgICAgIHNw
ZWNpZnkgZGF0YWJhc2UgbmFtZVxuIik7Ci0JZnByaW50ZihzdGRlcnIsICJcdCAtZSAgICAgICAg
ICAgICAgICAgICAgICBlY2hvIHRoZSBxdWVyeSBzZW50IHRvIHRoZSBiYWNrZW5kXG4iKTsKLQlm
cHJpbnRmKHN0ZGVyciwgIlx0IC1FICAgICAgICAgICAgICAgICAgICAgIGVjaG8gYWxsIHF1ZXJp
ZXMgc2VudCB0byB0aGUgYmFja2VuZFxuIik7Ci0JZnByaW50ZihzdGRlcnIsICJcdCAtZiBmaWxl
bmFtZSAgICAgICAgICAgICB1c2UgZmlsZSBhcyBhIHNvdXJjZSBvZiBxdWVyaWVzXG4iKTsKLQlm
cHJpbnRmKHN0ZGVyciwgIlx0IC1GIHNlcCAgICAgICAgICAgICAgICAgIHNldCB0aGUgZmllbGQg
c2VwYXJhdG9yIChkZWZhdWx0IGlzICd8JylcbiIpOwotCWZwcmludGYoc3RkZXJyLCAiXHQgLWgg
aG9zdCAgICAgICAgICAgICAgICAgc2V0IGRhdGFiYXNlIHNlcnZlciBob3N0XG4iKTsKLQlmcHJp
bnRmKHN0ZGVyciwgIlx0IC1IICAgICAgICAgICAgICAgICAgICAgIHR1cm4gb24gaHRtbDMuMCB0
YWJsZSBvdXRwdXRcbiIpOwotCWZwcmludGYoc3RkZXJyLCAiXHQgLWwgICAgICAgICAgICAgICAg
ICAgICAgbGlzdCBhdmFpbGFibGUgZGF0YWJhc2VzXG4iKTsKLQlmcHJpbnRmKHN0ZGVyciwgIlx0
IC1uICAgICAgICAgICAgICAgICAgICAgIGRvbid0IHVzZSByZWFkbGluZSBsaWJyYXJ5XG4iKTsK
LQlmcHJpbnRmKHN0ZGVyciwgIlx0IC1vIGZpbGVuYW1lICAgICAgICAgICAgIHNlbmQgb3V0cHV0
IHRvIGZpbGVuYW1lIG9yICh8cGlwZSlcbiIpOwotCWZwcmludGYoc3RkZXJyLCAiXHQgLXAgcG9y
dCAgICAgICAgICAgICAgICAgc2V0IHBvcnQgbnVtYmVyXG4iKTsKLQlmcHJpbnRmKHN0ZGVyciwg
Ilx0IC1xICAgICAgICAgICAgICAgICAgICAgIHJ1biBxdWlldGx5IChubyBtZXNzYWdlcywgbm8g
cHJvbXB0cylcbiIpOwotCWZwcmludGYoc3RkZXJyLCAiXHQgLXMgICAgICAgICAgICAgICAgICAg
ICAgc2luZ2xlIHN0ZXAgbW9kZSAocHJvbXB0cyBmb3IgZWFjaCBxdWVyeSlcbiIpOwotCWZwcmlu
dGYoc3RkZXJyLCAiXHQgLVMgICAgICAgICAgICAgICAgICAgICAgc2luZ2xlIGxpbmUgbW9kZSAo
aS5lLiBxdWVyeSB0ZXJtaW5hdGVkIGJ5IG5ld2xpbmUpXG4iKTsKLQlmcHJpbnRmKHN0ZGVyciwg
Ilx0IC10ICAgICAgICAgICAgICAgICAgICAgIHR1cm4gb2ZmIHByaW50aW5nIG9mIGhlYWRpbmdz
IGFuZCByb3cgY291bnRcbiIpOwotCWZwcmludGYoc3RkZXJyLCAiXHQgLVQgaHRtbCAgICAgICAg
ICAgICAgICAgc2V0IGh0bWwzLjAgdGFibGUgY29tbWFuZCBvcHRpb25zIChjZi4gLUgpXG4iKTsK
LQlmcHJpbnRmKHN0ZGVyciwgIlx0IC11ICAgICAgICAgICAgICAgICAgICAgIGFzayBmb3IgYSB1
c2VybmFtZSBhbmQgcGFzc3dvcmQgZm9yIGF1dGhlbnRpY2F0aW9uXG4iKTsKLQlmcHJpbnRmKHN0
ZGVyciwgIlx0IC14ICAgICAgICAgICAgICAgICAgICAgIHR1cm4gb24gZXhwYW5kZWQgb3V0cHV0
IChmaWVsZCBuYW1lcyBvbiBsZWZ0KVxuIik7CisJZnByaW50ZihzdGRlcnIsIF8oIlVzYWdlOiAl
cyBbb3B0aW9uc10gW2RibmFtZV1cbiIpLCBwcm9nbmFtZSk7CisJZnByaW50ZihzdGRlcnIsIF8o
Ilx0IC1hIGF1dGhzdmMgICAgICAgICAgICAgIHNldCBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlXG4i
KSk7CisJZnByaW50ZihzdGRlcnIsIF8oIlx0IC1BICAgICAgICAgICAgICAgICAgICAgIHR1cm4g
b2ZmIGFsaWdubWVudCB3aGVuIHByaW50aW5nIG91dCBhdHRyaWJ1dGVzXG4iKSk7CisJZnByaW50
ZihzdGRlcnIsIF8oIlx0IC1jIHF1ZXJ5ICAgICAgICAgICAgICAgIHJ1biBzaW5nbGUgcXVlcnkg
KHNsYXNoIGNvbW1hbmRzIHRvbylcbiIpKTsKKwlmcHJpbnRmKHN0ZGVyciwgXygiXHQgLWQgZGJO
YW1lICAgICAgICAgICAgICAgc3BlY2lmeSBkYXRhYmFzZSBuYW1lXG4iKSk7CisJZnByaW50Zihz
dGRlcnIsIF8oIlx0IC1lICAgICAgICAgICAgICAgICAgICAgIGVjaG8gdGhlIHF1ZXJ5IHNlbnQg
dG8gdGhlIGJhY2tlbmRcbiIpKTsKKwlmcHJpbnRmKHN0ZGVyciwgXygiXHQgLUUgICAgICAgICAg
ICAgICAgICAgICAgZWNobyBhbGwgcXVlcmllcyBzZW50IHRvIHRoZSBiYWNrZW5kXG4iKSk7CisJ
ZnByaW50ZihzdGRlcnIsIF8oIlx0IC1mIGZpbGVuYW1lICAgICAgICAgICAgIHVzZSBmaWxlIGFz
IGEgc291cmNlIG9mIHF1ZXJpZXNcbiIpKTsKKwlmcHJpbnRmKHN0ZGVyciwgXygiXHQgLUYgc2Vw
ICAgICAgICAgICAgICAgICAgc2V0IHRoZSBmaWVsZCBzZXBhcmF0b3IgKGRlZmF1bHQgaXMgJ3wn
KVxuIikpOworCWZwcmludGYoc3RkZXJyLCBfKCJcdCAtaCBob3N0ICAgICAgICAgICAgICAgICBz
ZXQgZGF0YWJhc2Ugc2VydmVyIGhvc3RcbiIpKTsKKwlmcHJpbnRmKHN0ZGVyciwgXygiXHQgLUgg
ICAgICAgICAgICAgICAgICAgICAgdHVybiBvbiBodG1sMy4wIHRhYmxlIG91dHB1dFxuIikpOwor
CWZwcmludGYoc3RkZXJyLCBfKCJcdCAtbCAgICAgICAgICAgICAgICAgICAgICBsaXN0IGF2YWls
YWJsZSBkYXRhYmFzZXNcbiIpKTsKKwlmcHJpbnRmKHN0ZGVyciwgXygiXHQgLW4gICAgICAgICAg
ICAgICAgICAgICAgZG9uJ3QgdXNlIHJlYWRsaW5lIGxpYnJhcnlcbiIpKTsKKwlmcHJpbnRmKHN0
ZGVyciwgXygiXHQgLW8gZmlsZW5hbWUgICAgICAgICAgICAgc2VuZCBvdXRwdXQgdG8gZmlsZW5h
bWUgb3IgKHxwaXBlKVxuIikpOworCWZwcmludGYoc3RkZXJyLCBfKCJcdCAtcCBwb3J0ICAgICAg
ICAgICAgICAgICBzZXQgcG9ydCBudW1iZXJcbiIpKTsKKwlmcHJpbnRmKHN0ZGVyciwgXygiXHQg
LXEgICAgICAgICAgICAgICAgICAgICAgcnVuIHF1aWV0bHkgKG5vIG1lc3NhZ2VzLCBubyBwcm9t
cHRzKVxuIikpOworCWZwcmludGYoc3RkZXJyLCBfKCJcdCAtcyAgICAgICAgICAgICAgICAgICAg
ICBzaW5nbGUgc3RlcCBtb2RlIChwcm9tcHRzIGZvciBlYWNoIHF1ZXJ5KVxuIikpOworCWZwcmlu
dGYoc3RkZXJyLCBfKCJcdCAtUyAgICAgICAgICAgICAgICAgICAgICBzaW5nbGUgbGluZSBtb2Rl
IChpLmUuIHF1ZXJ5IHRlcm1pbmF0ZWQgYnkgbmV3bGluZSlcbiIpKTsKKwlmcHJpbnRmKHN0ZGVy
ciwgXygiXHQgLXQgICAgICAgICAgICAgICAgICAgICAgdHVybiBvZmYgcHJpbnRpbmcgb2YgaGVh
ZGluZ3MgYW5kIHJvdyBjb3VudFxuIikpOworCWZwcmludGYoc3RkZXJyLCBfKCJcdCAtVCBodG1s
ICAgICAgICAgICAgICAgICBzZXQgaHRtbDMuMCB0YWJsZSBjb21tYW5kIG9wdGlvbnMgKGNmLiAt
SClcbiIpKTsKKwlmcHJpbnRmKHN0ZGVyciwgXygiXHQgLXUgICAgICAgICAgICAgICAgICAgICAg
YXNrIGZvciBhIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBmb3IgYXV0aGVudGljYXRpb25cbiIpKTsK
KwlmcHJpbnRmKHN0ZGVyciwgXygiXHQgLXggICAgICAgICAgICAgICAgICAgICAgdHVybiBvbiBl
eHBhbmRlZCBvdXRwdXQgKGZpZWxkIG5hbWVzIG9uIGxlZnQpXG4iKSk7CiAJZXhpdCgxKTsKIH0K
IApAQCAtMjY4LDQxICsyNjksNDEgQEAKIAkJZm91dCA9IHN0ZG91dDsKIAogCS8qIGlmIHlvdSBh
ZGQvcmVtb3ZlIGEgbGluZSBoZXJlLCBjaGFuZ2UgdGhlIHJvdyB0ZXN0IGFib3ZlICovCi0JZnBy
aW50Zihmb3V0LCAiIFxcPyAgICAgICAgICAgLS0gaGVscFxuIik7Ci0JZnByaW50Zihmb3V0LCAi
IFxcYSAgICAgICAgICAgLS0gdG9nZ2xlIGZpZWxkLWFsaWdubWVudCAoY3VycmVudGx5ICVzKVxu
Iiwgb24ocHNldC0+b3B0LmFsaWduKSk7Ci0JZnByaW50Zihmb3V0LCAiIFxcQyBbPGNhcHRuPl0g
LS0gc2V0IGh0bWwzIGNhcHRpb24gKGN1cnJlbnRseSAnJXMnKVxuIiwgcHNldC0+b3B0LmNhcHRp
b24gPyBwc2V0LT5vcHQuY2FwdGlvbiA6ICIiKTsKLQlmcHJpbnRmKGZvdXQsICIgXFxjb25uZWN0
IDxkYm5hbWV8LT4gPHVzZXI+IC0tIGNvbm5lY3QgdG8gbmV3IGRhdGFiYXNlIChjdXJyZW50bHkg
JyVzJylcbiIsIFBRZGIocHNldC0+ZGIpKTsKLQlmcHJpbnRmKGZvdXQsICIgXFxjb3B5IHRhYmxl
IHtmcm9tIHwgdG99IDxmbmFtZT5cbiIpOwotCWZwcmludGYoZm91dCwgIiBcXGQgWzx0YWJsZT5d
IC0tIGxpc3QgdGFibGVzIGFuZCBpbmRpY2VzLCBjb2x1bW5zIGluIDx0YWJsZT4sIG9yICogZm9y
IGFsbFxuIik7Ci0JZnByaW50Zihmb3V0LCAiIFxcZGEgICAgICAgICAgLS0gbGlzdCBhZ2dyZWdh
dGVzXG4iKTsKLQlmcHJpbnRmKGZvdXQsICIgXFxkZCBbPG9iamVjdD5dLSBsaXN0IGNvbW1lbnQg
Zm9yIHRhYmxlLCBmaWVsZCwgdHlwZSwgZnVuY3Rpb24sIG9yIG9wZXJhdG9yLlxuIik7Ci0JZnBy
aW50Zihmb3V0LCAiIFxcZGYgICAgICAgICAgLS0gbGlzdCBmdW5jdGlvbnNcbiIpOwotCWZwcmlu
dGYoZm91dCwgIiBcXGRpICAgICAgICAgIC0tIGxpc3Qgb25seSBpbmRpY2VzXG4iKTsKLQlmcHJp
bnRmKGZvdXQsICIgXFxkbyAgICAgICAgICAtLSBsaXN0IG9wZXJhdG9yc1xuIik7Ci0JZnByaW50
Zihmb3V0LCAiIFxcZHMgICAgICAgICAgLS0gbGlzdCBvbmx5IHNlcXVlbmNlc1xuIik7Ci0JZnBy
aW50Zihmb3V0LCAiIFxcZFMgICAgICAgICAgLS0gbGlzdCBzeXN0ZW0gdGFibGVzIGFuZCBpbmRl
eGVzXG4iKTsKLQlmcHJpbnRmKGZvdXQsICIgXFxkdCAgICAgICAgICAtLSBsaXN0IG9ubHkgdGFi
bGVzXG4iKTsKLQlmcHJpbnRmKGZvdXQsICIgXFxkVCAgICAgICAgICAtLSBsaXN0IHR5cGVzXG4i
KTsKLQlmcHJpbnRmKGZvdXQsICIgXFxlIFs8Zm5hbWU+XSAtLSBlZGl0IHRoZSBjdXJyZW50IHF1
ZXJ5IGJ1ZmZlciBvciA8Zm5hbWU+XG4iKTsKLQlmcHJpbnRmKGZvdXQsICIgXFxFIFs8Zm5hbWU+
XSAtLSBlZGl0IHRoZSBjdXJyZW50IHF1ZXJ5IGJ1ZmZlciBvciA8Zm5hbWU+LCBhbmQgZXhlY3V0
ZVxuIik7Ci0JZnByaW50Zihmb3V0LCAiIFxcZiBbPHNlcD5dICAgLS0gY2hhbmdlIGZpZWxkIHNl
cGFyYXRlciAoY3VycmVudGx5ICclcycpXG4iLCBwc2V0LT5vcHQuZmllbGRTZXApOwotCWZwcmlu
dGYoZm91dCwgIiBcXGcgWzxmbmFtZT5dIFt8PGNtZD5dIC0tIHNlbmQgcXVlcnkgdG8gYmFja2Vu
ZCBbYW5kIHJlc3VsdHMgaW4gPGZuYW1lPiBvciBwaXBlXVxuIik7Ci0JZnByaW50Zihmb3V0LCAi
IFxcaCBbPGNtZD5dICAgLS0gaGVscCBvbiBzeW50YXggb2Ygc3FsIGNvbW1hbmRzLCAqIGZvciBh
bGwgY29tbWFuZHNcbiIpOwotCWZwcmludGYoZm91dCwgIiBcXEggICAgICAgICAgIC0tIHRvZ2ds
ZSBodG1sMyBvdXRwdXQgKGN1cnJlbnRseSAlcylcbiIsIG9uKHBzZXQtPm9wdC5odG1sMykpOwot
CWZwcmludGYoZm91dCwgIiBcXGkgPGZuYW1lPiAgIC0tIHJlYWQgYW5kIGV4ZWN1dGUgcXVlcmll
cyBmcm9tIGZpbGVuYW1lXG4iKTsKLQlmcHJpbnRmKGZvdXQsICIgXFxsICAgICAgICAgICAtLSBs
aXN0IGFsbCBkYXRhYmFzZXNcbiIpOwotCWZwcmludGYoZm91dCwgIiBcXG0gICAgICAgICAgIC0t
IHRvZ2dsZSBtb25pdG9yLWxpa2UgdGFibGUgZGlzcGxheSAoY3VycmVudGx5ICVzKVxuIiwgb24o
cHNldC0+b3B0LnN0YW5kYXJkKSk7Ci0JZnByaW50Zihmb3V0LCAiIFxcbyBbPGZuYW1lPl0gW3w8
Y21kPl0gLS0gc2VuZCBhbGwgcXVlcnkgcmVzdWx0cyB0byBzdGRvdXQsIDxmbmFtZT4sIG9yIHBp
cGVcbiIpOwotCWZwcmludGYoZm91dCwgIiBcXHAgICAgICAgICAgIC0tIHByaW50IHRoZSBjdXJy
ZW50IHF1ZXJ5IGJ1ZmZlclxuIik7Ci0JZnByaW50Zihmb3V0LCAiIFxccSAgICAgICAgICAgLS0g
cXVpdFxuIik7Ci0JZnByaW50Zihmb3V0LCAiIFxcciAgICAgICAgICAgLS0gcmVzZXQoY2xlYXIp
IHRoZSBxdWVyeSBidWZmZXJcbiIpOwotCWZwcmludGYoZm91dCwgIiBcXHMgWzxmbmFtZT5dIC0t
IHByaW50IGhpc3Rvcnkgb3Igc2F2ZSBpdCBpbiA8Zm5hbWU+XG4iKTsKLQlmcHJpbnRmKGZvdXQs
ICIgXFx0ICAgICAgICAgICAtLSB0b2dnbGUgdGFibGUgaGVhZGluZ3MgYW5kIHJvdyBjb3VudCAo
Y3VycmVudGx5ICVzKVxuIiwgb24ocHNldC0+b3B0LmhlYWRlcikpOwotCWZwcmludGYoZm91dCwg
IiBcXFQgWzxodG1sPl0gIC0tIHNldCBodG1sMy4wIDx0YWJsZSAuLi4+IG9wdGlvbnMgKGN1cnJl
bnRseSAnJXMnKVxuIiwgcHNldC0+b3B0LnRhYmxlT3B0ID8gcHNldC0+b3B0LnRhYmxlT3B0IDog
IiIpOwotCWZwcmludGYoZm91dCwgIiBcXHggICAgICAgICAgIC0tIHRvZ2dsZSBleHBhbmRlZCBv
dXRwdXQgKGN1cnJlbnRseSAlcylcbiIsIG9uKHBzZXQtPm9wdC5leHBhbmRlZCkpOwotCWZwcmlu
dGYoZm91dCwgIiBcXHcgPGZuYW1lPiAgIC0tIG91dHB1dCBjdXJyZW50IGJ1ZmZlciB0byBhIGZp
bGVcbiIpOwotCWZwcmludGYoZm91dCwgIiBcXHogICAgICAgICAgIC0tIGxpc3QgY3VycmVudCBn
cmFudC9yZXZva2UgcGVybWlzc2lvbnNcbiIpOwotCWZwcmludGYoZm91dCwgIiBcXCEgWzxjbWQ+
XSAgIC0tIHNoZWxsIGVzY2FwZSBvciBjb21tYW5kXG4iKTsKKwlmcHJpbnRmKGZvdXQsIF8oIiBc
XD8gICAgICAgICAgIC0tIGhlbHBcbiIpKTsKKwlmcHJpbnRmKGZvdXQsIF8oIiBcXGEgICAgICAg
ICAgIC0tIHRvZ2dsZSBmaWVsZC1hbGlnbm1lbnQgKGN1cnJlbnRseSAlcylcbiIpLCBvbihwc2V0
LT5vcHQuYWxpZ24pKTsKKwlmcHJpbnRmKGZvdXQsIF8oIiBcXEMgWzxjYXB0bj5dIC0tIHNldCBo
dG1sMyBjYXB0aW9uIChjdXJyZW50bHkgJyVzJylcbiIpLCBwc2V0LT5vcHQuY2FwdGlvbiA/IHBz
ZXQtPm9wdC5jYXB0aW9uIDogIiIpOworCWZwcmludGYoZm91dCwgXygiIFxcY29ubmVjdCA8ZGJu
YW1lfC0+IDx1c2VyPiAtLSBjb25uZWN0IHRvIG5ldyBkYXRhYmFzZSAoY3VycmVudGx5ICclcycp
XG4iKSwgUFFkYihwc2V0LT5kYikpOworCWZwcmludGYoZm91dCwgXygiIFxcY29weSB0YWJsZSB7
ZnJvbSB8IHRvfSA8Zm5hbWU+XG4iKSk7CisJZnByaW50Zihmb3V0LCBfKCIgXFxkIFs8dGFibGU+
XSAtLSBsaXN0IHRhYmxlcyBhbmQgaW5kaWNlcywgY29sdW1ucyBpbiA8dGFibGU+LCBvciAqIGZv
ciBhbGxcbiIpKTsKKwlmcHJpbnRmKGZvdXQsIF8oIiBcXGRhICAgICAgICAgIC0tIGxpc3QgYWdn
cmVnYXRlc1xuIikpOworCWZwcmludGYoZm91dCwgXygiIFxcZGQgWzxvYmplY3Q+XS0gbGlzdCBj
b21tZW50IGZvciB0YWJsZSwgZmllbGQsIHR5cGUsIGZ1bmN0aW9uLCBvciBvcGVyYXRvci5cbiIp
KTsKKwlmcHJpbnRmKGZvdXQsIF8oIiBcXGRmICAgICAgICAgIC0tIGxpc3QgZnVuY3Rpb25zXG4i
KSk7CisJZnByaW50Zihmb3V0LCBfKCIgXFxkaSAgICAgICAgICAtLSBsaXN0IG9ubHkgaW5kaWNl
c1xuIikpOworCWZwcmludGYoZm91dCwgXygiIFxcZG8gICAgICAgICAgLS0gbGlzdCBvcGVyYXRv
cnNcbiIpKTsKKwlmcHJpbnRmKGZvdXQsIF8oIiBcXGRzICAgICAgICAgIC0tIGxpc3Qgb25seSBz
ZXF1ZW5jZXNcbiIpKTsKKwlmcHJpbnRmKGZvdXQsIF8oIiBcXGRTICAgICAgICAgIC0tIGxpc3Qg
c3lzdGVtIHRhYmxlcyBhbmQgaW5kZXhlc1xuIikpOworCWZwcmludGYoZm91dCwgLSgiIFxcZHQg
ICAgICAgICAgLS0gbGlzdCBvbmx5IHRhYmxlc1xuIikpOworCWZwcmludGYoZm91dCwgXygiIFxc
ZFQgICAgICAgICAgLS0gbGlzdCB0eXBlc1xuIikpOworCWZwcmludGYoZm91dCwgXygiIFxcZSBb
PGZuYW1lPl0gLS0gZWRpdCB0aGUgY3VycmVudCBxdWVyeSBidWZmZXIgb3IgPGZuYW1lPlxuIikp
OworCWZwcmludGYoZm91dCwgXygiIFxcRSBbPGZuYW1lPl0gLS0gZWRpdCB0aGUgY3VycmVudCBx
dWVyeSBidWZmZXIgb3IgPGZuYW1lPiwgYW5kIGV4ZWN1dGVcbiIpKTsKKwlmcHJpbnRmKGZvdXQs
IF8oIiBcXGYgWzxzZXA+XSAgIC0tIGNoYW5nZSBmaWVsZCBzZXBhcmF0ZXIgKGN1cnJlbnRseSAn
JXMnKVxuIiksIHBzZXQtPm9wdC5maWVsZFNlcCk7CisJZnByaW50Zihmb3V0LCBfKCIgXFxnIFs8
Zm5hbWU+XSBbfDxjbWQ+XSAtLSBzZW5kIHF1ZXJ5IHRvIGJhY2tlbmQgW2FuZCByZXN1bHRzIGlu
IDxmbmFtZT4gb3IgcGlwZV1cbiIpKTsKKwlmcHJpbnRmKGZvdXQsIF8oIiBcXGggWzxjbWQ+XSAg
IC0tIGhlbHAgb24gc3ludGF4IG9mIHNxbCBjb21tYW5kcywgKiBmb3IgYWxsIGNvbW1hbmRzXG4i
KSk7CisJZnByaW50Zihmb3V0LCBfKCIgXFxIICAgICAgICAgICAtLSB0b2dnbGUgaHRtbDMgb3V0
cHV0IChjdXJyZW50bHkgJXMpXG4iKSwgb24ocHNldC0+b3B0Lmh0bWwzKSk7CisJZnByaW50Zihm
b3V0LCBfKCIgXFxpIDxmbmFtZT4gICAtLSByZWFkIGFuZCBleGVjdXRlIHF1ZXJpZXMgZnJvbSBm
aWxlbmFtZVxuIikpOworCWZwcmludGYoZm91dCwgXygiIFxcbCAgICAgICAgICAgLS0gbGlzdCBh
bGwgZGF0YWJhc2VzXG4iKSk7CisJZnByaW50Zihmb3V0LCBfKCIgXFxtICAgICAgICAgICAtLSB0
b2dnbGUgbW9uaXRvci1saWtlIHRhYmxlIGRpc3BsYXkgKGN1cnJlbnRseSAlcylcbiIpLCBvbihw
c2V0LT5vcHQuc3RhbmRhcmQpKTsKKwlmcHJpbnRmKGZvdXQsIF8oIiBcXG8gWzxmbmFtZT5dIFt8
PGNtZD5dIC0tIHNlbmQgYWxsIHF1ZXJ5IHJlc3VsdHMgdG8gc3Rkb3V0LCA8Zm5hbWU+LCBvciBw
aXBlXG4iKSk7CisJZnByaW50Zihmb3V0LCBfKCIgXFxwICAgICAgICAgICAtLSBwcmludCB0aGUg
Y3VycmVudCBxdWVyeSBidWZmZXJcbiIpKTsKKwlmcHJpbnRmKGZvdXQsIF8oIiBcXHEgICAgICAg
ICAgIC0tIHF1aXRcbiIpKTsKKwlmcHJpbnRmKGZvdXQsIF8oIiBcXHIgICAgICAgICAgIC0tIHJl
c2V0KGNsZWFyKSB0aGUgcXVlcnkgYnVmZmVyXG4iKSk7CisJZnByaW50Zihmb3V0LCBfKCIgXFxz
IFs8Zm5hbWU+XSAtLSBwcmludCBoaXN0b3J5IG9yIHNhdmUgaXQgaW4gPGZuYW1lPlxuIikpOwor
CWZwcmludGYoZm91dCwgXygiIFxcdCAgICAgICAgICAgLS0gdG9nZ2xlIHRhYmxlIGhlYWRpbmdz
IGFuZCByb3cgY291bnQgKGN1cnJlbnRseSAlcylcbiIpLCBvbihwc2V0LT5vcHQuaGVhZGVyKSk7
CisJZnByaW50Zihmb3V0LCBfKCIgXFxUIFs8aHRtbD5dICAtLSBzZXQgaHRtbDMuMCA8dGFibGUg
Li4uPiBvcHRpb25zIChjdXJyZW50bHkgJyVzJylcbiIpLCBwc2V0LT5vcHQudGFibGVPcHQgPyBw
c2V0LT5vcHQudGFibGVPcHQgOiAiIik7CisJZnByaW50Zihmb3V0LCBfKCIgXFx4ICAgICAgICAg
ICAtLSB0b2dnbGUgZXhwYW5kZWQgb3V0cHV0IChjdXJyZW50bHkgJXMpXG4iKSwgb24ocHNldC0+
b3B0LmV4cGFuZGVkKSk7CisJZnByaW50Zihmb3V0LCBfKCIgXFx3IDxmbmFtZT4gICAtLSBvdXRw
dXQgY3VycmVudCBidWZmZXIgdG8gYSBmaWxlXG4iKSk7CisJZnByaW50Zihmb3V0LCBfKCIgXFx6
ICAgICAgICAgICAtLSBsaXN0IGN1cnJlbnQgZ3JhbnQvcmV2b2tlIHBlcm1pc3Npb25zXG4iKSk7
CisJZnByaW50Zihmb3V0LCBfKCIgXFwhIFs8Y21kPl0gICAtLSBzaGVsbCBlc2NhcGUgb3IgY29t
bWFuZFxuIikpOwogCiAJaWYgKHVzZVBpcGUpCiAJewpAQCAtMzE4LDcgKzMxOSw3IEBACiAKIAlp
ZiAocHNldC0+ZWNob0FsbFF1ZXJpZXMpCiAJewotCQlmcHJpbnRmKHN0ZGVyciwgIlFVRVJZOiAl
c1xuIiwgcXVlcnkpOworCQlmcHJpbnRmKHN0ZGVyciwgXygiUVVFUlk6ICVzXG4iKSwgcXVlcnkp
OwogCQlmcHJpbnRmKHN0ZGVyciwgIlxuIik7CiAJCWZmbHVzaChzdGRlcnIpOwogCX0KQEAgLTM3
MSwxMCArMzcyLDEwIEBACiAJCWV4aXQoMSk7CQkJCS8qIGFjY2VwdCBzaWduYWwgaWYgbm8gY29u
bmVjdGlvbiAqLwogCS8qIFRyeSB0byBzZW5kIGNhbmNlbCByZXF1ZXN0ICovCiAJaWYgKFBRcmVx
dWVzdENhbmNlbChjYW5jZWxDb25uKSkKLQkJc2FmZV93cml0ZV9zdGRlcnIoIlxuQ0FOQ0VMIHJl
cXVlc3Qgc2VudFxuIik7CisJCXNhZmVfd3JpdGVfc3RkZXJyKF8oIlxuQ0FOQ0VMIHJlcXVlc3Qg
c2VudFxuIikpOwogCWVsc2UKIAl7Ci0JCXNhZmVfd3JpdGVfc3RkZXJyKCJcbkNhbm5vdCBzZW5k
IGNhbmNlbCByZXF1ZXN0OlxuIik7CisJCXNhZmVfd3JpdGVfc3RkZXJyKF8oIlxuQ2Fubm90IHNl
bmQgY2FuY2VsIHJlcXVlc3Q6XG4iKSk7CiAJCXNhZmVfd3JpdGVfc3RkZXJyKFBRZXJyb3JNZXNz
YWdlKGNhbmNlbENvbm4pKTsKIAl9CiB9CkBAIC01MjksMTAgKzUzMCwxMCBAQAogCQl7CiAJCQkv
KiBEaXNwbGF5IHRoZSBpbmZvcm1hdGlvbiAqLwogCi0JCQlmcHJpbnRmKGZvdXQsICJEYXRhYmFz
ZSAgICA9ICVzXG4iLCBQUWRiKHBzZXQtPmRiKSk7Ci0JCQlmcHJpbnRmKGZvdXQsICIgKy0tLS0t
LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t
LS0rXG4iKTsKLQkJCWZwcmludGYoZm91dCwgIiB8ICBPd25lciAgICAgICAgICAgfCAgICAgICAg
ICAgICBSZWxhdGlvbiAgICAgICAgICAgICB8ICAgVHlwZSAgIHxcbiIpOwotCQkJZnByaW50Zihm
b3V0LCAiICstLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLSstLS0tLS0tLS0tK1xuIik7CisJCQlmcHJpbnRmKGZvdXQsIF8oIkRhdGFiYXNlICAgID0g
JXNcbiIpLCBQUWRiKHBzZXQtPmRiKSk7CisJCQlmcHJpbnRmKGZvdXQsIF8oIiArLS0tLS0tLS0t
LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLStc
biIpKTsKKwkJCWZwcmludGYoZm91dCwgXygiIHwgIE93bmVyICAgICAgICAgICB8ICAgICAgICAg
ICAgIFJlbGF0aW9uICAgICAgICAgICAgIHwgICBUeXBlICAgfFxuIikpOworCQkJZnByaW50Zihm
b3V0LCBfKCIgKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tKy0tLS0tLS0tLS0rXG4iKSk7CiAKIAkJCS8qIG5leHQsIHByaW50IG91dCB0aGUgaW5z
dGFuY2VzICovCiAJCQlmb3IgKGkgPSAwOyBpIDwgUFFudHVwbGVzKHJlcyk7IGkrKykKQEAgLTU0
MiwxNCArNTQzLDE0IEBACiAJCQkJcmsgPSBQUWdldHZhbHVlKHJlcywgaSwgMik7CiAJCQkJcnIg
PSBQUWdldHZhbHVlKHJlcywgaSwgMyk7CiAJCQkJaWYgKHN0cmNtcChyaywgInIiKSA9PSAwKQot
CQkJCQlmcHJpbnRmKGZvdXQsICIlLTguOHMgfCIsIChyclswXSA9PSAndCcpID8gInZpZXc/IiA6
ICJ0YWJsZSIpOworCQkJCQlmcHJpbnRmKGZvdXQsICIlLTguOHMgfCIsIChyclswXSA9PSAndCcp
ID8gXygidmlldz8iKSA6IF8oInRhYmxlIikpOwogCQkJCWVsc2UgaWYgKHN0cmNtcChyaywgImki
KSA9PSAwKQotCQkJCQlmcHJpbnRmKGZvdXQsICIlLTguOHMgfCIsICJpbmRleCIpOworCQkJCQlm
cHJpbnRmKGZvdXQsICIlLTguOHMgfCIsIF8oImluZGV4IikpOwogCQkJCWVsc2UKLQkJCQkJZnBy
aW50Zihmb3V0LCAiJS04LjhzIHwiLCAic2VxdWVuY2UiKTsKKwkJCQkJZnByaW50Zihmb3V0LCAi
JS04LjhzIHwiLCBfKCJzZXF1ZW5jZSIpKTsKIAkJCQlmcHJpbnRmKGZvdXQsICJcbiIpOwogCQkJ
fQotCQkJZnByaW50Zihmb3V0LCAiICstLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tK1xuIik7CisJCQlmcHJpbnRmKGZvdXQsIF8o
IiArLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r
LS0tLS0tLS0tLStcbiIpKTsKIAkJCWZwcmludGYoZm91dCwgIlxuIik7CiAJCQlQUWNsZWFyKHJl
cyk7CiAJCX0KQEAgLTU2NywxNyArNTY4LDE3IEBACiAJCXN3aXRjaCAoaW5mb190eXBlKQogCQl7
CiAJCQljYXNlICd0JzoKLQkJCQlmcHJpbnRmKHN0ZGVyciwgIkNvdWxkbid0IGZpbmQgYW55IHRh
YmxlcyFcbiIpOworCQkJCWZwcmludGYoc3RkZXJyLCBfKCJDb3VsZG4ndCBmaW5kIGFueSB0YWJs
ZXMhXG4iKSk7CiAJCQkJYnJlYWs7CiAJCQljYXNlICdpJzoKLQkJCQlmcHJpbnRmKHN0ZGVyciwg
IkNvdWxkbid0IGZpbmQgYW55IGluZGljZXMhXG4iKTsKKwkJCQlmcHJpbnRmKHN0ZGVyciwgXygi
Q291bGRuJ3QgZmluZCBhbnkgaW5kaWNlcyFcbiIpKTsKIAkJCQlicmVhazsKIAkJCWNhc2UgJ1Mn
OgotCQkJCWZwcmludGYoc3RkZXJyLCAiQ291bGRuJ3QgZmluZCBhbnkgc2VxdWVuY2VzIVxuIik7
CisJCQkJZnByaW50ZihzdGRlcnIsIF8oIkNvdWxkbid0IGZpbmQgYW55IHNlcXVlbmNlcyFcbiIp
KTsKIAkJCQlicmVhazsKIAkJCWNhc2UgJ2InOgogCQkJZGVmYXVsdDoKLQkJCQlmcHJpbnRmKHN0
ZGVyciwgIkNvdWxkbid0IGZpbmQgYW55IHRhYmxlcywgc2VxdWVuY2VzIG9yIGluZGljZXMhXG4i
KTsKKwkJCQlmcHJpbnRmKHN0ZGVyciwgXygiQ291bGRuJ3QgZmluZCBhbnkgdGFibGVzLCBzZXF1
ZW5jZXMgb3IgaW5kaWNlcyFcbiIpKTsKIAkJCQlicmVhazsKIAkJfQogCQlyZXR1cm4gLTE7CkBA
IC02NTUsMTUgKzY1NiwxNSBAQAogCiAJCS8qIERpc3BsYXkgdGhlIGluZm9ybWF0aW9uICovCiAK
LQkJZnByaW50Zihmb3V0LCAiRGF0YWJhc2UgICAgPSAlc1xuIiwgUFFkYihwc2V0LT5kYikpOwor
CQlmcHJpbnRmKGZvdXQsIF8oIkRhdGFiYXNlICAgID0gJXNcbiIpLCBQUWRiKHBzZXQtPmRiKSk7
CiAJCWZwcmludGYoZm91dCwgIiArIik7CiAJCWVtaXROdGltZXMoZm91dCwgIi0iLCBtYXhDb2wx
TGVuICsgMik7CiAJCWZwcmludGYoZm91dCwgIisiKTsKIAkJZW1pdE50aW1lcyhmb3V0LCAiLSIs
IG1heENvbDJMZW4gKyAyKTsKIAkJZnByaW50Zihmb3V0LCAiK1xuIik7CiAJCWZwcmludGYoZm91
dCwgIiB8ICUtKnMgfCAlLSpzIHxcbiIsCi0JCQkJbWF4Q29sMUxlbiwgIlJlbGF0aW9uIiwKLQkJ
CQltYXhDb2wyTGVuLCAiR3JhbnQvUmV2b2tlIFBlcm1pc3Npb25zIik7CisJCQkJbWF4Q29sMUxl
biwgXygiUmVsYXRpb24iKSwKKwkJCQltYXhDb2wyTGVuLCBfKCJHcmFudC9SZXZva2UgUGVybWlz
c2lvbnMiKSk7CiAJCWZwcmludGYoZm91dCwgIiArIik7CiAJCWVtaXROdGltZXMoZm91dCwgIi0i
LCBtYXhDb2wxTGVuICsgMik7CiAJCWZwcmludGYoZm91dCwgIisiKTsKQEAgLTY5NSw3ICs2OTYs
NyBAQAogCWVsc2UKIAl7CiAJCVBRY2xlYXIocmVzKTsKLQkJZnByaW50ZihzdGRlcnIsICJDb3Vs
ZG4ndCBmaW5kIGFueSB0YWJsZXMhXG4iKTsKKwkJZnByaW50ZihzdGRlcnIsIF8oIkNvdWxkbid0
IGZpbmQgYW55IHRhYmxlcyFcbiIpKTsKIAkJcmV0dXJuIC0xOwogCX0KIH0KQEAgLTgyNSwxNiAr
ODI2LDE2IEBACiAJCQkvKgogCQkJICogZGlzcGxheSB0aGUgcXVlcnkuIG8JCQkgKiAtUnlhbiAy
LzE0Lzk5CiAJCQkgKi8KLQkJCWZwcmludGYoZm91dCwgIlZpZXcgICAgPSAlc1xuIiwgdGFibGUp
OwotCQkJZnByaW50Zihmb3V0LCAiUXVlcnkgICA9ICVzXG4iLCBQUWdldHZhbHVlKHJlczIsIDAs
IDEpKTsKKwkJCWZwcmludGYoZm91dCwgXygiVmlldyAgICA9ICVzXG4iKSwgdGFibGUpOworCQkJ
ZnByaW50Zihmb3V0LCBfKCJRdWVyeSAgID0gJXNcbiIpLCBQUWdldHZhbHVlKHJlczIsIDAsIDEp
KTsKIAkJfQogCQllbHNlCi0JCQlmcHJpbnRmKGZvdXQsICJUYWJsZSAgICA9ICVzXG4iLCB0YWJs
ZSk7CisJCQlmcHJpbnRmKGZvdXQsIF8oIlRhYmxlICAgID0gJXNcbiIpLCB0YWJsZSk7CiAJCVBR
Y2xlYXIocmVzMik7CiAKLQkJZnByaW50Zihmb3V0LCAiKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tK1xu
Iik7Ci0JCWZwcmludGYoZm91dCwgInwgICAgICAgICAgICAgIEZpZWxkICAgICAgICAgICAgICAg
fCAgICAgICAgICAgICAgVHlwZSAgICAgICAgICAgICAgICB8IExlbmd0aHxcbiIpOwotCQlmcHJp
bnRmKGZvdXQsICIrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rXG4iKTsKKwkJZnByaW50Zihmb3V0LCBf
KCIrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rXG4iKSk7CisJCWZwcmludGYoZm91dCwgXygifCAgICAg
ICAgICAgICAgRmllbGQgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICBUeXBlICAgICAgICAg
ICAgICAgIHwgTGVuZ3RofFxuIikpOworCQlmcHJpbnRmKGZvdXQsIF8oIistLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r
LS0tLS0tLStcbiIpKTsKIAogCQkvKiBuZXh0LCBwcmludCBvdXQgdGhlIGluc3RhbmNlcyAqLwog
CQlmb3IgKGkgPSAwOyBpIDwgUFFudHVwbGVzKHJlcyk7IGkrKykKQEAgLTg2Miw3ICs4NjMsNyBA
QAogCiAJCQlpZiAocm5vdG51bGxbMF0gPT0gJ3QnKQogCQkJewotCQkJCXN0cm5jYXQodHlwZV9z
dHIsICIgbm90IG51bGwiLCAzMiAtIHN0cmxlbih0eXBlX3N0cikpOworCQkJCXN0cm5jYXQodHlw
ZV9zdHIsIF8oIiBub3QgbnVsbCIpLCAzMiAtIHN0cmxlbih0eXBlX3N0cikpOwogCQkJCXR5cGVf
c3RyWzMyXSA9ICdcMCc7CiAJCQl9CiAJCQlpZiAocmhhc2RlZlswXSA9PSAndCcpCkBAIC05MDIs
NyArOTAzLDcgQEAKIAkJCX0KIAkJCWZwcmludGYoZm91dCwgIlxuIik7CiAJCX0KLQkJZnByaW50
Zihmb3V0LCAiKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tK1xuIik7CisJCWZwcmludGYoZm91dCwgXygi
Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSstLS0tLS0tK1xuIikpOwogCQlQUWNsZWFyKHJlcyk7CiAKIAkJLyogZGlz
cGxheSBkZWZpbmVkIGluZGV4ZXMgZm9yIHRoaXMgdGFibGUgKi8KQEAgLTkyNiw5ICs5MjcsOSBA
QAogCQkJCSAqLwogCiAJCQkJaWYgKG5JbmRpY2VzID09IDEpCi0JCQkJCWZwcmludGYoZm91dCwg
IkluZGV4OiAgICAiKTsKKwkJCQkJZnByaW50Zihmb3V0LCBfKCJJbmRleDogICAgIikpOwogCQkJ
CWVsc2UKLQkJCQkJZnByaW50Zihmb3V0LCAiSW5kaWNlczogICIpOworCQkJCQlmcHJpbnRmKGZv
dXQsIF8oIkluZGljZXM6ICAiKSk7CiAKIAkJCQkvKiBuZXh0LCBwcmludCBvdXQgdGhlIGluc3Rh
bmNlcyAqLwogCQkJCWZvciAoaSA9IDA7IGkgPCBQUW50dXBsZXMocmVzKTsgaSsrKQpAQCAtOTUw
LDcgKzk1MSw3IEBACiAJZWxzZQogCXsKIAkJUFFjbGVhcihyZXMpOwotCQlmcHJpbnRmKHN0ZGVy
ciwgIkNvdWxkbid0IGZpbmQgdGFibGUgJXMhXG4iLCB0YWJsZSk7CisJCWZwcmludGYoc3RkZXJy
LCBfKCJDb3VsZG4ndCBmaW5kIHRhYmxlICVzIVxuIiksIHRhYmxlKTsKIAkJcmV0dXJuIC0xOwog
CX0KIH0KQEAgLTExNTgsNyArMTE1OSw3IEBACiAJbGluZVtNQVhfUVVFUllfQlVGRkVSIC0gMV0g
PSAnXDAnOwkvKiB0aGlzIGlzIHVubmVjZXNzYXJ5LCBJIHRoaW5rICovCiAJaWYgKHN0cmxlbihs
aW5lKSA9PSBNQVhfUVVFUllfQlVGRkVSIC0gMSkKIAl7Ci0JCWZwcmludGYoc3RkZXJyLCAibGlu
ZSByZWFkIGV4Y2VlZHMgbWF4aW11bSBsZW5ndGguICBUcnVuY2F0aW5nIGF0ICVkXG4iLAorCQlm
cHJpbnRmKHN0ZGVyciwgXygibGluZSByZWFkIGV4Y2VlZHMgbWF4aW11bSBsZW5ndGguICBUcnVu
Y2F0aW5nIGF0ICVkXG4iKSwKIAkJCQlNQVhfUVVFUllfQlVGRkVSIC0gMSk7CiAJfQogCXJldHVy
biBsaW5lOwpAQCAtMTE4Niw3ICsxMTg3LDcgQEAKIAogCWlmIChwc2V0LT5lY2hvUXVlcnkgfHwg
cHNldC0+c2luZ2xlU3RlcCkKIAl7Ci0JCWZwcmludGYoc3RkZXJyLCAiUVVFUlk6ICVzXG4iLCBx
dWVyeSk7CisJCWZwcmludGYoc3RkZXJyLCBfKCJRVUVSWTogJXNcbiIpLCBxdWVyeSk7CiAJCWZm
bHVzaChzdGRlcnIpOwogCX0KIAlpZiAocHNldC0+c2luZ2xlU3RlcCkKQEAgLTExOTQsNyArMTE5
NSw3IEBACiAJCWZwcmludGYoc3Rkb3V0LCAiXG4qKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKiIKIAkJCQkiKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KipcbiIpOwogCQlmZmx1c2goc3Rkb3V0KTsKLQkJcHJpbnRmKCJcbnByZXNzIHJldHVybiB0byBj
b250aW51ZSAuLlxuIik7CisJCXByaW50ZihfKCJcbnByZXNzIHJldHVybiB0byBjb250aW51ZSAu
LlxuIikpOwogCQlnZXRzX2Zyb21GaWxlKCIiLCBzdGRpbik7CiAJfQogCXJlc3VsdHMgPSBQUWV4
ZWMocHNldC0+ZGIsIHF1ZXJ5KTsKQEAgLTEyNTUsNyArMTI1Niw3IEBACiAJCQkJZWxzZQogCQkJ
CXsKIAkJCQkJaWYgKHBzZXQtPnF1ZXJ5Rm91dCA9PSBzdGRvdXQgJiYgIXBzZXQtPnF1aWV0KQot
CQkJCQkJcHJpbnRmKCJDb3B5IGNvbW1hbmQgcmV0dXJucy4uLlxuIik7CisJCQkJCQlwcmludGYo
XygiQ29weSBjb21tYW5kIHJldHVybnMuLi5cbiIpKTsKIAogCQkJCQlzdWNjZXNzID0gaGFuZGxl
Q29weU91dChwc2V0LT5kYiwgcHNldC0+cXVlcnlGb3V0KTsKIAkJCQl9CkBAIC0xMjc5LDE2ICsx
MjgwLDE0IEBACiAJCWlmIChQUXN0YXR1cyhwc2V0LT5kYikgPT0gQ09OTkVDVElPTl9CQUQpCiAJ
CXsKIAkJCWZwcmludGYoc3RkZXJyLAotCQkJCQkiV2UgaGF2ZSBsb3N0IHRoZSBjb25uZWN0aW9u
IHRvIHRoZSBiYWNrZW5kLCBzbyAiCi0JCQkJCSJmdXJ0aGVyIHByb2Nlc3NpbmcgaXMgaW1wb3Nz
aWJsZS4gICIKLQkJCQkJIlRlcm1pbmF0aW5nLlxuIik7CisJCQkJCV8oIldlIGhhdmUgbG9zdCB0
aGUgY29ubmVjdGlvbiB0byB0aGUgYmFja2VuZCwgc28gZnVydGhlciBwcm9jZXNzaW5nIGlzIGlt
cG9zc2libGUuICBUZXJtaW5hdGluZy5cbiIpKTsKIAkJCWV4aXQoMik7CQkJLyogd2UgYXJlIG91
dCd0YSBoZXJlICovCiAJCX0KIAkJLyogY2hlY2sgZm9yIGFzeW5jaHJvbm91cyByZXR1cm5zICov
CiAJCXdoaWxlICgobm90aWZ5ID0gUFFub3RpZmllcyhwc2V0LT5kYikpICE9IE5VTEwpCiAJCXsK
IAkJCWZwcmludGYoc3RkZXJyLAotCQkJCSAiQVNZTkMgTk9USUZZIG9mICclcycgZnJvbSBiYWNr
ZW5kIHBpZCAnJWQnIHJlY2VpdmVkXG4iLAorCQkJCSBfKCJBU1lOQyBOT1RJRlkgb2YgJyVzJyBm
cm9tIGJhY2tlbmQgcGlkICclZCcgcmVjZWl2ZWRcbiIpLAogCQkJCQlub3RpZnktPnJlbG5hbWUs
IG5vdGlmeS0+YmVfcGlkKTsKIAkJCWZyZWUobm90aWZ5KTsKIAkJfQpAQCAtMTMyNSw3ICsxMzI0
LDcgQEAKIHsKIAkqc3cgPSAhKnN3OwogCWlmICghcHNldC0+cXVpZXQpCi0JCXByaW50ZigidHVy
bmVkICVzICVzXG4iLCBvbigqc3cpLCBtc2cpOworCQlwcmludGYoXygidHVybmVkICVzICVzXG4i
KSwgb24oKnN3KSwgbXNnKTsKIAlyZXR1cm4gKnN3OwogfQogCkBAIC0xNDEzLDcgKzE0MTIsNyBA
QAogCXRhYmxlX3RvayA9IHN0cnRvayh3b3JrX2FyZ3MsICIgIik7CiAJaWYgKHRhYmxlX3RvayA9
PSBOVUxMKQogCXsKLQkJZnByaW50ZihzdGRlcnIsICJcXGNvcHkgbmVlZHMgYXJndW1lbnRzLlxu
Iik7CisJCWZwcmludGYoc3RkZXJyLCBfKCJcXGNvcHkgbmVlZHMgYXJndW1lbnRzLlxuIikpOwog
CQkqZXJyb3JfcCA9IHRydWU7CiAJfQogCWVsc2UKQEAgLTE0MjQsNyArMTQyMyw3IEBACiAJCWZy
b210b190b2sgPSBzdHJ0b2soTlVMTCwgIiAgIik7CiAJCWlmIChmcm9tdG9fdG9rID09IE5VTEwp
CiAJCXsKLQkJCWZwcmludGYoc3RkZXJyLCAiJ0ZST00nIG9yICdUTycgbXVzdCBmb2xsb3cgdGFi
bGUgbmFtZS5cbiIpOworCQkJZnByaW50ZihzdGRlcnIsIF8oIidGUk9NJyBvciAnVE8nIG11c3Qg
Zm9sbG93IHRhYmxlIG5hbWUuXG4iKSk7CiAJCQkqZXJyb3JfcCA9IHRydWU7CiAJCX0KIAkJZWxz
ZQpAQCAtMTQzNiw4ICsxNDM1LDggQEAKIAkJCWVsc2UKIAkJCXsKIAkJCQlmcHJpbnRmKHN0ZGVy
ciwKLQkJCQkJCSJVbnJlY29nbml6ZWQgdG9rZW4gZm91bmQgd2hlcmUgIgotCQkJCQkJIidGUk9N
JyBvciAnVE8nIGV4cGVjdGVkOiAnJXMnLlxuIiwKKwkJCQkJCV8oIlVucmVjb2duaXplZCB0b2tl
biBmb3VuZCB3aGVyZSAiCisJCQkJCQkiJ0ZST00nIG9yICdUTycgZXhwZWN0ZWQ6ICclcycuXG4i
KSwKIAkJCQkJCWZyb210b190b2spOwogCQkJCSplcnJvcl9wID0gdHJ1ZTsKIAkJCX0KQEAgLTE0
NDgsNyArMTQ0Nyw3IEBACiAJCQkJZmlsZV90b2sgPSBzdHJ0b2soTlVMTCwgIiAiKTsKIAkJCQlp
ZiAoZmlsZV90b2sgPT0gTlVMTCkKIAkJCQl7Ci0JCQkJCWZwcmludGYoc3RkZXJyLCAiQSBmaWxl
IHBhdGhuYW1lIG11c3QgZm9sbG93ICclcycuXG4iLAorCQkJCQlmcHJpbnRmKHN0ZGVyciwgXygi
QSBmaWxlIHBhdGhuYW1lIG11c3QgZm9sbG93ICclcycuXG4iKSwKIAkJCQkJCQlmcm9tdG9fdG9r
KTsKIAkJCQkJKmVycm9yX3AgPSB0cnVlOwogCQkJCX0KQEAgLTE0NTksNyArMTQ1OCw3IEBACiAJ
CQkJCWlmIChzdHJ0b2soTlVMTCwgIiAiKSAhPSBOVUxMKQogCQkJCQl7CiAJCQkJCQlmcHJpbnRm
KHN0ZGVyciwKLQkJCQkJCSAgIllvdSBoYXZlIGV4dHJhIHRva2VucyBhZnRlciB0aGUgZmlsZW5h
bWUuXG4iKTsKKwkJCQkJCSAgXygiWW91IGhhdmUgZXh0cmEgdG9rZW5zIGFmdGVyIHRoZSBmaWxl
bmFtZS5cbiIpKTsKIAkJCQkJCSplcnJvcl9wID0gdHJ1ZTsKIAkJCQkJfQogCQkJCX0KQEAgLTE1
MjYsNyArMTUyNSw3IEBACiAjZW5kaWYKIAkJaWYgKGNvcHlzdHJlYW0gPT0gTlVMTCkKIAkJCWZw
cmludGYoc3RkZXJyLAotCQkJCSJVbmFibGUgdG8gb3BlbiBmaWxlICVzIHdoaWNoIHRvIGNvcHks
IGVycm5vID0gJXMgKCVkKS4iLAorCQkJCV8oIlVuYWJsZSB0byBvcGVuIGZpbGUgJXMgd2hpY2gg
dG8gY29weSwgZXJybm8gPSAlcyAoJWQpLiIpLAogCQkJCQlmcm9tID8gImZyb20iIDogInRvIiwg
c3RyZXJyb3IoZXJybm8pLCBlcnJubyk7CiAJCWVsc2UKIAkJewpAQCAtMTUzOSw5ICsxNTM4LDkg
QEAKIAkJCWlmICghcHNldC0+cXVpZXQpCiAJCQl7CiAJCQkJaWYgKHN1Y2Nlc3MpCi0JCQkJCXBy
aW50ZigiU3VjY2Vzc2Z1bGx5IGNvcGllZC5cbiIpOworCQkJCQlwcmludGYoXygiU3VjY2Vzc2Z1
bGx5IGNvcGllZC5cbiIpKTsKIAkJCQllbHNlCi0JCQkJCXByaW50ZigiQ29weSBmYWlsZWQuXG4i
KTsKKwkJCQkJcHJpbnRmKF8oIkNvcHkgZmFpbGVkLlxuIikpOwogCQkJfQogCQl9CiAJfQpAQCAt
MTU1NCw5ICsxNTUzLDkgQEAKIAkJICAgUHNxbFNldHRpbmdzICpwc2V0KQogewogCWlmICghbmV3
X2RibmFtZSkKLQkJZnByaW50ZihzdGRlcnIsICJcXGNvbm5lY3QgbXVzdCBiZSBmb2xsb3dlZCBi
eSBhIGRhdGFiYXNlIG5hbWVcbiIpOworCQlmcHJpbnRmKHN0ZGVyciwgXygiXFxjb25uZWN0IG11
c3QgYmUgZm9sbG93ZWQgYnkgYSBkYXRhYmFzZSBuYW1lXG4iKSk7CiAJZWxzZSBpZiAobmV3X3Vz
ZXIgIT0gTlVMTCAmJiBwc2V0LT5nZXRQYXNzd29yZCkKLQkJZnByaW50ZihzdGRlcnIsICJZb3Ug
Y2FuJ3Qgc3BlY2lmeSBhIHVzZXJuYW1lIHdoZW4gdXNpbmcgcGFzc3dvcmRzLlxuIik7CisJCWZw
cmludGYoc3RkZXJyLCBfKCJZb3UgY2FuJ3Qgc3BlY2lmeSBhIHVzZXJuYW1lIHdoZW4gdXNpbmcg
cGFzc3dvcmRzLlxuIikpOwogCWVsc2UKIAl7CiAJCVBHY29ubgkgICAqb2xkZGIgPSBwc2V0LT5k
YjsKQEAgLTE2MDEsMTggKzE2MDAsMTggQEAKIAkJaWYgKCFwc2V0LT5xdWlldCkKIAkJewogCQkJ
aWYgKCFuZXdfdXNlcikKLQkJCQlwcmludGYoImNvbm5lY3RpbmcgdG8gbmV3IGRhdGFiYXNlOiAl
c1xuIiwgZGJwYXJhbSk7CisJCQkJcHJpbnRmKF8oImNvbm5lY3RpbmcgdG8gbmV3IGRhdGFiYXNl
OiAlc1xuIiksIGRicGFyYW0pOwogCQkJZWxzZSBpZiAoZGJwYXJhbSAhPSBuZXdfZGJuYW1lKQot
CQkJCXByaW50ZigiY29ubmVjdGluZyBhcyBuZXcgdXNlcjogJXNcbiIsIG5ld191c2VyKTsKKwkJ
CQlwcmludGYoXygiY29ubmVjdGluZyBhcyBuZXcgdXNlcjogJXNcbiIpLCBuZXdfdXNlcik7CiAJ
CQllbHNlCi0JCQkJcHJpbnRmKCJjb25uZWN0aW5nIHRvIG5ldyBkYXRhYmFzZTogJXMgYXMgdXNl
cjogJXNcbiIsCisJCQkJcHJpbnRmKF8oImNvbm5lY3RpbmcgdG8gbmV3IGRhdGFiYXNlOiAlcyBh
cyB1c2VyOiAlc1xuIiksCiAJCQkJCSAgIGRicGFyYW0sIG5ld191c2VyKTsKIAkJfQogCiAJCWlm
IChQUXN0YXR1cyhwc2V0LT5kYikgPT0gQ09OTkVDVElPTl9CQUQpCiAJCXsKIAkJCWZwcmludGYo
c3RkZXJyLCAiJXNcbiIsIFBRZXJyb3JNZXNzYWdlKHBzZXQtPmRiKSk7Ci0JCQlmcHJpbnRmKHN0
ZGVyciwgIkNvdWxkIG5vdCBjb25uZWN0IHRvIG5ldyBkYXRhYmFzZS4gZXhpdGluZ1xuIik7CisJ
CQlmcHJpbnRmKHN0ZGVyciwgXygiQ291bGQgbm90IGNvbm5lY3QgdG8gbmV3IGRhdGFiYXNlLiBl
eGl0aW5nXG4iKSk7CiAJCQlleGl0KDIpOwogCQl9CiAJCWVsc2UKQEAgLTE3MjYsNyArMTcyNSw3
IEBACiAJCWNoYXIJCWxlZnRfY2VudGVyX3JpZ2h0OwkvKiBXaGljaCBjb2x1bW4gd2UncmUgZGlz
cGxheWluZyAqLwogCQlpbnQJCQlpOwkJCS8qIEluZGV4IGludG8gUUxfSEVMUFtdICovCiAKLQkJ
cHJpbnRmKCJ0eXBlIFxcaCA8Y21kPiB3aGVyZSA8Y21kPiBpcyBvbmUgb2YgdGhlIGZvbGxvd2lu
ZzpcbiIpOworCQlwcmludGYoXygidHlwZSBcXGggPGNtZD4gd2hlcmUgPGNtZD4gaXMgb25lIG9m
IHRoZSBmb2xsb3dpbmc6XG4iKSk7CiAKIAkJbGVmdF9jZW50ZXJfcmlnaHQgPSAnTCc7LyogU3Rh
cnQgd2l0aCBsZWZ0IGNvbHVtbiAqLwogCQlpID0gMDsKQEAgLTE3NTEsNyArMTc1MCw3IEBACiAJ
CX0KIAkJaWYgKGxlZnRfY2VudGVyX3JpZ2h0ICE9ICdMJykKIAkJCXB1dHMoIlxuIik7Ci0JCXBy
aW50ZigidHlwZSBcXGggKiBmb3IgYSBjb21wbGV0ZSBkZXNjcmlwdGlvbiBvZiBhbGwgY29tbWFu
ZHNcbiIpOworCQlwcmludGYoXygidHlwZSBcXGggKiBmb3IgYSBjb21wbGV0ZSBkZXNjcmlwdGlv
biBvZiBhbGwgY29tbWFuZHNcbiIpKTsKIAl9CiAJZWxzZQogCXsKQEAgLTE3ODEsOSArMTc4MCw5
IEBACiAJCQkJc3RyY21wKHRvcGljLCAiKiIpID09IDApCiAJCQl7CiAJCQkJaGVscF9mb3VuZCA9
IHRydWU7Ci0JCQkJZnByaW50Zihmb3V0LCAiQ29tbWFuZDogJXNcbiIsIFFMX0hFTFBbaV0uY21k
KTsKLQkJCQlmcHJpbnRmKGZvdXQsICJEZXNjcmlwdGlvbjogJXNcbiIsIFFMX0hFTFBbaV0uaGVs
cCk7Ci0JCQkJZnByaW50Zihmb3V0LCAiU3ludGF4OlxuIik7CisJCQkJZnByaW50Zihmb3V0LCBf
KCJDb21tYW5kOiAlc1xuIiksIFFMX0hFTFBbaV0uY21kKTsKKwkJCQlmcHJpbnRmKGZvdXQsIF8o
IkRlc2NyaXB0aW9uOiAlc1xuIiksIFFMX0hFTFBbaV0uaGVscCk7CisJCQkJZnByaW50Zihmb3V0
LCBfKCJTeW50YXg6XG4iKSk7CiAJCQkJZnByaW50Zihmb3V0LCAiJXNcbiIsIFFMX0hFTFBbaV0u
c3ludGF4KTsKIAkJCQlmcHJpbnRmKGZvdXQsICJcbiIpOwogCQkJfQpAQCAtMTc5Niw4ICsxNzk1
LDggQEAKIAkJfQogCiAJCWlmICghaGVscF9mb3VuZCkKLQkJCWZwcmludGYoc3RkZXJyLCAiY29t
bWFuZCBub3QgZm91bmQsICIKLQkJCQkJInRyeSBcXGggd2l0aCBubyBhcmd1bWVudHMgdG8gc2Vl
IGF2YWlsYWJsZSBoZWxwXG4iKTsKKwkJCWZwcmludGYoc3RkZXJyLCBfKCJjb21tYW5kIG5vdCBm
b3VuZCwgIgorCQkJCQkidHJ5IFxcaCB3aXRoIG5vIGFyZ3VtZW50cyB0byBzZWUgYXZhaWxhYmxl
IGhlbHBcbiIpKTsKIAl9CiB9CiAKQEAgLTE5MjgsNyArMTkyNyw3IEBACiAJCQkJCWRvX2NvcHko
b3B0YXJnMiwgcHNldCk7CiAJCQkJZWxzZSBpZiAoc3RyY21wKGNtZCwgImNvcHkiKSA9PSAwKQog
CQkJCXsKLQkJCQkJZnByaW50ZihzdGRlcnIsICJTZWUgXFw/IGZvciBoZWxwXG4iKTsKKwkJCQkJ
ZnByaW50ZihzdGRlcnIsIF8oIlNlZSBcXD8gZm9yIGhlbHBcbiIpKTsKIAkJCQkJYnJlYWs7CiAJ
CQkJfQogCQkJCWVsc2UgaWYgKHN0cm5jbXAoY21kLCAiY29ubmVjdCAiLCBzdHJsZW4oImNvbm5l
Y3QgIikpID09IDAgfHwKQEAgLTIyMjcsNyArMjIyNiw3IEBACiAJCQkJfQogCQkJCWVsc2UgaWYg
KCFsYXN0ZmlsZSkKIAkJCQl7Ci0JCQkJCWZwcmludGYoc3RkZXJyLCAiXFxyIG11c3QgYmUgZm9s
bG93ZWQgYnkgYSBmaWxlIG5hbWUgaW5pdGlhbGx5XG4iKTsKKwkJCQkJZnByaW50ZihzdGRlcnIs
IF8oIlxcciBtdXN0IGJlIGZvbGxvd2VkIGJ5IGEgZmlsZSBuYW1lIGluaXRpYWxseVxuIikpOwog
CQkJCQlicmVhazsKIAkJCQl9CiAJCQkJc3RhdChsYXN0ZmlsZSwgJnN0KTsKQEAgLTIyNDQsNyAr
MjI0Myw3IEBACiAJCQkJaWYgKHN0Mi5zdF9tdGltZSA9PSBzdC5zdF9tdGltZSkKIAkJCQl7CiAJ
CQkJCWlmICghcHNldC0+cXVpZXQpCi0JCQkJCQlmcHJpbnRmKHN0ZGVyciwgIndhcm5pbmc6ICVz
IG5vdCBtb2RpZmllZC4gcXVlcnkgbm90IGV4ZWN1dGVkXG4iLCBsYXN0ZmlsZSk7CisJCQkJCQlm
cHJpbnRmKHN0ZGVyciwgXygid2FybmluZzogJXMgbm90IG1vZGlmaWVkLiBxdWVyeSBub3QgZXhl
Y3V0ZWRcbiIpLCBsYXN0ZmlsZSk7CiAJCQkJCWZjbG9zZShmZCk7CiAJCQkJCWJyZWFrOwogCQkJ
CX0KQEAgLTIyNzcsNyArMjI3Niw3IEBACiAJCQkJCWV4aXQoQ01EX1RFUk1JTkFURSk7CiAJCQkJ
fQogCQkJCWlmICghcHNldC0+cXVpZXQpCi0JCQkJCXByaW50ZigiZmllbGQgc2VwYXJhdG9yIGNo
YW5nZWQgdG8gJyVzJ1xuIiwgcHNldC0+b3B0LmZpZWxkU2VwKTsKKwkJCQkJcHJpbnRmKF8oImZp
ZWxkIHNlcGFyYXRvciBjaGFuZ2VkIHRvICclcydcbiIpLCBwc2V0LT5vcHQuZmllbGRTZXApOwog
CQkJCWJyZWFrOwogCQkJfQogCQljYXNlICdnJzoJCQkJLyogXGcgbWVhbnMgc2VuZCBxdWVyeSAq
LwpAQCAtMjMwMyw3ICsyMzAyLDcgQEAKIAogCQkJCWlmICghb3B0YXJnKQogCQkJCXsKLQkJCQkJ
ZnByaW50ZihzdGRlcnIsICJcXGkgbXVzdCBiZSBmb2xsb3dlZCBieSBhIGZpbGUgbmFtZVxuIik7
CisJCQkJCWZwcmludGYoc3RkZXJyLCBfKCJcXGkgbXVzdCBiZSBmb2xsb3dlZCBieSBhIGZpbGUg
bmFtZVxuIikpOwogCQkJCQlicmVhazsKIAkJCQl9CiAjaWZuZGVmIF9fQ1lHV0lOMzJfXwpAQCAt
MjMxMiw3ICsyMzExLDcgQEAKIAkJCQlpZiAoKGZkID0gZm9wZW4ob3B0YXJnLCAicmIiKSkgPT0g
TlVMTCkKICNlbmRpZgogCQkJCXsKLQkJCQkJZnByaW50ZihzdGRlcnIsICJmaWxlIG5hbWVkICVz
IGNvdWxkIG5vdCBiZSBvcGVuZWRcbiIsIG9wdGFyZyk7CisJCQkJCWZwcmludGYoc3RkZXJyLCBf
KCJmaWxlIG5hbWVkICVzIGNvdWxkIG5vdCBiZSBvcGVuZWRcbiIpLCBvcHRhcmcpOwogCQkJCQli
cmVhazsKIAkJCQl9CiAJCQkJTWFpbkxvb3AocHNldCwgcXVlcnksIGZkKTsKQEAgLTIzMjEsNyAr
MjMyMCw3IEBACiAJCQl9CiAKIAkJY2FzZSAnSCc6Ci0JCQlpZiAodG9nZ2xlKHBzZXQsICZwc2V0
LT5vcHQuaHRtbDMsICJIVE1MMy4wIHRhYnVsYXIgb3V0cHV0IikpCisJCQlpZiAodG9nZ2xlKHBz
ZXQsICZwc2V0LT5vcHQuaHRtbDMsIF8oIkhUTUwzLjAgdGFidWxhciBvdXRwdXQiKSkpCiAJCQkJ
cHNldC0+b3B0LnN0YW5kYXJkID0gMDsKIAkJCWJyZWFrOwogCkBAIC0yMzMwLDcgKzIzMjksNyBA
QAogCQkJYnJlYWs7CiAKIAkJY2FzZSAnbSc6CQkJCS8qIG1vbml0b3IgbGlrZSB0eXBlLXNldHRp
bmcgKi8KLQkJCWlmICh0b2dnbGUocHNldCwgJnBzZXQtPm9wdC5zdGFuZGFyZCwgInN0YW5kYXJk
IFNRTCBzZXBhcmF0ZXJzIGFuZCBwYWRkaW5nIikpCisJCQlpZiAodG9nZ2xlKHBzZXQsICZwc2V0
LT5vcHQuc3RhbmRhcmQsIF8oInN0YW5kYXJkIFNRTCBzZXBhcmF0ZXJzIGFuZCBwYWRkaW5nIikp
KQogCQkJewogCQkJCXBzZXQtPm9wdC5odG1sMyA9IHBzZXQtPm9wdC5leHBhbmRlZCA9IDA7CiAJ
CQkJcHNldC0+b3B0LmFsaWduID0gcHNldC0+b3B0LmhlYWRlciA9IDE7CkBAIC0yMzM4LDcgKzIz
MzcsNyBAQAogCQkJCQlmcmVlKHBzZXQtPm9wdC5maWVsZFNlcCk7CiAJCQkJcHNldC0+b3B0LmZp
ZWxkU2VwID0gc3RyZHVwKCJ8Iik7CiAJCQkJaWYgKCFwc2V0LT5xdWlldCkKLQkJCQkJcHJpbnRm
KCJmaWVsZCBzZXBhcmF0b3IgY2hhbmdlZCB0byAnJXMnXG4iLCBwc2V0LT5vcHQuZmllbGRTZXAp
OworCQkJCQlwcmludGYoXygiZmllbGQgc2VwYXJhdG9yIGNoYW5nZWQgdG8gJyVzJ1xuIiksIHBz
ZXQtPm9wdC5maWVsZFNlcCk7CiAJCQl9CiAJCQllbHNlCiAJCQl7CkBAIC0yMzQ2LDcgKzIzNDUs
NyBAQAogCQkJCQlmcmVlKHBzZXQtPm9wdC5maWVsZFNlcCk7CiAJCQkJcHNldC0+b3B0LmZpZWxk
U2VwID0gc3RyZHVwKERFRkFVTFRfRklFTERfU0VQKTsKIAkJCQlpZiAoIXBzZXQtPnF1aWV0KQot
CQkJCQlwcmludGYoImZpZWxkIHNlcGFyYXRvciBjaGFuZ2VkIHRvICclcydcbiIsIHBzZXQtPm9w
dC5maWVsZFNlcCk7CisJCQkJCXByaW50ZihfKCJmaWVsZCBzZXBhcmF0b3IgY2hhbmdlZCB0byAn
JXMnXG4iKSwgcHNldC0+b3B0LmZpZWxkU2VwKTsKIAkJCX0KIAkJCWJyZWFrOwogCkBAIC0yMzY5
LDcgKzIzNjgsNyBAQAogCQljYXNlICdyJzoJCQkJLyogcmVzZXQoY2xlYXIpIHRoZSBidWZmZXIg
Ki8KIAkJCXF1ZXJ5WzBdID0gJ1wwJzsKIAkJCWlmICghcHNldC0+cXVpZXQpCi0JCQkJcHJpbnRm
KCJidWZmZXIgcmVzZXQoY2xlYXJlZClcbiIpOworCQkJCXByaW50ZihfKCJidWZmZXIgcmVzZXQo
Y2xlYXJlZClcbiIpKTsKIAkJCWJyZWFrOwogCiAJCWNhc2UgJ3MnOgkJCQkvKiBccyBpcyBzYXZl
IGhpc3RvcnkgdG8gYSBmaWxlICovCkBAIC0yMzc3LDEyICsyMzc2LDEyIEBACiAJCQkJb3B0YXJn
ID0gIi9kZXYvdHR5IjsKICNpZmRlZiBVU0VfSElTVE9SWQogCQkJaWYgKHdyaXRlX2hpc3Rvcnko
b3B0YXJnKSAhPSAwKQotCQkJCWZwcmludGYoc3RkZXJyLCAiY2Fubm90IHdyaXRlIGhpc3Rvcnkg
dG8gJXNcbiIsIG9wdGFyZyk7CisJCQkJZnByaW50ZihzdGRlcnIsIF8oImNhbm5vdCB3cml0ZSBo
aXN0b3J5IHRvICVzXG4iKSwgb3B0YXJnKTsKICNlbmRpZgogCQkJYnJlYWs7CiAKIAkJY2FzZSAn
dCc6CQkJCS8qIHRvZ2dsZSBoZWFkZXJzICovCi0JCQl0b2dnbGUocHNldCwgJnBzZXQtPm9wdC5o
ZWFkZXIsICJvdXRwdXQgaGVhZGluZ3MgYW5kIHJvdyBjb3VudCIpOworCQkJdG9nZ2xlKHBzZXQs
ICZwc2V0LT5vcHQuaGVhZGVyLCBfKCJvdXRwdXQgaGVhZGluZ3MgYW5kIHJvdyBjb3VudCIpKTsK
IAkJCWJyZWFrOwogCiAJCWNhc2UgJ1QnOgkJCQkvKiBkZWZpbmUgaHRtbCA8dGFibGUgLi4uPiBv
cHRpb24gKi8KQEAgLTI0MDMsNyArMjQwMiw3IEBACiAKIAkJCQlpZiAoIW9wdGFyZykKIAkJCQl7
Ci0JCQkJCWZwcmludGYoc3RkZXJyLCAiXFx3IG11c3QgYmUgZm9sbG93ZWQgYnkgYSBmaWxlIG5h
bWVcbiIpOworCQkJCQlmcHJpbnRmKHN0ZGVyciwgXygiXFx3IG11c3QgYmUgZm9sbG93ZWQgYnkg
YSBmaWxlIG5hbWVcbiIpKTsKIAkJCQkJYnJlYWs7CiAJCQkJfQogI2lmbmRlZiBfX0NZR1dJTjMy
X18KQEAgLTI0MTIsNyArMjQxMSw3IEBACiAJCQkJaWYgKChmZCA9IGZvcGVuKG9wdGFyZywgInci
KSkgPT0gTlVMTCkKICNlbmRpZgogCQkJCXsKLQkJCQkJZnByaW50ZihzdGRlcnIsICJmaWxlIG5h
bWVkICVzIGNvdWxkIG5vdCBiZSBvcGVuZWRcbiIsIG9wdGFyZyk7CisJCQkJCWZwcmludGYoc3Rk
ZXJyLCBfKCJmaWxlIG5hbWVkICVzIGNvdWxkIG5vdCBiZSBvcGVuZWRcbiIpLCBvcHRhcmcpOwog
CQkJCQlicmVhazsKIAkJCQl9CiAJCQkJZnB1dHMocXVlcnksIGZkKTsKQEAgLTI0MjIsNyArMjQy
MSw3IEBACiAJCQl9CiAKIAkJY2FzZSAneCc6Ci0JCQl0b2dnbGUocHNldCwgJnBzZXQtPm9wdC5l
eHBhbmRlZCwgImV4cGFuZGVkIHRhYmxlIHJlcHJlc2VudGF0aW9uIik7CisJCQl0b2dnbGUocHNl
dCwgJnBzZXQtPm9wdC5leHBhbmRlZCwgXygiZXhwYW5kZWQgdGFibGUgcmVwcmVzZW50YXRpb24i
KSk7CiAJCQlicmVhazsKIAogCQljYXNlICd6JzoJCQkJLyogbGlzdCB0YWJsZSByaWdodHMgKGdy
YW50L3Jldm9rZSkgKi8KQEAgLTI0OTEsNyArMjQ5MCw3IEBACiAJY3VyX2NtZF9pbnRlcmFjdGl2
ZSA9ICgoc291cmNlID09IHN0ZGluKSAmJiAhcHNldC0+bm90dHkpOwogCiAJaWYgKChxdWVyeSA9
IG1hbGxvYyhNQVhfUVVFUllfQlVGRkVSKSkgPT0gTlVMTCkKLQkJcGVycm9yKCJNZW1vcnkgQWxs
b2NhdGlvbiBGYWlsZWQiKTsKKwkJcGVycm9yKF8oIk1lbW9yeSBBbGxvY2F0aW9uIEZhaWxlZCIp
KTsKIAogCWlmIChjdXJfY21kX2ludGVyYWN0aXZlKQogCXsKQEAgLTI1NzAsNyArMjU2OSw3IEBA
CiAJCXsJCQkJCQkvKiBObyBtb3JlIGlucHV0LiAgVGltZSB0byBxdWl0LCBvciBcaQogCQkJCQkJ
CQkgKiBkb25lICovCiAJCQlpZiAoIXBzZXQtPnF1aWV0KQotCQkJCXByaW50ZigiRU9GXG4iKTsv
KiBHb2VzIG9uIHByb21wdCBsaW5lICovCisJCQkJcHJpbnRmKF8oIkVPRlxuIikpOy8qIEdvZXMg
b24gcHJvbXB0IGxpbmUgKi8KIAkJCWVvZiA9IHRydWU7CiAJCQljb250aW51ZTsKIAkJfQpAQCAt
Mjc4Niw5ICsyNzg1LDkgQEAKIAkJfQogCQllbHNlIGlmIChzdHJsZW4ocXVlcnkpICsgc3RybGVu
KHF1ZXJ5X3N0YXJ0KSA+IE1BWF9RVUVSWV9CVUZGRVIpCiAJCXsKLQkJCWZwcmludGYoc3RkZXJy
LCAicXVlcnkgYnVmZmVyIG1heCBsZW5ndGggb2YgJWQgZXhjZWVkZWRcbiIsCisJCQlmcHJpbnRm
KHN0ZGVyciwgXygicXVlcnkgYnVmZmVyIG1heCBsZW5ndGggb2YgJWQgZXhjZWVkZWRcbiIpLAog
CQkJCQlNQVhfUVVFUllfQlVGRkVSKTsKLQkJCWZwcmludGYoc3RkZXJyLCAicXVlcnkgbGluZSBp
Z25vcmVkXG4iKTsKKwkJCWZwcmludGYoc3RkZXJyLCBfKCJxdWVyeSBsaW5lIGlnbm9yZWRcbiIp
KTsKIAkJCWZyZWUobGluZSk7CiAJCX0KIAkJZWxzZQpAQCAtMjg4Nyw2ICsyODg2LDEwIEBACiAJ
aGFzX2NsaWVudF9lbmNvZGluZyA9IGdldGVudigiUEdDTElFTlRFTkNPRElORyIpOwogI2VuZGlm
CiAKKyNpZmRlZiBVU0VfTVVMVElMQU5HCisJSW5pdE1hbHRpTGFuZygpOworI2VuZGlmCisKIAl3
aGlsZSAoKGMgPSBnZXRvcHQoYXJnYywgYXJndiwgIkFhOmM6ZDplRWY6RjpsaDpIbnNvOnA6cVN0
VDp1eCIpKSAhPSBFT0YpCiAJewogCQlzd2l0Y2ggKGMpCkBAIC0yOTg4LDcgKzI5OTEsNyBAQAog
CiAJaWYgKFBRc3RhdHVzKHNldHRpbmdzLmRiKSA9PSBDT05ORUNUSU9OX0JBRCkKIAl7Ci0JCWZw
cmludGYoc3RkZXJyLCAiQ29ubmVjdGlvbiB0byBkYXRhYmFzZSAnJXMnIGZhaWxlZC5cbiIsIGRi
bmFtZSk7CisJCWZwcmludGYoc3RkZXJyLCBfKCJDb25uZWN0aW9uIHRvIGRhdGFiYXNlICclcycg
ZmFpbGVkLlxuIiksIGRibmFtZSk7CiAJCWZwcmludGYoc3RkZXJyLCAiJXNcbiIsIFBRZXJyb3JN
ZXNzYWdlKHNldHRpbmdzLmRiKSk7CiAJCVBRZmluaXNoKHNldHRpbmdzLmRiKTsKIAkJZXhpdCgx
KTsKQEAgLTMwMDAsMTggKzMwMDMsMTggQEAKIAkJZXhpdChsaXN0QWxsRGJzKCZzZXR0aW5ncykp
OwogCWlmICghc2V0dGluZ3MucXVpZXQgJiYgIXNldHRpbmdzLm5vdHR5ICYmICFzaW5nbGVRdWVy
eSAmJiAhcWZpbGVuYW1lKQogCXsKLQkJcHJpbnRmKCJXZWxjb21lIHRvIHRoZSBQT1NUR1JFU1FM
IGludGVyYWN0aXZlIHNxbCBtb25pdG9yOlxuIik7Ci0JCXByaW50ZigiICBQbGVhc2UgcmVhZCB0
aGUgZmlsZSBDT1BZUklHSFQgZm9yIGNvcHlyaWdodCB0ZXJtcyAiCi0JCQkgICAib2YgUE9TVEdS
RVNRTFxuIik7CisJCXByaW50ZihfKCJXZWxjb21lIHRvIHRoZSBQT1NUR1JFU1FMIGludGVyYWN0
aXZlIHNxbCBtb25pdG9yOlxuIikpOworCQlwcmludGYoXygiICBQbGVhc2UgcmVhZCB0aGUgZmls
ZSBDT1BZUklHSFQgZm9yIGNvcHlyaWdodCB0ZXJtcyAiCisJCQkgICAib2YgUE9TVEdSRVNRTFxu
IikpOwogCiAJCWlmICgodmVyc2lvbiA9IHNlbGVjdFZlcnNpb24oJnNldHRpbmdzKSkgIT0gTlVM
TCkKIAkJCXByaW50ZigiWyVzXVxuIiwgdmVyc2lvbik7CiAKIAkJcHJpbnRmKCJcbiIpOwotCQlw
cmludGYoIiAgIHR5cGUgXFw/IGZvciBoZWxwIG9uIHNsYXNoIGNvbW1hbmRzXG4iKTsKLQkJcHJp
bnRmKCIgICB0eXBlIFxccSB0byBxdWl0XG4iKTsKLQkJcHJpbnRmKCIgICB0eXBlIFxcZyBvciB0
ZXJtaW5hdGUgd2l0aCBzZW1pY29sb24gdG8gZXhlY3V0ZSBxdWVyeVxuIik7Ci0JCXByaW50Zigi
IFlvdSBhcmUgY3VycmVudGx5IGNvbm5lY3RlZCB0byB0aGUgZGF0YWJhc2U6ICVzXG5cbiIsIGRi
bmFtZSk7CisJCXByaW50ZihfKCIgICB0eXBlIFxcPyBmb3IgaGVscCBvbiBzbGFzaCBjb21tYW5k
c1xuIikpOworCQlwcmludGYoXygiICAgdHlwZSBcXHEgdG8gcXVpdFxuIikpOworCQlwcmludGYo
XygiICAgdHlwZSBcXGcgb3IgdGVybWluYXRlIHdpdGggc2VtaWNvbG9uIHRvIGV4ZWN1dGUgcXVl
cnlcbiIpKTsKKwkJcHJpbnRmKF8oIiBZb3UgYXJlIGN1cnJlbnRseSBjb25uZWN0ZWQgdG8gdGhl
IGRhdGFiYXNlOiAlc1xuXG4iKSwgZGJuYW1lKTsKIAl9CiAKIAkvKgpAQCAtMzEzNSw5ICszMTM4
LDkgQEAKIAogCWlmIChtdXN0cHJvbXB0KQogCXsKLQkJZnB1dHMoIkVudGVyIGluZm8gZm9sbG93
ZWQgYnkgYSBuZXdsaW5lXG4iLCBzdGRvdXQpOwotCQlmcHV0cygiRW5kIHdpdGggYSBiYWNrc2xh
c2ggYW5kIGEgIgotCQkJICAicGVyaW9kIG9uIGEgbGluZSBieSBpdHNlbGYuXG4iLCBzdGRvdXQp
OworCQlmcHV0cyhfKCJFbnRlciBpbmZvIGZvbGxvd2VkIGJ5IGEgbmV3bGluZVxuIiksIHN0ZG91
dCk7CisJCWZwdXRzKF8oIkVuZCB3aXRoIGEgYmFja3NsYXNoIGFuZCBhICIKKwkJCSAgInBlcmlv
ZCBvbiBhIGxpbmUgYnkgaXRzZWxmLlxuIiksIHN0ZG91dCk7CiAJfQogCXdoaWxlICghY29weWRv
bmUpCiAJewkJCQkJCQkvKiBmb3IgZWFjaCBpbnB1dCBsaW5lIC4uLiAqLwpAQCAtMzI0MSw3ICsz
MjQ0LDcgQEAKIAogI2VuZGlmCiAKLQlwcmludGYoIlVzZXJuYW1lOiAiKTsKKwlwcmludGYoXygi
VXNlcm5hbWU6ICIpKTsKIAlmZ2V0cyh1c2VybmFtZSwgMTAwLCBzdGRpbik7CiAJbGVuZ3RoID0g
c3RybGVuKHVzZXJuYW1lKTsKIAkvKiBza2lwIHJlc3Qgb2YgdGhlIGxpbmUgKi8KZGlmZiAtdU5y
IHBvc3RncmVzcWwtNi41LjEtb3JpZy9zcmMvYmluL3BzcWwvcHNxbEhlbHAuaCBwb3N0Z3Jlc3Fs
LTYuNS4xL3NyYy9iaW4vcHNxbC9wc3FsSGVscC5oCi0tLSBwb3N0Z3Jlc3FsLTYuNS4xLW9yaWcv
c3JjL2Jpbi9wc3FsL3BzcWxIZWxwLmgJTW9uIEp1bCAxMiAwNjo0NzoyMSAxOTk5CisrKyBwb3N0
Z3Jlc3FsLTYuNS4xL3NyYy9iaW4vcHNxbC9wc3FsSGVscC5oCVN1biBKdWwgMjUgMjI6NTk6MDgg
MTk5OQpAQCAtMTksNDcgKzE5LDQ3IEBACiAKIHN0YXRpYyBzdHJ1Y3QgX2hlbHBTdHJ1Y3QgUUxf
SEVMUFtdID0gewogCXsiYWJvcnQgdHJhbnNhY3Rpb24iLAotCQkiYWJvcnQgdGhlIGN1cnJlbnQg
dHJhbnNhY3Rpb24iLAotCSJcCi1cdGFib3J0IFt0cmFuc2FjdGlvbnx3b3JrXTsifSwKKwkJXygi
YWJvcnQgdGhlIGN1cnJlbnQgdHJhbnNhY3Rpb24iKSwKKwlfKCJcCitcdGFib3J0IFt0cmFuc2Fj
dGlvbnx3b3JrXTsiKX0sCiAJeyJhbHRlciB0YWJsZSIsCi0JCSJhZGQvcmVuYW1lIGF0dHJpYnV0
ZXMsIHJlbmFtZSB0YWJsZXMiLAotCSJcCisJCV8oImFkZC9yZW5hbWUgYXR0cmlidXRlcywgcmVu
YW1lIHRhYmxlcyIpLAorCV8oIlwKIFx0QUxURVIgVEFCTEUgY2xhc3NfbmFtZSBbKl0gQUREIENP
TFVNTiBhdHRyIHR5cGVcblwKIFx0QUxURVIgVEFCTEUgY2xhc3NfbmFtZSBbKl0gUkVOQU1FIFtD
T0xVTU5dIGF0dHIxIFRPIGF0dHIyXG5cCi1cdEFMVEVSIFRBQkxFIGNsYXNzX25hbWUxIFJFTkFN
RSBUTyBjbGFzc19uYW1lMiJ9LAorXHRBTFRFUiBUQUJMRSBjbGFzc19uYW1lMSBSRU5BTUUgVE8g
Y2xhc3NfbmFtZTIiKX0sCiAJeyJhbHRlciB1c2VyIiwKLQkJImFsdGVyIHN5c3RlbSBpbmZvcm1h
dGlvbiBmb3IgYSB1c2VyIiwKLQkiXAorCQlfKCJhbHRlciBzeXN0ZW0gaW5mb3JtYXRpb24gZm9y
IGEgdXNlciIpLAorCV8oIlwKIFx0QUxURVIgVVNFUiB1c2VyX25hbWVcblwKIFx0W1dJVEggUEFT
U1dPUkQgcGFzc3dvcmRdXG5cCiBcdFtDUkVBVEVEQiB8IE5PQ0NSRUFURURCXVxuXAogXHRbQ1JF
QVRFVVNFUiB8IE5PQ1JFQVRFVVNFUl1cblwKIFx0W0lOIEdST1VQIGdyb3VwXzEsIC4uLmdyb3Vw
Tl1cblwKLVx0W1ZBTElEIFVOVElMICdhYnN0aW1lJ107In0sCitcdFtWQUxJRCBVTlRJTCAnYWJz
dGltZSddOyIpfSwKIAl7ImJlZ2luIHdvcmsiLAotCQkiYmVnaW4gYSBuZXcgdHJhbnNhY3Rpb24i
LAotCSJcCi1cdEJFR0lOIFtXT1JLfFRSQU5TQUNUSU9OXTsifSwKKwkJXygiYmVnaW4gYSBuZXcg
dHJhbnNhY3Rpb24iKSwKKwlfKCJcCitcdEJFR0lOIFtXT1JLfFRSQU5TQUNUSU9OXTsiKX0sCiAJ
eyJjbHVzdGVyIiwKLQkJImNyZWF0ZSBhIGNsdXN0ZXJlZCBpbmRleCAoZnJvbSBhbiBleGlzdGlu
ZyBpbmRleCkiLAotCSJcCi1cdENMVVNURVIgaW5kZXhfbmFtZSBPTiByZWxhdGlvbl9uYW1lIn0s
CisJCV8oImNyZWF0ZSBhIGNsdXN0ZXJlZCBpbmRleCAoZnJvbSBhbiBleGlzdGluZyBpbmRleCki
KSwKKwlfKCJcCitcdENMVVNURVIgaW5kZXhfbmFtZSBPTiByZWxhdGlvbl9uYW1lIil9LAogCXsi
Y2xvc2UiLAotCQkiY2xvc2UgYW4gZXhpc3RpbmcgY3Vyc29yIChjdXJzb3IpIiwKLQkiXAotXHRD
TE9TRSBjdXJzb3JuYW1lOyJ9LAorCQlfKCJjbG9zZSBhbiBleGlzdGluZyBjdXJzb3IgKGN1cnNv
cikiKSwKKwlfKCJcCitcdENMT1NFIGN1cnNvcm5hbWU7Iil9LAogCXsiY29tbWl0IHdvcmsiLAot
CQkiY29tbWl0IGEgdHJhbnNhY3Rpb24iLAotCSJcCi1cdENPTU1JVCBbV09SS3xUUkFOU0FDVElP
Tl0ifSwKKwkJXygiY29tbWl0IGEgdHJhbnNhY3Rpb24iKSwKKwlfKCJcCitcdENPTU1JVCBbV09S
S3xUUkFOU0FDVElPTl0iKX0sCiAJeyJjb3B5IiwKLQkJImNvcHkgZGF0YSB0byBhbmQgZnJvbSBh
IHRhYmxlIiwKLQkiXAorCQlfKCJjb3B5IGRhdGEgdG8gYW5kIGZyb20gYSB0YWJsZSIpLAorCV8o
IlwKIFx0Q09QWSBbQklOQVJZXSBjbGFzc19uYW1lIFtXSVRIIE9JRFNdXG5cCi1cdFRPfEZST00g
ZmlsZW5hbWV8U1RESU58U1RET1VUIFtVU0lORyBERUxJTUlURVJTICdkZWxpbSddOyJ9LAorXHRU
T3xGUk9NIGZpbGVuYW1lfFNURElOfFNURE9VVCBbVVNJTkcgREVMSU1JVEVSUyAnZGVsaW0nXTsi
KX0sCiAJeyJjcmVhdGUiLAotCQkiUGxlYXNlIGJlIG1vcmUgc3BlY2lmaWM6IiwKKwkJXygiUGxl
YXNlIGJlIG1vcmUgc3BlY2lmaWM6IiksCiAJIlwKIFx0Y3JlYXRlIGFnZ3JlZ2F0ZVxuXAogXHRj
cmVhdGUgZGF0YWJhc2VcblwKQEAgLTczLDEwMCArNzMsMTAwIEBACiBcdGNyZWF0ZSB0eXBlXG5c
CiBcdGNyZWF0ZSB2aWV3In0sCiAJeyJjcmVhdGUgYWdncmVnYXRlIiwKLQkJImRlZmluZSBhbiBh
Z2dyZWdhdGUgZnVuY3Rpb24iLAotCSJcCisJCV8oImRlZmluZSBhbiBhZ2dyZWdhdGUgZnVuY3Rp
b24iKSwKKwlfKCJcCiBcdENSRUFURSBBR0dSRUdBVEUgYWdnX25hbWUgW0FTXSAoQkFTRVRZUEUg
PSBkYXRhX3R5cGUsIFxuXAogXHRbU0ZVTkMxID0gc2Z1bmNfMSwgU1RZUEUxID0gc2Z1bmMxX3Jl
dHVybl90eXBlXVxuXAogXHRbU0ZVTkMyID0gc2Z1bmNfMiwgU1RZUEUyID0gc2Z1bmMyX3JldHVy
bl90eXBlXVxuXAogXHRbLEZJTkFMRlVOQyA9IGZpbmFsLWZ1bmN0aW9uXVxuXAotXHRbLElOSVRD
T05EMSA9IGluaXRpYWwtY29uZDFdWyxJTklUQ09ORDIgPSBpbml0aWFsLWNvbmQyXSk7In0sCitc
dFssSU5JVENPTkQxID0gaW5pdGlhbC1jb25kMV1bLElOSVRDT05EMiA9IGluaXRpYWwtY29uZDJd
KTsiKX0sCiAJeyJjcmVhdGUgZGF0YWJhc2UiLAotCQkiY3JlYXRlIGEgZGF0YWJhc2UiLAotCSJc
Ci1cdENSRUFURSBEQVRBQkFTRSBkYm5hbWUgW1dJVEggTE9DQVRJT04gPSAnZGJwYXRoJ10ifSwK
KwkJXygiY3JlYXRlIGEgZGF0YWJhc2UiKSwKKwlfKCJcCitcdENSRUFURSBEQVRBQkFTRSBkYm5h
bWUgW1dJVEggTE9DQVRJT04gPSAnZGJwYXRoJ10iKX0sCiAJeyJjcmVhdGUgZnVuY3Rpb24iLAot
CQkiY3JlYXRlIGEgdXNlci1kZWZpbmVkIGZ1bmN0aW9uIiwKLQkiXAorCQlfKCJjcmVhdGUgYSB1
c2VyLWRlZmluZWQgZnVuY3Rpb24iKSwKKwlfKCJcCiBcdENSRUFURSBGVU5DVElPTiBmdW5jdGlv
bl9uYW1lIChbdHlwZTEsIC4uLnR5cGVOXSkgUkVUVVJOUyByZXR1cm5fdHlwZVxuXAogXHRBUyAn
b2JqZWN0X2ZpbGVuYW1lJ3wnc3FsLXF1ZXJpZXMnfCdidWlsdGluX2Z1bmN0aW9uX25hbWUnXG5c
Ci1cdExBTkdVQUdFICdjJ3wnc3FsJ3wnaW50ZXJuYWwnOyJ9LAorXHRMQU5HVUFHRSAnYyd8J3Nx
bCd8J2ludGVybmFsJzsiKX0sCiAJeyJjcmVhdGUgaW5kZXgiLAotCQkiY29uc3RydWN0IGFuIGlu
ZGV4IiwKLQkiXAorCQlfKCJjb25zdHJ1Y3QgYW4gaW5kZXgiKSwKKwlfKCJcCiBcdENSRUFURSBb
VU5JUVVFXSBJTkRFWCBpbmRleG5hbWUgT04gY2xhc3NfbmFtZSBbVVNJTkcgYWNjZXNzX21ldGhv
ZF1cblwKLSggYXR0cjEgW3R5cGVfY2xhc3MxXSwgLi4uYXR0ck4gfCBmdW5jbmFtZShhdHRyMSwg
Li4uKSBbdHlwZV9jbGFzc10gKTsifSwKKyggYXR0cjEgW3R5cGVfY2xhc3MxXSwgLi4uYXR0ck4g
fCBmdW5jbmFtZShhdHRyMSwgLi4uKSBbdHlwZV9jbGFzc10gKTsiKX0sCiAJeyJjcmVhdGUgb3Bl
cmF0b3IiLAotCQkiY3JlYXRlIGEgdXNlci1kZWZpbmVkIG9wZXJhdG9yIiwKLQkiXAorCQlfKCJj
cmVhdGUgYSB1c2VyLWRlZmluZWQgb3BlcmF0b3IiKSwKKwlfKCJcCiBcdENSRUFURSBPUEVSQVRP
UiBvcGVyYXRvcl9uYW1lIChcblwKIFx0W0xFRlRBUkcgPSB0eXBlMV1bLFJJR0hUQVJHID0gdHlw
ZTJdXG5cCiBcdCxQUk9DRURVUkUgPSBmdW5jX25hbWUsXG5cCiBcdFssQ09NTVVUQVRPUiA9IGNv
bV9vcF1bLE5FR0FUT1IgPSBuZWdfb3BdXG5cCiBcdFssUkVTVFJJQ1QgPSByZXNfcHJvY11bLEpP
SU4gPSBqb2luX3Byb2NdWyxIQVNIRVNdXG5cCi1cdFssU09SVDEgPSBsZWZ0X3NvcnRfb3BdWyxT
T1JUMiA9IHJpZ2h0X3NvcnRfb3BdKTsifSwKK1x0WyxTT1JUMSA9IGxlZnRfc29ydF9vcF1bLFNP
UlQyID0gcmlnaHRfc29ydF9vcF0pOyIpfSwKIAl7ImNyZWF0ZSBydWxlIiwKLQkJImRlZmluZSBh
IG5ldyBydWxlIiwKLQkiXAorCQlfKCJkZWZpbmUgYSBuZXcgcnVsZSIpLAorCV8oIlwKIFx0Q1JF
QVRFIFJVTEUgcnVsZV9uYW1lIEFTIE9OXG5cCiBcdHsgU0VMRUNUIHwgVVBEQVRFIHwgREVMRVRF
IHwgSU5TRVJUIH1cblwKIFx0VE8gb2JqZWN0IFtXSEVSRSBxdWFsXVxuXAotXHRETyBbSU5TVEVB
RF0gW2FjdGlvbnxOT1RISU5HfFthY3Rpb25zXV07In0sCitcdERPIFtJTlNURUFEXSBbYWN0aW9u
fE5PVEhJTkd8W2FjdGlvbnNdXTsiKX0sCiAJeyJjcmVhdGUgc2VxdWVuY2UiLAotCQkiY3JlYXRl
IGEgbmV3IHNlcXVlbmNlIG51bWJlciBnZW5lcmF0b3IiLAotCSJcCisJCV8oImNyZWF0ZSBhIG5l
dyBzZXF1ZW5jZSBudW1iZXIgZ2VuZXJhdG9yIiksCisJXygiXAogXHRDUkVBVEUgU0VRVUVOQ0Ug
c2VxdWVuY2VfbmFtZVxuXAogXHRbSU5DUkVNRU5UIG51bWJlcl1cblwKIFx0W1NUQVJUIG51bWJl
cl1cblwKIFx0W01JTlZBTFVFIG51bWJlcl1cblwKIFx0W01BWFZBTFVFIG51bWJlcl1cblwKIFx0
W0NBQ0hFIG51bWJlcl1cblwKLVx0W0NZQ0xFXTsifSwKK1x0W0NZQ0xFXTsiKX0sCiAJeyJjcmVh
dGUgdGFibGUiLAotCQkiY3JlYXRlIGEgbmV3IHRhYmxlIiwKLQkiXAorCQlfKCJjcmVhdGUgYSBu
ZXcgdGFibGUiKSwKKwlfKCJcCiBcdENSRUFURSBbVEVNUF0gVEFCTEUgY2xhc3NfbmFtZVxuXAog
XHQoYXR0cjEgdHlwZTEgW0RFRkFVTFQgZXhwcmVzc2lvbl0gW05PVCBOVUxMXSwgLi4uYXR0ck5c
blwKIFx0W1tDT05TVFJBSU5UIG5hbWVdIENIRUNLIGNvbmRpdGlvbjEsIC4uLmNvbmRpdGlvbk5d
IClcblwKIFx0W0lOSEVSSVRTIChjbGFzc19uYW1lMSwgLi4uY2xhc3NfbmFtZU4pXG5cCi07In0s
Cis7Iil9LAogCXsiY3JlYXRlIHRyaWdnZXIiLAotCQkiY3JlYXRlIGEgbmV3IHRyaWdnZXIiLAot
CSJcCisJCV8oImNyZWF0ZSBhIG5ldyB0cmlnZ2VyIiksCisJXygiXAogXHRDUkVBVEUgVFJJR0dF
UiB0cmlnZ2VyX25hbWUgQUZURVJ8QkVGT1JFIGV2ZW50MSBbT1IgZXZlbnQyIFtPUiBldmVudDNd
IF1cblwKIFx0T04gY2xhc3NfbmFtZSBGT1IgRUFDSCBST1d8U1RBVEVNRU5UXG5cCiBcdEVYRUNV
VEUgUFJPQ0VEVVJFIGZ1bmNfbmFtZSAoW2FyZ3VtZW50c10pXG5cCiBcblwKLVx0ZXZlbnRYIGlz
IG9uZSBvZiBJTlNFUlQsIERFTEVURSwgVVBEQVRFIn0sCitcdGV2ZW50WCBpcyBvbmUgb2YgSU5T
RVJULCBERUxFVEUsIFVQREFURSIpfSwKIAl7ImNyZWF0ZSB0eXBlIiwKLQkJImNyZWF0ZSBhIG5l
dyB1c2VyLWRlZmluZWQgYmFzZSBkYXRhIHR5cGUiLAotCSJcCisJCV8oImNyZWF0ZSBhIG5ldyB1
c2VyLWRlZmluZWQgYmFzZSBkYXRhIHR5cGUiKSwKKwlfKCJcCiBcdENSRUFURSBUWVBFIHR5cGVu
YW1lIChcblwKIFx0SU5URVJOQUxMRU5HVEggPSAobnVtYmVyfFZBUklBQkxFKSxcblwKIFx0W0VY
VEVSTkFMTEVOR1RIID0gKG51bWJlcnxWQVJJQUJMRSksXVxuXAogXHRJTlBVVCA9IGlucHV0X2Z1
bmN0aW9uLCBPVVRQVVQgPSBvdXRwdXRfZnVuY3Rpb25cblwKIFx0WyxFTEVNRU5UID0gdHlwZW5h
bWVdWyxERUxJTUlURVIgPSBjaGFyYWN0ZXJdWyxERUZBVUxUPVwnPHN0cmluZz5cJ11cblwKLVx0
WyxTRU5EID0gc2VuZF9mdW5jdGlvbl1bLFJFQ0VJVkUgPSByZWNlaXZlX2Z1bmN0aW9uXVssUEFT
U0VEQllWQUxVRV0pOyJ9LAorXHRbLFNFTkQgPSBzZW5kX2Z1bmN0aW9uXVssUkVDRUlWRSA9IHJl
Y2VpdmVfZnVuY3Rpb25dWyxQQVNTRURCWVZBTFVFXSk7Iil9LAogCXsiY3JlYXRlIHVzZXIiLAot
CQkiY3JlYXRlIGEgbmV3IHVzZXIiLAotCSJcCisJCV8oImNyZWF0ZSBhIG5ldyB1c2VyIiksCisJ
XygiXAogXHRDUkVBVEUgVVNFUiB1c2VyX25hbWVcblwKIFx0W1dJVEggUEFTU1dPUkQgcGFzc3dv
cmRdXG5cCiBcdFtDUkVBVEVEQiB8IE5PQ1JFQVRFREJdXG5cCiBcdFtDUkVBVEVVU0VSIHwgTk9D
UkVBVEVVU0VSXVxuXAogXHRbSU4gR1JPVVAgZ3JvdXAxLCAuLi5ncm91cE5dXG5cCi1cdFtWQUxJ
RCBVTlRJTCAnYWJzdGltZSddOyJ9LAorXHRbVkFMSUQgVU5USUwgJ2Fic3RpbWUnXTsiKX0sCiAJ
eyJjcmVhdGUgdmlldyIsCi0JCSJjcmVhdGUgYSB2aWV3IiwKLQkiXAorCQlfKCJjcmVhdGUgYSB2
aWV3IiksCisJXygiXAogXHRDUkVBVEUgVklFVyB2aWV3X25hbWUgQVNcblwKIFx0U0VMRUNUIFtE
SVNUSU5DVCBbT04gYXR0ck5dXVxuXAogXHRleHByMSBbQVMgYXR0cjFdLCAuLi5leHByTlxuXAog
XHRbRlJPTSBmcm9tX2xpc3RdXG5cCiBcdFtXSEVSRSBxdWFsXVxuXAotXHRbR1JPVVAgQlkgZ3Jv
dXBfbGlzdF07In0sCitcdFtHUk9VUCBCWSBncm91cF9saXN0XTsiKX0sCiAJeyJkZWNsYXJlIiwK
LQkJInNldCB1cCBhIGN1cnNvciIsCi0JIlwKKwkJXygic2V0IHVwIGEgY3Vyc29yIiksCisJXygi
XAogXHRERUNMQVJFIGN1cnNvcm5hbWUgW0JJTkFSWV0gQ1VSU09SIEZPUlxuXAogXHRTRUxFQ1Qg
W0RJU1RJTkNUIFtPTiBhdHRyTl1dXG5cCiBcdGV4cHIxIFtBUyBhdHRyMV0sIC4uLmV4cHJOXG5c
CkBAIC0xNzUsMTMgKzE3NSwxMyBAQAogXHRbR1JPVVAgQlkgZ3JvdXBfbGlzdF1cblwKIFx0W0hB
VklORyBoYXZpbmdfY2xhdXNlXVxuXAogXHRbT1JERVIgQlkgYXR0cjEgW1VTSU5HIG9wMV0sIC4u
LmF0dHJOXVxuXAotXHRbIHsgVU5JT04gW0FMTF0gfCBJTlRFUlNFQ1QgfCBFWENFUFQgfSBTRUxF
Q1QgLi4uXTsifSwKK1x0WyB7IFVOSU9OIFtBTExdIHwgSU5URVJTRUNUIHwgRVhDRVBUIH0gU0VM
RUNUIC4uLl07Iil9LAogCXsiZGVsZXRlIiwKLQkJImRlbGV0ZSB0dXBsZXMiLAotCSJcCi1cdERF
TEVURSBGUk9NIGNsYXNzX25hbWUgW1dIRVJFIHF1YWxdOyJ9LAorCQlfKCJkZWxldGUgdHVwbGVz
IiksCisJXygiXAorXHRERUxFVEUgRlJPTSBjbGFzc19uYW1lIFtXSEVSRSBxdWFsXTsiKX0sCiAJ
eyJkcm9wIiwKLQkJIlBsZWFzZSBiZSBtb3JlIHNwZWNpZmljOiIsCisJCV8oIlBsZWFzZSBiZSBt
b3JlIHNwZWNpZmljOiIpLAogCSJcCiBcdGRyb3AgYWdncmVnYXRlXG5cCiBcdGRyb3AgZGF0YWJh
c2VcblwKQEAgLTE5NSw3NCArMTk1LDc0IEBACiBcdGRyb3AgdHlwZVxuXAogXHRkcm9wIHZpZXci
fSwKIAl7ImRyb3AgYWdncmVnYXRlIiwKLQkJInJlbW92ZSBhbiBhZ2dyZWdhdGUgZnVuY3Rpb24i
LAotCSJcCi1cdERST1AgQUdHUkVHQVRFIGFnZ19uYW1lIGFnZ190eXBlfCo7In0sCisJCV8oInJl
bW92ZSBhbiBhZ2dyZWdhdGUgZnVuY3Rpb24iKSwKKwlfKCJcCitcdERST1AgQUdHUkVHQVRFIGFn
Z19uYW1lIGFnZ190eXBlfCo7Iil9LAogCXsiZHJvcCBkYXRhYmFzZSIsCi0JCSJyZW1vdmUgYSBk
YXRhYmFzZSIsCi0JIlwKLVx0RFJPUCBEQVRBQkFTRSBkYm5hbWUifSwKKwkJXygicmVtb3ZlIGEg
ZGF0YWJhc2UiKSwKKwlfKCJcCitcdERST1AgREFUQUJBU0UgZGJuYW1lIil9LAogCXsiZHJvcCBm
dW5jdGlvbiIsCi0JCSJyZW1vdmUgYSB1c2VyLWRlZmluZWQgZnVuY3Rpb24iLAotCSJcCi1cdERS
T1AgRlVOQ1RJT04gZnVuY25hbWUgKFt0eXBlMSwgLi4udHlwZU5dKTsifSwKKwkJXygicmVtb3Zl
IGEgdXNlci1kZWZpbmVkIGZ1bmN0aW9uIiksCisJXygiXAorXHREUk9QIEZVTkNUSU9OIGZ1bmNu
YW1lIChbdHlwZTEsIC4uLnR5cGVOXSk7Iil9LAogCXsiZHJvcCBpbmRleCIsCi0JCSJyZW1vdmUg
YW4gZXhpc3RpbmcgaW5kZXgiLAotCSJcCi1cdERST1AgSU5ERVggaW5kZXhuYW1lOyJ9LAorCQlf
KCJyZW1vdmUgYW4gZXhpc3RpbmcgaW5kZXgiKSwKKwlfKCJcCitcdERST1AgSU5ERVggaW5kZXhu
YW1lOyIpfSwKIAl7ImRyb3Agb3BlcmF0b3IiLAotCQkicmVtb3ZlIGEgdXNlci1kZWZpbmVkIG9w
ZXJhdG9yIiwKLQkiXAotXHREUk9QIE9QRVJBVE9SIG9wZXJhdG9yX25hbWUgKFtsdHlwZXxOT05F
XSxbUlRZUEV8bm9uZV0pOyJ9LAorCQlfKCJyZW1vdmUgYSB1c2VyLWRlZmluZWQgb3BlcmF0b3Ii
KSwKKwlfKCJcCitcdERST1AgT1BFUkFUT1Igb3BlcmF0b3JfbmFtZSAoW2x0eXBlfE5PTkVdLFtS
VFlQRXxub25lXSk7Iil9LAogCXsiZHJvcCBydWxlIiwKLQkJInJlbW92ZSBhIHJ1bGUiLAotCSJc
Ci1cdERST1AgUlVMRSBydWxlbmFtZTsifSwKKwkJXygicmVtb3ZlIGEgcnVsZSIpLAorCV8oIlwK
K1x0RFJPUCBSVUxFIHJ1bGVuYW1lOyIpfSwKIAl7ImRyb3Agc2VxdWVuY2UiLAotCQkicmVtb3Zl
IGEgc2VxdWVuY2UgbnVtYmVyIGdlbmVyYXRvciIsCi0JIlwKLVx0RFJPUCBTRVFVRU5DRSBzZXF1
ZW5jZV9uYW1lWywgLi4uc2VxdWVuY2VfbmFtZU5dOyJ9LAorCQlfKCJyZW1vdmUgYSBzZXF1ZW5j
ZSBudW1iZXIgZ2VuZXJhdG9yIiksCisJXygiXAorXHREUk9QIFNFUVVFTkNFIHNlcXVlbmNlX25h
bWVbLCAuLi5zZXF1ZW5jZV9uYW1lTl07Iil9LAogCXsiZHJvcCB0YWJsZSIsCi0JCSJyZW1vdmUg
YSB0YWJsZSIsCi0JIlwKLVx0RFJPUCBUQUJMRSBjbGFzc19uYW1lMSwgLi4uY2xhc3NfbmFtZU47
In0sCisJCV8oInJlbW92ZSBhIHRhYmxlIiksCisJXygiXAorXHREUk9QIFRBQkxFIGNsYXNzX25h
bWUxLCAuLi5jbGFzc19uYW1lTjsiKX0sCiAJeyJkcm9wIHRyaWdnZXIiLAotCQkicmVtb3ZlIGEg
dHJpZ2dlciIsCi0JIlwKLVx0RFJPUCBUUklHR0VSIHRyaWdnZXJfbmFtZSBPTiBjbGFzc19uYW1l
OyJ9LAorCQlfKCJyZW1vdmUgYSB0cmlnZ2VyIiksCisJXygiXAorXHREUk9QIFRSSUdHRVIgdHJp
Z2dlcl9uYW1lIE9OIGNsYXNzX25hbWU7Iil9LAogCXsiZHJvcCB0eXBlIiwKLQkJInJlbW92ZSBh
IHVzZXItZGVmaW5lZCBiYXNlIHR5cGUiLAotCSJcCi1cdERST1AgVFlQRSB0eXBlbmFtZTsifSwK
KwkJXygicmVtb3ZlIGEgdXNlci1kZWZpbmVkIGJhc2UgdHlwZSIpLAorCV8oIlwKK1x0RFJPUCBU
WVBFIHR5cGVuYW1lOyIpfSwKIAl7ImRyb3AgdXNlciIsCi0JCSJyZW1vdmUgYSB1c2VyIGZyb20g
dGhlIHN5c3RlbSIsCi0JIlwKLVx0RFJPUCBVU0VSIHVzZXJfbmFtZTsifSwKKwkJXygicmVtb3Zl
IGEgdXNlciBmcm9tIHRoZSBzeXN0ZW0iKSwKKwlfKCJcCitcdERST1AgVVNFUiB1c2VyX25hbWU7
Iil9LAogCXsiZHJvcCB2aWV3IiwKLQkJInJlbW92ZSBhIHZpZXciLAotCSJcCi1cdERST1AgVklF
VyB2aWV3X25hbWUifSwKKwkJXygicmVtb3ZlIGEgdmlldyIpLAorCV8oIlwKK1x0RFJPUCBWSUVX
IHZpZXdfbmFtZSIpfSwKIAl7ImVuZCB3b3JrIiwKLQkJImVuZCB0aGUgY3VycmVudCB0cmFuc2Fj
dGlvbiIsCi0JIlwKLVx0RU5EIFtXT1JLfFRSQU5TQUNUSU9OXTsifSwKKwkJXygiZW5kIHRoZSBj
dXJyZW50IHRyYW5zYWN0aW9uIiksCisJXygiXAorXHRFTkQgW1dPUkt8VFJBTlNBQ1RJT05dOyIp
fSwKIAl7ImV4cGxhaW4iLAotCQkiZXhwbGFpbiB0aGUgcXVlcnkgZXhlY3V0aW9uIHBsYW4iLAot
CSJcCi1cdEVYUExBSU4gW1ZFUkJPU0VdIHF1ZXJ5In0sCisJCV8oImV4cGxhaW4gdGhlIHF1ZXJ5
IGV4ZWN1dGlvbiBwbGFuIiksCisJXygiXAorXHRFWFBMQUlOIFtWRVJCT1NFXSBxdWVyeSIpfSwK
IAl7ImZldGNoIiwKLQkJInJldHJpZXZlIHR1cGxlcyBmcm9tIGEgY3Vyc29yIiwKLQkiXAotXHRG
RVRDSCBbRk9SV0FSRHxCQUNLV0FSRF0gW251bWJlcnxBTExdIFtJTiBjdXJzb3JuYW1lXTsifSwK
KwkJXygicmV0cmlldmUgdHVwbGVzIGZyb20gYSBjdXJzb3IiKSwKKwlfKCJcCitcdEZFVENIIFtG
T1JXQVJEfEJBQ0tXQVJEXSBbbnVtYmVyfEFMTF0gW0lOIGN1cnNvcm5hbWVdOyIpfSwKIAl7Imdy
YW50IiwKLQkJImdyYW50IGFjY2VzcyBjb250cm9sIHRvIGEgdXNlciBvciBncm91cCIsCi0JIlwK
KwkJXygiZ3JhbnQgYWNjZXNzIGNvbnRyb2wgdG8gYSB1c2VyIG9yIGdyb3VwIiksCisJXygiXAog
XHRHUkFOVCBwcml2aWxlZ2UxLCAuLi5wcml2aWxlZ2VOIE9OIHJlbDEsIC4uLnJlbE4gVE8gXG5c
CiB7IFBVQkxJQyB8IEdST1VQIGdyb3VwIHwgdXNlcm5hbWUgfVxuXAotXHQgcHJpdmlsZWdlIGlz
IHsgQUxMIHwgU0VMRUNUIHwgSU5TRVJUIHwgVVBEQVRFIHwgREVMRVRFIHwgUlVMRSB9In0sCitc
dCBwcml2aWxlZ2UgaXMgeyBBTEwgfCBTRUxFQ1QgfCBJTlNFUlQgfCBVUERBVEUgfCBERUxFVEUg
fCBSVUxFIH0iKX0sCiAJeyJpbnNlcnQiLAotCQkiaW5zZXJ0IHR1cGxlcyIsCi0JIlwKKwkJXygi
aW5zZXJ0IHR1cGxlcyIpLAorCV8oIlwKIFx0SU5TRVJUIElOVE8gY2xhc3NfbmFtZSBbKGF0dHIx
LCAuLi5hdHRyTildXG5cCiBcdFZBTFVFUyAoZXhwcjEsLi5leHByTikgfFxuXAogXHRTRUxFQ1Qg
W0RJU1RJTkNUIFtPTiBhdHRyTl1dXG5cCkBAIC0yNzEsNDYgKzI3MSw0NiBAQAogXHRbV0hFUkUg
cXVhbF1cblwKIFx0W0dST1VQIEJZIGdyb3VwX2xpc3RdXG5cCiBcdFtIQVZJTkcgaGF2aW5nX2Ns
YXVzZV1cblwKLVx0WyB7IFVOSU9OIFtBTExdIHwgSU5URVJTRUNUIHwgRVhDRVBUIH0gU0VMRUNU
IC4uLl07In0sCitcdFsgeyBVTklPTiBbQUxMXSB8IElOVEVSU0VDVCB8IEVYQ0VQVCB9IFNFTEVD
VCAuLi5dOyIpfSwKIAl7Imxpc3RlbiIsCi0JCSJsaXN0ZW4gZm9yIG5vdGlmaWNhdGlvbiBvbiBh
IGNvbmRpdGlvbiBuYW1lIiwKLQkiXAotXHRMSVNURU4gbmFtZXxcIm5vbi1uYW1lIHN0cmluZ1wi
In0sCisJCV8oImxpc3RlbiBmb3Igbm90aWZpY2F0aW9uIG9uIGEgY29uZGl0aW9uIG5hbWUiKSwK
KwlfKCJcCitcdExJU1RFTiBuYW1lfFwibm9uLW5hbWUgc3RyaW5nXCIiKX0sCiAJeyJsb2FkIiwK
LQkJImR5bmFtaWNhbGx5IGxvYWQgYSBtb2R1bGUiLAotCSJcCi1cdExPQUQgJ2ZpbGVuYW1lJzsi
fSwKKwkJXygiZHluYW1pY2FsbHkgbG9hZCBhIG1vZHVsZSIpLAorCV8oIlwKK1x0TE9BRCAnZmls
ZW5hbWUnOyIpfSwKIAl7ImxvY2siLAotCQkiZXhjbHVzaXZlIGxvY2sgYSB0YWJsZSBpbnNpZGUg
YSB0cmFuc2FjdGlvbiIsCi0JIlwKKwkJXygiZXhjbHVzaXZlIGxvY2sgYSB0YWJsZSBpbnNpZGUg
YSB0cmFuc2FjdGlvbiIpLAorCV8oIlwKIFx0TE9DSyBbVEFCTEVdIGNsYXNzX25hbWUgXG5cCi1c
dFtJTiBbUk9XfEFDQ0VTU10gW1NIQVJFfEVYQ0xVU0lWRV0gfCBbU0hBUkUgUk9XIEVYQ0xVU0lW
RV0gTU9ERV07In0sCitcdFtJTiBbUk9XfEFDQ0VTU10gW1NIQVJFfEVYQ0xVU0lWRV0gfCBbU0hB
UkUgUk9XIEVYQ0xVU0lWRV0gTU9ERV07Iil9LAogCXsibW92ZSIsCi0JCSJtb3ZlIGFuIGN1cnNv
ciBwb3NpdGlvbiIsCi0JIlwKLVx0TU9WRSBbRk9SV0FSRHxCQUNLV0FSRF0gW251bWJlcnxBTExd
IFtJTiBjdXJzb3JuYW1lXTsifSwKKwkJXygibW92ZSBhbiBjdXJzb3IgcG9zaXRpb24iKSwKKwlf
KCJcCitcdE1PVkUgW0ZPUldBUkR8QkFDS1dBUkRdIFtudW1iZXJ8QUxMXSBbSU4gY3Vyc29ybmFt
ZV07Iil9LAogCXsibm90aWZ5IiwKLQkJInNpZ25hbCBhbGwgZnJvbnRlbmRzIGxpc3RlbmluZyBv
biBhIGNvbmRpdGlvbiBuYW1lIiwKLQkiXAotXHROT1RJRlkgbmFtZXxcIm5vbi1uYW1lIHN0cmlu
Z1wiIn0sCisJCV8oInNpZ25hbCBhbGwgZnJvbnRlbmRzIGxpc3RlbmluZyBvbiBhIGNvbmRpdGlv
biBuYW1lIiksCisJXygiXAorXHROT1RJRlkgbmFtZXxcIm5vbi1uYW1lIHN0cmluZ1wiIil9LAog
CXsicmVzZXQiLAotCQkic2V0IHJ1bi10aW1lIGVudmlyb25tZW50IGJhY2sgdG8gZGVmYXVsdCIs
Ci0JIlwKKwkJXygic2V0IHJ1bi10aW1lIGVudmlyb25tZW50IGJhY2sgdG8gZGVmYXVsdCIpLAor
CV8oIlwKIFx0UkVTRVQgREFURVNUWUxFfENPU1RfSEVBUHxDT1NUX0lOREVYfEdFUU98S1NRT3xc
blwKLVRJTUVaT05FfFhBQ1RJU09MRVZFTHxDTElFTlRfRU5DT0RJTkd8U0VSVkVSX0VOQ09ESU5H
In0sCitUSU1FWk9ORXxYQUNUSVNPTEVWRUx8Q0xJRU5UX0VOQ09ESU5HfFNFUlZFUl9FTkNPRElO
RyIpfSwKIAl7InJldm9rZSIsCi0JCSJyZXZva2UgYWNjZXNzIGNvbnRyb2wgZnJvbSBhIHVzZXIg
b3IgZ3JvdXAiLAotCSJcCisJCV8oInJldm9rZSBhY2Nlc3MgY29udHJvbCBmcm9tIGEgdXNlciBv
ciBncm91cCIpLAorCV8oIlwKIFx0UkVWT0tFIHByaXZpbGVnZTEsIC4uLnByaXZpbGVnZU4gT04g
cmVsMSwgLi4ucmVsTiBGUk9NIFxuXAogeyBQVUJMSUMgfCBHUk9VUCBncm91cCB8IHVzZXJuYW1l
IH1cblwKLVx0IHByaXZpbGVnZSBpcyB7IEFMTCB8IFNFTEVDVCB8IElOU0VSVCB8IFVQREFURSB8
IERFTEVURSB8IFJVTEUgfSJ9LAorXHQgcHJpdmlsZWdlIGlzIHsgQUxMIHwgU0VMRUNUIHwgSU5T
RVJUIHwgVVBEQVRFIHwgREVMRVRFIHwgUlVMRSB9Iil9LAogCXsicm9sbGJhY2sgd29yayIsCi0J
CSJhYm9ydCBhIHRyYW5zYWN0aW9uIiwKLQkiXAotXHRST0xMQkFDSyBbV09SS3xUUkFOU0FDVElP
Tl0ifSwKKwkJXygiYWJvcnQgYSB0cmFuc2FjdGlvbiIpLAorCV8oIlwKK1x0Uk9MTEJBQ0sgW1dP
Ukt8VFJBTlNBQ1RJT05dIil9LAogCXsic2VsZWN0IiwKLQkJInJldHJpZXZlIHR1cGxlcyIsCi0J
IlwKKwkJXygicmV0cmlldmUgdHVwbGVzIiksCisJXygiXAogXHRTRUxFQ1QgW0RJU1RJTkNUIFtP
TiBhdHRyTl1dIGV4cHIxIFtBUyBhdHRyMV0sIC4uLmV4cHJOXG5cCiBcdFtJTlRPIFtURU1QXSBb
VEFCTEVdIGNsYXNzX25hbWVdXG5cCiBcdFtGUk9NIGZyb21fbGlzdF1cblwKQEAgLTMyMCwxMCAr
MzIwLDEwIEBACiBcdFsgeyBVTklPTiBbQUxMXSB8IElOVEVSU0VDVCB8IEVYQ0VQVCB9IFNFTEVD
VCAuLi5dXG5cCiBcdFtPUkRFUiBCWSBhdHRyMSBbQVNDfERFU0NdIFtVU0lORyBvcDFdLCAuLi5h
dHRyTiBdXG5cCiBcdFtGT1IgVVBEQVRFIFtPRiBjbGFzc19uYW1lLi4uXV1cblwKLVx0W0xJTUlU
IGNvdW50IFtPRkZTRVR8LCBjb3VudF1dOyJ9LAorXHRbTElNSVQgY291bnQgW09GRlNFVHwsIGNv
dW50XV07Iil9LAogCXsic2V0IiwKLQkJInNldCBydW4tdGltZSBlbnZpcm9ubWVudCIsCi0JIlwK
KwkJXygic2V0IHJ1bi10aW1lIGVudmlyb25tZW50IiksCisJXygiXAogXHRTRVQgREFURVNUWUxF
IFRPICdJU08nfCdTUUwnfCdQb3N0Z3Jlcyd8J0V1cm9wZWFuJ3wnVVMnfCdOb25FdXJvcGVhbidc
blwKIFx0U0VUIENPU1RfSEVBUCBUTyAjXG5cCiBcdFNFVCBDT1NUX0lOREVYIFRPICNcblwKQEAg
LTMzNiwyOCArMzM2LDI4IEBACiBcdCAgJ0tPSTh8J1dJTid8J0FMVCd8J1dJTjEyNTAnXG5cCiBc
dFNFVCBTRVJWRVJfRU5DT0RJTkcgVE8gJ0VVQ19KUCd8J1NKSVMnfCdFVUNfQ04nfCdFVUNfS1In
fCdFVUNfVFcnfFxuXAogXHQgICdCSUc1J3wnTVVMRV9JTlRFUk5BTCd8J0xBVElOMSd8J0xBVElO
Mid8J0xBVElOMyd8J0xBVElONCd8J0xBVElONSd8XG5cCi1cdCAgJ0tPSTh8J1dJTid8J0FMVCci
fSwKK1x0ICAnS09JOHwnV0lOJ3wnQUxUJyIpfSwKIAl7InNob3ciLAotCQkic2hvdyBjdXJyZW50
IHJ1bi10aW1lIGVudmlyb25tZW50IiwKLQkiXAorCQlfKCJzaG93IGN1cnJlbnQgcnVuLXRpbWUg
ZW52aXJvbm1lbnQiKSwKKwlfKCJcCiBcdFNIT1cgREFURVNUWUxFfENPU1RfSEVBUHxDT1NUX0lO
REVYfEdFUU98S1NRT3xcblwKLVRJTUVaT05FfFhBQ1RJU09MRVZFTHxDTElFTlRfRU5DT0RJTkd8
U0VSVkVSX0VOQ09ESU5HIn0sCitUSU1FWk9ORXxYQUNUSVNPTEVWRUx8Q0xJRU5UX0VOQ09ESU5H
fFNFUlZFUl9FTkNPRElORyIpfSwKIAl7InVubGlzdGVuIiwKLQkJInN0b3AgbGlzdGVuaW5nIGZv
ciBub3RpZmljYXRpb24gb24gYSBjb25kaXRpb24gbmFtZSIsCi0JIlwKLVx0VU5MSVNURU4gbmFt
ZXxcIm5vbi1uYW1lIHN0cmluZ1wifFwiKlwiIn0sCisJCV8oInN0b3AgbGlzdGVuaW5nIGZvciBu
b3RpZmljYXRpb24gb24gYSBjb25kaXRpb24gbmFtZSIpLAorCV8oIlwKK1x0VU5MSVNURU4gbmFt
ZXxcIm5vbi1uYW1lIHN0cmluZ1wifFwiKlwiIil9LAogCXsidXBkYXRlIiwKLQkJInVwZGF0ZSB0
dXBsZXMiLAotCSJcCisJCV8oInVwZGF0ZSB0dXBsZXMiKSwKKwlfKCJcCiBcdFVQREFURSBjbGFz
c19uYW1lIFNFVCBhdHRyMSA9IGV4cHIxLCAuLi5hdHRyTiA9IGV4cHJOXG5cCiBcdFtGUk9NIGZy
b21fY2xhdXNlXVxuXAotXHRbV0hFUkUgcXVhbF07In0sCitcdFtXSEVSRSBxdWFsXTsiKX0sCiAJ
eyJ2YWN1dW0iLAotCQkidmFjdXVtIHRoZSBkYXRhYmFzZSwgaS5lLiBjbGVhbnMgb3V0IGRlbGV0
ZWQgcmVjb3JkcywgdXBkYXRlcyBzdGF0aXN0aWNzIiwKLQkiXAorCQlfKCJ2YWN1dW0gdGhlIGRh
dGFiYXNlLCBpLmUuIGNsZWFucyBvdXQgZGVsZXRlZCByZWNvcmRzLCB1cGRhdGVzIHN0YXRpc3Rp
Y3MiKSwKKwlfKCJcCiBcdFZBQ1VVTSBbVkVSQk9TRV0gW0FOQUxZWkVdIFt0YWJsZV1cblwKIFx0
b3JcblwKLVx0VkFDVVVNIFtWRVJCT1NFXSAgQU5BTFlaRSAgW3RhYmxlIFsoYXR0cjEsIC4uLmF0
dHJOKV1dOyJ9LAorXHRWQUNVVU0gW1ZFUkJPU0VdICBBTkFMWVpFICBbdGFibGUgWyhhdHRyMSwg
Li4uYXR0ck4pXV07Iil9LAogCXtOVUxMLCBOVUxMLCBOVUxMfQkJCS8qIGltcG9ydGFudCB0byBr
ZWVwIGEgTlVMTCB0ZXJtaW5hdG9yCiAJCQkJCQkJCSAqIGhlcmUhICovCiB9OwpkaWZmIC11TnIg
cG9zdGdyZXNxbC02LjUuMS1vcmlnL3NyYy9iaW4vcHNxbC9zdHJpbmd1dGlscy5jIHBvc3RncmVz
cWwtNi41LjEvc3JjL2Jpbi9wc3FsL3N0cmluZ3V0aWxzLmMKLS0tIHBvc3RncmVzcWwtNi41LjEt
b3JpZy9zcmMvYmluL3BzcWwvc3RyaW5ndXRpbHMuYwlTdW4gRmViIDE0IDA3OjIwOjQxIDE5OTkK
KysrIHBvc3RncmVzcWwtNi41LjEvc3JjL2Jpbi9wc3FsL3N0cmluZ3V0aWxzLmMJU3VuIEp1bCAy
NSAyMzowMDowMCAxOTk5CkBAIC0xMDYsMTQgKzEwNiwxNCBAQAogCQljaGFyCSAgICp0OwogCiAJ
CXQgPSBzdHJkdXAodGVzdHNbaV0pOwotCQlwcmludGYoImxlZnRUcmltKCVzKSA9ICIsIHQpOwot
CQlwcmludGYoIiVzRU5EXG4iLCBsZWZ0VHJpbSh0KSk7CisJCXByaW50ZihfKCJsZWZ0VHJpbSgl
cykgPSAiKSwgdCk7CisJCXByaW50ZihfKCIlc0VORFxuIiksIGxlZnRUcmltKHQpKTsKIAkJdCA9
IHN0cmR1cCh0ZXN0c1tpXSk7Ci0JCXByaW50ZigicmlnaHRUcmltKCVzKSA9ICIsIHQpOwotCQlw
cmludGYoIiVzRU5EXG4iLCByaWdodFRyaW0odCkpOworCQlwcmludGYoXygicmlnaHRUcmltKCVz
KSA9ICIpLCB0KTsKKwkJcHJpbnRmKF8oIiVzRU5EXG4iKSwgcmlnaHRUcmltKHQpKTsKIAkJdCA9
IHN0cmR1cCh0ZXN0c1tpXSk7Ci0JCXByaW50ZigiZG91YmxlVHJpbSglcykgPSAiLCB0KTsKLQkJ
cHJpbnRmKCIlc0VORFxuIiwgZG91YmxlVHJpbSh0KSk7CisJCXByaW50ZihfKCJkb3VibGVUcmlt
KCVzKSA9ICIpLCB0KTsKKwkJcHJpbnRmKF8oIiVzRU5EXG4iKSwgZG91YmxlVHJpbSh0KSk7CiAJ
CWkrKzsKIAl9CiAKZGlmZiAtdU5yIHBvc3RncmVzcWwtNi41LjEtb3JpZy9zcmMvYmluL3BzcWwv
c3RyaW5ndXRpbHMuaCBwb3N0Z3Jlc3FsLTYuNS4xL3NyYy9iaW4vcHNxbC9zdHJpbmd1dGlscy5o
Ci0tLSBwb3N0Z3Jlc3FsLTYuNS4xLW9yaWcvc3JjL2Jpbi9wc3FsL3N0cmluZ3V0aWxzLmgJU3Vu
IEZlYiAxNCAwNzoyMDo0MiAxOTk5CisrKyBwb3N0Z3Jlc3FsLTYuNS4xL3NyYy9iaW4vcHNxbC9z
dHJpbmd1dGlscy5oCVN1biBKdWwgMjUgMjM6MDA6MzAgMTk5OQpAQCAtMjEsNiArMjEsOCBAQAog
I2RlZmluZSByZWFsbG9jKHgseSkgY2tyZWFsbG9jKHgseSkKICNlbmRpZgogCisjaW5jbHVkZSAi
bXVsdGlsYW5nLmgiCisKIC8qIHN0cmluZyBmaWRkbGluZyB1dGlsdGllcyAqLwogCiAvKiBhbGwg
cm91dGluZXMgYXNzdW1lIG51bGwtdGVybWluYXRlZCBzdHJpbmdzISBhcyBhcmd1bWVudHMgKi8K
ZGlmZiAtdU5yIHBvc3RncmVzcWwtNi41LjEtb3JpZy9zcmMvaW5jbHVkZS9tdWx0aWxhbmcuaCBw
b3N0Z3Jlc3FsLTYuNS4xL3NyYy9pbmNsdWRlL211bHRpbGFuZy5oCi0tLSBwb3N0Z3Jlc3FsLTYu
NS4xLW9yaWcvc3JjL2luY2x1ZGUvbXVsdGlsYW5nLmgJVGh1IEphbiAgMSAwODowMDowMCAxOTcw
CisrKyBwb3N0Z3Jlc3FsLTYuNS4xL3NyYy9pbmNsdWRlL211bHRpbGFuZy5oCU1vbiBKdWwgMjYg
MDA6NTg6MzEgMTk5OQpAQCAtMCwwICsxLDQwIEBACisvKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyAq
IG11bHRpbGFuZy5oCisgKgorICogVGhpcyBpcyBhIGhlYWRlciBmaWxlIG9mIFBvc3RncmVTUUwg
Zm9yIHN1cHBvcnQgTXVsdGlMYW5nIHZpYSBHTlUgTGlicmFyeQorICogQyBnZXR0ZXh0KCkgZnVu
Y3Rpb24uIFRoaXMgZmlsZSBpcyB3cml0dGVuIGJ5IAorICogQ2QgQ2hlbiA8Y2RjaGVuQG1haWwu
Y3luaXguY29tLnR3PiwgMTk5OS0wNy0zMC4KKyAqCisgKiAkQXV0aG9yJAorICoKKyAqICREYXRl
JAorICoKKyAqICRJZCQKKyAqCisgKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8KKworI2lmbmRlZiBf
SF9NVUxUSUxBTkdfSF8KKyNkZWZpbmUgX0hfTVVMVElMQU5HX0hfCisKKyNpbmNsdWRlIDxsaWJp
bnRsLmg+CisKKyNpZmRlZiBVU0VfTVVMVElMQU5HCisjZGVmaW5lIExPQ0FMRURJUgkiL3Vzci9z
aGFyZS9sb2NhbGUiCisjZGVmaW5lIF8oU3RyaW5nKQlnZXR0ZXh0IChTdHJpbmcpCisKK3ZvaWQK
K0luaXRNdWx0aUxhbmcoY2hhciAqUGFja2FnZSwgY2hhciAqTG9jYWxlRGlyKQoreworICBzZXRs
b2NhbGUgKExDX0FMTCwgIiIpOworICBiaW5kdGV4dGRvbWFpbihQYWNrYWdlLCBMb2NhbGVEaXIp
OworICB0ZXh0ZG9tYWluIChQYWNrYWdlKTsKK30KKworCisjZWxzZQorI2RlZmluZSBfKFN0cmlu
ZykJU3RyaW5nCisjZW5kaWYKKworCisKKyNlbmRpZiBfSF9NVUxUSUxBTkdfSF8KZGlmZiAtdU5y
IHBvc3RncmVzcWwtNi41LjEtb3JpZy9zcmMvaW5jbHVkZS9tdWx0aWxhbmcuaH4gcG9zdGdyZXNx
bC02LjUuMS9zcmMvaW5jbHVkZS9tdWx0aWxhbmcuaH4KLS0tIHBvc3RncmVzcWwtNi41LjEtb3Jp
Zy9zcmMvaW5jbHVkZS9tdWx0aWxhbmcuaH4JVGh1IEphbiAgMSAwODowMDowMCAxOTcwCisrKyBw
b3N0Z3Jlc3FsLTYuNS4xL3NyYy9pbmNsdWRlL211bHRpbGFuZy5ofglNb24gSnVsIDI2IDAwOjQ1
OjEwIDE5OTkKQEAgLTAsMCArMSwzOSBAQAorLyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisgKiBtdWx0
aWxhbmcuaAorICoKKyAqIFRoaXMgaXMgYSBoZWFkZXIgZmlsZSBvZiBQb3N0Z3JlU1FMIGZvciBz
dXBwb3J0IE11bHRpTGFuZyB2aWEgR05VIExpYnJhcnkKKyAqIEMgZ2V0dGV4dCgpIGZ1bmN0aW9u
LiBUaGlzIGZpbGUgaXMgd3JpdHRlbiBieSAKKyAqIENkIENoZW4gPGNkY2hlbkBtYWlsLmN5bml4
LmNvbS50dz4sIDE5OTktMDctMzAuCisgKgorICogJEF1dGhvciQKKyAqCisgKiAkRGF0ZSQKKyAq
CisgKiAkSWQkCisgKgorICogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICovCisKKyNpZm5kZWYgX0hfTVVM
VElMQU5HX0hfCisjZGVmaW5lIF9IX01VTFRJTEFOR19IXworCisjaWZkZWYgVVNFX01VTFRJTEFO
RworI2luY2x1ZGUgPGxpYmludGwuaD4KKyNkZWZpbmUgTE9DQUxFRElSCSIvdXNyL3NoYXJlL2xv
Y2FsZSIKKyNkZWZpbmUgXyhTdHJpbmcpCWdldHRleHQgKFN0cmluZykKKwordm9pZAorSW5pdE1h
bHRpTGFuZyh2b2lkKQoreworICBzZXRsb2NhbGUgKExDX0FMTCwgIiIpOworICBiaW5kdGV4dGRv
bWFpbihQQUNLQUdFLCBMT0NBTEVESVIpOworICB0ZXh0ZG9tYWluIChQQUNLQUdFKTsKK30KKwor
CisjZWxzZQorI2RlZmluZSBfKFN0cmluZykJKFN0cmluZykKKyNlbmRpZgorCisKKworI2VuZGlm
IF9IX01VTFRJTEFOR19IXwo=

--V2VkLCAyOCBKdWwgMTk5OSAwMToxNjo1MyArMDgwMA==--

--ELM938402765-28528-0_--

From bouncefilter Sun Sep 26 23:30:55 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA09211
for <pgsql-hackers@postgreSQL.org>;
Sun, 26 Sep 1999 23:30:46 -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 XAA01510;
Sun, 26 Sep 1999 23:30:02 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909270330.XAA01510@candle.pha.pa.us>
Subject: Re: [HACKERS] double opens
In-Reply-To: <000401bed8ba$e23fc7e0$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Jul 28, 1999 02:34:38 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Sun, 26 Sep 1999 23:30:02 -0400 (EDT)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tom, can you comment on this patch. Seems you have made changes in this
area. Thanks.

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Hi all,

There is a TODO item
* Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup

In Windows-NT,we could see the following error reported by
yutaka tanida [yutaka@marin.or.jp].

version
------------------------------------------------------------
PostgreSQL 6.5.1 on i686-pc-cygwin, compiled by gcc gcc-2.95
(1 row)

template1=> create table table1 ( i int,j int);
CREATE
template1=> create view view1 as select * from table1;
CREATE
template1=> drop view view1;
DROP
template1=> create view view1 as select * from table1;
ERROR: cannot create view1

"drop view" couldn't unlink the base file of target view because
it is doubly opened and so "create view" coundn't create the view.

After applying the following patch on trial,"drop view" was able to
unlink the base file and "create view" was able to create the view
again.

I think base files should be closed at the time of cache invalidation.
RelationFlushRelation() invalidates the entry of relation cache but
doesn't close the base file of target relation.
Is there any reason ?

Or why doesn't RelationCacheDelete() close the base file of
target relation ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp
*** utils/cache/relcache.c.orig	Wed May 26 16:05:38 1999
--- utils/cache/relcache.c	Wed Jul 28 13:23:49 1999
***************
*** 1282,1287 ****
--- 1282,1288 ----
oldcxt = MemoryContextSwitchTo((MemoryContext) CacheCxt);
RelationCacheDelete(relation);
+ smgrclose(DEFAULT_SMGR, relation);

FreeTupleDesc(relation->rd_att);
SystemCacheRelationFlushed(RelationGetRelid(relation));

-- 
  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 Mon Sep 27 02:25:57 1999
Received: from leeloo.zip.com.au (IDENT:mail@leeloo.zip.com.au [203.12.97.48])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA17214
for <pgsql-hackers@postgresql.org>;
Mon, 27 Sep 1999 02:25:42 -0400 (EDT)
(envelope-from rmills@netport.com.au)
Received: from rm (rm.netport.com.au [61.8.13.141])
by leeloo.zip.com.au (8.9.1/8.9.1) with SMTP id QAA00344
for <pgsql-hackers@postgresql.org>; Mon, 27 Sep 1999 16:25:27 +1000
From: Ryan Mills <rmills@netport.com.au>
To: pgsql-hackers@postgresql.org
Subject: question.
Date: Mon, 27 Sep 1999 15:03:19 +1000
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99092715062000.01028@rm>
Content-Transfer-Encoding: 8bit

hi there,

i'm wondering if postgres has, or is currently developing, the ability to
create in memory tables similar to hash tables but sql'ised. the reason i ask
is i am looking to write a library to link my c/c++ against that allows me to
use sql statements to manage internal hash tables by requesting the statement
to be parsed by a local function as opposed to a sql server.

im not on the pgsql-hackers list, so please reply cc'd to me directly.

From bouncefilter Mon Sep 27 01:32:56 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 BAA15033
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 01:32:20 -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 BAA23381;
Mon, 27 Sep 1999 01:31:13 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: TODO items (was Re: [COMMITTERS] pgsql/src/include/nodes
(execnodes.h))
In-reply-to: Your message of Sun, 26 Sep 1999 20:36:39 -0400 (EDT)
<199909270036.UAA26981@candle.pha.pa.us>
Date: Mon, 27 Sep 1999 01:31:13 -0400
Message-ID: <23379.938410273@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Tom, I only see one entry in TODO for this:
* -Fix memory leak for aggregates?

----------------------------- Log Message -----------------------------
Modify nodeAgg.c so that no rows are returned for a GROUP BY
with no input rows, per pghackers discussions around 7/22/99. Clean up
a bunch of ugly coding while at it; remove redundant re-lookup of
aggregate info at start of each new GROUP. Arrange to pfree intermediate
values when they are pass-by-ref types, so that aggregates on pass-by-ref
types no longer eat memory. This takes care of a couple of TODO items...

Hmm, you are right --- I thought that discussion about changing the
semantics of aggregates with GROUP BY had made it to the TODO list,
but apparently it never did. It should have, however:
* When using aggregates + GROUP BY, no rows in should yield no rows out

This motivated me to grovel through the TODO list, which I hadn't done
for a while, and I have some updates/comments.

PARSER
------

* Select a[1] FROM test fails, it needs test.a[1]

Fixed for 6.6 --- actually same thing as next item,
* -Array index references without table name cause problems [array]

* Update table SET table.value = 3 fails

AFAICS, the SQL92 syntax allows only a bare <column name> as the
target of a SET clause. Not sure it's worth expending any effort
on this one...

ENHANCEMENTS
------------

COMMANDS

* Generate error on CREATE OPERATOR of ~~, ~ and and ~*

"Error" seems a little strong, maybe a "NOTICE" along the lines of
"We trust you know that ~~ defines the behavior of the LIKE keyword".

I believe the original motivation for this entry was that the parser
would do the wrong thing for arbitrary operators named ~~ etc, because
it would try to apply optimizations that were only suitable for the
standard ops of those names (textlike etc). That's no longer a problem,
because those optimizations are now triggered off matching of the
operator OID; they will not cause a problem if Joe User invents an
operator named ~~ for his spiffy new datatype. But perhaps Joe should
be reminded that he just made LIKE applicable to his datatype. Or maybe
that's not worth worrying about...

* Move LIKE index optimization handling to the optimizer

This is basically done, although I have a couple of cleanup issues
to take care of.

CLIENTS

* PQrequestCancel() be able to terminate backend waiting for lock

There is an equivalent item under MISC, and it doesn't seem like it
belongs under CLIENTS --- the necessary code change is in the backend.

MISC

* Do autocommit so always in a transaction block(?)

Huh? What is this supposed to mean?

PERFORMANCE
-----------

INDEXES

* Convert function(constant) into a constant for index use

Done as of now; see Frankpitt's constant-expression simplifier.
We might have some lingering bugs with simplifying things that
ought not be simplified, however...

* Allow SELECT * FROM tab WHERE int2col = 4 use int2col index, int8 too
[optimizer]

I believe float4 columns have the same sort of problem, since a numeric
constant will be taken as float8 not float4 if not explicitly casted.
For that matter, numeric/decimal columns do too, or would if we had
indexing support for them...

* Allow optimizer to prefer plans that match ORDER BY

This is done, although we now have the opposite problem: the darn thing
is too eager to pick an indexscan plan :-(. Need to make the cost
estimates for indexscan vs explicit sort more accurate.

MISC

* Update pg_statistic table to remove operator column

I do not believe we should do this. It's true that right now we have
no use for the operator column, because only the default '<' ordering
will ever be used by VACUUM, but we should keep the column in the name
of datatype extensibility. Someday VACUUM might compute stats with
respect to more than one ordering, for datatypes that have more than one.

* -Fix memory exhaustion when using many OR's [cnfify]

cnfify is still pretty slow with many subclauses --- the behavior
is now O(N^2) rather than O(2^N), but that just means it's
slow rather than intolerable. I'm not sure what to do about it.
We probably need to be using heuristics instead of an unconditional
convert-to-normal-form-or-bust algorithm, but what should the
heuristic conditions be? Am thinking about it, could use suggestions.

* Process const = const parts of OR clause in separate pass

Done --- Frankpitt's const simplifier handles this.

* change VACUUM ANALYZE to use btree comparison functions, not <,=,> calls

Didn't we decide this probably wasn't worth doing?

SOURCE CODE
-----------

* Remove SET KSQO option if OR processing is improved

You can put my name on this one --- I'm not quite ready to pull KSQO
but I think we are close.

regards, tom lane

From bouncefilter Mon Sep 27 04:08:58 1999
Received: from lota.izhcom.ru (lota.izhcom.ru [213.24.0.2])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA26623
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 04:07:59 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (U112.dialup.udm.net [192.168.53.112])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id NAA45053;
Mon, 27 Sep 1999 13:07:04 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37EF229A.8D81E3D9@udmnet.ru>
Date: Mon, 27 Sep 1999 12:54:02 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Profiling?
References: <199909270025.UAA26569@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Yes, I have done it many times. I profile that postgres process, not
the backend.

Hmm, isn't Postgres process called backend process? AFAIK postmaster
(it's simply a nickname to Postgres) forks itself on receiveing new
connection request. Isn't it true? I mean that Postmaster is the same
binary as Postgres itself.

Look for this in Makefile.global:

# Comment out PROFILE to generate a profile version of the binaries
#PROFILE= -p -non_shared

Of course I used -p option. The problem is, when I start Postmaster,
it complains about 'profile timer expired'. What do I do wrong?

--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.

From bouncefilter Mon Sep 27 04:09:58 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA26656
for <pgsql-hackers@postgresql.org>;
Mon, 27 Sep 1999 04:09:02 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11VVqG-0000uT-0K; Mon, 27 Sep 1999 08:09:00 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id KAA01229;
Mon, 27 Sep 1999 10:05:56 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <TN2ZHB9W>; Mon, 27 Sep 1999 09:07:22 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E647@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] psql code to be obducted by alien (me)
Date: Mon, 27 Sep 1999 09:07:18 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 25 September 1999 23:58
To: Peter Eisentraut
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql code to be obducted by alien (me)

Another part of psql that should be made as independent as possible
is the support for \copy. I recall a number of people asking in the
past how they can read and write tables to files in their own apps.
There's not that much code involved, but psql is such a mess that it's
hard to point to a chunk of code they can borrow.

This is a common request for JDBC (which I'm targetting for 6.6)

BTW, something closely related to \copy that's languishing on the TODO
list is the ability to load the contents of a local file into a Large
Object or write the data out again. This would be the
equivalent of the
server-side operations lo_import and lo_export, but reading
or writing a
file in psql's environment instead of the backend's.
Basically a wrapper
around lo_read/lo_write, not much to it but it needs done...

If I remember, one of the tests/examples for libpq does this (although
that code is commented out) - testlo & testlo2 ?

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

From bouncefilter Mon Sep 27 04:47:58 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 EAA29026;
Mon, 27 Sep 1999 04:47:53 -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 RAA14454; Mon, 27 Sep 1999 17:47:52 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-patches" <pgsql-patches@postgreSQL.org>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Index access using multi-column indices
Date: Mon, 27 Sep 1999 17:51:28 +0900
Message-ID: <001f01bf08c5$7d13eaa0$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
In-Reply-To: <000001bee49f$defce040$2801007e@cadzone.tpf.co.jp>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Hiroshi Inoue
Sent: Thursday, August 12, 1999 5:52 PM
To: pgsql-patches
Cc: pgsql-hackers
Subject: [HACKERS] Index access using multi-column indices

Hello all,

Currently,only the first column of multi-column indices
is used to find start scan position of Indexscan-s.

To speed up finding scan start position,I have changed
_bt_first() to use as many keys as possible.

I'll attach the patch here.

Seems this isn't committed yet.
If there's no objection,I will commit this patch to current tree.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Sep 27 08:10:00 1999
Received: from server.pyrenet.fr (server.pyrenet.fr [194.250.190.1])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA47661
for <pgsql-hackers@postgresql.org>;
Mon, 27 Sep 1999 08:09:46 -0400 (EDT) (envelope-from ohp@pyrenet.fr)
Received: from localhost (localhost [127.0.0.1])
by server.pyrenet.fr (8.8.7/8.8.8) with SMTP id OAA07305
for <pgsql-hackers@postgresql.org>;
Mon, 27 Sep 1999 14:09:46 +0200 (MET DST)
Date: Mon, 27 Sep 1999 14:09:46 +0200 (MET DST)
From: Olivier PRENANT <ohp@pyrenet.fr>
Reply-To: ohp@pyrenet.fr
To: pgsql-hackers@postgresql.org
Subject: Column crypt
Message-ID: <Pine.SV4.3.96.990927140902.7241G-110000@server.pyrenet.fr>
MIME-Version: 1.0
Content-Type: MULTIPART/REPORT; REPORT-TYPE=delivery-status;
BOUNDARY="OAA07290.938434057/server.pyrenet.fr"
Content-ID: <Pine.SV4.3.96.990927140902.7241H@server.pyrenet.fr>

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

--OAA07290.938434057/server.pyrenet.fr
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.SV4.3.96.990927140902.7241I@server.pyrenet.fr>

Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

---------- Forwarded message ----------
Date: Mon, 27 Sep 1999 14:07:37 +0200 (MET DST)
From: Mail Delivery Subsystem <MAILER-DAEMON@pyrenet.fr>
To: ohp@pyrenet.fr
Subject: Returned mail: Host unknown (Name server: postgreql.org: host not found)

The original message was received at Mon, 27 Sep 1999 14:07:34 +0200 (MET DST)
from localhost [127.0.0.1]

----- The following addresses had permanent fatal errors -----
<pgsql-hackers@postgreql.org>

----- Transcript of session follows -----
550 <pgsql-hackers@postgreql.org>... Host unknown (Name server: postgreql.org: host not found)

--OAA07290.938434057/server.pyrenet.fr
Content-Type: MESSAGE/RFC822
Content-ID: <Pine.SV4.3.96.990927140902.7241K@server.pyrenet.fr>
Content-Description:

Return-Path: <ohp@pyrenet.fr>
Received: from localhost (localhost [127.0.0.1])
by server.pyrenet.fr (8.8.7/8.8.8) with SMTP id OAA07288;
Mon, 27 Sep 1999 14:07:34 +0200 (MET DST)
Date: Mon, 27 Sep 1999 14:07:33 +0200 (MET DST)
From: Olivier PRENANT <ohp@pyrenet.fr>
Reply-To: ohp@pyrenet.fr
To: pgsql-ports@postgresql.org
cc: pgsql-hackers@postgreql.org
Subject: Column crypt
Message-ID: <Pine.SV4.3.96.990927140514.7241A-100000@server.pyrenet.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi all,

Is there any simple way to crypt a text before inserting it in a column.

I could'nt see any crypt function in the docs. So if someone has already
wirttent such function, please share!

Thanks in advance to you all.

Regards,
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

--OAA07290.938434057/server.pyrenet.fr--

From bouncefilter Mon Sep 27 10:21:02 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA63285
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 10:20:17 -0400 (EDT) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA08775
for <pgsql-hackers@postgreSQL.org>; Mon, 27 Sep 1999 15:11:10 +0200
Date: Mon, 27 Sep 1999 15:11:10 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: _text problem in union
Message-ID: <Pine.LNX.3.96.990927150619.8444A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

I have small problem with text array in union query.. see:

abil=> select 5 union select 5;
?column?
--------
5
(1 row)

abil=> select 5 union select 6;
?column?
--------
5
6
(2 rows)

abil=> select '{"aaa"}'::_text union select '{"aaa"}'::_text;
?column?
--------
{"aaa"}
(1 row)

abil=> select '{"aaa"}'::_text union select '{"bbb"}'::_text;
ERROR: Unable to identify an ordering operator '<' for type '_text'
Use an explicit ordering operator or modify the query
abil=>

... hmm, any suggestion?

Zakkr

From bouncefilter Mon Sep 27 09:26:03 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 JAA53295
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 09:25:23 -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 JAA25952;
Mon, 27 Sep 1999 09:20:26 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Michael Simms" <grim@argh.demon.co.uk>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Frustration
In-reply-to: Your message of Mon, 27 Sep 1999 09:13:38 +0900
<001501bf087d$25ea27a0$2801007e@cadzone.tpf.co.jp>
Date: Mon, 27 Sep 1999 09:20:26 -0400
Message-ID: <25950.938438426@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Different from other spinlocks,io_in_progress spinlock is a per bufpage
spinlock and ProcReleaseSpins() doesn't release the spinlock.
If an error(in md.c in most cases) occured while holding the spinlock
,the spinlock would necessarily freeze.

Oooh, good point. Shouldn't this be fixed? If we don't fix it, then
a disk I/O error will translate to an installation-wide shutdown and
restart as soon as some backend tries to touch the locked page (as
indeed was happening to Michael). That seems a tad extreme.

Michael Simms says
ERROR: cannot read block 641 of server
occured before the spinlock stuck abort.
Probably it is an original cause of the spinlock freeze.

I seem to have missed the message containing that bit of info,
but it certainly suggests that your diagnosis is correct.

However I don't understand the following status of his machine.
/dev/sda1 30356106785018642307 43892061535609608 0 100%

Now that we know the root problem was disk driver flakiness, I think
we can write that off as Not Our Fault ;-)

regards, tom lane

From bouncefilter Mon Sep 27 09:32:02 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 JAA54077
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 09:31:42 -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 JAA26002;
Mon, 27 Sep 1999 09:29:32 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Bruce Momjian" <maillist@candle.pha.pa.us>, t-ishii@sra.co.jp,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] int8 and index
In-reply-to: Your message of Mon, 27 Sep 1999 10:08:55 +0900
<001601bf0884$de79e920$2801007e@cadzone.tpf.co.jp>
Date: Mon, 27 Sep 1999 09:29:31 -0400
Message-ID: <26000.938438971@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

int4 -> int8 never fails.
But int4 -> int2 fails if abs(int4) > 32768.

select .. from .. where int2_column = 32769;

should return 0 rows or cause an elog(ERROR) ?

Should return 0 rows, clearly. (That's what happens now, and I can
see no justification for doing otherwise.) When we add code to try to
coerce the constant to match the type of the column, we will have to
watch out for overflow and not do the coercion if so.

What would be really way cool would be if the constant simplifier could
recognize that this condition is a constant FALSE, but that would
probably mean building in more knowledge about the semantics of
specific operators than is justified...

regards, tom lane

From bouncefilter Mon Sep 27 09:36:01 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 JAA54508
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 09:35:19 -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 JAA26036;
Mon, 27 Sep 1999 09:34:13 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] double opens
In-reply-to: Your message of Sun, 26 Sep 1999 23:30:02 -0400 (EDT)
<199909270330.XAA01510@candle.pha.pa.us>
Date: Mon, 27 Sep 1999 09:34:13 -0400
Message-ID: <26034.938439253@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Tom, can you comment on this patch. Seems you have made changes in this
area. Thanks.

This change is in place in current sources --- it's a few lines away from
where Hiroshi suggested, but I don't think that makes any difference...

*** utils/cache/relcache.c.orig	Wed May 26 16:05:38 1999
--- utils/cache/relcache.c	Wed Jul 28 13:23:49 1999
***************
*** 1282,1287 ****
--- 1282,1288 ----
oldcxt = MemoryContextSwitchTo((MemoryContext) CacheCxt);
RelationCacheDelete(relation);
+ smgrclose(DEFAULT_SMGR, relation);

FreeTupleDesc(relation->rd_att);
SystemCacheRelationFlushed(RelationGetRelid(relation));

regards, tom lane

From bouncefilter Mon Sep 27 11:24:08 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA73102
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 11:22:58 -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 LAA14759;
Mon, 27 Sep 1999 11:19:18 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271519.LAA14759@candle.pha.pa.us>
Subject: Re: TODO items (was Re: [COMMITTERS] pgsql/src/include/nodes
(execnodes.h))
In-Reply-To: <23379.938410273@sss.pgh.pa.us> from Tom Lane at "Sep 27,
1999 01:31:13 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 27 Sep 1999 11:19:18 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Tom, I only see one entry in TODO for this:
* -Fix memory leak for aggregates?

----------------------------- Log Message -----------------------------
Modify nodeAgg.c so that no rows are returned for a GROUP BY
with no input rows, per pghackers discussions around 7/22/99. Clean up
a bunch of ugly coding while at it; remove redundant re-lookup of
aggregate info at start of each new GROUP. Arrange to pfree intermediate
values when they are pass-by-ref types, so that aggregates on pass-by-ref
types no longer eat memory. This takes care of a couple of TODO items...

Hmm, you are right --- I thought that discussion about changing the
semantics of aggregates with GROUP BY had made it to the TODO list,
but apparently it never did. It should have, however:
* When using aggregates + GROUP BY, no rows in should yield no rows out

Added to TODO, with a completion mark.

This motivated me to grovel through the TODO list, which I hadn't done
for a while, and I have some updates/comments.

Good. It is a long list.

PARSER
------

* Select a[1] FROM test fails, it needs test.a[1]

Fixed for 6.6 --- actually same thing as next item,
* -Array index references without table name cause problems [array]

Done.

* Update table SET table.value = 3 fails

AFAICS, the SQL92 syntax allows only a bare <column name> as the
target of a SET clause. Not sure it's worth expending any effort
on this one...

Marked now as:

* Update table SET table.value = 3 fails(SQL standard says this is OK)

ENHANCEMENTS
------------

COMMANDS

* Generate error on CREATE OPERATOR of ~~, ~ and and ~*

"Error" seems a little strong, maybe a "NOTICE" along the lines of
"We trust you know that ~~ defines the behavior of the LIKE keyword".

I believe the original motivation for this entry was that the parser
would do the wrong thing for arbitrary operators named ~~ etc, because
it would try to apply optimizations that were only suitable for the
standard ops of those names (textlike etc). That's no longer a problem,
because those optimizations are now triggered off matching of the
operator OID; they will not cause a problem if Joe User invents an
operator named ~~ for his spiffy new datatype. But perhaps Joe should
be reminded that he just made LIKE applicable to his datatype. Or maybe
that's not worth worrying about...

Removed. You are correct that the message describes the old LIKE
optimization of user ~~ functions. This item is removed.

* Move LIKE index optimization handling to the optimizer

This is basically done, although I have a couple of cleanup issues
to take care of.

Marked as done.

CLIENTS

* PQrequestCancel() be able to terminate backend waiting for lock

There is an equivalent item under MISC, and it doesn't seem like it
belongs under CLIENTS --- the necessary code change is in the backend.

Removed. Already present, as you mentioned.

MISC

* Do autocommit so always in a transaction block(?)

Huh? What is this supposed to mean?

Some people want the SQL session to start inside a transaction, and you
have to explicity use COMMIT, at which point you are in a new
transaction that lasts until the next commit. Ingres SQL does this, and
it is a pain, I think.

PERFORMANCE
-----------

INDEXES

* Convert function(constant) into a constant for index use

Done as of now; see Frankpitt's constant-expression simplifier.
We might have some lingering bugs with simplifying things that
ought not be simplified, however...

Marked as done.

* Allow SELECT * FROM tab WHERE int2col = 4 use int2col index, int8 too
[optimizer]

I believe float4 columns have the same sort of problem, since a numeric
constant will be taken as float8 not float4 if not explicitly casted.
For that matter, numeric/decimal columns do too, or would if we had
indexing support for them...

Added new types to list.

* Allow optimizer to prefer plans that match ORDER BY

This is done, although we now have the opposite problem: the darn thing
is too eager to pick an indexscan plan :-(. Need to make the cost
estimates for indexscan vs explicit sort more accurate.

That is amusing. Marked as done.

MISC

* Update pg_statistic table to remove operator column

I do not believe we should do this. It's true that right now we have
no use for the operator column, because only the default '<' ordering
will ever be used by VACUUM, but we should keep the column in the name
of datatype extensibility. Someday VACUUM might compute stats with
respect to more than one ordering, for datatypes that have more than one.

Removed from the list.

* -Fix memory exhaustion when using many OR's [cnfify]

cnfify is still pretty slow with many subclauses --- the behavior
is now O(N^2) rather than O(2^N), but that just means it's
slow rather than intolerable. I'm not sure what to do about it.
We probably need to be using heuristics instead of an unconditional
convert-to-normal-form-or-bust algorithm, but what should the
heuristic conditions be? Am thinking about it, could use suggestions.

Marked as done. Let's see if people complain.

* Process const = const parts of OR clause in separate pass

Done --- Frankpitt's const simplifier handles this.

Marked as done.

* change VACUUM ANALYZE to use btree comparison functions, not <,=,> calls

Didn't we decide this probably wasn't worth doing?

Yes. Removed.

SOURCE CODE
-----------

* Remove SET KSQO option if OR processing is improved

You can put my name on this one --- I'm not quite ready to pull KSQO
but I think we are close.

Marked for you. New TODO copy installed.

-- 
  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 Mon Sep 27 11:31:08 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA73949
for <pgsql-hackers@postgresql.org>;
Mon, 27 Sep 1999 11:30:16 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id LAA21482;
Mon, 27 Sep 1999 11:30:19 -0400
Message-ID: <37EF8D84.C0E04F@wgcr.org>
Date: Mon, 27 Sep 1999 11:30:12 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: dale@redhat.com
CC: pgsql-hackers@postgresql.org, jbj@redhat.com
Subject: Re: New init script and upgrade attempt: failed
References: <199909252351.TAA01887@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[cc:ing the hackers mailing list, as this exposes an issue I hadn't
thought about]
[for the benefit of the hackers list, Dale Lovelace is testing the rpm
upgrading for potential inclusion in RedHat 6.1. Read his transcript
carefully. I comment below it on what the problem is.]
[version 6.0 had postgresql-6.4.2; version 6.1 potentially 6.5.1]

Dale Lovelace wrote:

Here is a test of upgrading a database with your method:

[root@test144 i386]# cd /mnt/redhat/comps/dist/6.0/i386/
[root@test144 i386]# rpm -Uvh postgresql-*
postgresql ##################################################
postgresql-clients ##################################################
postgresql-devel ##################################################
[root@test144 i386]# su postgres
[postgres@test144 i386]$ initdb --pglib=/usr/lib/pgsql/
--pgdata=/var/lib/pgsql/
We are initializing the database system with username postgres (uid=215).
This user will own all the files and must also own the server process.

Creating Postgres database system directory /var/lib/pgsql//base

Creating template database in /var/lib/pgsql//base/template1

Creating global classes in /var/lib/pgsql//base

Adding template1 database to pg_database...

Vacuuming template1
Creating public pg_user view
Creating view pg_rules
Creating view pg_views
Creating view pg_tables
Creating view pg_indexes
Loading pg_description
[postgres@test144 i386]$ exit

[root@test144 i386]# /etc/rc.d/init.d/postgresql start
Starting postgresql service: postmaster [1481]
[root@test144 i386]# su postgres
[postgres@test144 i386]$ psql -d template1
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL

type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: template1

-----NOTE THIS SESSION! WHAT'S MISSING?-------

template1=> create table dale (row1 text, row2 text, row3 text);
CREATE
template1=> insert into dale (row1, row2, row3) values ('this', 'is', 'text');
INSERT 17515 1
template1=> insert into dale (row1, row2, row3) values ('this', 'is', 'text');
INSERT 17516 1
template1=> insert into dale (row1, row2, row3) values ('this', 'is', 'text');
INSERT 17517 1
template1=> insert into dale (row1, row2, row3) values ('this', 'is', 'text');
INSERT 17518 1
template1=> insert into dale (row1, row2, row3) values ('this', 'is', 'text');
INSERT 17519 1
template1=> insert into dale (row1, row2, row3) values ('this', 'is', 'text');
INSERT 17520 1
template1=> insert into dale (row1, row2, row3) values ('this', 'is', 'text');
INSERT 17521 1
template1=> insert into dale (row1, row2, row3) values ('this', 'is', 'text');
INSERT 17522 1
template1=> insert into dale (row1, row2, row3) values ('this', 'is', 'text');
INSERT 17523 1
template1=> insert into dale (row1, row2, row3) values ('this', 'is', 'text');
INSERT 17524 1
template1=> select * from dale;
row1|row2|row3
----+----+----
this|is |text
this|is |text
this|is |text
this|is |text
this|is |text
this|is |text
this|is |text
this|is |text
this|is |text
this|is |text
(10 rows)

template1=> \q
[postgres@test144 i386]$ exit
[root@test144 i386]# /etc/rc.d/init.d/postgresql stop
Stopping postgresql service: [ OK ]
[root@test144 i386]# cd /mnt/redhat/comps/dist/6.1/i386/
[root@test144 i386]# rpm -Uvh postgresql-*
postgresql ##################################################
cannot remove /var/lib/pgsql - directory not empty
cannot remove /usr/lib/pgsql - directory not empty
postgresql-devel ##################################################
postgresql-jdbc ##################################################
postgresql-odbc ##################################################
postgresql-perl ##################################################
postgresql-python ##################################################
postgresql-server ##################################################
postgresql-tcl ##################################################
postgresql-test ##################################################
[root@test144 i386]# /etc/rc.d/init.d/postgresql start
Checking postgresql installation: old version. Need to Upgrade.
See /usr/doc/postgresql-6.5.2/README.rpm for more information.
[root@test144 i386]# su postgres
[postgres@test144 i386]$ postgresql-dump -t /usr/lib/pgsql/backup/db.bak -p
/usr/lib/pgsql/backup/old -d
/usr/bin/postgresql-dump: [: /usr/lib/pgsql/backup/db.bak: unary operator
expected
/usr/bin/postgresql-dump: [: /usr/lib/pgsql/backup: unary operator expected
/usr/bin/postgresql-dump: [: /usr/lib/pgsql: unary operator expected
/usr/bin/postgresql-dump: [: /usr/lib: unary operator expected
/usr/bin/postgresql-dump: [: /usr: unary operator expected
This is the ASCII output of the dump for you to check:

-- postgresql-dump on Sat Sep 25 19:36:51 EDT 1999 from version 6.4
\connect template1
select datdba into table tmp_pg_shadow from pg_database where datname =
'template1';
delete from pg_shadow where usesysid <> tmp_pg_shadow.datdba;
drop table tmp_pg_shadow;
copy pg_shadow from stdin;
\.
-- postgresql-dump completed on Sat Sep 25 19:36:51 EDT 1999
On the basis of this dump, is it OK to delete the old database? [y/n] y
Destroying old database...
[postgres@test144 i386]$ exit
[root@test144 i386]# /etc/rc.d/init.d/postgresql start
Checking postgresql installation: no database files found.

We are initializing the database system with username postgres (uid=215).
This user will own all the files and must also own the server process.

Creating Postgres database system directory /var/lib/pgsql/base

Creating template database in /var/lib/pgsql/base/template1

Creating global classes in /var/lib/pgsql/base

Adding template1 database to pg_database...

Vacuuming template1
Creating public pg_user view
Creating view pg_rules
Creating view pg_views
Creating view pg_tables
Creating view pg_indexes
Loading pg_description
Starting postgresql service: postmaster [1828]
[root@test144 i386]# su postgres
[postgres@test144 i386]$ psql -e template1 </usr/lib/pgsql/backup/db.bak
-- postgresql-dump on Sat Sep 25 19:36:51 EDT 1999 from version 6.4
\connect template1
connecting to new database: template1
select datdba into table tmp_pg_shadow from pg_database where datname =
'template1';
QUERY: select datdba into table tmp_pg_shadow from pg_database where
datname = 'template1';
SELECT
delete from pg_shadow where usesysid <> tmp_pg_shadow.datdba;
QUERY: delete from pg_shadow where usesysid <> tmp_pg_shadow.datdba;
DELETE 0
drop table tmp_pg_shadow;
QUERY: drop table tmp_pg_shadow;
DROP
copy pg_shadow from stdin;
QUERY: copy pg_shadow from stdin;
-- postgresql-dump completed on Sat Sep 25 19:36:51 EDT 1999
EOF
[postgres@test144 i386]$ psql -d template1
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66]

type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: template1

template1=> \d
Couldn't find any tables, sequences or indices!
template1=> select * from dale;
ERROR: dale: Table does not exist.
template1=>

I'm not really sure what is going on. I really don't have time to delve into
it :-) If you could point me in the right direction I would sure appreciate
it! I am wondering if those unary operator errors while running
postgresql-dump are the root of this?

The unary operator errors are red herrings. The core issue is an
undocumented assumption of pg_dumpall (a modified version of which is
use by postgresql-dump) -- template1 is assumed to always be empty.
[hackers -- is this an ACCURATE ASSUMPTION???]

To test the upgrading with this assumption in place, do this:

1.) Downgrade to 6.4.2
2.) Initdb
3.) Su to postgres, and type the following command: createdb dale
4.) Perform the same psql session as you did above.
5.) Upgrade just as you did above.
6.) When checking for the existance of you data, issue a psql -d dale
instead of psql -d template1
7.) The data should be there.

Wow, Dale, you are exposing some serious assumptions made in PostgreSQL.

Also, unless you guys are releasing 6.5.2, then you'll need to replace
all the '6.5.2's in postgresql.init with '6.5.1'. Of course, if you're
shipping 6.5.2, ignore that... ;-)

Hackers: should pg_dumpall dump template1?? If not, why not? What
EXACTLY does template1 do in the larger scheme of things? If dumping
template1 is desired -- it can be arranged in the upgrade by modifying
pg_dumpall.

As it stands now, any data the user might, whether mistakenly or not,
place in tables in template1 will not get dumped by pg_dumpall. Dale,
I'll get back to you ASAIC with a patch to pg_dumpall_new that will
address this, if I don't hear otherwise from the hackers list.
Ordinarily, template1 is not used for user data storage and is normally
empty.

Thanks for your help with this! I am totally braindead, going home. Will be
working on this tommorrow. If you get a chance to look at it, wouldbe great!

Glad to be of help....

From bouncefilter Mon Sep 27 12:08:10 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 MAA78941
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 12:07:30 -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 LAA15302;
Mon, 27 Sep 1999 11:33:33 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271533.LAA15302@candle.pha.pa.us>
Subject: Re: [HACKERS] Profiling?]
In-Reply-To: <37EF229A.8D81E3D9@udmnet.ru> from Leon at "Sep 27, 1999 12:54:02
pm"
To: Leon <leon@udmnet.ru>
Date: Mon, 27 Sep 1999 11:33:33 -0400 (EDT)
CC: hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Yes, I have done it many times. I profile that postgres process, not
the backend.

Hmm, isn't Postgres process called backend process? AFAIK postmaster
(it's simply a nickname to Postgres) forks itself on receiveing new
connection request. Isn't it true? I mean that Postmaster is the same
binary as Postgres itself.

Yes.

Look for this in Makefile.global:

# Comment out PROFILE to generate a profile version of the binaries
#PROFILE= -p -non_shared

Of course I used -p option. The problem is, when I start Postmaster,
it complains about 'profile timer expired'. What do I do wrong?

That's strange. I have not profiled in a while. I wonder if the
removal of the exec() has caused this.

-- 
  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 Mon Sep 27 11:41:08 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA75099
for <pgsql-hackers@postgresql.org>;
Mon, 27 Sep 1999 11:40:09 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <T2ZVSK5K>; Mon, 27 Sep 1999 17:40:07 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C0CE@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>, "'pgsql-hackers@postgresql.org'"
<pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] Lexxing and yaccing...
Date: Mon, 27 Sep 1999 17:35:16 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Yes, exactly. I know that you have been saying this from the word go, and
this adds to the chorus.
The check is pretty simple - if the previous token was not a value or right
parenthesis, then it's a unary, not binary, minus. Of course, we would have
to expand 'value' to mean constant or column name. Is there anything else
that defines the binary minus that I've left out? We would, I suppose, also
have to check that the minus isn't part of a user-defined operator. What is
the BNF for our operators? In fact, do we have a BNF diagram for our
flavour of SQL? Perhaps that is where the problem lies. I must admit, I
have hardly been into the compiler.

MikeA

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Thursday, September 23, 1999 5:03 PM
To: Ansley, Michael
Subject: Re: [HACKERS] Lexxing and yaccing...

"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:

However, the most interesting part that I noticed is on

the second page,

under the 'Other Titles' section. It's called 'Operator-Precedence
Parsing'. I haven't yet managed to get to it, because the

web server (or my

browser, I'm not sure yet) keeps hooching over the page,

however, I'll put

money on the fact that it will provide us with some

insight into solving the

current operator problem(s?) that we have (see previous

postings titled

'Status Report: long query string changes' and "Postgres' lexer").

I doubt it. Operator precedence is a grammar-level technique; it
doesn't have anything to do with lexical analysis...

regards, tom lane

From bouncefilter Mon Sep 27 12:08: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 MAA78947;
Mon, 27 Sep 1999 12:07:36 -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 LAA15571;
Mon, 27 Sep 1999 11:38:05 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271538.LAA15571@candle.pha.pa.us>
Subject: Re: [PATCHES] RE: [HACKERS] Index access using multi-column indices
In-Reply-To: <001f01bf08c5$7d13eaa0$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Sep 27, 1999 05:51:28 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 27 Sep 1999 11:38:05 -0400 (EDT)
CC: pgsql-patches <pgsql-patches@postgreSQL.org>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I will apply it today. I am working through my mailbox after a very
busy Summer.

[Charset iso-8859-1 unsupported, filtering to ASCII...]

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Hiroshi Inoue
Sent: Thursday, August 12, 1999 5:52 PM
To: pgsql-patches
Cc: pgsql-hackers
Subject: [HACKERS] Index access using multi-column indices

Hello all,

Currently,only the first column of multi-column indices
is used to find start scan position of Indexscan-s.

To speed up finding scan start position,I have changed
_bt_first() to use as many keys as possible.

I'll attach the patch here.

Seems this isn't committed yet.
If there's no objection,I will commit this patch to current tree.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

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

-- 
  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 Mon Sep 27 12:08:13 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 MAA78945
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 12:07:35 -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 LAA16213;
Mon, 27 Sep 1999 11:42:33 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271542.LAA16213@candle.pha.pa.us>
Subject: Re: [HACKERS] _text problem in union
In-Reply-To: <Pine.LNX.3.96.990927150619.8444A-100000@ara.zf.jcu.cz> from
Zakkr
at "Sep 27, 1999 03:11:10 pm"
To: Zakkr <zakkr@zf.jcu.cz>
Date: Mon, 27 Sep 1999 11:42:33 -0400 (EDT)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

I have small problem with text array in union query.. see:

abil=> select 5 union select 5;
?column?
--------
5
(1 row)

abil=> select 5 union select 6;
?column?
--------
5
6
(2 rows)

abil=> select '{"aaa"}'::_text union select '{"aaa"}'::_text;
?column?
--------
{"aaa"}
(1 row)

abil=> select '{"aaa"}'::_text union select '{"bbb"}'::_text;
ERROR: Unable to identify an ordering operator '<' for type '_text'
Use an explicit ordering operator or modify the query
abil=>

Good problem description. Seems we can't compare arrays of text fields.

Seems if we have an array of text fields, we could compare each element
one-by-one using the base type until we get a comparison result.

Not sure if this should make the TODO list or not.

-- 
  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 Mon Sep 27 12:08:43 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 MAA78935
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 12:07:27 -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 LAA17065;
Mon, 27 Sep 1999 11:49:12 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271549.LAA17065@candle.pha.pa.us>
Subject: Re: [HACKERS] double opens
In-Reply-To: <26034.938439253@sss.pgh.pa.us> from Tom Lane at "Sep 27,
1999 09:34:13 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 27 Sep 1999 11:49:12 -0400 (EDT)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Tom, can you comment on this patch. Seems you have made changes in this
area. Thanks.

This change is in place in current sources --- it's a few lines away from
where Hiroshi suggested, but I don't think that makes any difference...

Sorry, I missed it the first time. I see it now. Thanks.

*** utils/cache/relcache.c.orig	Wed May 26 16:05:38 1999
--- utils/cache/relcache.c	Wed Jul 28 13:23:49 1999
***************
*** 1282,1287 ****
--- 1282,1288 ----
oldcxt = MemoryContextSwitchTo((MemoryContext) CacheCxt);
RelationCacheDelete(relation);
+ smgrclose(DEFAULT_SMGR, relation);

FreeTupleDesc(relation->rd_att);
SystemCacheRelationFlushed(RelationGetRelid(relation));
regards, tom lane

-- 
  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 Mon Sep 27 12:03:08 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA78298
for <pgsql-hackers@postgresql.org>;
Mon, 27 Sep 1999 12:02:35 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id MAA21593
for <pgsql-hackers@postgresql.org>; Mon, 27 Sep 1999 12:02:33 -0400
Message-ID: <37EF9512.C4F67DFE@wgcr.org>
Date: Mon, 27 Sep 1999 12:02:26 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Regression tests on intel for 6.5.2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

In the course of building and testing the rpm's for 6.5.2, unexpected
results were found in the regression testing. I am curious as to what
the results for 'float8' mean (geometry also failed, but it's obvious as
to why):

*** expected/float8.out Sat Jan 23 19:12:59 1999
--- results/float8.out  Mon Sep 27 11:01:13 1999
***************
*** 189,201 ****
QUERY: SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
ERROR:  Bad float8 input format -- overflow
QUERY: SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
! ERROR:  pow() result is out of range
QUERY: SELECT '' AS bad, (; (f.f1)) from FLOAT8_TBL f where f.f1 = '0.0' ;
ERROR:  can't take log of zero
QUERY: SELECT '' AS bad, (; (f.f1)) from FLOAT8_TBL f where f.f1 < '0.0' ;
ERROR:  can't take log of a negative number
QUERY: SELECT '' AS bad, : (f.f1) from FLOAT8_TBL f;
! ERROR:  exp() result is out of range
QUERY: SELECT '' AS bad, f.f1 / '0.0' from FLOAT8_TBL f;
ERROR:  float8div: divide by zero error
QUERY: SELECT '' AS five, FLOAT8_TBL.*;
--- 189,217 ----
QUERY: SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
ERROR:  Bad float8 input format -- overflow
QUERY: SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
! bad|?column?
! ---+--------
!    |0       
!    |NaN     
!    |NaN     
!    |NaN     
!    |NaN     
! (5 rows)
! 
QUERY: SELECT '' AS bad, (; (f.f1)) from FLOAT8_TBL f where f.f1 = '0.0' ;
ERROR:  can't take log of zero
QUERY: SELECT '' AS bad, (; (f.f1)) from FLOAT8_TBL f where f.f1 < '0.0' ;
ERROR:  can't take log of a negative number
QUERY: SELECT '' AS bad, : (f.f1) from FLOAT8_TBL f;
! bad|            ?column?
! ---+--------------------
!    |                   1
!    |7.39912306090513e-16
!    |                   0
!    |                   0
!    |                   1
! (5 rows)
! 
QUERY: SELECT '' AS bad, f.f1 / '0.0' from FLOAT8_TBL f;
ERROR:  float8div: divide by zero error
QUERY: SELECT '' AS five, FLOAT8_TBL.*;

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

TIA

Lamar Owen
WGCR Internet Radio

From bouncefilter Mon Sep 27 12:43:10 1999
Received: from lota.izhcom.ru (lota.izhcom.ru [213.24.0.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA86048
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 12:42:23 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (U123.dialup.udm.net [192.168.53.123])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id VAA29249;
Mon, 27 Sep 1999 21:41:28 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37EF99F2.BDB695D@udmnet.ru>
Date: Mon, 27 Sep 1999 21:23:14 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Profiling?]
References: <199909271533.LAA15302@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

# Comment out PROFILE to generate a profile version of the binaries
#PROFILE= -p -non_shared

Of course I used -p option. The problem is, when I start Postmaster,
it complains about 'profile timer expired'. What do I do wrong?

That's strange. I have not profiled in a while. I wonder if the
removal of the exec() has caused this.

BTW, gcc on Linux doesn't understand the option -non_shared. Maybe
that is the cause? In general, who and where should I talk to on
that strange matter? Info and man seem not to say anything about it.

--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.

From bouncefilter Mon Sep 27 12:45:04 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA86603
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 12:44:37 -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 MAA02295;
Mon, 27 Sep 1999 12:43:09 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271643.MAA02295@candle.pha.pa.us>
Subject: Re: [HACKERS] Cannot insert into temp tables
In-Reply-To: <199907311726.SAA21548@linda.lfix.co.uk> from Oliver Elphick at
"Jul 31, 1999 06:26:22 pm"
To: Oliver Elphick <olly@lfix.co.uk>
Date: Mon, 27 Sep 1999 12:43:09 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:
...

OK, you have good points. usecatupd should not be set by default.
Making changes to the system tables can mess things up for everyone.
Initdb will give the postgres superuser permissions, but now createuser
and the SQL command CREATE USER will not give this permission. Also, I
have fixed the code so temp tables, which are acutally named pg_temp,
can be updated by normal users without usecatupd permissions.

Attached is a patch. I will apply it to the current tree.

Bruce, this change has some other implications. I tested
the effect of the patch by altering the rights of my own account (setting
usecatupd to false). I cannot now create other users: although usesuper is
true, the attempt to update pg_shadow with the new user's row fails:

OK, I have committed a fix for this. I now give update catalog rights
to anyone who has createdb or super-user rights. This is in the current
tree only. Let me know if you see any additional problems.

-- 
  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 Mon Sep 27 12:53:04 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA89151
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 12:52:39 -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 MAA02457;
Mon, 27 Sep 1999 12:51:42 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271651.MAA02457@candle.pha.pa.us>
Subject: Re: [HACKERS] _text problem in union
In-Reply-To: <37EFA1CA.5691C0EA@tm.ee> from Hannu Krosing at "Sep 27,
1999 07:56:42 pm"
To: Hannu Krosing <hannu@tm.ee>
Date: Mon, 27 Sep 1999 12:51:42 -0400 (EDT)
CC: Zakkr <zakkr@zf.jcu.cz>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

abil=> select '{"aaa"}'::_text union select '{"bbb"}'::_text;
ERROR: Unable to identify an ordering operator '<' for type '_text'
Use an explicit ordering operator or modify the query
abil=>

Good problem description. Seems we can't compare arrays of text fields.

Seems if we have an array of text fields, we could compare each element
one-by-one using the base type until we get a comparison result.

Not sure if this should make the TODO list or not.

It woulf be better to have a generic array compare op, that just
traverses
both arrays comparing them with the "<" for base type

Yes, that was my idea. Is this a worthy TODO item?

-- 
  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 Mon Sep 27 12:55:08 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA89643
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 12:55:07 -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 MAA02521;
Mon, 27 Sep 1999 12:52:54 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271652.MAA02521@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_upgrade may be mortally wounded
In-Reply-To: <14739.933689027@sss.pgh.pa.us> from Tom Lane at "Aug 3,
1999 10:03:47 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 27 Sep 1999 12:52:54 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tom, did we address this. I forgot.

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

BTW, it seems to me that it is a good idea to kill and restart the
postmaster immediately after pg_upgrade finishes. Otherwise there might
be buffers in shared memory that do not reflect the actual contents of
the corresponding pages of the relation files (now that pg_upgrade
overwrote the files with other data).

Your issue with buffer cache is a major one. Clearly, this would be a
problem. However, it is my understanding that the buffer cache after
initdb would only contain system table info, so if they pg_upgrade after
that, there is no way they have bad stuf in the cache, right?

Cached copies of system tables obviously are no problem, since
pg_upgrade doesn't overwrite those. I'm concerned whether there can
be cached copies of pages from user tables or indexes. Since we've
just done a bunch of CREATE INDEXes (and a VACUUM, if my latest hack
is right), it seems at least possible that this would happen.

Now all those user tables will be empty (zero-length files), so there is
nothing to cache. But the user indexes are *not* zero-length --- it looks
like they are at least 2 pages long even when empty. So there seems
to be a real risk of having a cached copy of one of the pages of a user
index while pg_upgrade is overwriting the index file with new data...

regards, tom lane

-- 
  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 Mon Sep 27 12:50:04 1999
Received: from kodu.home.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA88293
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 12:49:56 -0400 (EDT) (envelope-from hannu@tm.ee)
Received: from tm.ee (hannu@localhost [127.0.0.1])
by kodu.home.ee (8.8.7/8.8.7) with ESMTP id TAA00507;
Mon, 27 Sep 1999 19:56:42 +0300
Sender: hannu@kodu.home.ee
Message-ID: <37EFA1CA.5691C0EA@tm.ee>
Date: Mon, 27 Sep 1999 19:56:42 +0300
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.2.6 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Zakkr <zakkr@zf.jcu.cz>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] _text problem in union
References: <199909271542.LAA16213@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

abil=> select '{"aaa"}'::_text union select '{"bbb"}'::_text;
ERROR: Unable to identify an ordering operator '<' for type '_text'
Use an explicit ordering operator or modify the query
abil=>

Good problem description. Seems we can't compare arrays of text fields.

Seems if we have an array of text fields, we could compare each element
one-by-one using the base type until we get a comparison result.

Not sure if this should make the TODO list or not.

It woulf be better to have a generic array compare op, that just
traverses
both arrays comparing them with the "<" for base type

--------------
Hannu

From bouncefilter Mon Sep 27 14:01:05 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 OAA02065
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 14:00:04 -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 VAA14344
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 21:59:51 +0400 (MSD)
Date: Mon, 27 Sep 1999 21:59:50 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: pgsql-hackers@postgreSQL.org
Subject: NULL as an argument in plpgsql functions
Message-ID: <Pine.GSO.3.96.SK.990927215550.8336p-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

this select produces error message:
test=> select test2(NULL);
ERROR: typeidTypeRelid: Invalid type - oid = 0

test2:
CREATE FUNCTION test2 (int4) RETURNS int4 AS '
Declare
keyval Alias For $1;
cnt int4;
Begin
Update hits set count = count +1 where msg_id = keyval;
return cnt;
End;
' LANGUAGE 'plpgsql';

When I do manually update
Update hits set count = count +1 where msg_id = NULL;
it works fine. What's the problem ?

Regards,

Oleg

test=> \d hits
Table    = hits
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                | Length|
+----------------------------------+----------------------------------+-------+
| msg_id                           | int4                             |     4 |
| count                            | int4                             |     4 |
+----------------------------------+----------------------------------+-------+
test=> select version();
version                                                           
------------------------------------------------------------------
PostgreSQL 6.5.2 on i586-pc-linux-gnulibc1, compiled by gcc 2.95.1
(1 row)

From bouncefilter Mon Sep 27 14:07:10 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA04782
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 14:07:05 -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 OAA10131;
Mon, 27 Sep 1999 14:04:42 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271804.OAA10131@candle.pha.pa.us>
Subject: Re: [HACKERS] Inefficiencies in COPY command
In-Reply-To: <11798.934038075@sss.pgh.pa.us> from Tom Lane at "Aug 7,
1999 11:01:15 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 27 Sep 1999 14:04:42 -0400 (EDT)
CC: Wayne Piekarski <wayne@senet.com.au>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yes, I too would be interested in any code that would speed up COPY
without loosing modularity or portability.

Please let us know if you get a patch we can include in our source tree.

Wayne Piekarski <wayne@senet.com.au> writes:

So I made some changes to CopyAttributeOut so that it escapes the string
initially into a temporary buffer (allocated onto the stack) and then
feeds the whole string to the CopySendData which is a lot more efficient
because it can blast the whole string in one go, saving about 1/3 to 1/4
the number of memcpy and so on.

copy.c is pretty much of a hack job to start with, IMHO. If you can
speed it up without making it even uglier, have at it! However, it
also has to be portable, and what you've done here:

CopyAttributeOut(FILE *fp, char *server_string, char *delim, int is_array)
{
char *string;
char c;
+ char __buffer [(strlen (server_string) * 2) + 4]; /* Use +4 for safety */

is not portable --- variable-sized local arrays are a gcc-ism. (I use
'em a lot too, but not in code intended for public release...) Also,
be careful that you don't introduce any assumptions about maximum
field or tuple width; we want to get rid of those, not add more.

to also make changes to remove all use of sprintf when numbers
and floats are being converted into strings.

^^^^^^^^^^

While formatting an int is pretty simple, formatting a float is not so
simple. I'd be leery of replacing sprintf with quick-hack float
conversion code. OTOH, if someone wanted to go to the trouble of doing
it *right*, using our own code would tend to yield more consistent
results across different OSes, which would be a Good Thing. I'm not
sure it'd be any faster than the typical sprintf, but it might be worth
doing anyway.

(My idea of *right* is the guaranteed-inverse float<=>ASCII routines
published a few years ago in some SIGPLAN proceedings ... I've got the
proceedings, and I even know approximately where they are, but I don't
feel like excavating for them right now...)

regards, tom lane

-- 
  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 Mon Sep 27 14:07:05 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA04730
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 14:06:17 -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 OAA10180;
Mon, 27 Sep 1999 14:05:29 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271805.OAA10180@candle.pha.pa.us>
Subject: Re: [HACKERS] another DECIMAL problem
In-Reply-To: <37AFDD39.E3986E@sferacarta.com> from "[Jos_] Soares" at "Aug 10,
1999 10:05:13 am"
To: "[Jos_] Soares" <jose@sferacarta.com>
Date: Mon, 27 Sep 1999 14:05:29 -0400 (EDT)
CC: hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Hi all,

I'm trying to create an index on a composite key using a DECIMAL type
but PostgreSQL raises the following error:

CREATE TABLE header (
year decimal(4) NOT NULL,
number INTEGER NOT NULL,
date DATE NOT NULL,
cod_client CHAR(4) NOT NULL,
CONSTRAINT k_header PRIMARY KEY (year,number)
);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'k_header'
for tabl
e 'header'
ERROR: Can't find a default operator class for type 1700.

We have the TODO item:

* Add index on NUMERIC/DECIMAL type

-- 
  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 Mon Sep 27 14:21:13 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 OAA06479;
Mon, 27 Sep 1999 14:20:18 -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 OAA10449;
Mon, 27 Sep 1999 14:18:57 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271818.OAA10449@candle.pha.pa.us>
Subject: Re: [PATCHES] Index access using multi-column indices
In-Reply-To: <000001bee49f$defce040$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Aug 12, 1999 05:51:30 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 27 Sep 1999 14:18:57 -0400 (EDT)
CC: pgsql-patches <pgsql-patches@postgreSQL.org>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied.

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Hello all,

Currently,only the first column of multi-column indices
is used to find start scan position of Indexscan-s.

To speed up finding scan start position,I have changed
_bt_first() to use as many keys as possible.

I'll attach the patch here.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

[Attachment, skipping...]

-- 
  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 Mon Sep 27 14:23:05 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA06664
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 14:22:09 -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 OAA10598;
Mon, 27 Sep 1999 14:21:23 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271821.OAA10598@candle.pha.pa.us>
Subject: Re: [HACKERS] 6.5.2
In-Reply-To: <Pine.LNX.4.04.9908161346340.20684-100000@emerald.netskate.ru>
from Oleg Broytmann at "Aug 16, 1999 01:48:49 pm"
To: phd2@earthling.net
Date: Mon, 27 Sep 1999 14:21:23 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Oleg, do you seem them now? If not, can you send them to me.

Hello!

I didn't saw my latest patches for README.locale in latest (Aug 15)
snapshot, although Bruce reported he got it. I think it best to apply it
for 6.5.2 than to 6.6 ot 7.0...

-- 
  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 Mon Sep 27 14:36:10 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA08543
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 14:35:31 -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 OAA11226;
Mon, 27 Sep 1999 14:32:34 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271832.OAA11226@candle.pha.pa.us>
Subject: Re: [HACKERS] backend freezeing on win32 fixed (I hope ;-) )
In-Reply-To: <000301bee90a$95d40f00$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Aug 18, 1999 08:45:28 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 27 Sep 1999 14:32:34 -0400 (EDT)
CC: Horak Daniel <horak@mmp.plzen-city.cz>, "'Tom Lane'" <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have added this to the end of the README.NT file.

[Charset iso-8859-1 unsupported, filtering to ASCII...]

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Horak Daniel
Sent: Tuesday, August 17, 1999 9:06 PM
To: 'Tom Lane'
Cc: 'pgsql-hackers@postgreSQL.org'
Subject: RE: [HACKERS] backend freezeing on win32 fixed (I hope ;-) )

In any case, when one backend quits and another one is
started, the new
one will re-use the semaphore no longer used by the defunct backend.

I have tested my solution a bit more and I have to say that reusing a
semaphore by a new backend works OK. But it is not possible for a newly
created backend to use a semaphore allocated by postmaster (it freezes on
test if the semaphore with given key already exists - done with
semId=semget(semKey, 0, 0) in function IpcSemaphoreCreate() in
storage/ipc/ipc.c ). Why it is, I don't know, but it seems that
my solution
uses the ipc library in the right way. There are no longer any error
messages from the ipc library when running the server. And I
can't say that
the ipc library is a 100% correct implementation of SysV IPC, it
is probably
(sure ;-) )caused by the Windows internals.

Yutaka Tanida [yutaka@marin.or.jp] and I have examined IPC
library.

We found that postmaster doesn't call exec() after fork() since v6.4.

The value of static/extern variables which cygipc library holds may
be different from their initial values when postmaster fork()s child
backend processes.

I made the following patch for cygipc library on trial.
This patch was effective for Yutaka's test case.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp
*** sem.c.orig	Tue Dec 01 00:16:25 1998
--- sem.c	Tue Aug 17 13:22:06 1999
***************
*** 58,63 ****
--- 58,78 ----
static int		  GFirstSem	 = 0;		/*PCPC*/
static int		  GFdSem	    ;		/*PCPC*/
+ static pid_t	GProcessId = 0;
+
+ static void	init_globals(void)
+ {
+ 	pid_t pid;
+
+ 	if (pid=getpid(), pid != GProcessId)
+ 	{
+ 		GFirstSem = 0;
+ 		used_sems = used_semids = max_semid = 0;
+ 		sem_seq = 0;
+ 		GProcessId = pid;
+ 	}
+ }
+
/************************************************************************/
/* Demande d'acces a la zone partagee de gestion des semaphores		*/
/************************************************************************/
***************
*** 77,82 ****
--- 92,98 ----
{
int LRet ;
+ 	init_globals();
if( GFirstSem == 0 )
{
if( IsGSemSemExist() )
*** shm.c.orig	Tue Dec 01 01:04:57 1998
--- shm.c	Tue Aug 17 13:22:27 1999
***************
*** 59,64 ****
--- 59,81 ----
static int		  GFirstShm	 = 0;		/*PCPC*/
static int		  GFdShm	    ;		/*PCPC*/
+ /*****************************************/
+ /*	Initialization of static variables   */
+ /*****************************************/
+ static pid_t GProcessId = 0;
+ static void init_globals(void)
+ {
+ 	pid_t pid;
+
+ 	if (pid=getpid(), pid != GProcessId)
+ 	{
+ 		GFirstShm = 0;
+ 		shm_rss = shm_swp = max_shmid = 0;
+ 		shm_seq = 0;
+ 		GProcessId = pid;
+ 	}
+ }
+
/************************************************************************/
/* Demande d'acces a la zone partagee de gestion des shm		*/
/************************************************************************/
***************
*** 82,87 ****
--- 99,105 ----
{
int LRet ;
+  init_globals();
if( GFirstShm == 0 )
{
if( IsGSemShmExist() )
*** msg.c.orig	Tue Dec 01 00:16:09 1998
--- msg.c	Tue Aug 17 13:20:04 1999
***************
*** 57,62 ****
--- 57,77 ----
static int		  GFirstMsg	 = 0;		/*PCPC*/
static int		  GFdMsg	    ;		/*PCPC*/
+ /*****************************************/
+ /*	Initialization of static variables   */
+ /*****************************************/
+ static pid_t GProcessId = 0;
+ static void init_globals(void)
+ {
+ 	pid_t pid;
+
+ 	if (pid=getpid(), pid != GProcessId)
+ 	{
+ 		GFirstMsg = 0;
+ 		msgbytes = msghdrs = msg_seq = used_queues = max_msqid = 0;
+ 		GProcessId = pid;
+ 	}
+ }
/************************************************************************/
/* Demande d'acces a la zone partagee de gestion des semaphores		*/
/************************************************************************/
***************
*** 79,84 ****
--- 94,100 ----
{
int LRet ;
+ init_globals();
if( GFirstMsg == 0 )
{
if( IsGSemMsgExist() )

-- 
  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 Mon Sep 27 14:36:06 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA08529
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 14:35:24 -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 OAA11252;
Mon, 27 Sep 1999 14:33:06 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271833.OAA11252@candle.pha.pa.us>
Subject: Re: [HACKERS] vacuum process size
In-Reply-To: <199908190854.RAA02572@srapc451.sra.co.jp> from Tatsuo Ishii at
"Aug 19, 1999 05:54:00 pm"
To: t-ishii@sra.co.jp
Date: Mon, 27 Sep 1999 14:33:06 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tom, you already handled this, right?

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

Just for a testing I made a huge table (>2GB and it has 10000000
tuples). copy 10000000 tuples took 23 minutes. This is not so
bad. Vacuum analyze took 11 minutes, not too bad. After this I created
an index on int4 column. It took 9 minutes. Next I deleted 5000000
tuples to see how long delete took. I found it was 6
minutes. Good. Then I ran into a problem. After that I did vacuum
analyze, and seemed it took forever! (actually took 47 minutes). The
biggest problem was postgres's process size. It was 478MB! This is not
acceptable for me. Any idea?

Yeah, I've complained about that before --- it seems that vacuum takes
a really unreasonable amount of time to remove dead tuples from an index.
It's been like that at least since 6.3.2, probably longer.

Hiroshi came up with a work around for this(see included
patches). After applying it, the process size shrinked from 478MB to
86MB! (the processing time did not descrease, however). According to
him, repalloc seems not very effective with large number of calls. The
patches probably descreases the number to 1/10.
--
Tatsuo Ishii
-------------------------------------------------------------------------
*** vacuum.c.orig	Sat Jul 3 09:32:40 1999
--- vacuum.c	Thu Aug 19 17:34:18 1999
***************
*** 2519,2530 ****
static void
vc_vpinsert(VPageList vpl, VPageDescr vpnew)
{
/* allocate a VPageDescr entry if needed */
if (vpl->vpl_num_pages == 0)
! vpl->vpl_pagedesc = (VPageDescr *) palloc(100 * sizeof(VPageDescr));
! else if (vpl->vpl_num_pages % 100 == 0)
! vpl->vpl_pagedesc = (VPageDescr *) repalloc(vpl->vpl_pagedesc, (vpl->vpl_num_pages + 100) * sizeof(VPageDescr));
vpl->vpl_pagedesc[vpl->vpl_num_pages] = vpnew;
(vpl->vpl_num_pages)++;
--- 2519,2531 ----
static void
vc_vpinsert(VPageList vpl, VPageDescr vpnew)
{
+ #define PG_NPAGEDESC 1000
/* allocate a VPageDescr entry if needed */
if (vpl->vpl_num_pages == 0)
! vpl->vpl_pagedesc = (VPageDescr *) palloc(PG_NPAGEDESC * sizeof(VPageDescr));
! else if (vpl->vpl_num_pages % PG_NPAGEDESC == 0)
! vpl->vpl_pagedesc = (VPageDescr *) repalloc(vpl->vpl_pagedesc, (vpl->vpl_num_pages + PG_NPAGEDESC) * sizeof(VPageDescr));
vpl->vpl_pagedesc[vpl->vpl_num_pages] = vpnew;
(vpl->vpl_num_pages)++;

************
Check out "PostgreSQL Wearables" @ http://www.pgsql.com

-- 
  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 Mon Sep 27 14:49:06 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 OAA10881
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 14:48:35 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11Vfix-0003kLC; Mon, 27 Sep 99 20:42 MET DST
Message-Id: <m11Vfix-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: RI status report #1
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Mon, 27 Sep 1999 20:42:07 +0200 (MET DST)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Hi all,

just to give anyone a chance to complain, I'd like to
describe what I plan to implement for v6.6 in the referential
integrity (RI) corner.

1. What will be supported

I'm concentrating on FOREIGN KEY support. From the general
definition (thanks to Vadim for the SQL3 draft):

[ CONSTRAINT constraint-name ] FOREIGN KEY ( column [, ...] )
REFERENCES [ PENDANT ] table-name [ ( column [, ...] ) ]
[ MATCH { FULL | PARTIAL } ]
[ ON DELETE <referential-action> ]
[ ON UPDATE <referential-action> ]
[ [ NOT ] DEFERRABLE ]
[ INITIALLY { IMMEDIATE | DEFERRED } ]

<referential-action> ::=
CASCADE
| SET NULL
| SET DEFAULT
| RESTRICT
| NO ACTION

I'll omit the following parts on the first go:

PENDANT
MATCH (match type is allways FULL)

The implementation of referential-actions will require
that the columns in the referenced table build a unique
key. It will not be guaranteed, that an appropriate unique
index exists.

The support for the SET DEFAULT action depends on the
smartness of the generic trigger procedure described later
- so that detail might be left unsupported too in v6.6.

2. Implementation

As previous discussions turned out, the rule system isn't
adequate for implementing deferred constraints with
respect to all their side effects. Thus, RI constraints
will be implemented by specialized trigger procedures.

Therefore, a bunch of new attributes and some indices are
added to the pg_trigger system catalog. These are required
to tell constraints from real triggers, automatically drop
referential-action constraints from referenced tables if
the referencing table is dropped and to hold information
about deferrability and initially deferred states for the
constraints.

The procedures will finally get implemented as builtin, C
language, generic functions.

3. What I have so far

I've added the following attributes to pg_trigger:

tgenabled A bool that is designed to switch off
a regular trigger with the ALTER
TRIGGER command. This is not related
to RI and I'm not actually planning on
implementing the parser/utility stuff.

tgisconstraint A bool that tells a constraint from a
trigger.

tgconstrname The NAME of the constraint. RI
constraint triggers will be
automatically inserted during CREATE
TABLE with trigger names
_RI_Fkey_Constraint_<n> so that they
are unique "triggers" per table. This
attribute (indexed) holds the real
constraint name for SET CONSTRAINT.

tgconstrrelid The OID of the opposite table
(indexed). In the constraints that
check foreign key existance, it's the
Oid of the referenced table. In the
constraints that do the referential-
actions, it's the Oid of the
referenced table. This Oid is used to
quickly drop triggers from the
opposite table in the case of DROP
TABLE.

tgdeferrable A bool telling if the constraint can
be set to DEFERRED checking.

tginitdeferred A bool telling if the constraint is in
DEFERRED state by default.

To commands/trigger.c I've added a few hundred lines of
code. All AFTER ROW IMMEDIATE triggers are executed after
the entire query. DEFERRED triggers are executed at SET
CONSTRAINTS ... IMMEDIATE or at COMMIT.

To the time qualification code I've added SnapshotAny.
Since I know the exact CTID of the tuple WHICH IS OLD/NEW
for the event in question, this new snapshot completely
ignores any time qualification and fetches it.

What I see so far from the tests, anything (except for the
damned funny_dup17 reported earlier) still works. And
setting triggers to deferred execution solves the cyclic
integrity problems which are the reason for deferred
execution. So I assume I'm on the right track.

4. Next steps

First I need to implement the SET CONSTRAINTS command in
the parser and utility stuff now.

Second I'll write the generic trigger procs in PL/Tcl that
don't use prepared SPI plans (it's easiest to do it this
way). When they work as needed by the implementation, I'll
write down the specs and ask the co-developers to
implement their high quality, plan saving C-language
equivalents. Sorry, but all co-developers therefore should
at least compile in PL/Tcl support.

All the parser/utility stuff must be written that handles
constraint trigger creation/dropping during CREATE/DROP
table. And all the new features/definitions must be
adapted to pg_dump and psql.

Finally the deferred trigger manager must buffer huge
amounts of trigger events (actually collected in memory)
out onto disk.

Most of the activities after "Second" next step can be
done parallel. I'll commit my changes after that, because
then I'm able to run a full test of deferred constraints
to be sure I'm really on the right track. All co-
developers can join then using the CURRENT tree.

Any comments?

Jan

From bouncefilter Mon Sep 27 15:03:10 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 PAA12843
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 15:02:26 -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 OAA11599;
Mon, 27 Sep 1999 14:52:06 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271852.OAA11599@candle.pha.pa.us>
Subject: Re: [GENERAL] Error during 'vacuum analyze'
In-Reply-To: <37BD8A26.BED83813@nsi.edu> from "G. Anthony Reina" at "Aug 20,
1999 10:02:30 am"
To: "G. Anthony Reina" <reina@nsi.edu>
Date: Mon, 27 Sep 1999 14:52:06 -0400 (EDT)
CC: Mark Dalphin <mdalphin@amgen.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I assume we addressed this in our current tree, right?

Mark,

The error you are experiencing was discussed on the hacker's list
last week. Oliver Elphick and Tom Good worked out a patch for SQL to
solve the problem. You're right that the pg_vlock is getting created and
then getting deleted during the vacuuming of the last table. This ends
up boinking the vacuum. I've attached the patch that Oliver sent to me.
The patch won't go through all of the way so you'll have to go through
file by file and just make the changes yourself (just deleting a few
lines or adding a few, nothing big). That has solved the problem on my
machine.

-Tony

Index: include/access/nbtree.h
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/include/access/nbtree.h,v
retrieving revision 1.27
retrieving revision 1.27.2.1
diff -c -r1.27 -r1.27.2.1
*** include/access/nbtree.h     1999/05/25 22:04:55     1.27
--- include/access/nbtree.h     1999/08/08 20:24:09     1.27.2.1
***************
*** 255,260 ****
--- 255,261 ----
extern void _bt_regscan(IndexScanDesc scan);
extern void _bt_dropscan(IndexScanDesc scan);
extern void _bt_adjscans(Relation rel, ItemPointer tid);
+ extern void AtEOXact_nbtree(void);

/*
* prototypes for functions in nbtsearch.c
Index: backend/access/nbtree/nbtscan.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/access/nbtree/nbtscan.c,v
retrieving revision 1.23.2.1
retrieving revision 1.23.2.2
diff -c -r1.23.2.1 -r1.23.2.2
*** backend/access/nbtree/nbtscan.c     1999/08/02 05:24:41     1.23.2.1
--- backend/access/nbtree/nbtscan.c     1999/08/08 20:24:10     1.23.2.2
***************
*** 42,47 ****
--- 42,69 ----
static BTScanList BTScans = (BTScanList) NULL;

static void _bt_scandel(IndexScanDesc scan, BlockNumber blkno, OffsetNumber offno);
+ 
+ /*
+  * AtEOXact_nbtree() --- clean up nbtree subsystem at xact abort or commit.
+  *
+  * This is here because it needs to touch this module's static var BTScans.
+  */
+ void
+ AtEOXact_nbtree(void)
+ {
+       /* Note: these actions should only be necessary during xact abort;
+        * but they can't hurt during a commit.
+        */
+ 
+       /* Reset the active-scans list to empty.
+        * We do not need to free the list elements, because they're all
+        * palloc()'d, so they'll go away at end of transaction anyway.
+        */
+       BTScans = NULL;
+ 
+       /* If we were building a btree, we ain't anymore. */
+       BuildingBtree = false;
+ }

/*
*    _bt_regscan() -- register a new scan.
Index: backend/access/transam/transam.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/access/transam/transam.c,v
retrieving revision 1.27.2.1
retrieving revision 1.27.2.2
diff -c -r1.27.2.1 -r1.27.2.2
*** backend/access/transam/transam.c    1999/08/02 05:56:46     1.27.2.1
--- backend/access/transam/transam.c    1999/08/08 20:24:12     1.27.2.2
***************
*** 20,26 ****

#include "access/heapam.h"
#include "catalog/catname.h"
- #include "commands/vacuum.h"

static int    RecoveryCheckingEnabled(void);
static void TransRecover(Relation logRelation);
--- 20,25 ----
***************
*** 83,95 ****
*/
extern int    OidGenLockId;

- /* ----------------
- * globals that must be reset at abort
- * ----------------
- */
- extern bool BuildingBtree;

- 
/* ----------------
*            recovery checking accessors
* ----------------
--- 82,88 ----
***************
*** 568,578 ****
void
TransactionIdAbort(TransactionId transactionId)
{
-       BuildingBtree = false;
- 
-       if (VacuumRunning)
-               vc_abort();
- 
if (AMI_OVERRIDE)
return;

--- 561,566 ----
Index: backend/access/transam/xact.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/access/transam/xact.c,v
retrieving revision 1.42.2.1
retrieving revision 1.42.2.2
diff -c -r1.42.2.1 -r1.42.2.2
*** backend/access/transam/xact.c       1999/08/02 05:56:48     1.42.2.1
--- backend/access/transam/xact.c       1999/08/08 20:24:12     1.42.2.2
***************
*** 144,152 ****
--- 144,154 ----
*/
#include "postgres.h"

+ #include "access/nbtree.h"
#include "catalog/heap.h"
#include "commands/async.h"
#include "commands/sequence.h"
+ #include "commands/vacuum.h"
#include "libpq/be-fsstubs.h"
#include "storage/proc.h"
#include "utils/inval.h"
***************
*** 952,957 ****
--- 954,960 ----
}

RelationPurgeLocalRelation(true);
+       AtEOXact_nbtree();
AtCommit_Cache();
AtCommit_Locks();
AtCommit_Memory();
***************
*** 1013,1021 ****
--- 1016,1027 ----
AtAbort_Notify();
CloseSequences();
AtEOXact_portals();
+       if (VacuumRunning)
+               vc_abort();
RecordTransactionAbort();
RelationPurgeLocalRelation(false);
DestroyNoNameRels();
+       AtEOXact_nbtree();
AtAbort_Cache();
AtAbort_Locks();
AtAbort_Memory();

-- 
  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 Mon Sep 27 15:32:06 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 PAA17700
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 15:31:52 -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 PAA12410;
Mon, 27 Sep 1999 15:26:08 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271926.PAA12410@candle.pha.pa.us>
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions
In-Reply-To: <Pine.GSO.3.96.SK.990927215550.8336p-100000@ra> from Oleg
Bartunov
at "Sep 27, 1999 09:59:50 pm"
To: Oleg Bartunov <oleg@sai.msu.su>
Date: Mon, 27 Sep 1999 15:26:08 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

this select produces error message:
test=> select test2(NULL);
ERROR: typeidTypeRelid: Invalid type - oid = 0

Not sure how to pass NULL's into functions.

test2:
CREATE FUNCTION test2 (int4) RETURNS int4 AS '
Declare
keyval Alias For $1;
cnt int4;
Begin
Update hits set count = count +1 where msg_id = keyval;
return cnt;
End;
' LANGUAGE 'plpgsql';

When I do manually update
Update hits set count = count +1 where msg_id = NULL;
it works fine. What's the problem ?

Regards,

Oleg
test=> \d hits
Table    = hits
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                | Length|
+----------------------------------+----------------------------------+-------+
| msg_id                           | int4                             |     4 |
| count                            | int4                             |     4 |
+----------------------------------+----------------------------------+-------+
test=> select version();
version                                                           
------------------------------------------------------------------
PostgreSQL 6.5.2 on i586-pc-linux-gnulibc1, compiled by gcc 2.95.1
(1 row)
_____________________________________________________________
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

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

-- 
  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 Mon Sep 27 15:33:10 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA17862
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 15:33:07 -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 PAA12551;
Mon, 27 Sep 1999 15:31:53 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271931.PAA12551@candle.pha.pa.us>
Subject: Re: [HACKERS] RI status report #1
In-Reply-To: <m11Vfix-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Sep 27, 1999 08:42:07 pm"
To: Jan Wieck <wieck@debis.com>
Date: Mon, 27 Sep 1999 15:31:53 -0400 (EDT)
CC: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Most of the activities after "Second" next step can be
done parallel. I'll commit my changes after that, because
then I'm able to run a full test of deferred constraints
to be sure I'm really on the right track. All co-
developers can join then using the CURRENT tree.

Any comments?

Great. How's that for a comment? :-)

-- 
  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 Mon Sep 27 15:44:12 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA19432
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 15:43:15 -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 PAA12912;
Mon, 27 Sep 1999 15:41:43 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271941.PAA12912@candle.pha.pa.us>
Subject: Re: [HACKERS] Files ...
In-Reply-To: <XFMail.990826204314.dms@wplus.net> from Dmitry Samersoff at "Aug
26, 1999 08:43:14 pm"
To: Dmitry Samersoff <dms@wplus.net>
Date: Mon, 27 Sep 1999 15:41:43 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

These look awful custom to me. Not sure how to integrate them.

[Charset KOI8-R unsupported, filtering to ASCII...]

This is three files IMHO useful for community

1. SysV start script for postgres, also can be used under freebsd
(see below)
2. simple utility su_postgres, it make su to user postgres whether or not
shell for it specified, is better than su for security reason
3. configure/configure.in checking for ps style
BSD ps -ax or SysV ps -e

Probably, there is the reason to include it (after some improvement0 into
distribution.

---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

============================================================================
#ident "@(#)/etc/init.d/pgsql 1.0 26/08/99 dms"

PG_HOME="/usr/local/pgsql"
PG_DATA="$PG_HOME/data"
UDS="/tmp/.s.PGSQL.5432"

PS="@PS@"
GREP="@GREP@"

case "$1" in
'start')
# If no postgres run, remove UDS and start postgres.
pid=
set -- `$PS | $GREP postmaster | $GREP -v grep`
[ $? -eq 0 ] && pid=$1

if [ -z "$pid" ]; then
rm -f "$UDS"
$PG_HOME/bin/su_postgres "$PG_HOME/bin/postmaster -D $PG_DATA
-b $PG_HOME/bin/postgres -i -S -o -F &"
echo "Postgres started"
else
echo "Postmaster already run with pid $pid"
fi
;;
'stop')
pid=
set -- `$PS | $GREP postmaster | $GREP -v grep`
[ $? -eq 0 ] && pid=$1

if [ -z "$pid" ]; then
echo "Postgres not run"
else
echo "Stoping postmaster with pid $pid"
kill $pid
fi

;;
*)
echo "USAGE: $0 {start | stop}"
;;
esac

Content-Description: pg_run.tar.gz

[Attachment, skipping...]

-- 
  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 Mon Sep 27 15:56:13 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA21126;
Mon, 27 Sep 1999 15:55:53 -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 PAA13210;
Mon, 27 Sep 1999 15:55:00 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909271955.PAA13210@candle.pha.pa.us>
Subject: Re: [HACKERS] IPC on win32 - additions for 6.5.2 and current trees
In-Reply-To:
<2E7F82FAC1FCD2118E1500A024B3BF907DED62@exchange.mmp.plzen-city.cz>
from Horak Daniel at "Aug 30, 1999 02:15:09 pm"
To: Horak Daniel <horak@mmp.plzen-city.cz>
Date: Mon, 27 Sep 1999 15:55:00 -0400 (EDT)
CC: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgresql.org>,
"'pgsql-patches@postgresql.org'" <pgsql-patches@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM938462100-12624-0_
Content-Transfer-Encoding: 7bit

[Charset ISO-8859-2 unsupported, filtering to ASCII...]

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

Hi,

please add the file ipc.patch (patch for the cygipc library) into src/win32
directory and apply the patch for README.NT (readme.patch). I think it
should go into both the 6.5.2 and current trees.

I have no reaction from the author of the cygipc library yet, so it will be
better to include the patch into the sources of PostgreSQL

Dan

I am attaching our current README.NT file. I have done some cleanups
and appended the patch to the README file.

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

--ELM938462100-12624-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/pgtop/doc/README.NT"
Content-Transfer-Encoding: 7bit

From: "Joost Kraaijeveld" <JKraaijeveld@askesis.nl>
To: "Pgsql-Ports@Postgresql. Org" <pgsql-ports@postgreSQL.org>
Subject: RE: [PORTS] Re: psql under win32
Date: Wed, 21 Apr 1999 07:07:47 +0200
Message-ID: <000001be8bb4$e59b0ab0$0300a8c0@abraracourcix.askesis.nl>
MIME-Version: 1.0

Installing PostgreSQL on NT:

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

It can be done by done by typing configure, make and make install.

1. Install the Cygwin package
2. Update to EGCS 1.1.2
(This may be optional.)

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

OPTIONAL

1. Install the Andy Piper Tools (http://www.xemacs.freeserve.co.uk/)
(This may be optional.)

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

CYGWIN32 INSTALLATION

1. Download the Cygwin32 IPC Package by Ludovic LANGE
http://www.multione.capgemini.fr:80/tools/pack_ipc/current.tar.gz
2. Untar the package and follow the readme instructions.
3. Apply the patch from the file.
4. I tested 1.03.
5. I used the \cygwin-b20\h-i568-cygwin32\i586-cygwin32\lib and
\cygwin-b20\h-i568-cygwin32\i586-cygwin32\include\sys instead of the
/usr/local/lib and usr/local/include/sys.

NOTE:
Also, the cygnus-bindir has to be placed in the path before the
NT-directories, because the sort.exe has to be taken for cygnus, not
NT.

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

POSTGRESQL INSTALL WITH NT SPECIFICS

1. Download the current version of PostgreSQL.
2. Untar the package.
3. Copy the files from \pgsql\src\win32 according to the readme file.
4. Edit \pgsql\src\template\cygwin32 if needed (I had to adjust the YFLAGS
path).
5. ./configure
6. make
7. create the directory /usr/local/pgsql manually: the mkdir cannot create a
directory 2 levels deep in one step.
8. make install
9. cd /usr/lical/pgsql/doc
10. make install
11. Set the environmental data
12. Initdb --username=jkr (do not run this command as administrator)

13. Open a new Cygwin command prompt
14. Start "ipc-deamon&" (background proces)
15. Start "postmaster -i 2>&1 > /tmp/postgres.log &" (background proces)
16. Start "tail -f /tmp/postgres.log" to see the messages

17. cd /usr/src/pgsql/src/test/regress
18. make all runtest

All test should be run, allthought the latest snapshot I tested (18-4)
appears to have some problems with locking.

NOTE:
By default, PostgreSQL clients like psql communicate using unix domain
sockets, which don't work on NT. Start the postmaster with -i, and
when connecting to the database from a client, set the PGHOST
environment variable to 'localhost' or supply the hostname on the
command line.

Joost

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

FIX FOR POSTGRESQL FREEZING ON NT MACHINES - EVERYONE SHOULD APPLY THIS PATCH

From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Horak Daniel" <horak@mmp.plzen-city.cz>, "'Tom Lane'" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] backend freezeing on win32 fixed (I hope ;-) )
Date: Wed, 18 Aug 1999 08:45:28 +0900
Message-ID: <000301bee90a$95d40f00$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
In-reply-to: <2E7F82FAC1FCD2118E1500A024B3BF907DED3F@exchange.mmp.plzen-city.cz>
Importance: Normal
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Horak Daniel
Sent: Tuesday, August 17, 1999 9:06 PM
To: 'Tom Lane'
Cc: 'pgsql-hackers@postgreSQL.org'
Subject: RE: [HACKERS] backend freezeing on win32 fixed (I hope ;-) )

Yutaka Tanida [yutaka@marin.or.jp] and I have examined IPC
library.

We found that postmaster doesn't call exec() after fork() since v6.4.

The value of static/extern variables which cygipc library holds may
be different from their initial values when postmaster fork()s child
backend processes.

I made the following patch for cygipc library on trial.
This patch was effective for Yutaka's test case.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

*** sem.c.orig	Tue Dec 01 00:16:25 1998
--- sem.c	Tue Aug 17 13:22:06 1999
***************
*** 58,63 ****
--- 58,78 ----
  static int		  GFirstSem	 = 0;		/*PCPC*/
  static int		  GFdSem	    ;		/*PCPC*/

+ static pid_t	GProcessId = 0;
+
+ static void	init_globals(void)
+ {
+ 	pid_t pid;
+
+ 	if (pid=getpid(), pid != GProcessId)
+ 	{
+ 		GFirstSem = 0;
+ 		used_sems = used_semids = max_semid = 0;
+ 		sem_seq = 0;
+ 		GProcessId = pid;
+ 	}
+ }
+
  /************************************************************************/
  /* Demande d'acces a la zone partagee de gestion des semaphores		*/
  /************************************************************************/
***************
*** 77,82 ****
--- 92,98 ----
  {
      int LRet ;

+ 	init_globals();
      if( GFirstSem == 0 )
      {
  	if( IsGSemSemExist() )
*** shm.c.orig	Tue Dec 01 01:04:57 1998
--- shm.c	Tue Aug 17 13:22:27 1999
***************
*** 59,64 ****
--- 59,81 ----
  static int		  GFirstShm	 = 0;		/*PCPC*/
  static int		  GFdShm	    ;		/*PCPC*/

+ /*****************************************/
+ /*	Initialization of static variables   */
+ /*****************************************/
+ static pid_t GProcessId = 0;
+ static void init_globals(void)
+ {
+ 	pid_t pid;
+
+ 	if (pid=getpid(), pid != GProcessId)
+ 	{
+ 		GFirstShm = 0;
+ 		shm_rss = shm_swp = max_shmid = 0;
+ 		shm_seq = 0;
+ 		GProcessId = pid;
+ 	}
+ }
+
  /************************************************************************/
  /* Demande d'acces a la zone partagee de gestion des shm		*/
  /************************************************************************/
***************
*** 82,87 ****
--- 99,105 ----
  {
   int LRet ;

+  init_globals();
   if( GFirstShm == 0 )
   {
    if( IsGSemShmExist() )
*** msg.c.orig	Tue Dec 01 00:16:09 1998
--- msg.c	Tue Aug 17 13:20:04 1999
***************
*** 57,62 ****
--- 57,77 ----
  static int		  GFirstMsg	 = 0;		/*PCPC*/
  static int		  GFdMsg	    ;		/*PCPC*/

+ /*****************************************/
+ /*	Initialization of static variables   */
+ /*****************************************/
+ static pid_t GProcessId = 0;
+ static void init_globals(void)
+ {
+ 	pid_t pid;
+
+ 	if (pid=getpid(), pid != GProcessId)
+ 	{
+ 		GFirstMsg = 0;
+ 		msgbytes = msghdrs = msg_seq = used_queues = max_msqid = 0;
+ 		GProcessId = pid;
+ 	}
+ }
  /************************************************************************/
  /* Demande d'acces a la zone partagee de gestion des semaphores		*/
  /************************************************************************/
***************
*** 79,84 ****
--- 94,100 ----
  {
   int LRet ;

+ init_globals();
if( GFirstMsg == 0 )
{
if( IsGSemMsgExist() )

--ELM938462100-12624-0_

--ELM938462100-12624-0_--

From bouncefilter Mon Sep 27 16:32:30 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA26416;
Mon, 27 Sep 1999 16:31:48 -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 QAA16314;
Mon, 27 Sep 1999 16:30:35 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909272030.QAA16314@candle.pha.pa.us>
Subject: Re: new patches
In-Reply-To: <199906121842.UAA05475@nikita.wizard.net> from Massimo Dal Zotto
at "Jun 12, 1999 08:42:24 pm"
To: Massimo Dal Zotto <dz@cs.unitn.it>
Date: Mon, 27 Sep 1999 16:30:35 -0400 (EDT)
CC: PostgreSQL Hackers <hackers@postgreSQL.org>,
Pgsql Patches <pgsql-patches@postgreSQL.org>, vadim@krs.ru
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Two small patches:

1) make default NBuffers = DEF_MAXBACKENDS*2 as required by check in
PostmasterMain().

Seems this line is gone in the current sources.

2) check for QueryCancel in the copy command. Maybe we should do the
same in vacuum command (Vadim?).

Applied.

*** src/include/miscadmin.h.orig	Wed May 26 09:06:39 1999
--- src/include/miscadmin.h	Sat Jun 12 20:01:10 1999
***************
*** 106,112 ****
*		default number of buffers in buffer pool
*
*/
! #define NDBUFS 64

/*****************************************************************************
*	  pdir.h --																 *
--- 106,112 ----
*		default number of buffers in buffer pool
*
*/
! #define NDBUFS (2*DEF_MAXBACKENDS)

/*****************************************************************************
*	  pdir.h --																 *
*** src/backend/commands/copy.c.orig	Sun May 30 09:01:01 1999
--- src/backend/commands/copy.c	Sat Jun 12 20:23:51 1999
***************
*** 18,23 ****
--- 18,24 ----

#include <access/heapam.h>
#include <tcop/dest.h>
+ #include "tcop/tcopprot.h"
#include <fmgr.h>
#include <miscadmin.h>
#include <utils/builtins.h>
***************
*** 253,259 ****
*/
if (file_opened)
{
! FreeFile(fp);
file_opened = false;
}

--- 254,265 ----
*/
if (file_opened)
{
! 		/*
! 		 * This is unnecessary: files are closed automatically by
! 		 * AtEOXact_Files() at transaction abort. -- dz
! 		 */
! 
! 		/* FreeFile(fp); */
file_opened = false;
}

***************
*** 419,424 ****
--- 425,432 ----

while (HeapTupleIsValid(tuple = heap_getnext(scandesc, 0)))
{
+ 		if (QueryCancel)
+ 			CancelQuery();

if (oids && !binary)
{
***************
*** 691,696 ****
--- 699,707 ----
lineno = 0;
while (!done)
{
+ 		if (QueryCancel)
+ 			CancelQuery();
+ 
if (!binary)
{
#ifdef COPY_PATCH

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

-- 
  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 Mon Sep 27 16:33:07 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA26507;
Mon, 27 Sep 1999 16:32:30 -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 QAA16383;
Mon, 27 Sep 1999 16:31:34 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909272031.QAA16383@candle.pha.pa.us>
Subject: Re: patch for large queries
In-Reply-To: <199906111749.TAA23015@nikita.wizard.net> from Massimo Dal Zotto
at "Jun 11, 1999 07:49:19 pm"
To: Massimo Dal Zotto <dz@cs.unitn.it>
Date: Mon, 27 Sep 1999 16:31:34 -0400 (EDT)
CC: PostgreSQL Hackers <hackers@postgreSQL.org>,
Pgsql Patches <pgsql-patches@postgreSQL.org>, tgl@sss.pgh.pa.us
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I think it was agreed that this patch was too ugly to apply. We have
addressed the aggregate memory case already.

Hi Hackers,

I don't like last minute patches before the final freeze, but I believe that
this one could be useful for people experiencing out-of-memory crashes while
executing queries which retrieve or use a very large number of tuples.

The problem happens when storage is allocated for functions results used in
a large query, for example:

select upper(name) from big_table;
select big_table.array[1] from big_table;
select count(upper(name)) from big_table;

This patch is a dirty hack that fixes the out-of-memory problem for the most
common cases, like the above ones. It is not the final solution for the
problem but it can work for some people, so I'm posting it.

The patch should be safe because all changes are under #ifdef. Furthermore
the feature can be enabled or disabled at runtime by the `free_tuple_memory'
options in the pg_options file. The option is disabled by default and must
be explicitly enabled at runtime to have any effect.

To enable the patch add the follwing line to Makefile.custom:

CUSTOM_COPT += -DFREE_TUPLE_MEMORY

To enable the option at runtime add the following line to pg_option:

free_tuple_memory=1

Here is the patch:

*** src/include/utils/portal.h.orig	Wed May 26 09:07:16 1999
--- src/include/utils/portal.h	Fri Jun 11 18:06:07 1999
***************
*** 80,85 ****
--- 80,89 ----
extern PortalVariableMemory PortalGetVariableMemory(Portal portal);
extern PortalHeapMemory PortalGetHeapMemory(Portal portal);

+ #ifdef FREE_TUPLE_MEMORY
+ bool   PortalHeapMemoryIsValid(MemoryContext context, Pointer pointer);
+ #endif
+ 
/* estimate of the maximum number of open portals a user would have,
* used in initially sizing the PortalHashTable in	EnablePortalManager()
*/
*** src/backend/utils/mmgr/portalmem.c.orig	Wed May 26 09:06:02 1999
--- src/backend/utils/mmgr/portalmem.c	Fri Jun 11 18:06:28 1999
***************
*** 289,294 ****
--- 289,312 ----
}
}

+ #ifdef FREE_TUPLE_MEMORY
+ /*
+  * PortalHeapMemoryIsValid --
+  *
+  * Check if a pointer is allocated in a memory context.
+  *
+  */
+ bool
+ PortalHeapMemoryIsValid(MemoryContext context, Pointer pointer)
+ {
+ 	HeapMemoryBlock block = HEAPMEMBLOCK((PortalHeapMemory) context);
+ 
+ 	AssertState(PointerIsValid(block));
+ 
+ 	return (AllocSetContains(&block->setData, pointer));
+ }
+ #endif
+ 
/* ----------------
*		PortalHeapMemoryRealloc
* ----------------
*** src/include/utils/trace.h.orig	Sat Jun  5 09:00:40 1999
--- src/include/utils/trace.h	Fri Jun 11 19:01:30 1999
***************
*** 64,69 ****
--- 64,72 ----
OPT_SYSLOG,					/* use syslog for error messages */
OPT_HOSTLOOKUP,				/* enable hostname lookup in ps_status */
OPT_SHOWPORTNUMBER,			/* show port number in ps_status */
+ #ifdef FREE_TUPLE_MEMORY
+ 	OPT_FREE_TUPLE_MEMORY,		/* try to pfree memory for each tuple */
+ #endif

NUM_PG_OPTIONS /* must be the last item of enum */
};
***************
*** 83,91 ****
#endif /* TRACE_H */

/*
!  * Local variables:
!  *	tab-width: 4
!  *	c-indent-level: 4
!  *	c-basic-offset: 4
* End:
*/
--- 86,94 ----
#endif	 /* TRACE_H */

/*
!  * Local Variables:
!  *  tab-width: 4
!  *  c-indent-level: 4
!  *  c-basic-offset: 4
* End:
*/
*** src/backend/utils/misc/trace.c.orig	Sat Jun  5 09:00:37 1999
--- src/backend/utils/misc/trace.c	Fri Jun 11 19:01:31 1999
***************
*** 73,78 ****
--- 73,81 ----
"syslog",					/* use syslog for error messages */
"hostlookup",				/* enable hostname lookup in ps_status */
"showportnumber",			/* show port number in ps_status */
+ #ifdef FREE_TUPLE_MEMORY
+ 	"free_tuple_memory",		/* try to pfree memory for each tuple */
+ #endif

/* NUM_PG_OPTIONS */ /* must be the last item of enum */
};
***************
*** 404,412 ****
}

/*
!  * Local variables:
!  *	tab-width: 4
!  *	c-indent-level: 4
!  *	c-basic-offset: 4
* End:
*/
--- 407,415 ----
}

/*
!  * Local Variables:
!  *  tab-width: 4
!  *  c-indent-level: 4
!  *  c-basic-offset: 4
* End:
*/
*** src/backend/access/common/heaptuple.c.orig	Wed May 26 09:01:59 1999
--- src/backend/access/common/heaptuple.c	Fri Jun 11 19:08:33 1999
***************
*** 27,32 ****
--- 27,37 ----
#include <storage/bufpage.h>
#include <utils/memutils.h>

+ #ifdef FREE_TUPLE_MEMORY
+ #include <utils/portal.h>
+ #include <utils/trace.h>
+ #endif
+ 
#ifndef HAVE_MEMMOVE
#include <regex/utils.h>
#else
***************
*** 93,98 ****
--- 98,106 ----
int			i;
int			numberOfAttributes = tupleDesc->natts;
Form_pg_attribute *att = tupleDesc->attrs;
+ #ifdef FREE_TUPLE_MEMORY
+ 	bool		free_tuple_memory = pg_options[OPT_FREE_TUPLE_MEMORY];
+ #endif

if (bit != NULL)
{
***************
*** 131,136 ****
--- 139,152 ----
*infomask |= HEAP_HASVARLENA;
data_length = VARSIZE(DatumGetPointer(value[i]));
memmove(data, DatumGetPointer(value[i]), data_length);
+ #ifdef FREE_TUPLE_MEMORY
+ 				/* try to pfree value[i] - dz */
+ 				if (free_tuple_memory &&
+ 					PortalHeapMemoryIsValid(CurrentMemoryContext,
+ 											(Pointer) value[i])) {
+ 					pfree(value[i]);
+ 				}
+ #endif
break;
case sizeof(char):
*data = att[i]->attbyval ?
***************
*** 147,154 ****
*((int32 *) value[i]));
break;
default:
! 				memmove(data, DatumGetPointer(value[i]),
! 						att[i]->attlen);
break;
}
data = (char *) att_addlength((long) data, att[i]->attlen, value[i]);
--- 163,177 ----
*((int32 *) value[i]));
break;
default:
! 				memmove(data, DatumGetPointer(value[i]), att[i]->attlen);
! #ifdef FREE_TUPLE_MEMORY
! 				/* try to pfree value[i] - dz */
! 				if (free_tuple_memory &&
! 					PortalHeapMemoryIsValid(CurrentMemoryContext,
! 											(Pointer) value[i])) {
! 					pfree(value[i]);
! 				}
! #endif
break;
}
data = (char *) att_addlength((long) data, att[i]->attlen, value[i]);
*** src/backend/executor/nodeAgg.c.orig	Wed May 26 09:02:57 1999
--- src/backend/executor/nodeAgg.c	Fri Jun 11 19:10:27 1999
***************
*** 31,36 ****
--- 31,41 ----
#include "utils/syscache.h"
#include "optimizer/clauses.h"

+ #ifdef FREE_TUPLE_MEMORY
+ #include <utils/portal.h>
+ #include <utils/trace.h>
+ #endif
+
/*
* AggFuncInfo -
* keeps the transition functions information around
***************
*** 113,119 ****
isNull1 = FALSE,
isNull2 = FALSE;
bool qual_result;
!

/* ---------------------
*	get state info from node
--- 118,126 ----
isNull1 = FALSE,
isNull2 = FALSE;
bool		qual_result;
! #ifdef FREE_TUPLE_MEMORY
! 	bool		free_tuple_memory = pg_options[OPT_FREE_TUPLE_MEMORY];
! #endif

/* ---------------------
*	get state info from node
***************
*** 241,246 ****
--- 248,257 ----
for (;;)
{
TupleTableSlot *outerslot;
+ #ifdef FREE_TUPLE_MEMORY
+ 			Oid				valueType;
+ 			bool			isByValue = 0;
+ #endif

isNull = isNull1 = isNull2 = 0;
outerslot = ExecProcNode(outerPlan, (Plan *) node);
***************
*** 293,298 ****
--- 304,334 ----
newVal = ExecEvalExpr(aggref->target, econtext,
&isNull, &isDone);
}
+ #ifdef FREE_TUPLE_MEMORY
+ 				if (free_tuple_memory) {
+ 					switch (nodeTag(aggref->target)) {
+ 					case T_Const:
+ 						isByValue = ((Const*) (aggref->target))->constbyval;
+ 						break;
+ 					case T_Var:
+ 						valueType = ((Var*) (aggref->target))->vartype;
+ 						isByValue = typeByVal(typeidType(valueType));
+ 						break;
+ 					case T_Array:
+ 						isByValue = ((Array*)(aggref->target))->arrayelembyval;
+ 						break;
+ 					case T_ArrayRef:
+ 						isByValue =((ArrayRef*)(aggref->target))->refelembyval;
+ 						break;
+ 					case T_Expr:
+ 						valueType = ((Expr*) (aggref->target))->typeOid;
+ 						isByValue = typeByVal(typeidType(valueType));
+ 						break;
+ 					default:
+ 						break;
+ 					}
+ 				}
+ #endif

if (isNull && !aggref->usenulls)
continue;	/* ignore this tuple for this agg */
***************
*** 353,358 ****
--- 389,404 ----
(FmgrValues *) args, &isNull2);
Assert(!isNull2);
}
+ 
+ #ifdef FREE_TUPLE_MEMORY
+ 				/* try to pfree newVal if not isByValue - dz */
+ 				if (free_tuple_memory && !isByValue && 
+ 					PortalHeapMemoryIsValid(CurrentMemoryContext,
+ 											(Pointer) newVal))
+ 				{
+ 					pfree(newVal);
+ 				}
+ #endif
}

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

-- 
  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 Mon Sep 27 16:34:06 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA26653
for <hackers@postgreSQL.org>; Mon, 27 Sep 1999 16:33:26 -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 QAA16407;
Mon, 27 Sep 1999 16:32:33 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909272032.QAA16407@candle.pha.pa.us>
Subject: Re: new patches...
In-Reply-To: <199906142032.WAA20907@nikita.wizard.net> from Massimo Dal Zotto
at "Jun 14, 1999 10:32:50 pm"
To: Massimo Dal Zotto <dz@cs.unitn.it>
Date: Mon, 27 Sep 1999 16:32:33 -0400 (EDT)
CC: PostgreSQL Hackers <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied. Thanks.

Hi,

I have added the pg_options variable to the SET command. It can be executed
only by the superuser and is intended mainly as a debugging aid.
I have also moved the disableFsync variable to the pg_options array, so it
can now be set in the pg_options file or interactively with the commands:

SET pg_options to 'nofsinc=1';
SET pg_options to 'nofsinc=0';

There are obviously also the SHOW and RESET pg_options commands.

*** src/backend/commands/variable.c.orig	Wed May 26 09:02:48 1999
--- src/backend/commands/variable.c	Mon Jun 14 20:45:58 1999
***************
*** 15,20 ****
--- 15,22 ----
#include "commands/variable.h"
#include "utils/builtins.h"
#include "optimizer/internal.h"
+ #include "utils/trace.h"
+ #include "catalog/pg_shadow.h"
#include "access/xact.h"
#ifdef MULTIBYTE
#include "mb/pg_wchar.h"
***************
*** 581,589 ****
ExecutorLimit(ALL_TUPLES);
return (TRUE);
}
- 
#endif

/*-----------------------------------------------------------------------*/

struct VariableParsers
--- 583,622 ----
ExecutorLimit(ALL_TUPLES);
return (TRUE);
}
#endif

+ /*
+  *
+  * Pg_options
+  *
+  */
+ static bool
+ parse_pg_options(const char *value)
+ {
+ 	if (!superuser()) {
+ 		elog(ERROR, "Only users with Postgres superuser can set pg_options");
+ 	}
+ 	parse_options((char *) value, TRUE);
+ 	return (TRUE);
+ }
+ 
+ static bool
+ show_pg_options(void)
+ {
+ 	show_options();
+ 	return (TRUE);
+ }
+ 
+ static bool
+ reset_pg_options(void)
+ {
+ 	if (!superuser()) {
+ 		elog(ERROR, "Only users with Postgres superuser can set pg_options");
+ 	}
+ 	read_pg_options(0);
+ 	return (TRUE);
+ }
+ 
/*-----------------------------------------------------------------------*/

struct VariableParsers
***************
*** 629,634 ****
--- 662,670 ----
"query_limit", parse_query_limit, show_query_limit, reset_query_limit
},
#endif
+ 	{
+ 		"pg_options", parse_pg_options, show_pg_options, reset_pg_options
+ 	},
{
NULL, NULL, NULL, NULL
}
*** src/backend/utils/init/globals.c.orig	Wed May 26 09:05:49 1999
--- src/backend/utils/init/globals.c	Mon Jun 14 20:56:34 1999
***************
*** 82,88 ****
* malloc? XXX */
char		FloatFormat[20] = "%f";

! bool disableFsync = false;
bool allowSystemTableMods = false;
int SortMem = 512;

--- 82,88 ----
* malloc? XXX */
char		FloatFormat[20] = "%f";

! /* bool disableFsync = false; */
bool allowSystemTableMods = false;
int SortMem = 512;

*** src/include/miscadmin.h.orig	Wed May 26 09:06:39 1999
--- src/include/miscadmin.h	Mon Jun 14 20:01:27 1999
***************
*** 22,27 ****
--- 22,29 ----
#ifndef MISCADMIN_H
#define MISCADMIN_H

+ #include "utils/trace.h"
+
/*****************************************************************************
* globals.h -- *
*****************************************************************************/
***************
*** 93,99 ****
extern char FloatFormat[];
extern char DateFormat[];

! extern bool disableFsync;
extern bool allowSystemTableMods;
extern int SortMem;

--- 95,103 ----
extern char FloatFormat[];
extern char DateFormat[];

! /* extern bool disableFsync; */
! #define disableFsync pg_options[OPT_NOFSYNC]
!
extern bool allowSystemTableMods;
extern int SortMem;

*** src/bin/psql/psqlHelp.h.orig	Fri Jun  4 09:00:17 1999
--- src/bin/psql/psqlHelp.h	Mon Jun 14 20:17:45 1999
***************
*** 297,303 ****
"set run-time environment back to default",
"\
\tRESET DATESTYLE|COST_HEAP|COST_INDEX|GEQO|KSQO|QUERY_LIMIT|\n\
! TIMEZONE|XACTISOLEVEL|CLIENT_ENCODING|SERVER_ENCODING"},
{"revoke",
"revoke access control from a user or group",
"\
--- 297,303 ----
"set run-time environment back to default",
"\
\tRESET DATESTYLE|COST_HEAP|COST_INDEX|GEQO|KSQO|QUERY_LIMIT|\n\
! \t  TIMEZONE|XACTISOLEVEL|CLIENT_ENCODING|SERVER_ENCODING|PG_OPTIONS"},
{"revoke",
"revoke access control from a user or group",
"\
***************
*** 331,336 ****
--- 331,337 ----
\tSET KSQO TO 'ON'|'OFF'\n\
\tSET QUERY_LIMIT TO #\n\
\tSET TIMEZONE TO 'value'\n\
+ \tSET PG_OPTIONS TO 'value'\n\
\tSET TRANSACTION ISOLATION LEVEL 'SERIALIZABLE'|'READ COMMITTED'\n\
\tSET CLIENT_ENCODING|NAMES TO 'EUC_JP'|'SJIS'|'EUC_CN'|'EUC_KR'|'EUC_TW'|\n\
\t  'BIG5'|'MULE_INTERNAL'|'LATIN1'|'LATIN2'|'LATIN3'|'LATIN4'|'LATIN5'|\n\
***************
*** 342,348 ****
"show current run-time environment",
"\
\tSHOW DATESTYLE|COST_HEAP|COST_INDEX|GEQO|KSQO|QUERY_LIMIT|\n\
! TIMEZONE|XACTISOLEVEL|CLIENT_ENCODING|SERVER_ENCODING"},
{"unlisten",
"stop listening for notification on a condition name",
"\
--- 343,349 ----
"show current run-time environment",
"\
\tSHOW DATESTYLE|COST_HEAP|COST_INDEX|GEQO|KSQO|QUERY_LIMIT|\n\
! \t  TIMEZONE|XACTISOLEVEL|CLIENT_ENCODING|SERVER_ENCODING|PG_OPTIONS"},
{"unlisten",
"stop listening for notification on a condition name",
"\
*** src/include/utils/trace.h.orig	Sat Jun 12 22:45:23 1999
--- src/include/utils/trace.h	Mon Jun 14 20:50:56 1999
***************
*** 30,38 ****
--- 30,39 ----
extern int	tprintf(int flag, const char *fmt,...);
extern int	eprintf(const char *fmt,...);
extern void write_syslog(int level, char *line);
+ extern void show_options(void);
extern void parse_options(char *str, bool secure);
extern void read_pg_options(SIGNAL_ARGS);

/*
* Trace options, used as index into pg_options.
* Must match the constants in pg_options[].
***************
*** 61,66 ****
--- 61,67 ----
TRACE_LOCKRELATION,
OPT_LOCKREADPRIORITY,		/* lock priority, see lock.c */
OPT_DEADLOCKTIMEOUT,		/* deadlock timeout, see proc.c */
+ 	OPT_NOFSYNC,				/* turn fsync off */
OPT_SYSLOG,					/* use syslog for error messages */
OPT_HOSTLOOKUP,				/* enable hostname lookup in ps_status */
OPT_SHOWPORTNUMBER,			/* show port number in ps_status */
*** src/backend/utils/misc/trace.c.orig	Sat Jun 12 22:47:32 1999
--- src/backend/utils/misc/trace.c	Mon Jun 14 20:50:06 1999
***************
*** 70,75 ****
--- 70,76 ----
"lock_debug_relid",
"lock_read_priority",		/* lock priority, see lock.c */
"deadlock_timeout",			/* deadlock timeout, see proc.c */
+ 	"nofsync",					/* turn fsync off */
"syslog",					/* use syslog for error messages */
"hostlookup",				/* enable hostname lookup in ps_status */
"showportnumber",			/* show port number in ps_status */
***************
*** 407,412 ****
--- 407,422 ----
close(fd);
}

+ void
+ show_options(void)
+ {
+ 	int		i;
+ 
+ 	for (i=0; i<NUM_PG_OPTIONS; i++) {
+ 		elog(NOTICE, "%s=%d", opt_names[i], pg_options[i]);
+ 	}
+ }
+ 
/*
* Local Variables:
*  tab-width: 4
*** src/backend/bootstrap/bootstrap.c.orig	Wed May 26 09:02:25 1999
--- src/backend/bootstrap/bootstrap.c	Mon Jun 14 20:06:00 1999
***************
*** 182,188 ****
Form_pg_attribute attrtypes[MAXATTR];	/* points to attribute info */
static char *values[MAXATTR];	/* cooresponding attribute values */
int			numattr;			/* number of attributes for cur. rel */
! extern bool disableFsync;		/* do not fsync the database */

int			DebugMode;
static GlobalMemory nogc = (GlobalMemory) NULL; /* special no-gc mem
--- 182,188 ----
Form_pg_attribute attrtypes[MAXATTR];	/* points to attribute info */
static char *values[MAXATTR];	/* cooresponding attribute values */
int			numattr;			/* number of attributes for cur. rel */
! /* extern bool disableFsync; */		/* do not fsync the database */

int DebugMode;
static GlobalMemory nogc = (GlobalMemory) NULL; /* special no-gc mem

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

-- 
  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 Mon Sep 27 16:37:06 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA27220
for <hackers@postgreSQL.org>; Mon, 27 Sep 1999 16:36:56 -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 QAA16467;
Mon, 27 Sep 1999 16:36:05 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909272036.QAA16467@candle.pha.pa.us>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-Reply-To: <199908302042.WAA19560@nikita.wizard.net> from Massimo Dal Zotto
at "Aug 30, 1999 10:42:37 pm"
To: Massimo Dal Zotto <dz@wizard.net>
Date: Mon, 27 Sep 1999 16:36:05 -0400 (EDT)
CC: PostgreSQL Hackers <hackers@postgreSQL.org>,
The Hermit Hacker <scrappy@hub.org>, tgl@sss.pgh.pa.us
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sun, 29 Aug 1999, Tom Lane wrote:

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

Are we going to release 6.5.2? If yes, then when?

Marc proposed Sept 1 (back on 8/15), and there were no objections...

And its still the date I'm planning around...So Wednesday this week :)

May I ask that the patches I submitted two months ago for 6.5.0 are applied
at least to 6.5.2?

Here is the 6.5.1 version of my patches.

I have applied these to 6.6. 6.5.* is only major bug fixes, not even
minor fixes.

I applied the contrib, copy-cancel, emacs-vars(for trace.* only), psql
readline(already applied), and set_variable (pg_options only,
query_limit was removed and I don't have agreement to re-add it.)

I skipped the tuple-freemem because someone complained it was a hack.
Hopefully we can address it properly before 6.6.

-- 
  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 Mon Sep 27 16:56:19 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 QAA29610;
Mon, 27 Sep 1999 16:56:06 -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 QAA16543;
Mon, 27 Sep 1999 16:39:40 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909272039.QAA16543@candle.pha.pa.us>
Subject: Re: bug in array contrib
In-Reply-To: <199908311501.RAA21503@nikita.wizard.net> from Massimo Dal Zotto
at "Aug 31, 1999 05:01:43 pm"
To: Massimo Dal Zotto <dz@wizard.net>
Date: Mon, 27 Sep 1999 16:39:40 -0400 (EDT)
CC: PostgreSQL Hackers <hackers@postgreSQL.org>,
Pgsql Patches <pgsql-patches@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

This shows as already applied.

Hi,

there is a bug in my array contrib. The varchar and bpchar function don't
work correctly. The following patch (for 6.5.1) fixes the problem.

*** contrib/array/array_iterator.c.orig	Sat Jun  5 21:09:35 1999
--- contrib/array/array_iterator.c	Tue Aug 31 11:22:44 1999
***************
*** 6,14 ****
* elements of the array and the value and compute a result as
* the logical OR or AND of the iteration results.
*
!  * Copyright (c) 1997, Massimo Dal Zotto <dz@cs.unitn.it>
* ported to postgreSQL 6.3.2,added oid_functions, 18.1.1999,
* Tobias Gabele <gabele@wiz.uni-kassel.de>
*/

#include <ctype.h>
--- 6,17 ----
* elements of the array and the value and compute a result as
* the logical OR or AND of the iteration results.
*
!  * Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
* ported to postgreSQL 6.3.2,added oid_functions, 18.1.1999,
* Tobias Gabele <gabele@wiz.uni-kassel.de>
+  *
+  * This software is distributed under the GNU General Public License
+  * either version 2, or (at your option) any later version.
*/

#include <ctype.h>
***************
*** 180,186 ****
int32
array_varchareq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 20,		/* varchar */
(Oid) 1070,	/* varchareq */
0,			/* logical or */
array, (Datum) value);
--- 183,189 ----
int32
array_varchareq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 1043,	/* varchar */
(Oid) 1070,	/* varchareq */
0,			/* logical or */
array, (Datum) value);
***************
*** 189,195 ****
int32
array_all_varchareq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 20,		/* varchar */
(Oid) 1070,	/* varchareq */
1,			/* logical and */
array, (Datum) value);
--- 192,198 ----
int32
array_all_varchareq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 1043,	/* varchar */
(Oid) 1070,	/* varchareq */
1,			/* logical and */
array, (Datum) value);
***************
*** 198,204 ****
int32
array_varcharregexeq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 20,		/* varchar */
(Oid) 1254,	/* textregexeq */
0,			/* logical or */
array, (Datum) value);
--- 201,207 ----
int32
array_varcharregexeq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 1043,	/* varchar */
(Oid) 1254,	/* textregexeq */
0,			/* logical or */
array, (Datum) value);
***************
*** 207,213 ****
int32
array_all_varcharregexeq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 20,		/* varchar */
(Oid) 1254,	/* textregexeq */
1,			/* logical and */
array, (Datum) value);
--- 210,216 ----
int32
array_all_varcharregexeq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 1043,	/* varchar */
(Oid) 1254,	/* textregexeq */
1,			/* logical and */
array, (Datum) value);
***************
*** 221,227 ****
int32
array_bpchareq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 20,		/* bpchar */
(Oid) 1048,	/* bpchareq */
0,			/* logical or */
array, (Datum) value);
--- 224,230 ----
int32
array_bpchareq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 1042,	/* bpchar */
(Oid) 1048,	/* bpchareq */
0,			/* logical or */
array, (Datum) value);
***************
*** 230,236 ****
int32
array_all_bpchareq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 20,		/* bpchar */
(Oid) 1048,	/* bpchareq */
1,			/* logical and */
array, (Datum) value);
--- 233,239 ----
int32
array_all_bpchareq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 1042,	/* bpchar */
(Oid) 1048,	/* bpchareq */
1,			/* logical and */
array, (Datum) value);
***************
*** 239,245 ****
int32
array_bpcharregexeq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 20,		/* bpchar */
(Oid) 1254,	/* textregexeq */
0,			/* logical or */
array, (Datum) value);
--- 242,248 ----
int32
array_bpcharregexeq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 1042,	/* bpchar */
(Oid) 1254,	/* textregexeq */
0,			/* logical or */
array, (Datum) value);
***************
*** 248,254 ****
int32
array_all_bpcharregexeq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 20,		/* bpchar */
(Oid) 1254,	/* textregexeq */
1,			/* logical and */
array, (Datum) value);
--- 251,257 ----
int32
array_all_bpcharregexeq(ArrayType *array, char *value)
{
! 	return array_iterator((Oid) 1042,	/* bpchar */
(Oid) 1254,	/* textregexeq */
1,			/* logical and */
array, (Datum) value);

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

-- 
  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 Mon Sep 27 16:56:12 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 QAA29607
for <hackers@postgreSQL.org>; Mon, 27 Sep 1999 16:56:03 -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 QAA16556;
Mon, 27 Sep 1999 16:41:08 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909272041.QAA16556@candle.pha.pa.us>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-Reply-To: <199909032027.WAA02488@nikita.wizard.net> from Massimo Dal Zotto
at "Sep 3, 1999 10:27:06 pm"
To: Massimo Dal Zotto <dz@wizard.net>
Date: Mon, 27 Sep 1999 16:41:08 -0400 (EDT)
CC: PostgreSQL Hackers <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Most objections were beacause they were submitted just before the release
date of 6.5.0. Now three months have passed.
Which were the unsafe pathes? If an unsafe patch is one that can break
some essential piece of code I would classify them in the following way:

array safe, important bug fix to my contrib

Applied.

contrib safe, changes to makefiles in my contrib

Applied.

copy-cancel-query safe, it can't break anything unless you hit ^C

Applied.

emacs-vars safe, only cosmetic changes required by emacs20

Applied.

free-tuple-mem safe, it is under #ifdef and disabled by default.
I won't recommend enabling it in a production
environment, but it could be the solution of many
headaches for some people, like my old sinval
patch.

We would rather not add this code.

psql-readline safe, it just sets a readline documented variable

Applied.

set-variable mostly safe, except the queryLimit stuff which can
be removed if you don't trust it.
The pg_options variable can be set only by the
superuser.

Applied, except query limit.

If you don't like the queryLimit stuff I can send you a new patch for the
pg_options variable only.

Removed manually. Thanks. I have been far behind in keeping up with
patches.

-- 
  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 Mon Sep 27 16:55:13 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 QAA29434
for <pgsql-hackers@hub.org>; Mon, 27 Sep 1999 16:55:00 -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 QAA16695;
Mon, 27 Sep 1999 16:49:08 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909272049.QAA16695@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: IPC on win32 - additions for 6.5.2 and current
trees
In-Reply-To: <37CB94A31ED.C8A2YUTAKA@malgate.marin.or.jp> from yutaka tanida
at "Aug 31, 1999 05:38:59 pm"
To: yutaka tanida <yutaka@marin.or.jp>
Date: Mon, 27 Sep 1999 16:49:08 -0400 (EDT)
CC: pgsql-hackers@hub.org, inoue@tpf.co.jp
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

NT folks, I assume this patch is no longer needed.

Hi,

Daniel Horak wrote:

Hi,

please add the file ipc.patch (patch for the cygipc library) into src/win32
directory and apply the patch for README.NT (readme.patch). I think it
should go into both the 6.5.2 and current trees.

I have no reaction from the author of the cygipc library yet, so it will be
better to include the patch into the sources of PostgreSQL

I propose more patch against cygipc.

Hiroshi Inoue (inoue@tpf.co.jp) found another backend freezing problem.
He also found semop() in cygipc can't decrement semaphore value
correctly (Only -1 is supported).

I create follwing patch fixes these issues.

I'm sorry for my poor English.

*** sem.c.orig_	Tue Aug 17 14:19:37 1999
--- sem.c	Tue Aug 31 16:59:49 1999
***************
*** 204,210 ****
{
CloseHandle ( LHandle ) ;
}
!     LHandle = CreateSemaphore(NULL, 0, 0x7FFFFFFF, LBuff) ;
if( LHandle == NULL )
{
printf( "Creation de Semaphore \"Sem\" impossible\n" ) ;
--- 204,210 ----
{
CloseHandle ( LHandle ) ;
}
!     LHandle = CreateSemaphore(NULL, 0, 1, LBuff) ;
if( LHandle == NULL )
{
printf( "Creation de Semaphore \"Sem\" impossible\n" ) ;
***************
*** 374,388 ****
debug_printf("do_semop : return -EACCES\n");
CYGWIN32_IPCNT_RETURN (-EACCES) ;
}
! 		    ReleaseSemaphore(LHandle, sop->sem_op, &LVal) ;
! 	    	    shareadrsem->current_nb[id].current_nb[sop->sem_num] +=
! 					sop->sem_op ;
sem_deconnect() ;
} else {
if( sop->sem_flg == IPC_NOWAIT )
{
! 			LRet = WaitForSingleObject(LHandle, 0) ;
! 			if( LRet == WAIT_TIMEOUT )
{
debug_printf("do_semop : return -EAGAIN\n");
CYGWIN32_IPCNT_RETURN (-EAGAIN) ;
--- 374,387 ----
debug_printf("do_semop : return -EACCES\n");
CYGWIN32_IPCNT_RETURN (-EACCES) ;
}
!     	    shareadrsem->current_nb[id].current_nb[sop->sem_num] +=
! 				sop->sem_op ;
sem_deconnect() ;
+ 		    ReleaseSemaphore(LHandle, 1 , &LVal) ;
} else {
if( sop->sem_flg == IPC_NOWAIT )
{
! 			if( sop->sem_op + shareadrsem->current_nb[id].current_nb[sop->sem_num] <0 )
{
debug_printf("do_semop : return -EAGAIN\n");
CYGWIN32_IPCNT_RETURN (-EAGAIN) ;
***************
*** 392,407 ****
debug_printf("do_semop : return -EACCES\n");
CYGWIN32_IPCNT_RETURN (-EACCES) ;
}
! 	    		shareadrsem->current_nb[id].current_nb[sop->sem_num] -= 1 ;
sem_deconnect() ;
} else {
! 			LRet = WaitForSingleObject(LHandle, INFINITE) ;
if (sem_connect() == 0)
{
debug_printf("do_semop : return -EACCES\n");
CYGWIN32_IPCNT_RETURN (-EACCES) ;
}
! 			    shareadrsem->current_nb[id].current_nb[sop->sem_num] -= 1 ;
sem_deconnect() ;
}
}
--- 391,408 ----
debug_printf("do_semop : return -EACCES\n");
CYGWIN32_IPCNT_RETURN (-EACCES) ;
}
! 	    		shareadrsem->current_nb[id].current_nb[sop->sem_num] += sop->sem_op;
sem_deconnect() ;
} else {
! 		    while(sop->sem_op + shareadrsem->current_nb[id].current_nb[sop->sem_num] <0)
! 				LRet = WaitForSingleObject(LHandle, INFINITE) ;
! 		    
if (sem_connect() == 0)
{
debug_printf("do_semop : return -EACCES\n");
CYGWIN32_IPCNT_RETURN (-EACCES) ;
}
! 			    shareadrsem->current_nb[id].current_nb[sop->sem_num] += sop->sem_op ;
sem_deconnect() ;
}
}
***************
*** 452,458 ****
char LBuff[100] ;
HANDLE LHandle ;
long LPrevious ;
- 	int LIndex;

debug_printf("semctl : semid=%X semnum=%X cmd=0x%02X arg=%p\n",semid,semnum,cmd,arg);
if (semid < 0 || semnum < 0 || cmd < 0)
--- 453,458 ----
***************
*** 585,606 ****
if( LHandle != NULL )
{
if( arg.val > shareadrsem->current_nb[id].current_nb[semnum] )
! 		    {
! 			ReleaseSemaphore(LHandle,
! 			arg.val-shareadrsem->current_nb[id].current_nb[semnum],
! 			&LPrevious) ;
! 		    }
! 		    else if (arg.val <
! 		             shareadrsem->current_nb[id].current_nb[semnum] )
! 		    {
! 			for( LIndex = arg.val;
! 			LIndex < shareadrsem->current_nb[id].current_nb[semnum];
! 			LIndex++ )
! 			{
! 			    WaitForSingleObject(LHandle, 0) ;
! 			}
! 		    }
!             	    shareadrsem->current_nb[id].current_nb[semnum] = arg.val ;
}
debug_printf("semctl : SETVAL : return 0\n");
CYGWIN32_IPCNT_RETURN_DECONNECT (0);
--- 585,592 ----
if( LHandle != NULL )
{
if( arg.val > shareadrsem->current_nb[id].current_nb[semnum] )
! 				ReleaseSemaphore(LHandle,1,&LPrevious) ;
!             shareadrsem->current_nb[id].current_nb[semnum] = arg.val ;
}
debug_printf("semctl : SETVAL : return 0\n");
CYGWIN32_IPCNT_RETURN_DECONNECT (0);

--
Yutaka tanida / S34 Co., Ltd.
tanida@s34.co.jp (Office)
yutaka@marin.or.jp(Private, or if you *HATE* Microsoft Outlook)

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

-- 
  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 Mon Sep 27 16:55:11 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA29452
for <hackers@postgreSQL.org>; Mon, 27 Sep 1999 16:55:06 -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 QAA16830;
Mon, 27 Sep 1999 16:54:12 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909272054.QAA16830@candle.pha.pa.us>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-Reply-To: <16154.936121871@sss.pgh.pa.us> from Tom Lane at "Aug 31,
1999 01:51:11 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 27 Sep 1999 16:54:12 -0400 (EDT)
CC: Massimo Dal Zotto <dz@wizard.net>,
PostgreSQL Hackers <hackers@postgreSQL.org>,
The Hermit Hacker <scrappy@hub.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Massimo Dal Zotto <dz@wizard.net> writes:

May I ask that the patches I submitted two months ago for 6.5.0 are applied
at least to 6.5.2?
Here is the 6.5.1 version of my patches.

I don't much care for QueryLimit (we got rid of that for a reason!)
nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe
enough... but are we in the business of adding features to 6.5.*,
even little ones? Maybe it should only go in current.

Applied to 6.6 only, without tuple memory or query limit fix.

-- 
  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 Mon Sep 27 17:04:07 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA30521
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 17:03:15 -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 RAA17906;
Mon, 27 Sep 1999 17:02:05 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909272102.RAA17906@candle.pha.pa.us>
Subject: Re: [HACKERS] Lexer again.
In-Reply-To: <37CE99EC.2E9EE8DE@udmnet.ru> from Leon at "Sep 2, 1999 08:38:20
pm"
To: Leon <leon@udmnet.ru>
Date: Mon, 27 Sep 1999 17:02:05 -0400 (EDT)
CC: hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Sorry, guys. Here is the ultimate patch which keeps the entire
behavior as it was, apart from forbidding minus-terminated
operators. Seems that I have to break the habit of doing before
thinking properly :-/ The point is that my second patch breaks
constructs like a & b or a ! b. This patch is to be applied
instead of any of two other today's patches.

Applied.

-- 
  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 Mon Sep 27 17:17:11 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 RAA33034
for <hackers@postgreSQL.org>; Mon, 27 Sep 1999 17:17:09 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgreSQL.org
id m11Vi2G-0003kLC; Mon, 27 Sep 99 23:10 MET DST
Message-Id: <m11Vi2G-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] PostgreSQL 6.5.2
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Mon, 27 Sep 1999 23:10:12 +0200 (MET DST)
Cc: dz@wizard.net, hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199909272041.QAA16556@candle.pha.pa.us> from "Bruce Momjian" at
Sep 27, 99 04:41:08 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

Removed manually. Thanks. I have been far behind in keeping up with
patches.

Looks like :)

Well, actually running regression test emits alot of

NOTICE: Auto-creating query reference to table <table-name>

from inside the parser - which make most of the regression
tests fail. Not sure which of the patches introduced them
and why. Could you please take a look at it? On the things
I'm doing right now (adding fields + indices to system
catalogs and modifying code that's invoked during heap_open()
or the like) I feel much better if I get identical (+
correct) regression results before'n'after.

Jan

From bouncefilter Mon Sep 27 18:41:08 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 SAA42828
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 18:40:44 -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 SAA27598;
Mon, 27 Sep 1999 18:40:01 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_upgrade may be mortally wounded
In-reply-to: Your message of Mon, 27 Sep 1999 12:52:54 -0400 (EDT)
<199909271652.MAA02521@candle.pha.pa.us>
Date: Mon, 27 Sep 1999 18:40:00 -0400
Message-ID: <27596.938472000@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Tom, did we address this. I forgot.

No, it's still an open issue as far as I'm concerned. I was hoping to
hear something from Vadim about how pg_upgrade could work safely under
MVCC...

regards, tom lane

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

BTW, it seems to me that it is a good idea to kill and restart the
postmaster immediately after pg_upgrade finishes. Otherwise there might
be buffers in shared memory that do not reflect the actual contents of
the corresponding pages of the relation files (now that pg_upgrade
overwrote the files with other data).

Your issue with buffer cache is a major one. Clearly, this would be a
problem. However, it is my understanding that the buffer cache after
initdb would only contain system table info, so if they pg_upgrade after
that, there is no way they have bad stuf in the cache, right?

Cached copies of system tables obviously are no problem, since
pg_upgrade doesn't overwrite those. I'm concerned whether there can
be cached copies of pages from user tables or indexes. Since we've
just done a bunch of CREATE INDEXes (and a VACUUM, if my latest hack
is right), it seems at least possible that this would happen.

Now all those user tables will be empty (zero-length files), so there is
nothing to cache. But the user indexes are *not* zero-length --- it looks
like they are at least 2 pages long even when empty. So there seems
to be a real risk of having a cached copy of one of the pages of a user
index while pg_upgrade is overwriting the index file with new data...

From bouncefilter Mon Sep 27 18:51:08 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 SAA43687
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 18:50:57 -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 SAA27682;
Mon, 27 Sep 1999 18:50:08 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] vacuum process size
In-reply-to: Your message of Mon, 27 Sep 1999 14:33:06 -0400 (EDT)
<199909271833.OAA11252@candle.pha.pa.us>
Date: Mon, 27 Sep 1999 18:50:08 -0400
Message-ID: <27680.938472608@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Tom, you already handled this, right?

Someone committed it, not sure if it was me.

I was worried whether vacuum's other expandable lists needed the same
treatment, but Hiroshi and/or Tatsuo seemed to think it wasn't worth the
trouble to change them. So I guess the item is closed.

regards, tom lane

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

Just for a testing I made a huge table (>2GB and it has 10000000
tuples). copy 10000000 tuples took 23 minutes. This is not so
bad. Vacuum analyze took 11 minutes, not too bad. After this I created
an index on int4 column. It took 9 minutes. Next I deleted 5000000
tuples to see how long delete took. I found it was 6
minutes. Good. Then I ran into a problem. After that I did vacuum
analyze, and seemed it took forever! (actually took 47 minutes). The
biggest problem was postgres's process size. It was 478MB! This is not
acceptable for me. Any idea?

Yeah, I've complained about that before --- it seems that vacuum takes
a really unreasonable amount of time to remove dead tuples from an index.
It's been like that at least since 6.3.2, probably longer.

Hiroshi came up with a work around for this(see included
patches). After applying it, the process size shrinked from 478MB to
86MB! (the processing time did not descrease, however). According to
him, repalloc seems not very effective with large number of calls. The
patches probably descreases the number to 1/10.
--
Tatsuo Ishii
-------------------------------------------------------------------------
*** vacuum.c.orig	Sat Jul 3 09:32:40 1999
--- vacuum.c	Thu Aug 19 17:34:18 1999
***************
*** 2519,2530 ****
static void
vc_vpinsert(VPageList vpl, VPageDescr vpnew)
{
/* allocate a VPageDescr entry if needed */
if (vpl->vpl_num_pages == 0)
! vpl->vpl_pagedesc = (VPageDescr *) palloc(100 * sizeof(VPageDescr));
! else if (vpl->vpl_num_pages % 100 == 0)
! vpl->vpl_pagedesc = (VPageDescr *) repalloc(vpl->vpl_pagedesc, (vpl->vpl_num_pages + 100) * sizeof(VPageDescr));

vpl-> vpl_pagedesc[vpl->vpl_num_pages] = vpnew;

(vpl->vpl_num_pages)++;
--- 2519,2531 ----
static void
vc_vpinsert(VPageList vpl, VPageDescr vpnew)
{
+ #define PG_NPAGEDESC 1000
/* allocate a VPageDescr entry if needed */
if (vpl->vpl_num_pages == 0)
! vpl->vpl_pagedesc = (VPageDescr *) palloc(PG_NPAGEDESC * sizeof(VPageDescr));
! else if (vpl->vpl_num_pages % PG_NPAGEDESC == 0)
! vpl->vpl_pagedesc = (VPageDescr *) repalloc(vpl->vpl_pagedesc, (vpl->vpl_num_pages + PG_NPAGEDESC) * sizeof(VPageDescr));

vpl-> vpl_pagedesc[vpl->vpl_num_pages] = vpnew;

(vpl->vpl_num_pages)++;

From bouncefilter Mon Sep 27 19:32:08 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 TAA46812
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 19:31:59 -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 TAA27909;
Mon, 27 Sep 1999 19:30:51 -0400 (EDT)
To: Zakkr <zakkr@zf.jcu.cz>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] _text problem in union
In-reply-to: Your message of Mon, 27 Sep 1999 15:11:10 +0200 (CEST)
<Pine.LNX.3.96.990927150619.8444A-100000@ara.zf.jcu.cz>
Date: Mon, 27 Sep 1999 19:30:51 -0400
Message-ID: <27907.938475051@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Zakkr <zakkr@zf.jcu.cz> writes:

abil=> select '{"aaa"}'::_text union select '{"bbb"}'::_text;
ERROR: Unable to identify an ordering operator '<' for type '_text'
Use an explicit ordering operator or modify the query

Depending on what you're trying to do, UNION ALL might be an adequate
workaround. UNION is defined to remove duplicates, so it has to sort
the results of the union'ed queries, which requires an ordering
operator. UNION ALL just appends the two query results together...

In the long run we probably ought to think about providing ordering
operators for array types.

regards, tom lane

From bouncefilter Mon Sep 27 19:38:08 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 TAA47216
for <pgsql-hackers@postgresql.org>;
Mon, 27 Sep 1999 19:37:17 -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 TAA27942;
Mon, 27 Sep 1999 19:35:41 -0400 (EDT)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: dale@redhat.com, pgsql-hackers@postgresql.org, jbj@redhat.com
Subject: Re: [HACKERS] Re: New init script and upgrade attempt: failed
In-reply-to: Your message of Mon, 27 Sep 1999 11:30:12 -0400
<37EF8D84.C0E04F@wgcr.org>
Date: Mon, 27 Sep 1999 19:35:40 -0400
Message-ID: <27940.938475340@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Lamar Owen <lamar.owen@wgcr.org> writes:

Hackers: should pg_dumpall dump template1?? If not, why not? What
EXACTLY does template1 do in the larger scheme of things? If dumping
template1 is desired -- it can be arranged in the upgrade by modifying
pg_dumpall.

template1 is copied verbatim by CREATE DATABASE to produce the initial
state of any new database. So, people might reasonably put stuff in
it that they want copied to new DB's. The most common example is
doing a createlang to create non-default PLs (plpgsql etc); you can do
it just once in template1 instead of every time you make a DB, assuming
that you want plpgsql in all your DBs. I guess there could be reasons
for making a user table in template1 to be copied to each new DB.

If pg_dumpall doesn't dump the (user-added) contents of template1,
I think that's an oversight...

regards, tom lane

From bouncefilter Mon Sep 27 19:39:13 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 TAA47403
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 19:39:08 -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 TAA27964;
Mon, 27 Sep 1999 19:37:43 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Leon <leon@udmnet.ru>, hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Profiling?]
In-reply-to: Your message of Mon, 27 Sep 1999 11:33:33 -0400 (EDT)
<199909271533.LAA15302@candle.pha.pa.us>
Date: Mon, 27 Sep 1999 19:37:43 -0400
Message-ID: <27962.938475463@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Of course I used -p option. The problem is, when I start Postmaster,
it complains about 'profile timer expired'. What do I do wrong?

That's strange. I have not profiled in a while. I wonder if the
removal of the exec() has caused this.

I've done profiles successfully (with gcc -pg + gprof on HPUX) since
the exec change. I think Leon is running into some sort of platform-
specific profiler bug, but I dunno how to get around it.

regards, tom lane

From bouncefilter Mon Sep 27 19:43:08 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA47818
for <pgsql-hackers@postgresql.org>;
Mon, 27 Sep 1999 19:42:35 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from lowen.wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id TAA22351;
Mon, 27 Sep 1999 19:42:38 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] Re: New init script and upgrade attempt: failed
Date: Mon, 27 Sep 1999 19:40:54 -0400
X-Mailer: KMail [version 1.0.24]
Content-Type: text/plain
Cc: dale@redhat.com, pgsql-hackers@postgresql.org, jbj@redhat.com
References: <27940.938475340@sss.pgh.pa.us>
MIME-Version: 1.0
Message-Id: <99092719422701.07044@lowen.wgcr.org>
Content-Transfer-Encoding: 8bit

On Mon, 27 Sep 1999, Tom Lane wrote:

If pg_dumpall doesn't dump the (user-added) contents of template1,
I think that's an oversight...

Thanks, Tom -- that's what I thought. I'll tackle making and verifying changes
to pg_dumpall to do just that. It's not a showstopper -- but it is a nuisance.

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

From bouncefilter Mon Sep 27 19:48:08 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 TAA48461
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 19:47:57 -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 TAA28006;
Mon, 27 Sep 1999 19:46:53 -0400 (EDT)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Regression tests on intel for 6.5.2
In-reply-to: Your message of Mon, 27 Sep 1999 12:02:26 -0400
<37EF9512.C4F67DFE@wgcr.org>
Date: Mon, 27 Sep 1999 19:46:53 -0400
Message-ID: <28004.938476013@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Lamar Owen <lamar.owen@wgcr.org> writes:

In the course of building and testing the rpm's for 6.5.2, unexpected
results were found in the regression testing. I am curious as to what
the results for 'float8' mean (geometry also failed, but it's obvious as
to why):

I saw similar results with older Postgres releases on HPUX. The problem
is failure to detect an invalid result from the exp() library function.
Unfortunately there's not complete uniformity about how to test that
on different platforms.

What's currently in dexp() in backend/utils/adt/float.c is

#ifndef finite
errno = 0;
#endif
*result = (float64data) exp(tmp);
#ifndef finite
if (errno == ERANGE)
#else
/* infinity implies overflow, zero implies underflow */
if (!finite(*result) || *result == 0.0)
#endif
elog(ERROR, "exp() result is out of range");

which is evidently doing the wrong thing on your platform. What does
your man page for exp() say about error return conventions?

I suspect the assumption that finite() is always implemented as a macro
if it's present at all is the weak spot ... or it might be that your
math lib returns some other error code like EDOM ...

regards, tom lane

From bouncefilter Mon Sep 27 20:05:09 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA50417
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 20:04:23 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from lowen.wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id UAA22404;
Mon, 27 Sep 1999 20:01:24 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] Regression tests on intel for 6.5.2
Date: Mon, 27 Sep 1999 19:52:07 -0400
X-Mailer: KMail [version 1.0.24]
Content-Type: text/plain
Cc: pgsql-hackers@postgreSQL.org
References: <28004.938476013@sss.pgh.pa.us>
MIME-Version: 1.0
Message-Id: <99092720011203.07044@lowen.wgcr.org>
Content-Transfer-Encoding: 8bit

On Mon, 27 Sep 1999, Tom Lane wrote:

which is evidently doing the wrong thing on your platform. What does
your man page for exp() say about error return conventions?

Platform is Intel Linux -- specifically:
RedHat Linux 6.0/Intel (glibc 2.1.1):

Man page for exp(3)...
-------------------
The log() and log10() functions can return the following errors:

EDOM
The argument x is negative.

ERANGE The argument x is zero. The log of zero is not defined.

The pow() function can return the following error:

EDOM
The argument x is negative and y is not an integral value. This would result in a complex number.
-------------------------------

I suspect the assumption that finite() is always implemented as a macro
if it's present at all is the weak spot ... or it might be that your
math lib returns some other error code like EDOM ...

Man page finite(3)
-------------------------------
The finite() function returns a non-zero value if value is neither infinite nor a
ï¿½not-a-numberï¿½ (NaN) value, and 0 otherwise.
-------------------------------

Seems that there was a table in those regression test results populated by
NaN....

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

From bouncefilter Mon Sep 27 19:51:09 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 TAA48895
for <pgsql-hackers@hub.org>; Mon, 27 Sep 1999 19:50:51 -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 IAA14789; Tue, 28 Sep 1999 08:49:54 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>,
"yutaka tanida" <yutaka@marin.or.jp>
Cc: <pgsql-hackers@hub.org>
Subject: RE: [HACKERS] Re: IPC on win32 - additions for 6.5.2 and current
trees
Date: Tue, 28 Sep 1999 08:53:31 +0900
Message-ID: <000001bf0943$809265c0$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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-reply-to: <199909272049.QAA16695@candle.pha.pa.us>

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: Tuesday, September 28, 1999 5:49 AM
To: yutaka tanida
Cc: pgsql-hackers@hub.org; inoue@tpf.co.jp
Subject: Re: [HACKERS] Re: IPC on win32 - additions for 6.5.2 and
current trees

NT folks, I assume this patch is no longer needed.

No,his patch is needed.
I have already committed a new patch which combines Yutaka's and
my patch to current tree under src/win32.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Sep 27 20:07:13 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 UAA50675
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 20:07:09 -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 UAA28064;
Mon, 27 Sep 1999 20:06:33 -0400 (EDT)
To: wieck@debis.com (Jan Wieck)
cc: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Subject: Re: [HACKERS] RI status report #1
In-reply-to: Your message of Mon, 27 Sep 1999 20:42:07 +0200 (MET DST)
<m11Vfix-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Mon, 27 Sep 1999 20:06:32 -0400
Message-ID: <28062.938477192@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

just to give anyone a chance to complain, I'd like to
describe what I plan to implement for v6.6 in the referential
integrity (RI) corner.

Jan, I have no comments about the RI features, but I am a little worried
about not creating big headaches in merging different changes. Can we
work out a schedule that will minimize tromping on each others' toes?

I am in the middle of some fairly extensive revisions in
rewriteManip.c, rewriteHandler.c, and ruleutils.c --- basically,
fixing all the routines that recurse through expression trees to use
expression_tree_walker and expression_tree_mutator, for a big space
savings and elimination of a bunch of routine-X-doesn't-handle-node-
type-Y bugs. Also I'm going to fix the rule deparser to use a
stringinfo buffer so it doesn't have any hardwired limits on the textual
length of a rule. And I think I know how to fix some of the problems
with aggregates in subselects, like this one:

create table t1 (name text, value float8);
CREATE
select name from t1 where name IN
(select name from t1 group by name having 2 = count(*));
ERROR: SELECT/HAVING requires aggregates to be valid

(It looks to me like some of the routines recurse into subselects when
they shouldn't. It's a lot easier to see that sort of issue when
there's no code left except the actual Var manipulation and the
nonstandard recursion decisions ;-).)

I intended to finish these up in the next few days and commit them,
but if you've already started major hacking in these files then maybe
we should find another way.

Also, I believe Thomas is in the middle of wide-ranging revisions in
the parser, so you'd better coordinate with him on touching that area.

regards, tom lane

From bouncefilter Mon Sep 27 20:41:14 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 UAA58436
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 20:40:31 -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 JAA14811; Tue, 28 Sep 1999 09:38:53 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Michael Simms" <grim@argh.demon.co.uk>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Frustration
Date: Tue, 28 Sep 1999 09:42:31 +0900
Message-ID: <000101bf094a$58ecb140$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-reply-to: <25950.938438426@sss.pgh.pa.us>

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Monday, September 27, 1999 10:20 PM
To: Hiroshi Inoue
Cc: Michael Simms; pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Frustration

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

Different from other spinlocks,io_in_progress spinlock is a per bufpage
spinlock and ProcReleaseSpins() doesn't release the spinlock.
If an error(in md.c in most cases) occured while holding the spinlock
,the spinlock would necessarily freeze.

Oooh, good point. Shouldn't this be fixed? If we don't fix it, then

Yes,it's on TODO.
* spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgr

I would try to fix it.

a disk I/O error will translate to an installation-wide shutdown and
restart as soon as some backend tries to touch the locked page (as
indeed was happening to Michael). That seems a tad extreme.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Sep 27 21:22:09 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA60797
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 21:21:18 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA01437;
Tue, 28 Sep 1999 10:21:16 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id KAA05419;
Tue, 28 Sep 1999 10:21:15 +0900 (JST)
Message-Id: <199909280121.KAA05419@srapc451.sra.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, t-ishii@sra.co.jp,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] vacuum process size
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Mon, 27 Sep 1999 18:50:08 -0400.
<27680.938472608@sss.pgh.pa.us>
Date: Tue, 28 Sep 1999 10:21:15 +0900
Sender: t-ishii@srapc451.sra.co.jp

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

Tom, you already handled this, right?

Someone committed it, not sure if it was me.

I have comitted changes to both the statble and the current.

I was worried whether vacuum's other expandable lists needed the same
treatment, but Hiroshi and/or Tatsuo seemed to think it wasn't worth the
trouble to change them. So I guess the item is closed.

I think so.
--
Tatsuo Ishii

From bouncefilter Mon Sep 27 21:34:14 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 VAA61861
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 21:34:02 -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 BAA32750;
Tue, 28 Sep 1999 01:32:40 GMT
Sender: lockhart@hub.org
Message-ID: <37F01AB7.EAD26F10@alumni.caltech.edu>
Date: Tue, 28 Sep 1999 01:32:39 +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: Hannu Krosing <hannu@tm.ee>, Zakkr <zakkr@zf.jcu.cz>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] _text problem in union
References: <199909271651.MAA02457@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It woulf be better to have a generic array compare op, that just
traverses both arrays comparing them with the "<" for base type

Yes, that was my idea. Is this a worthy TODO item?

Sure. There should be a fairly large list of things for arrays, which
have not quite gotten the same attention as other Postgres features.

- Thomas

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

From bouncefilter Mon Sep 27 21:48:10 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 VAA63326
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 21:47:13 -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 VAA23160;
Mon, 27 Sep 1999 21:38:28 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280138.VAA23160@candle.pha.pa.us>
Subject: Re: [HACKERS] _text problem in union
In-Reply-To: <27907.938475051@sss.pgh.pa.us> from Tom Lane at "Sep 27,
1999 07:30:51 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 27 Sep 1999 21:38:28 -0400 (EDT)
CC: Zakkr <zakkr@zf.jcu.cz>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Zakkr <zakkr@zf.jcu.cz> writes:

abil=> select '{"aaa"}'::_text union select '{"bbb"}'::_text;
ERROR: Unable to identify an ordering operator '<' for type '_text'
Use an explicit ordering operator or modify the query

Depending on what you're trying to do, UNION ALL might be an adequate
workaround. UNION is defined to remove duplicates, so it has to sort
the results of the union'ed queries, which requires an ordering
operator. UNION ALL just appends the two query results together...

In the long run we probably ought to think about providing ordering
operators for array types.

Added to TODO:

* Allow arrays to be ORDER'ed

-- 
  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 Mon Sep 27 21:43:14 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA62823
for <pgsql-hackers@hub.org>; Mon, 27 Sep 1999 21:43:11 -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 VAA23373;
Mon, 27 Sep 1999 21:42:17 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280142.VAA23373@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: IPC on win32 - additions for 6.5.2 and current
trees
In-Reply-To: <000001bf0943$809265c0$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Sep 28, 1999 08:53:31 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 27 Sep 1999 21:42:17 -0400 (EDT)
CC: yutaka tanida <yutaka@marin.or.jp>, pgsql-hackers@hub.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: Tuesday, September 28, 1999 5:49 AM
To: yutaka tanida
Cc: pgsql-hackers@hub.org; inoue@tpf.co.jp
Subject: Re: [HACKERS] Re: IPC on win32 - additions for 6.5.2 and
current trees

NT folks, I assume this patch is no longer needed.

No,his patch is needed.
I have already committed a new patch which combines Yutaka's and
my patch to current tree under src/win32.

OK, patch removed from README, and user pointed to new file in win32
directory.

-- 
  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 Mon Sep 27 22:58:10 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA01335
for <hackers@postgreSQL.org>; Mon, 27 Sep 1999 22:57:28 -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 WAA26807;
Mon, 27 Sep 1999 22:55:14 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280255.WAA26807@candle.pha.pa.us>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-Reply-To: <m11Vi2G-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Sep 27, 1999 11:10:12 pm"
To: Jan Wieck <wieck@debis.com>
Date: Mon, 27 Sep 1999 22:55:14 -0400 (EDT)
CC: dz@wizard.net, hackers@postgreSQL.org,
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Removed manually. Thanks. I have been far behind in keeping up with
patches.

Looks like :)

Well, actually running regression test emits alot of

NOTICE: Auto-creating query reference to table <table-name>

from inside the parser - which make most of the regression
tests fail. Not sure which of the patches introduced them
and why. Could you please take a look at it? On the things
I'm doing right now (adding fields + indices to system
catalogs and modifying code that's invoked during heap_open()
or the like) I feel much better if I get identical (+
correct) regression results before'n'after.

Thomas, can you re-generate the regression output so my new NOTICE is in
there? I tried, but there are too many errno messages differences to
get just the new NOTICE stuff in there.

-- 
  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 Mon Sep 27 23:33:11 1999
Received: from lota.izhcom.ru (lota.izhcom.ru [213.24.0.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA08524
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 23:32:51 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (U112.dialup.udm.net [192.168.53.112])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id IAA28771;
Tue, 28 Sep 1999 08:32:38 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37F0333A.6918D934@udmnet.ru>
Date: Tue, 28 Sep 1999 08:17:14 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Lexer again.
References: <199909272102.RAA17906@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Sorry, guys. Here is the ultimate patch which keeps the entire
behavior as it was, apart from forbidding minus-terminated
operators. Seems that I have to break the habit of doing before
thinking properly :-/ The point is that my second patch breaks
constructs like a & b or a ! b. This patch is to be applied
instead of any of two other today's patches.

Applied.

Hey! Later discussion on that matter made us think that minus-terminated
operators have to be preserved, especially considering
that there is already one such operator here: geometric ?-.
I'm terribly sorry, but that patch shouldn't be applied.

The other patch applied by you which exterminates uminus exclusive
state in parser is considered to be ok.

--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.

From bouncefilter Mon Sep 27 23:41:10 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA10113
for <pgsql-hackers@postgreSQL.org>;
Mon, 27 Sep 1999 23:41:00 -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 XAA29177;
Mon, 27 Sep 1999 23:39:26 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280339.XAA29177@candle.pha.pa.us>
Subject: Re: [HACKERS] Lexer again.
In-Reply-To: <37F0333A.6918D934@udmnet.ru> from Leon at "Sep 28, 1999 08:17:14
am"
To: Leon <leon@udmnet.ru>
Date: Mon, 27 Sep 1999 23:39:26 -0400 (EDT)
CC: hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Sorry, guys. Here is the ultimate patch which keeps the entire
behavior as it was, apart from forbidding minus-terminated
operators. Seems that I have to break the habit of doing before
thinking properly :-/ The point is that my second patch breaks
constructs like a & b or a ! b. This patch is to be applied
instead of any of two other today's patches.

Applied.

Hey! Later discussion on that matter made us think that minus-terminated
operators have to be preserved, especially considering
that there is already one such operator here: geometric ?-.
I'm terribly sorry, but that patch shouldn't be applied.

The other patch applied by you which exterminates uminus exclusive
state in parser is considered to be ok.

Reversed out.

-- 
  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 Sep 28 00:08:15 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA16037
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 00:08:07 -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 AAA29790;
Tue, 28 Sep 1999 00:06:47 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280406.AAA29790@candle.pha.pa.us>
Subject: Re: [HACKERS] md.c is feeling much better now, thank you
In-Reply-To: <5805.936545607@sss.pgh.pa.us> from Tom Lane at "Sep 5,
1999 11:33:27 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 28 Sep 1999 00:06:47 -0400 (EDT)
CC: t-ishii@sra.co.jp, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Any resolution on this?

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

Ok. I will give another example that seems more serious.
test=> aaa;
ERROR: parser: parse error at or near "aaa"
-- transaction is aborted and the table file t1 is unlinked.
test=> select * from t1;
-- but parser doesn't know t1 does not exist any more.
-- it tries to open t1 using mdopen(). (see including backtrace)
-- mdopen() tries to open t1 and fails. In this case mdopen()
-- creates t1!
NOTICE: (transaction aborted): queries ignored until END
*ABORT STATE*

Hmm. It seems a more straightforward solution would be to alter
pg_parse_and_plan so that the parser isn't even called if we have
already failed the current transaction; that is, the "queries ignored"
test should occur sooner. I'm rather surprised to realize that
we do run the parser in this situation...

I think the long range solution would be let parser obtain certain
locks as Tom said.

That would not solve this particular problem, since the lock manager
wouldn't know any better than the parser that the table doesn't really
exist any more.

Until that I propose following solution. It looks
simple, safe and would be neccessary anyway (I don't know why that
check had not been implemented). See included patches.

This looks like it might be a good change, but I'm not quite as sure
as you are that it won't have any bad effects. Have you tested it?

regards, tom lane

-- 
  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 Sep 28 00:09:11 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA16284
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 00:08:59 -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 AAA29839;
Tue, 28 Sep 1999 00:08:12 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280408.AAA29839@candle.pha.pa.us>
Subject: Re: [HACKERS] DROP TABLE inside transaction block
In-Reply-To: <7322.936569875@sss.pgh.pa.us> from Tom Lane at "Sep 5,
1999 06:17:55 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 28 Sep 1999 00:08:12 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

My guess is that your new open routines with locking have fixed this.

Pursuant to a phone conversation I had with Bruce, I added code this
morning to reject DROP TABLE or DROP INDEX inside a transaction block;
that is, you can't do BEGIN; DROP TABLE foo; END anymore. The reason
for rejecting this case is that we do the wrong thing if the transaction
is later aborted. Following BEGIN; DROP TABLE foo; ABORT, the system
tables will claim that foo is still valid (since the changes to them
were never committed) but we've already unlinked foo's physical file,
and we can't get it back. Solution: only allow DROP TABLE outside
BEGIN, so that the user can't try to change his mind later.

However, on second thought I wonder if this cure is worse than the
disease. Will it be unreasonably hard to drop tables using client
interfaces that like to wrap everything in BEGIN/END? Plugging an
obscure hole might not be worth that.

A possible compromise is not to error out, but just to issue a NOTICE
along the lines of "DROP TABLE is not undoable, so don't even think of
trying to abort now..."

(Of course, what would be really nice is if it just worked, but I don't
see any way to make that happen without major changes. Simply
postponing the unlink to end of transaction isn't workable; consider
BEGIN; DROP TABLE foo; CREATE TABLE foo; ...)

Any thoughts? Will there indeed be a problem with JDBC or ODBC if we
leave this error check in place?

regards, tom lane

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

-- 
  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 Sep 28 00:10:11 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA16448
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 00:09:37 -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 AAA29897;
Tue, 28 Sep 1999 00:08:39 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280408.AAA29897@candle.pha.pa.us>
Subject: Re: [HACKERS] DROP TABLE inside transaction block
In-Reply-To: <37D50B5C.636B68C2@sferacarta.com> from "[Jos_] Soares" at "Sep
7, 1999 02:55:56 pm"
To: "[Jos_] Soares" <jose@sferacarta.com>
Date: Tue, 28 Sep 1999 00:08:39 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Any comment on this?

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Tom Lane ha scritto:

Pursuant to a phone conversation I had with Bruce, I added code this
morning to reject DROP TABLE or DROP INDEX inside a transaction block;
that is, you can't do BEGIN; DROP TABLE foo; END anymore. The reason
for rejecting this case is that we do the wrong thing if the transaction
is later aborted. Following BEGIN; DROP TABLE foo; ABORT, the system
tables will claim that foo is still valid (since the changes to them
were never committed) but we've already unlinked foo's physical file,
and we can't get it back. Solution: only allow DROP TABLE outside
BEGIN, so that the user can't try to change his mind later.

However, on second thought I wonder if this cure is worse than the
disease. Will it be unreasonably hard to drop tables using client
interfaces that like to wrap everything in BEGIN/END? Plugging an
obscure hole might not be worth that.

A possible compromise is not to error out, but just to issue a NOTICE
along the lines of "DROP TABLE is not undoable, so don't even think of
trying to abort now..."

(Of course, what would be really nice is if it just worked, but I don't
see any way to make that happen without major changes. Simply
postponing the unlink to end of transaction isn't workable; consider
BEGIN; DROP TABLE foo; CREATE TABLE foo; ...)

Any thoughts? Will there indeed be a problem with JDBC or ODBC if we
leave this error check in place?

regards, tom lane

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

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

Seems a good solution. I have an old note about this problem.
What about to reject also the following commands inside transactions?

* BUGS: There are some commands that doesn't work properly
inside transactions. Users should NOT use the following
statements inside transactions:

- DROP TABLE -- in case of ROLLBACK only table structure
will be recovered, data will be
lost.
- CREATE VIEWS -- the behavior of the backend is unpredictable.
- ALTER TABLE -- the behavior of the backend is unpredictable.
- CREATE DATABASE -- in case of ROLLBACK will be removed references
from "pg_database" but directory
$PGDATA/databasename will not be removed.

Jos_

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

-- 
  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 Sep 28 00:10:11 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA16661
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 00:10:05 -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 AAA29908;
Tue, 28 Sep 1999 00:09:10 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280409.AAA29908@candle.pha.pa.us>
Subject: Re: [HACKERS] DROP TABLE inside transaction block
In-Reply-To: <27397.936712434@sss.pgh.pa.us> from Tom Lane at "Sep 7,
1999 09:53:54 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 28 Sep 1999 00:09:10 -0400 (EDT)
CC: "[Jos_] Soares" <jose@sferacarta.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Seems like good comments on these items. Anything for TODO list here?

=?iso-8859-1?Q?Jos=E9?= Soares <jose@sferacarta.com> writes:

Seems a good solution. I have an old note about this problem.
What about to reject also the following commands inside transactions?

* BUGS: There are some commands that doesn't work properly
inside transactions. Users should NOT use the following
statements inside transactions:

- DROP TABLE -- in case of ROLLBACK only table structure
will be recovered, data will be
lost.
- CREATE VIEWS -- the behavior of the backend is unpredictable.
- ALTER TABLE -- the behavior of the backend is unpredictable.
- CREATE DATABASE -- in case of ROLLBACK will be removed references
from "pg_database" but directory
$PGDATA/databasename will not be removed.

CREATE DATABASE (and presumably also DROP DATABASE) probably should
refuse to run inside a transaction.

I see no good reason that CREATE VIEW or ALTER TABLE should not work
cleanly in a transaction. It may be that they have bugs interfering
with that (for example, Hiroshi just pointed out that ALTER TABLE
seems not to be locking the table, which is surely bogus).

The main reason that DROP TABLE is an issue is that it alters the
underlying Unix file structure, which means we can't just rely on the
normal transaction mechanisms of committed/uncommitted tuples to handle
rollback. ALTER TABLE doesn't do anything except change tuples.
CREATE VIEW is a CREATE TABLE plus tuple changes (and while CREATE TABLE
does alter the file structure by making a new file, we have extra code
in there to handle rolling it back). So it seems like they oughta work.

RENAME TABLE is another thing that can't currently be rolled back,
because it renames the underlying Unix files and there's no mechanism
to undo that. (RENAME TABLE is missing a lock too...)

regards, tom lane

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

-- 
  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 Sep 28 00:12:11 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA17270
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 00:11:59 -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 AAA29954;
Tue, 28 Sep 1999 00:10:57 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280410.AAA29954@candle.pha.pa.us>
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
In-Reply-To: <000b01befb6d$9f4419c0$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Sep 10, 1999 06:19:45 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 28 Sep 1999 00:10:57 -0400 (EDT)
CC: Vadim Mikheev <vadim@krs.ru>, Michael Simms <grim@argh.demon.co.uk>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Is this patch still valid?

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Hiroshi Inoue wrote:

crashtest=> vacuum analyze;
NOTICE: Rel pg_type: TID 4/3: InsertTransactionInProgress 129915
- can't shrink relation

...

CREATE TABLE doesn't lock system tables till end of transaction.
It's a cause of these NOTICE messages.

Should we lock system tables till end of transaction ?

No, if we allow DDL statements inside BEGIN/END
(in long transaction).

Moreover CREATE TABLE doesn't acquire any lock for pg_attribute
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
while tuples are inserted into pg_attribute.
Concurrent vacuum may corrupt pg_attribute.

Should be fixed!

Seems CREATE TABLE don't acquire any lock for pg_relcheck and
pg_attrdef as well as pg_attribute. There may be other pg_.......

Here is a patch.
This patch also removes UnlockRelation() in heap_destroy_with_catalog().

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp
*** catalog/heap.c.orig	Tue Sep  7 08:52:04 1999
--- catalog/heap.c	Fri Sep 10 16:43:18 1999
***************
*** 547,552 ****
--- 547,553 ----
*/
Assert(rel);
Assert(rel->rd_rel);
+ 	LockRelation(rel, AccessExclusiveLock);
hasindex = RelationGetForm(rel)->relhasindex;
if (hasindex)
CatalogOpenIndices(Num_pg_attr_indices, Name_pg_attr_indices, idescs);
***************
*** 607,612 ****
--- 608,614 ----
dpp++;
}
+ UnlockRelation(rel, AccessExclusiveLock);
heap_close(rel);

/*
***************
*** 1330,1336 ****

rel->rd_nonameunlinked = TRUE;

- UnlockRelation(rel, AccessExclusiveLock);

heap_close(rel);
--- 1332,1337 ----
***************
*** 1543,1553 ****
--- 1544,1556 ----
values[Anum_pg_attrdef_adbin - 1] =
PointerGetDatum(textin(attrdef->adbin));
values[Anum_pg_attrdef_adsrc - 1] =
PointerGetDatum(textin(attrdef->adsrc));
adrel = heap_openr(AttrDefaultRelationName);
+ 	LockRelation(adrel, AccessExclusiveLock);
tuple = heap_formtuple(adrel->rd_att, values, nulls);
CatalogOpenIndices(Num_pg_attrdef_indices, Name_pg_attrdef_indices,
idescs);
heap_insert(adrel, tuple);
CatalogIndexInsert(idescs, Num_pg_attrdef_indices, adrel, tuple);
CatalogCloseIndices(Num_pg_attrdef_indices, idescs);
+ 	UnlockRelation(adrel, AccessExclusiveLock);
heap_close(adrel);
pfree(DatumGetPointer(values[Anum_pg_attrdef_adbin - 1]));
***************
*** 1606,1616 ****
--- 1609,1621 ----
values[Anum_pg_relcheck_rcbin - 1] =
PointerGetDatum(textin(check->ccbin));
values[Anum_pg_relcheck_rcsrc - 1] =
PointerGetDatum(textin(check->ccsrc));
rcrel = heap_openr(RelCheckRelationName);
+ 	LockRelation(rcrel, AccessExclusiveLock);
tuple = heap_formtuple(rcrel->rd_att, values, nulls);
CatalogOpenIndices(Num_pg_relcheck_indices, Name_pg_relcheck_indices,
idescs);
heap_insert(rcrel, tuple);
CatalogIndexInsert(idescs, Num_pg_relcheck_indices, rcrel, tuple);
CatalogCloseIndices(Num_pg_relcheck_indices, idescs);
+ 	UnlockRelation(rcrel, AccessExclusiveLock);
heap_close(rcrel);
pfree(DatumGetPointer(values[Anum_pg_relcheck_rcname - 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

From bouncefilter Tue Sep 28 00:13:11 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA17346
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 00:12:50 -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 AAA29966;
Tue, 28 Sep 1999 00:11:50 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280411.AAA29966@candle.pha.pa.us>
Subject: Re: [HACKERS] Patch for user-defined C-language functions
In-Reply-To: <11680.937268395@sss.pgh.pa.us> from Tom Lane at "Sep 13,
1999 08:19:55 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 28 Sep 1999 00:11:50 -0400 (EDT)
CC: Bernard Frankpitt <frankpit@pop.dn.net>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tom, where are we on this?

Bernard Frankpitt <frankpit@pop.dn.net> writes:

The solution that I propose, and have implemented in the attatched
patch extends the CREATE FUNCTION syntax as follows. In the first case
above I use the link symbol mytype2_to_mytype3 for the link object
that implements the first conversion function, and define the
Postgresql operator with the following syntax
CREATE FUNCTION mytype3 ( mytype2 )
RETURNS mytype3
AS 'mytypes.so', 'mytype2_to_mytype3'
LANGUAGE 'C'
The syntax for the AS clause, which was 'AS <link-file>' becomes
AS <link_file>[, <link_name>]
Specification of the link_name is optional, and not needed if the link
name is the same as the Postgresql function name.

I store the string for the link symbol in the prosrc text attribute of
the pg_proc table which is currently unused in rows that reference
dynamically loaded functions.

Sounds like a good plan to me. I'll be glad to check this over and
commit it into 6.6 (unless there are objections?) ... but could I
trouble you for documentation diffs as well? At the very least,
the text discussion of CREATE FUNCTION, the reference page entry,
and the online help in psql need to reflect this addition.

regards, tom lane

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

-- 
  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 Sep 28 00:23:11 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA19540
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 00:23:09 -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 AAA00398;
Tue, 28 Sep 1999 00:22:16 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280422.AAA00398@candle.pha.pa.us>
Subject: Re: [HACKERS] Status report: long-query-string changes
In-Reply-To: <19119.937404127@sss.pgh.pa.us> from Tom Lane at "Sep 15,
1999 10:02:07 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 28 Sep 1999 00:22:16 -0400 (EDT)
CC: Mike Mascari <mascarim@yahoo.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Mike Mascari <mascarim@yahoo.com> writes:

2. How is it that Tom Lane isn't considered "core"?

The core guys have been here a lot longer. I've only been
working with Postgres for a year or so.

There are quite a few major contributors besides the core four,
actually.

I have renamed the Core group to "Founders" on the web site, and changed
"Other Major Code Developers" to "Major Code Developers".

-- 
  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 Sep 28 00:26:13 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA20259
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 00:25:17 -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 AAA00465;
Tue, 28 Sep 1999 00:24:27 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280424.AAA00465@candle.pha.pa.us>
Subject: Re: [HACKERS] TRUNCATE TABLE patch
In-Reply-To: <19990917010618.13322.rocketmail@web129.yahoomail.com> from Mike
Mascari at "Sep 16, 1999 06:06:18 pm"
To: Mike Mascari <mascarim@yahoo.com>
Date: Tue, 28 Sep 1999 00:24:27 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied. Sorry for the delay. I think Tom Lane fixed the function
calls.

I submitted a patch to the patches list several
months ago which implemented Oracle's TRUNCATE TABLE
statement in PostgreSQL and was wondering whether or
not the patch was going to make it into current. I had
the patch ready before the 6.5 release but 6.5 was
already in beta at the time, so I waited until the
6.5 tree was split.

Recent discussions with regard to the functioning of
DROP TAPLE in transactions and changing heap_openr()
to require a locking type affect the nature of the
patch. TRUNCATE TABLE behaves like Oracle's DDL
statements by committing the running transaction and
starting a new one for the TRUNCATE operation
(which generates no rollback information), or, as
Bruce Momjian puts it "cheating".

Any news?

Just curious,

Mike Mascari
(mascarim@yahoo.com)

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

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

-- 
  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 Sep 28 00:23:11 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 AAA19475
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 00:22:56 -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 NAA00080; Tue, 28 Sep 1999 13:22:44 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Vacuum analyze bug CAUGHT
Date: Tue, 28 Sep 1999 13:26:21 +0900
Message-ID: <000c01bf0969$9dadeaa0$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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-reply-to: <199909280410.AAA29954@candle.pha.pa.us>

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: Tuesday, September 28, 1999 1:11 PM
To: Hiroshi Inoue
Cc: Vadim Mikheev; Michael Simms; pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT

Is this patch still valid?

No,it has been already changed by Tom together with
many other changes.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Sep 28 00:34:12 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA22297
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 00:33:27 -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 AAA00939;
Tue, 28 Sep 1999 00:32:14 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280432.AAA00939@candle.pha.pa.us>
Subject: Re: [HACKERS] Patch for user-defined C-language functions
In-Reply-To: <37DD6380.2E044072@pop.dn.net> from Bernard Frankpitt at "Sep 13,
1999 08:50:08 pm"
To: Bernard Frankpitt <frankpit@pop.dn.net>
Date: Tue, 28 Sep 1999 00:32:14 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied.

Hi all,

I have been working with user defined types and user defined c
functions. One problem that I have encountered with the function
manager is that it does not allow the user to define type conversion
functions that convert between user types. For instance if mytype1,
mytype2, and mytype3 are three Postgresql user types, and if I wish to
define Postgresql conversion functions like

CREATE FUNCTION mytype3 ( mytype2 )
RETURNS mytype3
AS 'mytypes.so'
LANGUAGE 'C'

CREATE FUNCTION mytype3 ( mytype1 )
RETURNS mytype3
AS 'mytypes.so'
LANGUAGE 'C'

I run into problems, because the Postgresql dynamic loader would look
for a single link symbol, mytype3, for both pieces of object code. If
I just change the name of one of the Postgresql functions (to make the
symbols distinct), the automatic type conversion that Postgresql uses,
for example, when matching operators to arguments no longer finds the
type conversion function.

The solution that I propose, and have implemented in the attatched
patch extends the CREATE FUNCTION syntax as follows. In the first case
above I use the link symbol mytype2_to_mytype3 for the link object
that implements the first conversion function, and define the
Postgresql operator with the following syntax

CREATE FUNCTION mytype3 ( mytype2 )
RETURNS mytype3
AS 'mytypes.so', 'mytype2_to_mytype3'
LANGUAGE 'C'

The syntax for the AS clause, which was 'AS <link-file>' becomes

AS <link_file>[, <link_name>]

Specification of the link_name is optional, and not needed if the link
name is the same as the Postgresql function name.

The patch includes changes to the parser to include the altered
syntax, changes to the ProcedureStmt node in nodes/parsenodes.h,
changes to commands/define.c to handle the extra information in the AS
clause, and changes to utils/fmgr/dfmgr.c that alter the way that the
dynamic loader figures out what link symbol to use. I store the
string for the link symbol in the prosrc text attribute of the pg_proc
table which is currently unused in rows that reference dynamically
loaded
functions.

Bernie Frankpitt

[Attachment, skipping...]

-- 
  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 Sep 28 00:34:11 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA22344
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 00:33:37 -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 AAA00946;
Tue, 28 Sep 1999 00:32:24 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280432.AAA00946@candle.pha.pa.us>
Subject: Re: [HACKERS] Doccumentation Patch for Create Function
In-Reply-To: <37E12015.AFA0D0BA@pop.dn.net> from Bernard Frankpitt at "Sep 16,
1999 04:51:33 pm"
To: Bernard Frankpitt <frankpit@pop.dn.net>
Date: Tue, 28 Sep 1999 00:32:24 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied Docs too.

Hi all,

Please find attached diffs to the documentation that are intended to
accompany the CREATE FUNCTION patch that I submitted earlier. I stuck
with the syntax in the original patch rather than the alternative
syntax suggested by Andreas.

When I was altering the xfunc.sgml page I came across this:

<title>Name Space Conflicts</title>

<para>
As of <productname>Postgres</productname> v6.5,
<command>CREATE FUNCTION</command> can decouple a C language
function name from the name of the entry point. This is now the
preferred technique to accomplish function overloading.
</para>

which seems to suggest that someone had a similar idea in the past. I
could find no evidence of this functionality in the 6.5 code though

Bernard Frankpitt

[Attachment, skipping...]

-- 
  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 Sep 28 00:48:12 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA25329
for <docs@postgreSQL.org>; Tue, 28 Sep 1999 00:47:11 -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 AAA01587;
Tue, 28 Sep 1999 00:44:07 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909280444.AAA01587@candle.pha.pa.us>
Subject: Re: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)
In-Reply-To: <Pine.LNX.4.10.9909212031480.1899-200000@peter-e.yi.org> from
Peter Eisentraut at "Sep 21, 1999 11:46:19 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 28 Sep 1999 00:44:07 -0400 (EDT)
CC: Vince Vielhaber <vev@michvhf.com>, The Hermit Hacker <scrappy@hub.org>,
docs@postgreSQL.org, "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thomas, can you comment on this. I think he has a good point. Can we
move some of the stuff to footnotes at the end of the file? Can you try
converting to HTML first, then to text to see if it formats better:

lynx -force_html -dump -hiddenlinks=ignore -nolist "$@"

On Sep 20, Bruce Momjian mentioned:

I agree our INSTALL is very large. Is there some way we can simplify
the install process?

On the one hand a database server is probably not your everyday
./configure && make && make install program you get from freshmeat and you
do want to put some time into a proper installation. On the other hand the
INSTALL file is really way too long and makes for unpleasant reading.

Here are a couple of ideas.

* Chapter 2 "Ports" should be moved to the README file (has nothing to do
with the actual installation).

* Move the gory details of item 5 (flex) to a separate file (README.flex).

* Move the locale stuff into a separate file.

* Same with Kerberos

* Move the release notes at the end to CHANGELOG.

That should make the file somewhat smaller, then also it is really to
verbose at times and is formatted really oddly, at least on my system.

Okay, now I really went out of my way and redid the whole thing. You'll
find the result attached. This is merely an idea of what I would consider
simpler. I removed some inconsistencies, things that were unnecessary, too
complicated, etc. Okay, I removed a lot of stuff, but most of the stuff
people can really figure out themselves if they need them in the first
place. And I shrunk the thing to 25%.

Perhaps there should be a separate Install FAQ of the sort "My shell said
'export: Command not found.'" or "What's a shared library?" to move the
really annoying stuff out of people's ways.

Comments?

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

Content-Description: New INSTALL file?

[Attachment, skipping...]

-- 
  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 Sep 28 00:49:11 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 AAA25541
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 00:48:40 -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 NAA00094 for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 13:48:35 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Recovery on incomplete write
Date: Tue, 28 Sep 1999 13:52:12 +0900
Message-ID: <000d01bf096d$3a22aee0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

Hi all,

I have wondered that md.c handles incomplete block(page)s
correctly.
Am I mistaken ?

1) _mdnblocks() takes the last incomplete block into account

2) mdextend() doesn't care about the existence of incomplete
block(page)s.

3) In spite of 1)2),mdextend() does nothing when incomplete
write occurs.

Comments ?

If I am right,I would provide a patch.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Sep 28 03:11:13 1999
Received: from sun.med.ru (sun.med.ru [194.67.88.10])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA49618
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 03:10:31 -0400 (EDT) (envelope-from phd@sun.med.ru)
Received: (from phd@localhost) by sun.med.ru (8.8.8+Sun/8.8.8) id LAA03300;
Tue, 28 Sep 1999 11:06:42 +0400 (MSD)
Date: Tue, 28 Sep 1999 11:06:42 +0400 (MSD)
From: Oleg Broytmann <phd@sun.med.ru>
Reply-To: phd2@earthling.net
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] 6.5.2
In-Reply-To: <199909271821.OAA10598@candle.pha.pa.us>
Message-ID: <Pine.SOL2.3.96.SK.990928110519.3298A-100000@sun.med.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi!

On Mon, 27 Sep 1999, Bruce Momjian wrote:

Oleg, do you seem them now? If not, can you send them to me.

I saw it long time ago and sent my thankx to the list. It seems you
store messages in your mailbox a little too long :)

Hello!

I didn't saw my latest patches for README.locale in latest (Aug 15)
snapshot, although Bruce reported he got it. I think it best to apply it
for 6.5.2 than to 6.6 ot 7.0...

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

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

From bouncefilter Tue Sep 28 04:38:14 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA59937
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 04:37:29 -0400 (EDT) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA29370;
Tue, 28 Sep 1999 09:26:12 +0200
Date: Tue, 28 Sep 1999 09:26:12 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] _text problem in union
In-Reply-To: <27907.938475051@sss.pgh.pa.us>
Message-ID: <Pine.LNX.3.96.990928091713.23696A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 27 Sep 1999, Tom Lane wrote:

Zakkr <zakkr@zf.jcu.cz> writes:

abil=> select '{"aaa"}'::_text union select '{"bbb"}'::_text;
ERROR: Unable to identify an ordering operator '<' for type '_text'
Use an explicit ordering operator or modify the query

Depending on what you're trying to do, UNION ALL might be an adequate
workaround. UNION is defined to remove duplicates, so it has to sort
the results of the union'ed queries, which requires an ordering
operator. UNION ALL just appends the two query results together...

Yes, UNION ALL is good resolution for me. Thank Tom.

In the long run we probably ought to think about providing ordering
operators for array types.

..hmm :-))

From bouncefilter Tue Sep 28 04:44:14 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 EAA61304
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 04:42:06 -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 MAA03193;
Tue, 28 Sep 1999 12:19:22 +0400 (MSD)
Date: Tue, 28 Sep 1999 12:19:22 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions
In-Reply-To: <199909271926.PAA12410@candle.pha.pa.us>
Message-ID: <Pine.GSO.3.96.SK.990928115218.16613H-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 27 Sep 1999, Bruce Momjian wrote:

Date: Mon, 27 Sep 1999 15:26:08 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
To: Oleg Bartunov <oleg@sai.msu.su>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions

Hi,

this select produces error message:
test=> select test2(NULL);
ERROR: typeidTypeRelid: Invalid type - oid = 0

Not sure how to pass NULL's into functions.

I'm unable to pass NULL also to sql function not only
to plpgsql one. I don't see any reason for this :-)
I'm wondering if I'm the only have this problem.

Regards,

Oleg

test2:
CREATE FUNCTION test2 (int4) RETURNS int4 AS '
Declare
keyval Alias For $1;
cnt int4;
Begin
Update hits set count = count +1 where msg_id = keyval;
return cnt;
End;
' LANGUAGE 'plpgsql';

When I do manually update
Update hits set count = count +1 where msg_id = NULL;
it works fine. What's the problem ?

Regards,

Oleg
test=> \d hits
Table    = hits
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                | Length|
+----------------------------------+----------------------------------+-------+
| msg_id                           | int4                             |     4 |
| count                            | int4                             |     4 |
+----------------------------------+----------------------------------+-------+
test=> select version();
version                                                           
------------------------------------------------------------------
PostgreSQL 6.5.2 on i586-pc-linux-gnulibc1, compiled by gcc 2.95.1
(1 row)
_____________________________________________________________
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

************
-- 
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 Sep 28 04:45:14 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA61535;
Tue, 28 Sep 1999 04:44:06 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <T2ZVSLRT>; Tue, 28 Sep 1999 10:44:06 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C0D0@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'pgsql-interfaces@postgresql.org'" <pgsql-interfaces@postgresql.org>,
"'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: Latest tree
Date: Tue, 28 Sep 1999 10:39:18 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Hi, all,

Whoever is doing the SSL stuff:
In postmaster.c, at lines 995, and 1841, there is code that is not wrapped
in the USE_SSL define.

Last night I checked out the latest source, and couldn't get it to compile.
It seems that the function heap_openr() has a new parameter, and there are
calls that have not been updated yet. I was a little hesitant to go adding
stuff, as the new parameter is a LOCKTYPE, and I wouldn't know what locks
are required where, so I just left well alone. Any comments on this? There
is another function which is paired up with it, but I forget the name, which
also has a new parameter, it seems, and also has calls which have not yet
been updated.

MikeA

From bouncefilter Tue Sep 28 05:02:15 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 FAA65037;
Tue, 28 Sep 1999 05:01:41 -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 RAA03443;
Tue, 28 Sep 1999 17:01:23 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37F083E2.5C40D897@krs.ru>
Date: Tue, 28 Sep 1999 17:01:22 +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: "Ansley, Michael" <Michael.Ansley@intec.co.za>
CC: "'pgsql-interfaces@postgresql.org'" <pgsql-interfaces@postgreSQL.org>,
"'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Latest tree
References: <1BF7C7482189D211B03F00805F8527F748C0D0@S-NATH-EXCH2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Ansley, Michael" wrote:

Hi, all,

Whoever is doing the SSL stuff:
In postmaster.c, at lines 995, and 1841, there is code that is not wrapped
in the USE_SSL define.

Last night I checked out the latest source, and couldn't get it to compile.
It seems that the function heap_openr() has a new parameter, and there are
calls that have not been updated yet. I was a little hesitant to go adding
stuff, as the new parameter is a LOCKTYPE, and I wouldn't know what locks
are required where, so I just left well alone. Any comments on this? There
is another function which is paired up with it, but I forget the name, which
also has a new parameter, it seems, and also has calls which have not yet
been updated.

I fixed all this yesterday while committing my WAL changes...

Vadim

From bouncefilter Tue Sep 28 05:59:21 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA73161;
Tue, 28 Sep 1999 05:58:35 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id SAA03220;
Tue, 28 Sep 1999 18:54:49 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id SAA11141;
Tue, 28 Sep 1999 18:54:48 +0900 (JST)
Message-Id: <199909280954.SAA11141@srapc451.sra.co.jp>
To: Vadim Mikheev <vadim@krs.ru>
cc: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'pgsql-interfaces@postgresql.org'" <pgsql-interfaces@postgreSQL.org>,
"'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: [INTERFACES] Re: [HACKERS] Latest tree
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Tue, 28 Sep 1999 17:01:22 +0800.
<37F083E2.5C40D897@krs.ru>
Date: Tue, 28 Sep 1999 18:54:48 +0900
Sender: t-ishii@srapc451.sra.co.jp

I fixed all this yesterday while committing my WAL changes...

Vadim

Does this mean that now we can enjoy the WAL?:-)

BTW, your WAL implementation will allow database recovery from log
files by using roll-forward or similar techniques?
--
Tatsuo Ishii

From bouncefilter Tue Sep 28 06:26:22 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id GAA75771;
Tue, 28 Sep 1999 06:25:29 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <T2ZVSLYL>; Tue, 28 Sep 1999 12:07:43 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C0D2@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'t-ishii@sra.co.jp'" <t-ishii@sra.co.jp>, Vadim Mikheev
<vadim@krs.ru>
Cc: "'pgsql-interfaces@postgresql.org'" <pgsql-interfaces@postgreSQL.org>,
"'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: RE: [INTERFACES] Re: [HACKERS] Latest tree
Date: Tue, 28 Sep 1999 12:03:00 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Hi, Vadim,

I had a problem compiling, message:

line: 1379
In function 'CreateCheckPoint'
storage size of 'delay' is unknown

It seems to hooch over the struct timeval. Ideas?

MikeA

-----Original Message-----
From: Tatsuo Ishii [mailto:t-ishii@sra.co.jp]
Sent: Tuesday, September 28, 1999 11:55 AM
To: Vadim Mikheev
Cc: Ansley, Michael; 'pgsql-interfaces@postgresql.org';
'pgsql-hackers@postgresql.org'
Subject: Re: [INTERFACES] Re: [HACKERS] Latest tree

I fixed all this yesterday while committing my WAL changes...

Vadim

Does this mean that now we can enjoy the WAL?:-)

BTW, your WAL implementation will allow database recovery from log
files by using roll-forward or similar techniques?
--
Tatsuo Ishii

From bouncefilter Tue Sep 28 06:26:23 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id GAA75789;
Tue, 28 Sep 1999 06:25:39 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <T2ZVSLYX>; Tue, 28 Sep 1999 12:15:18 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C0D3@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'t-ishii@sra.co.jp'" <t-ishii@sra.co.jp>,
"'Vadim Mikheev'" <vadim@krs.ru>
Cc: "'pgsql-interfaces@postgresql.org'" <pgsql-interfaces@postgreSQL.org>,
"'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: RE: [INTERFACES] Re: [HACKERS] Latest tree
Date: Tue, 28 Sep 1999 12:10:35 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Got it. sys/time wasn't #include'd in xlog.c. I probably should have
mentioned the file the last time as well ;-) sorry.

Hi, Vadim,

I had a problem compiling, message:

line: 1379
In function 'CreateCheckPoint'
storage size of 'delay' is unknown

It seems to hooch over the struct timeval. Ideas?

MikeA

-----Original Message-----
From: Tatsuo Ishii [mailto:t-ishii@sra.co.jp]
Sent: Tuesday, September 28, 1999 11:55 AM
To: Vadim Mikheev
Cc: Ansley, Michael; 'pgsql-interfaces@postgresql.org';
'pgsql-hackers@postgresql.org'
Subject: Re: [INTERFACES] Re: [HACKERS] Latest tree

I fixed all this yesterday while committing my WAL changes...

Vadim

Does this mean that now we can enjoy the WAL?:-)

BTW, your WAL implementation will allow database recovery from log
files by using roll-forward or similar techniques?
--
Tatsuo Ishii

From bouncefilter Tue Sep 28 06:51:21 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 GAA81549
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 06:50:34 -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 SAA04231
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 18:50:32 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37F09D78.7436429D@krs.ru>
Date: Tue, 28 Sep 1999 18:50:32 +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: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: [INTERFACES] Re: [HACKERS] Latest tree
References: <1BF7C7482189D211B03F00805F8527F748C0D2@S-NATH-EXCH2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Ansley, Michael" wrote:

Hi, Vadim,

I had a problem compiling, message:

line: 1379
In function 'CreateCheckPoint'
storage size of 'delay' is unknown

It seems to hooch over the struct timeval. Ideas?

I don't know why but sys/time.h was not required under FreeBSD :)

Vadim

From bouncefilter Tue Sep 28 06:52:21 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 GAA81930;
Tue, 28 Sep 1999 06:51:54 -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 SAA04237;
Tue, 28 Sep 1999 18:51:32 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37F09DB4.77C6917C@krs.ru>
Date: Tue, 28 Sep 1999 18:51:32 +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: t-ishii@sra.co.jp
CC: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'pgsql-interfaces@postgresql.org'" <pgsql-interfaces@postgreSQL.org>,
"'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: [INTERFACES] Re: [HACKERS] Latest tree
References: <199909280954.SAA11141@srapc451.sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tatsuo Ishii wrote:

I fixed all this yesterday while committing my WAL changes...

Vadim

Does this mean that now we can enjoy the WAL?:-)

No yet :))

BTW, your WAL implementation will allow database recovery from log
files by using roll-forward or similar techniques?

Yes.

Vadim

From bouncefilter Tue Sep 28 07:14:23 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA85800
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 07:14:17 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <T2ZVSL7J>; Tue, 28 Sep 1999 13:14:18 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C0D4@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Vadim Mikheev'" <vadim@krs.ru>, "'pgsql-hackers@postgresql.org'"
<pgsql-hackers@postgreSQL.org>
Subject: RE: [INTERFACES] Re: [HACKERS] Latest tree
Date: Tue, 28 Sep 1999 13:09:35 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Hmmmm...

Anyway, I added it, and found another glitch in
backend/utils/fmgr/dfmgr.c:106

I changed the function call to heap_close(rel, AccessShareLock);
Do you want a patch for this, and any others that I find?

MikeA

-----Original Message-----
From: Vadim Mikheev [mailto:vadim@krs.ru]
Sent: Tuesday, September 28, 1999 12:51 PM
To: 'pgsql-hackers@postgresql.org'
Subject: Re: [INTERFACES] Re: [HACKERS] Latest tree

"Ansley, Michael" wrote:

Hi, Vadim,

I had a problem compiling, message:

line: 1379
In function 'CreateCheckPoint'
storage size of 'delay' is unknown

It seems to hooch over the struct timeval. Ideas?

I don't know why but sys/time.h was not required under FreeBSD :)

Vadim

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

From bouncefilter Tue Sep 28 07:29:24 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 HAA88857
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 07:28:46 -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 TAA04564;
Tue, 28 Sep 1999 19:28:36 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37F0A662.C3A96A64@krs.ru>
Date: Tue, 28 Sep 1999 19:28:34 +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: "Ansley, Michael" <Michael.Ansley@intec.co.za>
CC: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: [INTERFACES] Re: [HACKERS] Latest tree
References: <1BF7C7482189D211B03F00805F8527F748C0D4@S-NATH-EXCH2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Ansley, Michael" wrote:

Hmmmm...

Anyway, I added it, and found another glitch in
backend/utils/fmgr/dfmgr.c:106

I changed the function call to heap_close(rel, AccessShareLock);

^^^^^^^^^^^^^^^^^^
It was there yesterday but disappeared today, fixed.

Vadim

From bouncefilter Tue Sep 28 08:05:24 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 IAA94306
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 08:04:36 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11VvtZ-0003kLC; Tue, 28 Sep 99 13:58 MET DST
Message-Id: <m11VvtZ-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] RI status report #1
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Tue, 28 Sep 1999 13:58:09 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <28062.938477192@sss.pgh.pa.us> from "Tom Lane" at Sep 27,
99 08:06:32 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Tom Lane wrote:

wieck@debis.com (Jan Wieck) writes:

just to give anyone a chance to complain, I'd like to
describe what I plan to implement for v6.6 in the referential
integrity (RI) corner.

Jan, I have no comments about the RI features, but I am a little worried
about not creating big headaches in merging different changes. Can we
work out a schedule that will minimize tromping on each others' toes?

To avoid this kind of trouble is one of my reasons for the
status report. So others can see which areas will be affected
and we can coordinate a little.

I am in the middle of some fairly extensive revisions in
rewriteManip.c, rewriteHandler.c, and ruleutils.c --- basically,

My changes absolutely don't touch the rule system. Except for
a few lines in tcop, transam and tqual all the work is done
in trigger.c.

I intended to finish these up in the next few days and commit them,
but if you've already started major hacking in these files then maybe
we should find another way.

Do it - I'll wait for you (would you please give me a sign
then). But I'm 97.5% sure our work has no collision areas.

Also, I believe Thomas is in the middle of wide-ranging revisions in
the parser, so you'd better coordinate with him on touching that area.

Ah - that's more critical. I just began to add the SET
CONSTRAINTS command and am through with thinking about the
CREATE CONSTRAINT TRIGGER too. We all know that our parser is
a very delicate peace of software. Thomas, could you please
comment on this?

Jan

From bouncefilter Tue Sep 28 09:02:25 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 JAA03890
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 09:01:27 -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 IAA14479;
Tue, 28 Sep 1999 08:51:43 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909281251.IAA14479@candle.pha.pa.us>
Subject: Re: [HACKERS] 6.5.2
In-Reply-To: <Pine.SOL2.3.96.SK.990928110519.3298A-100000@sun.med.ru> from
Oleg
Broytmann at "Sep 28, 1999 11:06:42 am"
To: phd2@earthling.net
Date: Tue, 28 Sep 1999 08:51:43 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi!

On Mon, 27 Sep 1999, Bruce Momjian wrote:

Oleg, do you seem them now? If not, can you send them to me.

I saw it long time ago and sent my thankx to the list. It seems you
store messages in your mailbox a little too long :)

Yes, I am way behind. I just got off a 4 month job, so I finally had
some time to work on this. With a major release months away, I wasn't
rushing to apply patches. I am now.

-- 
  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 Sep 28 09:13:47 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA06060
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 09:12:46 -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 JAA15766;
Tue, 28 Sep 1999 09:11:56 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909281311.JAA15766@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_upgrade may be mortally wounded
In-Reply-To: <27596.938472000@sss.pgh.pa.us> from Tom Lane at "Sep 27,
1999 06:40:00 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 28 Sep 1999 09:11:56 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Tom, did we address this. I forgot.

No, it's still an open issue as far as I'm concerned. I was hoping to
hear something from Vadim about how pg_upgrade could work safely under
MVCC...

regards, tom lane

Would a solution to this be to add instructions to pg_upgrade to require
the user to stop and restart the postmaster? Seems like that is the
only solution unless we do that stop of postmater inside pg_upgrade, but
that seems risky.

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

BTW, it seems to me that it is a good idea to kill and restart the
postmaster immediately after pg_upgrade finishes. Otherwise there might
be buffers in shared memory that do not reflect the actual contents of
the corresponding pages of the relation files (now that pg_upgrade
overwrote the files with other data).

Your issue with buffer cache is a major one. Clearly, this would be a
problem. However, it is my understanding that the buffer cache after
initdb would only contain system table info, so if they pg_upgrade after
that, there is no way they have bad stuf in the cache, right?

Cached copies of system tables obviously are no problem, since
pg_upgrade doesn't overwrite those. I'm concerned whether there can
be cached copies of pages from user tables or indexes. Since we've
just done a bunch of CREATE INDEXes (and a VACUUM, if my latest hack
is right), it seems at least possible that this would happen.

Now all those user tables will be empty (zero-length files), so there is
nothing to cache. But the user indexes are *not* zero-length --- it looks
like they are at least 2 pages long even when empty. So there seems
to be a real risk of having a cached copy of one of the pages of a user
index while pg_upgrade is overwriting the index file with new data...

-- 
  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 Sep 28 09:30:56 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 JAA11443
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 09:30:42 -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 JAA00254;
Tue, 28 Sep 1999 09:28:49 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: t-ishii@sra.co.jp, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] md.c is feeling much better now, thank you
In-reply-to: Your message of Tue, 28 Sep 1999 00:06:47 -0400 (EDT)
<199909280406.AAA29790@candle.pha.pa.us>
Date: Tue, 28 Sep 1999 09:28:48 -0400
Message-ID: <252.938525328@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Any resolution on this?

I believe I committed Tatsuo's change.

There is still the issue that the parser doesn't obtain any lock on
a relation during parsing, so it's possible to use a slightly stale
relcache entry for parsing purposes. (It can't be *really* stale,
since presumably we just read the SI queue during StartTransaction,
but still it could be wrong if someone commits an ALTER TABLE while
we are parsing our query.)

After thinking about it for a while, I am not sure if we should try to
fix this or not. The obvious fix would be to have the parser grab
AccessShareLock on any relation as soon as it is seen in the query,
and then keep this lock till end of transaction; that would guarantee
that no one else could alter the table structure and thereby invalidate
the parser's information about the relation. But that does not work
because it guarantees deadlock if two processes both try to get
AccessExclusiveLock, as in plain old "BEGIN; LOCK TABLE table; ...".
They'll both be holding AccessShareLock so neither can get exclusive.

There might be another way, but we need to be careful not to choose
a cure that's worse than the disease.

regards, tom lane

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

Ok. I will give another example that seems more serious.
test=> aaa;
ERROR: parser: parse error at or near "aaa"
-- transaction is aborted and the table file t1 is unlinked.
test=> select * from t1;
-- but parser doesn't know t1 does not exist any more.
-- it tries to open t1 using mdopen(). (see including backtrace)
-- mdopen() tries to open t1 and fails. In this case mdopen()
-- creates t1!
NOTICE: (transaction aborted): queries ignored until END
*ABORT STATE*

Hmm. It seems a more straightforward solution would be to alter
pg_parse_and_plan so that the parser isn't even called if we have
already failed the current transaction; that is, the "queries ignored"
test should occur sooner. I'm rather surprised to realize that
we do run the parser in this situation...

I think the long range solution would be let parser obtain certain
locks as Tom said.

That would not solve this particular problem, since the lock manager
wouldn't know any better than the parser that the table doesn't really
exist any more.

Until that I propose following solution. It looks
simple, safe and would be neccessary anyway (I don't know why that
check had not been implemented). See included patches.

This looks like it might be a good change, but I'm not quite as sure
as you are that it won't have any bad effects. Have you tested it?

From bouncefilter Tue Sep 28 09:41:41 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 JAA14296
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 09:41:37 -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 JAA00318;
Tue, 28 Sep 1999 09:40:18 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: "[Jos_] Soares" <jose@sferacarta.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] DROP TABLE inside transaction block
In-reply-to: Your message of Tue, 28 Sep 1999 00:09:10 -0400 (EDT)
<199909280409.AAA29908@candle.pha.pa.us>
Date: Tue, 28 Sep 1999 09:40:17 -0400
Message-ID: <316.938526017@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Seems like good comments on these items. Anything for TODO list here?

Actually, the current state of play is that I reduced the ERROR messages
to NOTICEs in DROP TABLE and DROP INDEX ("NOTICE: DROP TABLE cannot be
rolled back, so don't abort now"), since there seemed to be some
unhappiness about making them hard errors. I also put similar messages
into RENAME TABLE and TRUNCATE TABLE.

I have a personal TODO item to go and insert some more checks: per the
discussions so far, CREATE/DROP DATABASE probably need similar messages,
and I think we need to make VACUUM refuse to run inside a transaction
block at all (since its internal commits will not do the intended thing
if you do BEGIN; VACUUM). Also on my list is to investigate these
reports that CREATE VIEW and ALTER TABLE don't roll back cleanly ---
there may be bugs lurking there. If you want to add those to the
public list, go ahead.

regards, tom lane

=?iso-8859-1?Q?Jos=E9?= Soares <jose@sferacarta.com> writes:

Seems a good solution. I have an old note about this problem.
What about to reject also the following commands inside transactions?

* BUGS: There are some commands that doesn't work properly
inside transactions. Users should NOT use the following
statements inside transactions:

- DROP TABLE -- in case of ROLLBACK only table structure
will be recovered, data will be
lost.
- CREATE VIEWS -- the behavior of the backend is unpredictable.
- ALTER TABLE -- the behavior of the backend is unpredictable.
- CREATE DATABASE -- in case of ROLLBACK will be removed references
from "pg_database" but directory
$PGDATA/databasename will not be removed.

CREATE DATABASE (and presumably also DROP DATABASE) probably should
refuse to run inside a transaction.

I see no good reason that CREATE VIEW or ALTER TABLE should not work
cleanly in a transaction. It may be that they have bugs interfering
with that (for example, Hiroshi just pointed out that ALTER TABLE
seems not to be locking the table, which is surely bogus).

The main reason that DROP TABLE is an issue is that it alters the
underlying Unix file structure, which means we can't just rely on the
normal transaction mechanisms of committed/uncommitted tuples to handle
rollback. ALTER TABLE doesn't do anything except change tuples.
CREATE VIEW is a CREATE TABLE plus tuple changes (and while CREATE TABLE
does alter the file structure by making a new file, we have extra code
in there to handle rolling it back). So it seems like they oughta work.

RENAME TABLE is another thing that can't currently be rolled back,
because it renames the underlying Unix files and there's no mechanism
to undo that. (RENAME TABLE is missing a lock too...)

From bouncefilter Tue Sep 28 09:44:41 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 JAA14607
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 09:43: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 NAA01524;
Tue, 28 Sep 1999 13:43:00 GMT
Sender: lockhart@hub.org
Message-ID: <37F0C5E4.A0E655C0@alumni.caltech.edu>
Date: Tue, 28 Sep 1999 13:43:00 +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: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RI status report #1
References: <m11VvtZ-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Also, I believe Thomas is in the middle of wide-ranging revisions in
the parser, so you'd better coordinate with him on touching that area.

Ah - that's more critical. I just began to add the SET
CONSTRAINTS command and am through with thinking about the
CREATE CONSTRAINT TRIGGER too. We all know that our parser is
a very delicate peace of software. Thomas, could you please
comment on this?

At the moment I am working on join *syntax*, so my changes are
isolated to gram.y, analyze.c, parse_clause.c, and parse_target.c.
Don't wait for me; I'll bet that we don't collide much, and if we do I
don't mind doing the merge.

Sometime later, once I understand the syntax and have it coded for
inner joins, I'll want to start modifying the parser and planner to
handle outer joins. At that point, I'll be asking for help and advice,
and look forward to your input. But I'm not there yet.

I'm hoping to have some updates committed in a week or so, but things
have been going very slowly with little time to work on this :(

- Thomas

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

From bouncefilter Tue Sep 28 09:46:41 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 JAA15247
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 09:46:35 -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 JAA00367;
Tue, 28 Sep 1999 09:45:30 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Bernard Frankpitt <frankpit@pop.dn.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Patch for user-defined C-language functions
In-reply-to: Your message of Tue, 28 Sep 1999 00:11:50 -0400 (EDT)
<199909280411.AAA29966@candle.pha.pa.us>
Date: Tue, 28 Sep 1999 09:45:30 -0400
Message-ID: <365.938526330@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Tom, where are we on this?

It's in my to-do queue. I have to touch the same files anyway in order
to make the world safe for constant-folding, because right now CREATE
FUNCTION only lets you specify the ISCACHABLE flag for a C-language
routine. Need to open that up for all languages, and document it.

I was waiting for Thomas, because I had understood some of his remarks
to mean that he was busy doing a major rearrangement of code in the
parser, but he told me last night to go ahead and commit these changes.
So it should get done shortly.

regards, tom lane

Bernard Frankpitt <frankpit@pop.dn.net> writes:

The solution that I propose, and have implemented in the attatched
patch extends the CREATE FUNCTION syntax as follows.

From bouncefilter Tue Sep 28 10:12:41 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 KAA20262
for <hackers@postgresql.org>; Tue, 28 Sep 1999 10:11:43 -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 OAA01618;
Tue, 28 Sep 1999 14:11:04 GMT
Sender: lockhart@hub.org
Message-ID: <37F0CC78.EFA8B4B0@alumni.caltech.edu>
Date: Tue, 28 Sep 1999 14:11:04 +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: Tom Lane <tgl@sss.pgh.pa.us>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)
References: <m11VxLq-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To coordinate with your work I've included my needs for the
SET CONSTRAINTS command below. I can wait a little with the
other (CREATE CONTRAINT TRIGGER) until you're done - except
you need to lock the parser for loooong time.

I didn't look *carefully*, but I'm sure this is all just fine. If you
have a chance, could you please try adding every new keyword to the
existing alphabetical list in ColId and/or ColLabel? In many cases
keywords which appear in only a limited context can still be allowed
in other places, and when we add new ones we tend to forget to update
this list.

I can do this later if you like; send me a note to remind me after you
commit your changes.

btw, since I'd already done some work on gram.y for join syntax the
patches to get it right aren't all that invasive in that file.

- Thomas

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

From bouncefilter Tue Sep 28 10:34:42 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA25555
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 10:34:34 -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 KAA18169;
Tue, 28 Sep 1999 10:31:03 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909281431.KAA18169@candle.pha.pa.us>
Subject: Re: [HACKERS] Operator definitions
In-Reply-To: <14154.938097658@sss.pgh.pa.us> from Tom Lane at "Sep 23,
1999 10:40:58 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 28 Sep 1999 10:31:03 -0400 (EDT)
CC: Adriaan Joubert <a.joubert@albourne.com>,
Postgresql <pgsql-hackers@postgreSQL.org>,
Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Adriaan Joubert <a.joubert@albourne.com> writes:

OK, here is a patch to allow both ^ and | as operators, both in operator
definitions and expressions. It seems to work for me. Unfortunately the
regression tests do not tell me an awful lot, as several of them fail on
the Alpha anyway. As I don;t really know what I'm doing, I'd appreciate
it if somebody else could check the patch out and let me know whether it
is ok.

If you search for, eg, '%', you will find there are several production
lists that call out all the operators; your patch only caught one of them.

This is a real pain in the neck to maintain, but AFAIK we couldn't
collapse the productions into a single one using MathOp without losing
operator precedence info :-(

It might be helpful if gram.y had annotations like "# Here be MathOps"
so that you could search for the darn things and make sure you had
adjusted each and every production list whenever you added/deleted one.

OK, I have applied a patch to fix all the operator cases for ^ and |.
This will be in 6.6.

The issue is that we want to specify precedence for the common math
operators, and I needed to be able to specify precedence for '|' so people
could do SELECT 'A' | 'B' | 'C'.

-- 
  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 Sep 28 10:40:41 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 KAA27089
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 10:40: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 KAA00644;
Tue, 28 Sep 1999 10:39:22 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Recovery on incomplete write
In-reply-to: Your message of Tue, 28 Sep 1999 13:52:12 +0900
<000d01bf096d$3a22aee0$2801007e@cadzone.tpf.co.jp>
Date: Tue, 28 Sep 1999 10:39:22 -0400
Message-ID: <642.938529562@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

I have wondered that md.c handles incomplete block(page)s
correctly.
Am I mistaken ?

I think you are right, and there may be some other trouble spots in that
file too. I remember thinking that the code depended heavily on never
having a partial block at the end of the file.

But is it worth fixing? The only way I can see for the file length
to become funny is if we run out of disk space part way through writing
a page, which seems unlikely...

regards, tom lane

From bouncefilter Tue Sep 28 10:56:42 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA29992
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 10:55:43 -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 KAA18708;
Tue, 28 Sep 1999 10:54:26 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909281454.KAA18708@candle.pha.pa.us>
Subject: Re: [HACKERS] Recovery on incomplete write
In-Reply-To: <642.938529562@sss.pgh.pa.us> from Tom Lane at "Sep 28,
1999 10:39:22 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 28 Sep 1999 10:54:26 -0400 (EDT)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

I have wondered that md.c handles incomplete block(page)s
correctly.
Am I mistaken ?

I think you are right, and there may be some other trouble spots in that
file too. I remember thinking that the code depended heavily on never
having a partial block at the end of the file.

But is it worth fixing? The only way I can see for the file length
to become funny is if we run out of disk space part way through writing
a page, which seems unlikely...

That is how he got started, the TODO item about running out of disk
space causing corrupted databases. I think it needs a fix, if we can.

-- 
  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 Sep 28 11:06:42 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 LAA31887
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 11:06:32 -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 PAA02770;
Tue, 28 Sep 1999 15:05:20 GMT
Sender: lockhart@hub.org
Message-ID: <37F0D930.779880AD@alumni.caltech.edu>
Date: Tue, 28 Sep 1999 15:05:20 +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: Tom Lane <tgl@sss.pgh.pa.us>, Adriaan Joubert <a.joubert@albourne.com>,
Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Operator definitions
References: <199909281431.KAA18169@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

OK, I have applied a patch to fix all the operator cases for ^ and |.
This will be in 6.6.
The issue is that we want to specify precedence for the common math
operators, and I needed to be able to specify precedence for '|' so people
could do SELECT 'A' | 'B' | 'C'.

I had already posted and applied a patch for the stable branch, since
v6.5.2 was damaged wrt v6.5 functionality. The patch will also appear
in RedHat's rpms for their RH6.1 release. I hadn't yet applied the
patch to the main branch, but have it in my gram.y code where I'm
working on join syntax.

Can you compare your patch of the main branch with the very recent
changes on the stable branch?

Darn, back to cvs merge hell...

- Thomas

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

From bouncefilter Tue Sep 28 11:13:43 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA33112
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 11:13:26 -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 LAA19187;
Tue, 28 Sep 1999 11:12:08 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909281512.LAA19187@candle.pha.pa.us>
Subject: Re: [HACKERS] Operator definitions
In-Reply-To: <37F0D930.779880AD@alumni.caltech.edu> from Thomas Lockhart at
"Sep 28, 1999 03:05:20 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 28 Sep 1999 11:12:08 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Adriaan Joubert <a.joubert@albourne.com>,
Postgresql <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM938531528-14404-0_
Content-Transfer-Encoding: 7bit

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

OK, I have applied a patch to fix all the operator cases for ^ and |.
This will be in 6.6.
The issue is that we want to specify precedence for the common math
operators, and I needed to be able to specify precedence for '|' so people
could do SELECT 'A' | 'B' | 'C'.

I had already posted and applied a patch for the stable branch, since
v6.5.2 was damaged wrt v6.5 functionality. The patch will also appear
in RedHat's rpms for their RH6.1 release. I hadn't yet applied the
patch to the main branch, but have it in my gram.y code where I'm
working on join syntax.

Can you compare your patch of the main branch with the very recent
changes on the stable branch?

Darn, back to cvs merge hell...

Man, there are tons of changes between the two.

Here are the changes I made. I can easily back this out, and re-add
after you are done.

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

--ELM938531528-14404-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/bjm/diff"
Content-Transfer-Encoding: 7bit

Index: gram.y
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/gram.y,v
retrieving revision 2.100
retrieving revision 2.103
diff -c -r2.100 -r2.103
*** gram.y	1999/09/28 04:34:44	2.100
--- gram.y	1999/09/28 14:49:36	2.103
***************
*** 10,16 ****
   *
   *
   * IDENTIFICATION
!  *	  $Header: /usr/local/cvsroot/pgsql/src/backend/parser/gram.y,v 2.100 1999/09/28 04:34:44 momjian Exp $
   *
   * HISTORY
   *	  AUTHOR			DATE			MAJOR EVENT
--- 10,16 ----
   *
   *
   * IDENTIFICATION
!  *	  $Header: /usr/local/cvsroot/pgsql/src/backend/parser/gram.y,v 2.103 1999/09/28 14:49:36 momjian Exp $
   *
   * HISTORY
   *	  AUTHOR			DATE			MAJOR EVENT
***************
*** 977,982 ****
--- 977,984 ----
  				{	$$ = nconc( $1, lcons( makeString( "*"), $3)); }
  			| default_expr '^' default_expr
  				{	$$ = nconc( $1, lcons( makeString( "^"), $3)); }
+ 			| default_expr '|' default_expr
+ 				{	$$ = nconc( $1, lcons( makeString( "|"), $3)); }
  			| default_expr '=' default_expr
  				{	elog(ERROR,"boolean expressions not supported in DEFAULT"); }
  			| default_expr '<' default_expr
***************
*** 1127,1132 ****
--- 1129,1136 ----
  				{	$$ = nconc( $1, lcons( makeString( "*"), $3)); }
  			| constraint_expr '^' constraint_expr
  				{	$$ = nconc( $1, lcons( makeString( "^"), $3)); }
+ 			| constraint_expr '|' constraint_expr
+ 				{	$$ = nconc( $1, lcons( makeString( "|"), $3)); }
  			| constraint_expr '=' constraint_expr
  				{	$$ = nconc( $1, lcons( makeString( "="), $3)); }
  			| constraint_expr '<' constraint_expr
***************
*** 2042,2047 ****
--- 2046,2053 ----
  		| '*'			{ $$ = "*"; }
  		| '/'			{ $$ = "/"; }
  		| '%'			{ $$ = "%"; }
+ 		| '^'			{ $$ = "^"; }
+ 		| '|'			{ $$ = "|"; }
  		| '<'			{ $$ = "<"; }
  		| '>'			{ $$ = ">"; }
  		| '='			{ $$ = "="; }
***************
*** 3638,3643 ****
--- 3644,3651 ----
  		| '*'								{ $$ = "*"; }
  		| '/'								{ $$ = "/"; }
  		| '%'								{ $$ = "%"; }
+ 		| '^'								{ $$ = "^"; }
+ 		| '|'								{ $$ = "|"; }
  		;

  sub_type:  ANY								{ $$ = ANY_SUBLINK; }
***************
*** 3672,3693 ****
  				{	$$ = makeA_Expr(OP, "%", NULL, $2); }
  		| '^' a_expr
  				{	$$ = makeA_Expr(OP, "^", NULL, $2); }
  		| a_expr '%'
  				{	$$ = makeA_Expr(OP, "%", $1, NULL); }
  		| a_expr '^'
  				{	$$ = makeA_Expr(OP, "^", $1, NULL); }
  		| a_expr '+' a_expr
  				{	$$ = makeA_Expr(OP, "+", $1, $3); }
  		| a_expr '-' a_expr
  				{	$$ = makeA_Expr(OP, "-", $1, $3); }
  		| a_expr '/' a_expr
  				{	$$ = makeA_Expr(OP, "/", $1, $3); }
  		| a_expr '%' a_expr
  				{	$$ = makeA_Expr(OP, "%", $1, $3); }
- 		| a_expr '*' a_expr
- 				{	$$ = makeA_Expr(OP, "*", $1, $3); }
  		| a_expr '^' a_expr
  				{	$$ = makeA_Expr(OP, "^", $1, $3); }
  		| a_expr '<' a_expr
  				{	$$ = makeA_Expr(OP, "<", $1, $3); }
  		| a_expr '>' a_expr
--- 3680,3711 ----
  				{	$$ = makeA_Expr(OP, "%", NULL, $2); }
  		| '^' a_expr
  				{	$$ = makeA_Expr(OP, "^", NULL, $2); }
+ 		| '|' a_expr
+ 				{	$$ = makeA_Expr(OP, "|", NULL, $2); }
+ 		| ':' a_expr
+ 				{	$$ = makeA_Expr(OP, ":", NULL, $2); }
+ 		| ';' a_expr
+ 				{	$$ = makeA_Expr(OP, ";", NULL, $2); }
  		| a_expr '%'
  				{	$$ = makeA_Expr(OP, "%", $1, NULL); }
  		| a_expr '^'
  				{	$$ = makeA_Expr(OP, "^", $1, NULL); }
+ 		| a_expr '|'
+ 				{	$$ = makeA_Expr(OP, "|", $1, NULL); }
  		| a_expr '+' a_expr
  				{	$$ = makeA_Expr(OP, "+", $1, $3); }
  		| a_expr '-' a_expr
  				{	$$ = makeA_Expr(OP, "-", $1, $3); }
+ 		| a_expr '*' a_expr
+ 				{	$$ = makeA_Expr(OP, "*", $1, $3); }
  		| a_expr '/' a_expr
  				{	$$ = makeA_Expr(OP, "/", $1, $3); }
  		| a_expr '%' a_expr
  				{	$$ = makeA_Expr(OP, "%", $1, $3); }
  		| a_expr '^' a_expr
  				{	$$ = makeA_Expr(OP, "^", $1, $3); }
+ 		| a_expr '|' a_expr
+ 				{	$$ = makeA_Expr(OP, "|", $1, $3); }
  		| a_expr '<' a_expr
  				{	$$ = makeA_Expr(OP, "<", $1, $3); }
  		| a_expr '>' a_expr
***************
*** 3701,3712 ****

  		| a_expr '=' a_expr
  				{	$$ = makeA_Expr(OP, "=", $1, $3); }
- 		| ':' a_expr
- 				{	$$ = makeA_Expr(OP, ":", NULL, $2); }
- 		| ';' a_expr
- 				{	$$ = makeA_Expr(OP, ";", NULL, $2); }
- 		| '|' a_expr
- 				{	$$ = makeA_Expr(OP, "|", NULL, $2); }
  		| a_expr TYPECAST Typename
  				{
  					$$ = (Node *)$1;
--- 3719,3724 ----
***************
*** 4089,4094 ****
--- 4101,4116 ----
  					n->subselect = $4;
  					$$ = (Node *)n;
  				}
+ 		| a_expr '*' '(' SubSelect ')'
+ 				{
+ 					SubLink *n = makeNode(SubLink);
+ 					n->lefthand = lcons($1, NULL);
+ 					n->oper = lcons("*",NIL);
+ 					n->useor = false;
+ 					n->subLinkType = EXPR_SUBLINK;
+ 					n->subselect = $4;
+ 					$$ = (Node *)n;
+ 				}
  		| a_expr '/' '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
***************
*** 4109,4124 ****
  					n->subselect = $4;
  					$$ = (Node *)n;
  				}
! 		| a_expr '*' '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = lcons($1, NULL);
! 					n->oper = lcons("*",NIL);
  					n->useor = false;
  					n->subLinkType = EXPR_SUBLINK;
  					n->subselect = $4;
  					$$ = (Node *)n;
  				}
  		| a_expr '<' '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
--- 4131,4156 ----
  					n->subselect = $4;
  					$$ = (Node *)n;
  				}
! 		| a_expr '^' '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = lcons($1, NULL);
! 					n->oper = lcons("^",NIL);
  					n->useor = false;
  					n->subLinkType = EXPR_SUBLINK;
  					n->subselect = $4;
  					$$ = (Node *)n;
  				}
+ 		| a_expr '|' '(' SubSelect ')'
+ 				{
+ 					SubLink *n = makeNode(SubLink);
+ 					n->lefthand = lcons($1, NULL);
+ 					n->oper = lcons("|",NIL);
+ 					n->useor = false;
+ 					n->subLinkType = EXPR_SUBLINK;
+ 					n->subselect = $4;
+ 					$$ = (Node *)n;
+ 				}
  		| a_expr '<' '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
***************
*** 4179,4184 ****
--- 4211,4226 ----
  					n->subselect = $5;
  					$$ = (Node *)n;
  				}
+ 		| a_expr '*' ANY '(' SubSelect ')'
+ 				{
+ 					SubLink *n = makeNode(SubLink);
+ 					n->lefthand = lcons($1,NIL);
+ 					n->oper = lcons("*",NIL);
+ 					n->useor = false;
+ 					n->subLinkType = ANY_SUBLINK;
+ 					n->subselect = $5;
+ 					$$ = (Node *)n;
+ 				}
  		| a_expr '/' ANY '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
***************
*** 4199,4209 ****
  					n->subselect = $5;
  					$$ = (Node *)n;
  				}
! 		| a_expr '*' ANY '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = lcons($1,NIL);
! 					n->oper = lcons("*",NIL);
  					n->useor = false;
  					n->subLinkType = ANY_SUBLINK;
  					n->subselect = $5;
--- 4241,4261 ----
  					n->subselect = $5;
  					$$ = (Node *)n;
  				}
! 		| a_expr '^' ANY '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = lcons($1,NIL);
! 					n->oper = lcons("^",NIL);
! 					n->useor = false;
! 					n->subLinkType = ANY_SUBLINK;
! 					n->subselect = $5;
! 					$$ = (Node *)n;
! 				}
! 		| a_expr '|' ANY '(' SubSelect ')'
! 				{
! 					SubLink *n = makeNode(SubLink);
! 					n->lefthand = lcons($1,NIL);
! 					n->oper = lcons("|",NIL);
  					n->useor = false;
  					n->subLinkType = ANY_SUBLINK;
  					n->subselect = $5;
***************
*** 4269,4274 ****
--- 4321,4336 ----
  					n->subselect = $5;
  					$$ = (Node *)n;
  				}
+ 		| a_expr '*' ALL '(' SubSelect ')'
+ 				{
+ 					SubLink *n = makeNode(SubLink);
+ 					n->lefthand = lcons($1, NULL);
+ 					n->oper = lcons("*",NIL);
+ 					n->useor = false;
+ 					n->subLinkType = ALL_SUBLINK;
+ 					n->subselect = $5;
+ 					$$ = (Node *)n;
+ 				}
  		| a_expr '/' ALL '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
***************
*** 4289,4299 ****
  					n->subselect = $5;
  					$$ = (Node *)n;
  				}
! 		| a_expr '*' ALL '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = lcons($1, NULL);
! 					n->oper = lcons("*",NIL);
  					n->useor = false;
  					n->subLinkType = ALL_SUBLINK;
  					n->subselect = $5;
--- 4351,4371 ----
  					n->subselect = $5;
  					$$ = (Node *)n;
  				}
! 		| a_expr '^' ALL '(' SubSelect ')'
  				{
  					SubLink *n = makeNode(SubLink);
  					n->lefthand = lcons($1, NULL);
! 					n->oper = lcons("^",NIL);
! 					n->useor = false;
! 					n->subLinkType = ALL_SUBLINK;
! 					n->subselect = $5;
! 					$$ = (Node *)n;
! 				}
! 		| a_expr '|' ALL '(' SubSelect ')'
! 				{
! 					SubLink *n = makeNode(SubLink);
! 					n->lefthand = lcons($1, NULL);
! 					n->oper = lcons("|",NIL);
  					n->useor = false;
  					n->subLinkType = ALL_SUBLINK;
  					n->subselect = $5;
***************
*** 4363,4390 ****
  				{	$$ = makeA_Expr(OP, "%", NULL, $2); }
  		| '^' b_expr
  				{	$$ = makeA_Expr(OP, "^", NULL, $2); }
  		| b_expr '%'
  				{	$$ = makeA_Expr(OP, "%", $1, NULL); }
  		| b_expr '^'
  				{	$$ = makeA_Expr(OP, "^", $1, NULL); }
  		| b_expr '+' b_expr
  				{	$$ = makeA_Expr(OP, "+", $1, $3); }
  		| b_expr '-' b_expr
  				{	$$ = makeA_Expr(OP, "-", $1, $3); }
  		| b_expr '/' b_expr
  				{	$$ = makeA_Expr(OP, "/", $1, $3); }
  		| b_expr '%' b_expr
  				{	$$ = makeA_Expr(OP, "%", $1, $3); }
- 		| b_expr '*' b_expr
- 				{	$$ = makeA_Expr(OP, "*", $1, $3); }
  		| b_expr '^' b_expr
  				{	$$ = makeA_Expr(OP, "^", $1, $3); }
! 		| ':' b_expr
! 				{	$$ = makeA_Expr(OP, ":", NULL, $2); }
! 		| ';' b_expr
! 				{	$$ = makeA_Expr(OP, ";", NULL, $2); }
! 		| '|' b_expr
! 				{	$$ = makeA_Expr(OP, "|", NULL, $2); }
  		| b_expr TYPECAST Typename
  				{
  					$$ = (Node *)$1;
--- 4435,4466 ----
  				{	$$ = makeA_Expr(OP, "%", NULL, $2); }
  		| '^' b_expr
  				{	$$ = makeA_Expr(OP, "^", NULL, $2); }
+ 		| '|' b_expr
+ 				{	$$ = makeA_Expr(OP, "|", NULL, $2); }
+ 		| ':' b_expr
+ 				{	$$ = makeA_Expr(OP, ":", NULL, $2); }
+ 		| ';' b_expr
+ 				{	$$ = makeA_Expr(OP, ";", NULL, $2); }
  		| b_expr '%'
  				{	$$ = makeA_Expr(OP, "%", $1, NULL); }
  		| b_expr '^'
  				{	$$ = makeA_Expr(OP, "^", $1, NULL); }
+ 		| b_expr '|'
+ 				{	$$ = makeA_Expr(OP, "|", $1, NULL); }
  		| b_expr '+' b_expr
  				{	$$ = makeA_Expr(OP, "+", $1, $3); }
  		| b_expr '-' b_expr
  				{	$$ = makeA_Expr(OP, "-", $1, $3); }
+ 		| b_expr '*' b_expr
+ 				{	$$ = makeA_Expr(OP, "*", $1, $3); }
  		| b_expr '/' b_expr
  				{	$$ = makeA_Expr(OP, "/", $1, $3); }
  		| b_expr '%' b_expr
  				{	$$ = makeA_Expr(OP, "%", $1, $3); }
  		| b_expr '^' b_expr
  				{	$$ = makeA_Expr(OP, "^", $1, $3); }
! 		| b_expr '|' b_expr
! 				{	$$ = makeA_Expr(OP, "|", $1, $3); }
  		| b_expr TYPECAST Typename
  				{
  					$$ = (Node *)$1;

--ELM938531528-14404-0_

--ELM938531528-14404-0_--

From bouncefilter Tue Sep 28 11:17:42 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 LAA33876
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 11:16:53 -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 LAA00866;
Tue, 28 Sep 1999 11:15:13 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Operator definitions
In-reply-to: Your message of Tue, 28 Sep 1999 15:05:20 +0000
<37F0D930.779880AD@alumni.caltech.edu>
Date: Tue, 28 Sep 1999 11:15:12 -0400
Message-ID: <864.938531712@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Darn, back to cvs merge hell...

Yes, Bruce seems to be catching up on his patch queue --- and applying
a lot of old code that needs changes :-(.

regards, tom lane

From bouncefilter Tue Sep 28 11:20:52 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA34569
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 11:20:15 -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 LAA19258;
Tue, 28 Sep 1999 11:19:06 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909281519.LAA19258@candle.pha.pa.us>
Subject: Re: [HACKERS] Operator definitions
In-Reply-To: <864.938531712@sss.pgh.pa.us> from Tom Lane at "Sep 28,
1999 11:15:12 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 28 Sep 1999 11:19:06 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgresql <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Darn, back to cvs merge hell...

Yes, Bruce seems to be catching up on his patch queue --- and applying
a lot of old code that needs changes :-(.

True.

-- 
  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 Sep 28 11:21:43 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA34635
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 11:20:50 -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 LAA19284;
Tue, 28 Sep 1999 11:19:50 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909281519.LAA19284@candle.pha.pa.us>
Subject: Re: [HACKERS] Operator definitions
In-Reply-To: <864.938531712@sss.pgh.pa.us> from Tom Lane at "Sep 28,
1999 11:15:12 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 28 Sep 1999 11:19:50 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgresql <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Darn, back to cvs merge hell...

Yes, Bruce seems to be catching up on his patch queue --- and applying
a lot of old code that needs changes :-(.

Yes. Good news is that I am done.

-- 
  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 Sep 28 11:29:43 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA36287
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 11:29:40 -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 LAA19666;
Tue, 28 Sep 1999 11:26:34 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909281526.LAA19666@candle.pha.pa.us>
Subject: Re: [HACKERS] DROP TABLE inside transaction block
In-Reply-To: <37D50B5C.636B68C2@sferacarta.com> from "[Jos_] Soares" at "Sep
7, 1999 02:55:56 pm"
To: "[Jos_] Soares" <jose@sferacarta.com>
Date: Tue, 28 Sep 1999 11:26:34 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tom Lane is working on this, and it should be improved for 6.6.

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Tom Lane ha scritto:

Pursuant to a phone conversation I had with Bruce, I added code this
morning to reject DROP TABLE or DROP INDEX inside a transaction block;
that is, you can't do BEGIN; DROP TABLE foo; END anymore. The reason
for rejecting this case is that we do the wrong thing if the transaction
is later aborted. Following BEGIN; DROP TABLE foo; ABORT, the system
tables will claim that foo is still valid (since the changes to them
were never committed) but we've already unlinked foo's physical file,
and we can't get it back. Solution: only allow DROP TABLE outside
BEGIN, so that the user can't try to change his mind later.

However, on second thought I wonder if this cure is worse than the
disease. Will it be unreasonably hard to drop tables using client
interfaces that like to wrap everything in BEGIN/END? Plugging an
obscure hole might not be worth that.

A possible compromise is not to error out, but just to issue a NOTICE
along the lines of "DROP TABLE is not undoable, so don't even think of
trying to abort now..."

(Of course, what would be really nice is if it just worked, but I don't
see any way to make that happen without major changes. Simply
postponing the unlink to end of transaction isn't workable; consider
BEGIN; DROP TABLE foo; CREATE TABLE foo; ...)

Any thoughts? Will there indeed be a problem with JDBC or ODBC if we
leave this error check in place?

regards, tom lane

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

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

Seems a good solution. I have an old note about this problem.
What about to reject also the following commands inside transactions?

* BUGS: There are some commands that doesn't work properly
inside transactions. Users should NOT use the following
statements inside transactions:

- DROP TABLE -- in case of ROLLBACK only table structure
will be recovered, data will be
lost.
- CREATE VIEWS -- the behavior of the backend is unpredictable.
- ALTER TABLE -- the behavior of the backend is unpredictable.
- CREATE DATABASE -- in case of ROLLBACK will be removed references
from "pg_database" but directory
$PGDATA/databasename will not be removed.

Jos_

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

-- 
  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 Sep 28 12:12:43 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA44850
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 12:11:43 -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 MAA20393;
Tue, 28 Sep 1999 12:09:23 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909281609.MAA20393@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_upgrade may be mortally wounded
In-Reply-To: <27596.938472000@sss.pgh.pa.us> from Tom Lane at "Sep 27,
1999 06:40:00 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 28 Sep 1999 12:09:23 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Tom, did we address this. I forgot.

No, it's still an open issue as far as I'm concerned. I was hoping to
hear something from Vadim about how pg_upgrade could work safely under
MVCC...

I don't think there is going to be any way to fix the incorrect
postmaster buffers without restarting the postmaster, so I have added
this to the bottom of pg_upgrade:

echo "You must stop/start the postmaster before doing anything else."

and have re-organized the instructions to tell them to stop/start the
postmaster right after running pg_upgrade.

As it is, 6.5.* upgrades can not use it, and 6.6 can not use it either
because base structures will change. It does allow 6.5 people moving to
other 6.5 releases to use initdb to get new features.

Let's close this item.

-- 
  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 Sep 28 13:30:50 1999
Received: from smtp.shellnet.co.uk (smtp.shellnet.co.uk [194.129.209.14])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA61452
for <pgsql-hackers@postgresql.org>;
Tue, 28 Sep 1999 13:30:36 -0400 (EDT)
(envelope-from johnridout@ctasystems.co.uk)
Received: from f6s5f3 (station.ttg.co.uk [194.159.177.252] (may be forged))
by smtp.shellnet.co.uk (8.9.3/8.9.1-shellnet.stevenf) with SMTP id
SAA05632 for <pgsql-hackers@postgresql.org>;
Tue, 28 Sep 1999 18:30:33 +0100 (BST)
Posted-Date: Tue, 28 Sep 1999 18:30:33 +0100 (BST)
From: "John Ridout" <johnridout@ctasystems.co.uk>
To: <pgsql-hackers@postgresql.org>
Subject: MS Access upsizing
Date: Tue, 28 Sep 1999 18:31:19 +0100
Message-ID: <000001bf09d7$4684f340$6701010a@f6s5f3>
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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

Hi,

There is a very handy wizard for upsizing MS Access
to use MS SQL Server as a backend.

Has anyone produced anything similar fro upsizing MS Access
to use PostgreSQL as a backend?

Regards

John Ridout.

From bouncefilter Tue Sep 28 14:04:49 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 OAA68289
for <hackers@postgresql.org>; Tue, 28 Sep 1999 14:04:43 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgresql.org
id m11W1Vx-0003kLC; Tue, 28 Sep 99 19:58 MET DST
Message-Id: <m11W1Vx-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)
To: lockhart@alumni.caltech.edu (Thomas Lockhart)
Date: Tue, 28 Sep 1999 19:58:09 +0200 (MET DST)
Cc: wieck@debis.com, tgl@sss.pgh.pa.us, hackers@postgresql.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37F0CC78.EFA8B4B0@alumni.caltech.edu> from "Thomas Lockhart" at
Sep 28, 99 02:11:04 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Thomas Lockhart wrote:

To coordinate with your work I've included my needs for the
SET CONSTRAINTS command below. I can wait a little with the
other (CREATE CONTRAINT TRIGGER) until you're done - except
you need to lock the parser for loooong time.

I didn't look *carefully*, but I'm sure this is all just fine. If you
have a chance, could you please try adding every new keyword to the
existing alphabetical list in ColId and/or ColLabel? In many cases
keywords which appear in only a limited context can still be allowed
in other places, and when we add new ones we tend to forget to update
this list.

Just tell me which of these SQL3 "reserved" keywords
(according to the SQL3 draft I got from Vadim) should be
available for column ID or Label:

CONSTRAINTS
DEFERRABLE
DEFERRED
IMMEDIATE
INITIALLY
PENDANT
RESTRICT

Then I'll add them before committing. Overlooking the syntax
of my new commands, it wouldn't hurt to add them all to these
lists. But should SQL3 reserved words really be in them?

Jan

From bouncefilter Tue Sep 28 14:06:49 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA68836
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 14:06:27 -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 OAA22873;
Tue, 28 Sep 1999 14:03:56 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909281803.OAA22873@candle.pha.pa.us>
Subject: Re: [HACKERS] PG_UPGRADE status
In-Reply-To: <1726.936836853@sss.pgh.pa.us> from Tom Lane at "Sep 8,
1999 08:27:33 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 28 Sep 1999 14:03:56 -0400 (EDT)
CC: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

pg_upgrade doesn't import the old pg_log into the new database (and
can't very easily, since the new database will have its own), so there's
a problem with recent tuples possibly getting lost.

At the end of pg_upgrade, there are the lines:
mv -f $OLDDIR/pg_log data
mv -f $OLDDIR/pg_variable data
This is used to get the proper transaction status into the new
installation. Is the VACUUM added to pg_upgrade necessary?

I'm sorry, I had that backwards (knew I shoulda checked the code).

pg_upgrade *does* overwrite the destination pg_log, and what that
means is that incoming tuples in user relations should be fine.
What's at risk is recently-committed tuples in the system relations,
notably the metadata that pg_upgrade has just inserted for those
user relations.

The point of the VACUUM is to try to ensure that everything
in the system relations is marked as certainly committed (or
certainly dead) before we discard the pg_log information.
I don't recall ever hearing from Vadim about whether that
is a trustworthy way of doing it, however.

One thing that occurs to me just now is that we probably need
to vacuum *each* database in the new installation. The patch
I added to pg_dump doesn't do the job because it only vacuums
whichever database was dumped last by pg_dumpall...

I have modified pg_upgrade to vacuum all databases, as you suggested.

copy pg_shadow from stdin;
\.
-> VACUUM;
\connect template1 postgres
create database test;
\connect test postgres
\connect - postgres
CREATE TABLE "t1" (

I left your vacuum in there to vacuum the last database. This should
help.

-- 
  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 Sep 28 15:55:50 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA86723
for <hackers@postgreSQL.org>; Tue, 28 Sep 1999 15:54:54 -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 PAA26568;
Tue, 28 Sep 1999 15:53:40 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909281953.PAA26568@candle.pha.pa.us>
Subject: Re: [HACKERS] Heads up: does RULES regress test still work for you?
In-Reply-To: <371C8FC3.4804CF87@bigfoot.com> from Chris Bitmead at "Apr 20,
1999 02:31:31 pm"
To: Chris Bitmead <chris.bitmead@bigfoot.com>
Date: Tue, 28 Sep 1999 15:53:40 -0400 (EDT)
CC: hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Added to TODO list.

Does the following indicate a bug? It sure is wierd. Maybe some of these
statements aren't supported by postgresql (??), but the outcome doesn't
make sense to me.

httpd=> CREATE TABLE x (y text);
CREATE
httpd=> CREATE VIEW z AS select * from x;
CREATE
httpd=> CREATE TABLE a (b text) INHERITS(z);
CREATE
httpd=> INSERT INTO x VALUES ('foo');
INSERT 168602 1
httpd=> select * from z*;
y
---
foo
foo
(2 rows)

How did we suddenly get two rows??

--
Chris Bitmead
http://www.bigfoot.com/~chris.bitmead
mailto:chris.bitmead@bigfoot.com

-- 
  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 Sep 28 16:34:54 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA93719
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 16:34:30 -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 QAA04169;
Tue, 28 Sep 1999 16:32:30 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909282032.QAA04169@candle.pha.pa.us>
Subject: Re: [HACKERS] SYSLOGD facility
In-Reply-To: <Pine.GSO.3.96.SK.990728223505.27569U-100000@ra> from Oleg
Bartunov at "Jul 28, 1999 10:39:58 pm"
To: Oleg Bartunov <oleg@sai.msu.su>
Date: Tue, 28 Sep 1999 16:32:30 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org, dz@cs.unitn.it
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id QAA93741

I just compiled the current source tree with SYSLOGD enabled, and it
compiled fine.

Hi,

Has anyone tried tocompile with SYSLOGD facility enabled ?
I just tried 6.5.1 but couldn't compiled on Linux 2.2.10:

trace.c: In function printf':
trace.c:119: OG_INFO' undeclared (first use in this function)
trace.c:119: (Each undeclared identifier is reported only once
trace.c:119: for each function it appears in.)
trace.c:119: OG_DEBUG' undeclared (first use in this function)
trace.c:96: warning: og_level' might be used uninitialized in this function
trace.c: In function printf':
trace.c:180: OG_ERR' undeclared (first use in this function)
trace.c: In function rite_syslog':
trace.c:207: warning: implicit declaration of function enlog'
trace.c:207: OG_PID' undeclared (first use in this function)
trace.c:207: OG_NDELAY' undeclared (first use in this function)
trace.c:207: OG_LOCAL0' undeclared (first use in this function)

It seems I'm missing something - I just uncomment lines in src/include/config.h
#define ELOG_TIMESTAMPS
#define USE_SYSLOG

btw, I'm not familiar with /etc/syslogd.conf, so what do I need to enable
postgres messages in /usr/adm/pgsql ?
Something like:
*.LOCAL0 /usr/adm/pgsql

Regards,

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

-- 
  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 Sep 28 16:55:51 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA97991
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 16:55:46 -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 QAA04366
for pgsql-hackers@postgreSQL.org; Tue, 28 Sep 1999 16:54:49 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909282054.QAA04366@candle.pha.pa.us>
Subject: My mailbox size
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Tue, 28 Sep 1999 16:54:49 -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

I am down to 52 messages in my PostgreSQL mailbox. That is amazingly
small.

Thanks to Tom Lane for suggesting the new TODO.detail directory, so I
can get the bug reports out of my mailbox and into the CVS distribution.

-- 
  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 Sep 28 22:27:54 1999
Received: from thelab.hub.org (nat194.229.mpoweredpc.net [142.177.194.229])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA56502
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 22:27:27 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA57279;
Tue, 28 Sep 1999 23:27:23 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 28 Sep 1999 23:27:23 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: John Ridout <johnridout@ctasystems.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] MS Access upsizing
In-Reply-To: <000001bf09d7$4684f340$6701010a@f6s5f3>
Message-ID: <Pine.BSF.4.10.9909282327130.33998-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 28 Sep 1999, John Ridout wrote:

Hi,

There is a very handy wizard for upsizing MS Access
to use MS SQL Server as a backend.

Has anyone produced anything similar fro upsizing MS Access
to use PostgreSQL as a backend?

ODBC drivers? *raised eyebrow*

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Sep 28 23:32:25 1999
Received: from johann.inet.co.th (nuchk@johann.inet.co.th [203.150.17.140])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA74831
for <pgsql-hackers@postgreSQL.org>;
Tue, 28 Sep 1999 23:31:19 -0400 (EDT)
(envelope-from nuchk@inet.co.th)
Received: from localhost (nuchk@localhost)
by johann.inet.co.th (8.9.0/8.9.0) with ESMTP id KAA26070
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 10:31:11 +0700 (GMT+0700)
X-Authentication-Warning: johann.inet.co.th: nuchk owned process doing -bs
Date: Wed, 29 Sep 1999 10:31:00 +0700 (GMT+0700)
From: Nuchanach Klinjun <nuchk@inet.co.th>
To: pgsql-hackers@postgreSQL.org
Subject: Returned Result via ODBC!
Message-ID: <Pine.OSF.4.10.9909291030370.25094-100000@johann.inet.co.th>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dear Sir,

I got your email address from the file notice.txt of pub/odbc/
I've problem with getting output from database via ODBC
my query is -->
select s.account,sum(dround(date_part('epoch',s.stop-s.start)/36.0)/100) as
usage,sum(date_part('epoch',s.stop-s.start)/3600*s.rate/t.rate) as charge
from session s,ticket t
where s.stop >= '1999/06/10' and s.stop < '1999/06/21' and
s.ticket = t.id and not t.free and s.nas = '203.151.66.7' group by
s.account;

I use MS Access 97 as frontend application and
ODBC : postodbc 6.4.7
Database : PostgreSQL 6.5.1 on i386-unknown-freebsd2.2.8, compiled by cc

I sent the passthrough query to the postgres backend. it always
return only the first field and the second (account,usage). and I noticed
that the backend always return only some other fields and only 1 sum field
(it's wierd).
with the same query I tried run it on the database promt it return
the complete result.

Please help.

Regards,

-----------------------------------------
Nuchanach Klinjun
R&D Project. Internet Thailand
Email: nuchk@inet.co.th

From bouncefilter Wed Sep 29 00:42:24 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 AAA88262
for <hackers@postgresql.org>; Wed, 29 Sep 1999 00:42:05 -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 EAA04566;
Wed, 29 Sep 1999 04:41:26 GMT
Sender: lockhart@hub.org
Message-ID: <37F19876.D0852A9B@alumni.caltech.edu>
Date: Wed, 29 Sep 1999 04:41:26 +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: tgl@sss.pgh.pa.us, hackers@postgresql.org
Subject: Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)
References: <m11W1Vx-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Just tell me which of these SQL3 "reserved" keywords
(according to the SQL3 draft I got from Vadim) should be
available for column ID or Label:
CONSTRAINTS
DEFERRABLE
DEFERRED
IMMEDIATE
INITIALLY
PENDANT
RESTRICT
Then I'll add them before committing. Overlooking the syntax
of my new commands, it wouldn't hurt to add them all to these
lists. But should SQL3 reserved words really be in them?

We have tried to allow as many keywords as possible for identifiers
(for ColId, which includes ColLabel) or, as a more limited choice, for
column aliases (ColLabel only). This is particularly helpful as we
implement more and more of the standard, and take away previously
allowed column and table names. The keywords, reserved, unreserved,
and unused, are documented for Postgres in syntax.sgml, and the docs
present them wrt the SQL92 and SQL3 standards.

What I usually do is try adding one or all of them to ColId, and if
that fails by giving shift/reduce conflicts I'll try moving the
offenders to ColLabel. There aren't many places in the syntax where
yacc/bison can't handle keywords at least as column labels.

- Thomas

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

From bouncefilter Wed Sep 29 01:45:28 1999
Received: from web2102.mail.yahoo.com (web2102.mail.yahoo.com [128.11.68.246])
by hub.org (8.9.3/8.9.3) with SMTP id BAA97205
for <pgsql-hackers@postgresql.org>;
Wed, 29 Sep 1999 01:44:53 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19990929054551.28801.rocketmail@web2102.mail.yahoo.com>
Received: from [206.246.185.100] by web2102.mail.yahoo.com;
Tue, 28 Sep 1999 22:45:51 PDT
Date: Tue, 28 Sep 1999 22:45:51 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] DROP TABLE inside transaction block
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- Tom Lane <tgl@sss.pgh.pa.us> wrote:

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

Seems like good comments on these items. Anything

for TODO list here?

Actually, the current state of play is that I
reduced the ERROR messages
to NOTICEs in DROP TABLE and DROP INDEX ("NOTICE:
DROP TABLE cannot be
rolled back, so don't abort now"), since there
seemed to be some
unhappiness about making them hard errors. I also
put similar messages
into RENAME TABLE and TRUNCATE TABLE.

I have a personal TODO item to go and insert some
more checks: per the
discussions so far, CREATE/DROP DATABASE probably
need similar messages,
and I think we need to make VACUUM refuse to run
inside a transaction
block at all (since its internal commits will not do
the intended thing
if you do BEGIN; VACUUM). Also on my list is to
investigate these
reports that CREATE VIEW and ALTER TABLE don't roll
back cleanly ---
there may be bugs lurking there. If you want to add
those to the
public list, go ahead.

regards, tom lane

If my TRUNCATE TABLE patch was applied as submitted,
(I haven't downloaded a newer snapshot yet), then
it falls into category #2...same as VACUUM. It
commits the current transaction before truncating
the specified relation, then begins a new transaction.
Quite frankly, as Vadim pointed out in earlier posts,
PostgreSQL attempts to go "above and beyond" with
respect to rolling back transactions which contain
DDL statements.

From the ORACLE 7 Server Manual:

Transaction

A transaction (or a logical unit of work) is a
sequence
of SQL statements that ORACLE treats as a single unit.
A transaction begins with the first executable SQL
statement after a COMMIT, ROLLBACK or connection to
ORACLE. A transaction ends with a COMMIT statement, a
ROLLBACK statement, or disconnection (intentional or
unintentional) from ORACLE. ORACLE issues an implicit
^^^^^^^^^^^^^^^^^^^^^^^^^
COMMIT before and after any Data Definition Language
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
statement.
^^^^^^^^^

Anyways, so did the TRUNCATE TABLE patch.

For what its worth,

Mike Mascari
(mascarim@yahoo.com)

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

From bouncefilter Wed Sep 29 03:18:26 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 DAA13384
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 03:18:16 -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 QAA00703; Wed, 29 Sep 1999 16:16:35 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>,
"Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Recovery on incomplete write
Date: Wed, 29 Sep 1999 16:20:14 +0900
Message-ID: <001001bf0a4b$12b46360$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
In-reply-to: <199909281454.KAA18708@candle.pha.pa.us>
Importance: Normal

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: Tuesday, September 28, 1999 11:54 PM
To: Tom Lane
Cc: Hiroshi Inoue; pgsql-hackers
Subject: Re: [HACKERS] Recovery on incomplete write

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

I have wondered that md.c handles incomplete block(page)s
correctly.
Am I mistaken ?

I think you are right, and there may be some other trouble spots in that
file too. I remember thinking that the code depended heavily on never
having a partial block at the end of the file.

But is it worth fixing? The only way I can see for the file length
to become funny is if we run out of disk space part way through writing
a page, which seems unlikely...

That is how he got started, the TODO item about running out of disk
space causing corrupted databases. I think it needs a fix, if we can.

Maybe it isn't so difficult to fix.
I would provide a patch.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Wed Sep 29 04:19:27 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA20870
for <pgsql-hackers@postgresql.org>;
Wed, 29 Sep 1999 04:18:55 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <T2ZVSM6P>; Wed, 29 Sep 1999 10:18:44 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C0DB@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'John Ridout'" <johnridout@ctasystems.co.uk>,
pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] MS Access upsizing
Date: Wed, 29 Sep 1999 09:59:05 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

I believe Dave Page is thinking of putting that into pgAdmin, but you'll
need to check that with him.
Check on the pgAdmin page for features as well ->
http://www.pgadmin.freeserve.co.uk/

MikeA

-----Original Message-----
From: John Ridout [mailto:johnridout@ctasystems.co.uk]
Sent: Tuesday, September 28, 1999 7:31 PM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] MS Access upsizing

Hi,

There is a very handy wizard for upsizing MS Access
to use MS SQL Server as a backend.

Has anyone produced anything similar fro upsizing MS Access
to use PostgreSQL as a backend?

Regards

John Ridout.

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

From bouncefilter Wed Sep 29 04:45:27 1999
Received: from mail.kdt.de (mail.kdt.de [195.8.224.4])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA24773
for <pgsql-hackers@postgresql.org>;
Wed, 29 Sep 1999 04:45:23 -0400 (EDT)
(envelope-from christof.petig@wtal.de)
Received: from gateway.petig.de (line0034lf.kdt.de [195.8.241.34])
by mail.kdt.de (8.8.8/8.8.8) with ESMTP id KAA05589
for <pgsql-hackers@postgresql.org>; Wed, 29 Sep 1999 10:45:20 +0200
Received: from wtal.de (christof@[192.168.230.9])
by gateway (8.8.8/8.8.8) with ESMTP id KAA13796
for <pgsql-hackers@postgresql.org>; Wed, 29 Sep 1999 10:39:44 +0200
Sender: christof@to.wtal.de
Message-ID: <37F1D043.635CFC6C@wtal.de>
Date: Wed, 29 Sep 1999 10:39:32 +0200
From: Christof Petig <christof.petig@wtal.de>
Organization: Adolf Petig GmbH. & Co. KG
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.7 i586)
X-Accept-Language: de
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Recovery on incomplete write
References: <199909281454.KAA18708@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

I think you are right, and there may be some other trouble spots in that
file too. I remember thinking that the code depended heavily on never
having a partial block at the end of the file.

But is it worth fixing? The only way I can see for the file length
to become funny is if we run out of disk space part way through writing
a page, which seems unlikely...

That is how he got started, the TODO item about running out of disk
space causing corrupted databases. I think it needs a fix, if we can.

It does corrupt the database (happened twice to me last week, I'm using the
current CVS version!). You can't even pg_dump the database - it stops in the
middle of a line.
And this happened just because some process went amok and stdout was written
to a file.

Christof

From bouncefilter Wed Sep 29 09:44:32 1999
Received: from mail.kdt.de (mail.kdt.de [195.8.224.4])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA70504;
Wed, 29 Sep 1999 09:44:27 -0400 (EDT)
(envelope-from christof.petig@wtal.de)
Received: from gateway.petig.de (line0155lf.kdt.de [195.8.241.155])
by mail.kdt.de (8.8.8/8.8.8) with ESMTP id PAA19571;
Wed, 29 Sep 1999 15:44:25 +0200
Received: from wtal.de (christof@[192.168.230.9])
by gateway (8.8.8/8.8.8) with ESMTP id KAA13905;
Wed, 29 Sep 1999 10:56:19 +0200
Sender: christof@to.wtal.de
Message-ID: <37F1D427.25B49C94@wtal.de>
Date: Wed, 29 Sep 1999 10:56:07 +0200
From: Christof Petig <christof.petig@wtal.de>
Organization: Adolf Petig GmbH. & Co. KG
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.7 i586)
X-Accept-Language: de
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
CC: Michael Meskes <meskes@postgresql.org>
Subject: Re: [PATCHES] ECPGlib: NULL into bool, force indicator on NULL (2
patches)
References: <199909271916.PAA12328@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Since the message didn't come back to me via the list (I sent it last
Tuesday), I resend it, this time to pgsql-hackers, because I think the
discussion doesn't belong to PATCHES.

Bruce Momjian wrote:

Applied. Thanks. You can report any ecpg problems to the bugs list.

Ok, I'll flood the list ;-)

WARNING: My patch breaks existing code!
If an ecpg program did not provide an indicator variable the library set
the variable to zero.
Now it will return an error.

I would also like to address a remaining problem:
should ecpglib touch the host variable if the result is NULL and an
indicator
variable is given?
Ecpglib so far zeroed the variable, my patch doesn't touch the bool
variable.
What does the standard say about this? (Adabas e.g. doesn't touch the
variable.)

Christof

From bouncefilter Wed Sep 29 05:21:27 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 FAA31164
for <hackers@postgresql.org>; Wed, 29 Sep 1999 05:20:35 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgresql.org
id m11WFnM-0003kLC; Wed, 29 Sep 99 11:13 MET DST
Message-Id: <m11WFnM-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)
To: lockhart@alumni.caltech.edu (Thomas Lockhart)
Date: Wed, 29 Sep 1999 11:13:04 +0200 (MET DST)
Cc: wieck@debis.com, tgl@sss.pgh.pa.us, hackers@postgresql.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37F19876.D0852A9B@alumni.caltech.edu> from "Thomas Lockhart" at
Sep 29, 99 04:41:26 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

CONSTRAINTS
DEFERRABLE
DEFERRED
IMMEDIATE
INITIALLY
PENDANT
RESTRICT

[...]
allowed column and table names. The keywords, reserved, unreserved,
and unused, are documented for Postgres in syntax.sgml, and the docs
present them wrt the SQL92 and SQL3 standards.

What I usually do is try adding one or all of them to ColId, and if
that fails by giving shift/reduce conflicts I'll try moving the
offenders to ColLabel. There aren't many places in the syntax where
yacc/bison can't handle keywords at least as column labels.

O.K. - I was able to add them all to ColId without conflicts
for now. Let's see what happens after adding the syntax for
CREATE CONSTRAINT TRIGGER.

I'm not sure which of them are SQL92 or SQL3, at least they
are all SQL3 "reserved" words according to the SQL3 draft.

Jan

From bouncefilter Wed Sep 29 05:19:27 1999
Received: from smtp.shellnet.co.uk (smtp.shellnet.co.uk [194.129.209.14])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA30710
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 05:18:40 -0400 (EDT)
(envelope-from johnridout@ctasystems.co.uk)
Received: from f6s5f3 (station.ttg.co.uk [194.159.177.252] (may be forged))
by smtp.shellnet.co.uk (8.9.3/8.9.1-shellnet.stevenf) with SMTP id
KAA02799; Wed, 29 Sep 1999 10:18:30 +0100 (BST)
Posted-Date: Wed, 29 Sep 1999 10:18:30 +0100 (BST)
From: "John Ridout" <johnridout@ctasystems.co.uk>
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
<pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] MS Access upsizing
Date: Wed, 29 Sep 1999 10:19:15 +0100
Message-ID: <000101bf0a5b$b3867b60$6701010a@f6s5f3>
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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <1BF7C7482189D211B03F00805F8527F748C0DB@S-NATH-EXCH2>

Thanks for the link.
Unfortunately the code is not open source.
I'll put a little something together this
weekend and stick it on my website.
See it we can't tempt a few MS Access users
to go for PostgreSQL instead of MS SQLServer.

Regards

John.

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Ansley, Michael
Sent: 29 September 1999 08:59
To: 'John Ridout'; pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] MS Access upsizing

I believe Dave Page is thinking of putting that into pgAdmin, but you'll
need to check that with him.
Check on the pgAdmin page for features as well ->
http://www.pgadmin.freeserve.co.uk/

MikeA

-----Original Message-----
From: John Ridout [mailto:johnridout@ctasystems.co.uk]
Sent: Tuesday, September 28, 1999 7:31 PM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] MS Access upsizing

Hi,

There is a very handy wizard for upsizing MS Access
to use MS SQL Server as a backend.

Has anyone produced anything similar fro upsizing MS Access
to use PostgreSQL as a backend?

Regards

John Ridout.

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

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

From bouncefilter Wed Sep 29 05:26:27 1999
Received: from smtp.shellnet.co.uk (smtp.shellnet.co.uk [194.129.209.14])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA32079
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 05:26:05 -0400 (EDT)
(envelope-from johnridout@ctasystems.co.uk)
Received: from f6s5f3 (station.ttg.co.uk [194.159.177.252] (may be forged))
by smtp.shellnet.co.uk (8.9.3/8.9.1-shellnet.stevenf) with SMTP id
KAA03120; Wed, 29 Sep 1999 10:26:03 +0100 (BST)
Posted-Date: Wed, 29 Sep 1999 10:26:03 +0100 (BST)
From: "John Ridout" <johnridout@ctasystems.co.uk>
To: "The Hermit Hacker" <scrappy@hub.org>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] MS Access upsizing
Date: Wed, 29 Sep 1999 10:26:48 +0100
Message-ID: <000201bf0a5c$c1736f20$6701010a@f6s5f3>
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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Pine.BSF.4.10.9909282327130.33998-100000@thelab.hub.org>

Someone has already done the ODBC
Look in the PostgreSQL Programmer's Guide under Interfaces. ;-)

Or perhaps you mean it will be difficult over ODBC.
I intend to pass the DDL to PostgreSQL to execute.

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of The Hermit
Hacker
Sent: 29 September 1999 03:27
To: John Ridout
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] MS Access upsizing

On Tue, 28 Sep 1999, John Ridout wrote:

Hi,

There is a very handy wizard for upsizing MS Access
to use MS SQL Server as a backend.

Has anyone produced anything similar fro upsizing MS Access
to use PostgreSQL as a backend?

ODBC drivers? *raised eyebrow*

Marc G. Fournier ICQ#7615664 IRC
Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary:
scrappy@{freebsd|postgresql}.org

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

From bouncefilter Wed Sep 29 06:20:29 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 GAA40255
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 06:19:55 -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 OAA08228
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 14:19:35 +0400 (MSD)
Date: Wed, 29 Sep 1999 14:19:35 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions (fwd)
Message-ID: <Pine.GSO.3.96.SK.990929135438.16613m-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Excuse me for reposting,

I just want to be sure my original posting doesn't lost.
Is this a bug or feature ?
Also, it seems there is a limitation to a number of arguments.

Regards,
Oleg

---------- Forwarded message ----------
Date: Mon, 27 Sep 1999 15:26:08 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
To: Oleg Bartunov <oleg@sai.msu.su>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions

Hi,

this select produces error message:
test=> select test2(NULL);
ERROR: typeidTypeRelid: Invalid type - oid = 0

Not sure how to pass NULL's into functions.

test2:
CREATE FUNCTION test2 (int4) RETURNS int4 AS '
Declare
keyval Alias For $1;
cnt int4;
Begin
Update hits set count = count +1 where msg_id = keyval;
return cnt;
End;
' LANGUAGE 'plpgsql';

When I do manually update
Update hits set count = count +1 where msg_id = NULL;
it works fine. What's the problem ?

Regards,

Oleg
test=> \d hits
Table    = hits
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                | Length|
+----------------------------------+----------------------------------+-------+
| msg_id                           | int4                             |     4 |
| count                            | int4                             |     4 |
+----------------------------------+----------------------------------+-------+
test=> select version();
version                                                           
------------------------------------------------------------------
PostgreSQL 6.5.2 on i586-pc-linux-gnulibc1, compiled by gcc 2.95.1
(1 row)
_____________________________________________________________
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

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

-- 
  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 Wed Sep 29 09:41:33 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA69965
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 09:40:46 -0400 (EDT) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA28517
for <pgsql-hackers@postgreSQL.org>; Wed, 29 Sep 1999 14:32:00 +0200
Date: Wed, 29 Sep 1999 14:32:00 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: string function
Message-ID: <Pine.LNX.3.96.990929141359.27070B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

I wrote new buildin functions (inspired with ...src/backend/utils/adt):

text *asterisk(text *string) - Returns string, with all letters is
'*' and length of new string is equal
to original string.

text *pgcrypt(text *string) - Returns string, cryped via DES crypt(3).

Do somebody want this func. ? I try write more string func. if will
interest.. (in PSQL is not strcat(), md5() ...etc.).

Zakkr

PS. sorry I new in PSQL development, but PSQL programing is very interest
for me :-))

From bouncefilter Wed Sep 29 09:03:30 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA64012
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 09:03:25 -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 JAA25040;
Wed, 29 Sep 1999 09:02:10 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909291302.JAA25040@candle.pha.pa.us>
Subject: Re: [HACKERS] DROP TABLE inside transaction block
In-Reply-To: <19990929054551.28801.rocketmail@web2102.mail.yahoo.com> from
Mike
Mascari at "Sep 28, 1999 10:45:51 pm"
To: Mike Mascari <mascarim@yahoo.com>
Date: Wed, 29 Sep 1999 09:02:10 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

If my TRUNCATE TABLE patch was applied as submitted,
(I haven't downloaded a newer snapshot yet), then

Yes, applied.

-- 
  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 Wed Sep 29 09:35:32 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA68940
for <hackers@postgresql.org>; Wed, 29 Sep 1999 09:35:24 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from localhost (root@hectic-1.jpl.nasa.gov [128.149.68.203])
by trends.net (8.8.8/8.8.8) with ESMTP id JAA26281
for <hackers@postgresql.org>; Wed, 29 Sep 1999 09:11:22 -0400 (EDT)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id NAA08893;
Wed, 29 Sep 1999 13:10:29 GMT
Sender: lockhart@trends.net
Message-ID: <37F20FC5.55444A1B@alumni.caltech.edu>
Date: Wed, 29 Sep 1999 13:10:29 +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: tgl@sss.pgh.pa.us, hackers@postgresql.org
Subject: Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)
References: <m11WFnM-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

CONSTRAINTS
DEFERRABLE
DEFERRED
IMMEDIATE
INITIALLY
PENDANT
RESTRICT

O.K. - I was able to add them all to ColId without conflicts
for now. Let's see what happens after adding the syntax for
CREATE CONSTRAINT TRIGGER.

Right. Anything which causes trouble can be demoted to ColLabel.

I'm not sure which of them are SQL92 or SQL3, at least they
are all SQL3 "reserved" words according to the SQL3 draft.

According to my Date and Darwen (which is mostly SQL92), all of these
except "PENDANT" are SQL92 reserved words. PENDANT is not mentioned,
so is presumably an SQL3-ism.

Do you want me to update syntax.sgml?

- Thomas

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

From bouncefilter Wed Sep 29 10:40:34 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA84032
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 10:40:23 -0400 (EDT) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA31542;
Wed, 29 Sep 1999 15:31:29 +0200
Date: Wed, 29 Sep 1999 15:31:29 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: "D'Arcy J.M. Cain" <darcy@druid.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] string function
In-Reply-To: <m11WKO3-0000dVC@druid.net>
Message-ID: <Pine.LNX.3.96.990929151357.28808B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 29 Sep 1999, D'Arcy J.M. Cain wrote:

Thus spake Zakkr

text *pgcrypt(text *string) - Returns string, cryped via DES crypt(3).

Do somebody want this func. ? I try write more string func. if will
interest.. (in PSQL is not strcat(), md5() ...etc.).

Careful. This could affect the ability to distribute the code world wide.
I know that the server is in Canada but we have mirrors in the US.

Yes, I know unimaginable US restrictions... pgcrypt() is experiment for me
(I need it in my project) - I want write other func. for world wide.

Try somebody implemeny strftime(),strcat() to PSQL ? -
(is any problem in PSQL, that not exist more string/date/..etc functions or
is problem with programmer absence (only) ?)

Zakkr

From bouncefilter Wed Sep 29 09:34:31 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 JAA68544
for <pgsql-hackers@postgresql.org>;
Wed, 29 Sep 1999 09:34:29 -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 JAA03245;
Wed, 29 Sep 1999 09:33:52 -0400 (EDT)
To: Mike Mascari <mascarim@yahoo.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] DROP TABLE inside transaction block
In-reply-to: Your message of Tue, 28 Sep 1999 22:45:51 -0700 (PDT)
<19990929054551.28801.rocketmail@web2102.mail.yahoo.com>
Date: Wed, 29 Sep 1999 09:33:52 -0400
Message-ID: <3242.938612032@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Mike Mascari <mascarim@yahoo.com> writes:

If my TRUNCATE TABLE patch was applied as submitted,
(I haven't downloaded a newer snapshot yet), then
it falls into category #2...same as VACUUM. It
commits the current transaction before truncating
the specified relation, then begins a new transaction.

I took all that out ;-) while updating it to compile against the current
state of heap_open et al. I see no need for multiple transactions in
TRUNCATE. It's really on a par with RENAME TABLE, since both have to
force a buffer flush.

regards, tom lane

From bouncefilter Wed Sep 29 09:48:32 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 JAA71352
for <hackers@postgresql.org>; Wed, 29 Sep 1999 09:47:54 -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 NAA09838;
Wed, 29 Sep 1999 13:47:16 GMT
Sender: lockhart@hub.org
Message-ID: <37F21864.3A0B8DFB@alumni.caltech.edu>
Date: Wed, 29 Sep 1999 13:47:16 +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: Postgres Hackers List <hackers@postgresql.org>
Subject: New notices?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

postgres=> select * from t4;
NOTICE: Adding missing FROM-clause entry for table t4
m|n
-+-
...

I updated my current tree and now this message comes out on even
simple queries. Is it supposed to be there? If so, why??

- Thomas

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

From bouncefilter Wed Sep 29 09:58:38 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 JAA73394
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 09:58:10 -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 JAA03330;
Wed, 29 Sep 1999 09:55:16 -0400 (EDT)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions (fwd)
In-reply-to: Your message of Wed, 29 Sep 1999 14:19:35 +0400 (MSD)
<Pine.GSO.3.96.SK.990929135438.16613m-100000@ra>
Date: Wed, 29 Sep 1999 09:55:15 -0400
Message-ID: <3328.938613315@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Is this a bug or feature ?

It's a bug. Fixing it will require a wholesale code revision, however
(see my prior postings about redesigning the function call interface).

This is something we need to do for 6.6, IMHO, not only because of
the NULL-argument issue but also because it will solve the portability
problems that are being created by the existing fmgr interface (Alpha
bugs, need to dumb down to -O0 on some platforms, etc). I've been
trying to summon the will to get started on it, but other things keep
getting in the way...

Also, it seems there is a limitation to a number of arguments.

Yes, 8. I'm not planning to do anything about that in the near term.
Even just making the limit configurable would be a lot of work :-(

regards, tom lane

From bouncefilter Wed Sep 29 10:10:32 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 KAA76256
for <hackers@postgresql.org>; Wed, 29 Sep 1999 10:09:34 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgresql.org
id m11WKK1-0003kLC; Wed, 29 Sep 99 16:03 MET DST
Message-Id: <m11WKK1-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)
To: lockhart@alumni.caltech.edu (Thomas Lockhart)
Date: Wed, 29 Sep 1999 16:03:05 +0200 (MET DST)
Cc: wieck@debis.com, tgl@sss.pgh.pa.us, hackers@postgresql.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37F20FC5.55444A1B@alumni.caltech.edu> from "Thomas Lockhart" at
Sep 29, 99 01:10:29 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Thomas Lockhart wrote:

CONSTRAINTS
DEFERRABLE
DEFERRED
IMMEDIATE
INITIALLY
PENDANT
RESTRICT

O.K. - I was able to add them all to ColId without conflicts
for now. Let's see what happens after adding the syntax for
CREATE CONSTRAINT TRIGGER.

Right. Anything which causes trouble can be demoted to ColLabel.

I'm not sure which of them are SQL92 or SQL3, at least they
are all SQL3 "reserved" words according to the SQL3 draft.

According to my Date and Darwen (which is mostly SQL92), all of these
except "PENDANT" are SQL92 reserved words. PENDANT is not mentioned,
so is presumably an SQL3-ism.

Do you want me to update syntax.sgml?

Please be so kind. CREATE CONSTRAINT TRIGGER did not mess up
anything, so all these new reserved words appear in ColId and
are still available.

Jan

From bouncefilter Wed Sep 29 10:05: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 KAA75378
for <hackers@postgreSQL.org>; Wed, 29 Sep 1999 10:05:41 -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 KAA03447;
Wed, 29 Sep 1999 10:03:58 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] New notices?
In-reply-to: Your message of Wed, 29 Sep 1999 13:47:16 +0000
<37F21864.3A0B8DFB@alumni.caltech.edu>
Date: Wed, 29 Sep 1999 10:03:58 -0400
Message-ID: <3445.938613838@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

postgres=> select * from t4;
NOTICE: Adding missing FROM-clause entry for table t4

Hoo, boy. I think your change didn't quite work right, Bruce...

regards, tom lane

From bouncefilter Wed Sep 29 10:07:32 1999
Received: from druid.net (root@druid.net [216.126.72.98])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA75782
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 10:07:16 -0400 (EDT) (envelope-from darcy@druid.net)
Received: from localhost (1141 bytes) by druid.net
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <darcy>) (ident <darcy> using unix)
id <m11WKO3-0000dVC@druid.net> for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 10:07:15 -0400 (EDT)
(Smail-3.2.0.104 1998-Nov-20 #4 built 1999-Apr-13)
Message-Id: <m11WKO3-0000dVC@druid.net>
Subject: Re: [HACKERS] string function
In-Reply-To: <Pine.LNX.3.96.990929141359.27070B-100000@ara.zf.jcu.cz> from
Zakkr at "Sep 29, 1999 02:32:00 pm"
To: zakkr@zf.jcu.cz (Zakkr)
Date: Wed, 29 Sep 1999 10:07:14 -0400 (EDT)
From: "D'Arcy" "J.M." Cain <darcy@druid.net>
Cc: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL50 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thus spake Zakkr

text *pgcrypt(text *string) - Returns string, cryped via DES crypt(3).

Do somebody want this func. ? I try write more string func. if will
interest.. (in PSQL is not strcat(), md5() ...etc.).

Careful. This could affect the ability to distribute the code world wide.
I know that the server is in Canada but we have mirrors in the US.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

From bouncefilter Wed Sep 29 10:34:41 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 KAA82591
for <hackers@postgresql.org>; Wed, 29 Sep 1999 10:34:15 -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 KAA26120;
Wed, 29 Sep 1999 10:14:18 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909291414.KAA26120@candle.pha.pa.us>
Subject: Re: New notices?
In-Reply-To: <37F21864.3A0B8DFB@alumni.caltech.edu> from Thomas Lockhart at
"Sep 29, 1999 01:47:16 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Wed, 29 Sep 1999 10:14:17 -0400 (EDT)
CC: Postgres Hackers List <hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

postgres=> select * from t4;
NOTICE: Adding missing FROM-clause entry for table t4
m|n
-+-
...

I updated my current tree and now this message comes out on even
simple queries. Is it supposed to be there? If so, why??

Strange. I don't get it:

test=> select * from pg_language;
lanname |lanispl|lanpltrusted|lanplcallfoid|lancompiler
--------+-------+------------+-------------+--------------
internal|f |f | 0|n/a
lisp |f |f | 0|/usr/ucb/liszt
C |f |f | 0|/bin/cc
sql |f |f | 0|postgres
(4 rows)

-- 
  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 Wed Sep 29 10:30:33 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 KAA81999
for <hackers@postgreSQL.org>; Wed, 29 Sep 1999 10:30:28 -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 KAA26135;
Wed, 29 Sep 1999 10:15:17 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909291415.KAA26135@candle.pha.pa.us>
Subject: Re: [HACKERS] New notices?
In-Reply-To: <3445.938613838@sss.pgh.pa.us> from Tom Lane at "Sep 29,
1999 10:03:58 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 29 Sep 1999 10:15:17 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

postgres=> select * from t4;
NOTICE: Adding missing FROM-clause entry for table t4

Hoo, boy. I think your change didn't quite work right, Bruce...

Do you see it there too? I can't see it here. Let me cvs update.

-- 
  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 Wed Sep 29 10:35:41 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 KAA82971
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 10:35:14 -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 KAA03627
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 10:34:43 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Planner drops unreferenced tables --- bug, no?
Date: Wed, 29 Sep 1999 10:34:43 -0400
Message-ID: <3624.938615683@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Whilst chasing down a few more aggregate-related bug reports,
I realized that the planner is doing the Wrong Thing when
a query's FROM clause mentions tables that are not used
elswhere in the query. For example, I make a table with
three rows:

play=> select x.f1 from x;
f1
--
1
2
3
(3 rows)

Now:

play=> select x.f1 from x, x as x2;
f1
--
1
2
3
(3 rows)

It seems to me that the latter query must yield 9 rows (three
occurrences of each value) to satisfy the SQL spec. The spec defines
the result of a two-query FROM clause to be the Cartesian product of the
two tables, period. It doesn't say anything about "only if one or more
columns of each table are actually used somewhere".

The particular case that led me into this was for an aggregate:

play=> select count(f1) from x;
count
-----
3
(1 row)

play=> select count(1) from x;
count
-----
1
(1 row)

Now IMHO count(1) should yield the same count as for any other non-null
expression, ie, the number of rows in the source table, because the spec
effectively says "evaluate the expression for each row and count the
number of non-null results". The reason you get 1 here is that the
planner is dropping the "unreferenced" x, deciding that the query looks
like "select 2+2;", and generating a single-row Result plan.

Before I look into ways of fixing this, is there anyone who wants
to argue that the current behavior is correct? It looks all wrong
to me, but...

regards, tom lane

From bouncefilter Wed Sep 29 10:50:32 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 KAA85438
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 10:47:31 -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 SAA14127;
Wed, 29 Sep 1999 18:38:30 +0400 (MSD)
Date: Wed, 29 Sep 1999 18:38:30 +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] NULL as an argument in plpgsql functions (fwd)
In-Reply-To: <3328.938613315@sss.pgh.pa.us>
Message-ID: <Pine.GSO.3.96.SK.990929183155.16613v-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Thanks Tom for explanation. I'm giving up :-)
Will wait ... Just surprised how many things are covered from
casual glimpse.
It seems that Perl is the only panacea for all kind of problem.

BTW, I think this bug must be written in documentation so people
will not spent time as me or at leaset in release notices.

Regards,

Oleg

On Wed, 29 Sep 1999, Tom Lane wrote:

Date: Wed, 29 Sep 1999 09:55:15 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Oleg Bartunov <oleg@sai.msu.su>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions (fwd)

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

Is this a bug or feature ?

It's a bug. Fixing it will require a wholesale code revision, however
(see my prior postings about redesigning the function call interface).

This is something we need to do for 6.6, IMHO, not only because of
the NULL-argument issue but also because it will solve the portability
problems that are being created by the existing fmgr interface (Alpha
bugs, need to dumb down to -O0 on some platforms, etc). I've been
trying to summon the will to get started on it, but other things keep
getting in the way...

Also, it seems there is a limitation to a number of arguments.

Yes, 8. I'm not planning to do anything about that in the near term.
Even just making the limit configurable would be a lot of work :-(

regards, tom lane

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

From bouncefilter Wed Sep 29 10:58:32 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 KAA87462
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 10:58:21 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11WL5Q-0003kLC; Wed, 29 Sep 99 16:52 MET DST
Message-Id: <m11WL5Q-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Planner drops unreferenced tables --- bug, no?
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Wed, 29 Sep 1999 16:52:04 +0200 (MET DST)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <3624.938615683@sss.pgh.pa.us> from "Tom Lane" at Sep 29,
99 10:34:43 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Tom Lane wrote:

[...]

Now:

play=> select x.f1 from x, x as x2;
f1
--
1
2
3
(3 rows)

It seems to me that the latter query must yield 9 rows (three
occurrences of each value) to satisfy the SQL spec. The spec defines
the result of a two-query FROM clause to be the Cartesian product of the
two tables, period. It doesn't say anything about "only if one or more
columns of each table are actually used somewhere".

Caution here!

After rewriting there can be many unused rangetable entries
floating around. Especially if you SELECT from a view, the
view's relation is still mentioned in the rangetable.

If you now build the cartesian product over all relations
(including the EMPTY view relation), you'll allways get NO
rows.

So when touching this, make sure the rewriter removes
properly all rewritten RTE's and those for NEW and OLD.
Removing RTE's will then require changing varno's allover
again. Are you sure you want to open this can of worms?

Jan

From bouncefilter Wed Sep 29 11:05:32 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 LAA88947
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 11:05:28 -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 LAA03865;
Wed, 29 Sep 1999 11:04:52 -0400 (EDT)
To: wieck@debis.com (Jan Wieck)
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Planner drops unreferenced tables --- bug, no?
In-reply-to: Your message of Wed, 29 Sep 1999 16:52:04 +0200 (MET DST)
<m11WL5Q-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Wed, 29 Sep 1999 11:04:52 -0400
Message-ID: <3863.938617492@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

It seems to me that the latter query must yield 9 rows (three
occurrences of each value) to satisfy the SQL spec. The spec defines
the result of a two-query FROM clause to be the Cartesian product of the
two tables, period. It doesn't say anything about "only if one or more
columns of each table are actually used somewhere".

Caution here!

After rewriting there can be many unused rangetable entries
floating around. Especially if you SELECT from a view, the
view's relation is still mentioned in the rangetable.

I was thinking of forcing rangetable entries that are marked as
'inFromCl' to be included in the planner's target relation set,
but those not so marked would only get added if referenced, same as now.
Do you think that will not work?

regards, tom lane

From bouncefilter Thu Sep 30 01:50:45 1999
Received: from mail.kdt.de (mail.kdt.de [195.8.224.4])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA64342
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 01:50:04 -0400 (EDT)
(envelope-from christof.petig@wtal.de)
Received: from gateway.petig.de (line0249lf.kdt.de [195.8.241.249])
by mail.kdt.de (8.8.8/8.8.8) with ESMTP id HAA04403;
Thu, 30 Sep 1999 07:50:01 +0200
Received: from wtal.de (christof@[192.168.230.9])
by gateway (8.8.8/8.8.8) with ESMTP id RAA15384;
Wed, 29 Sep 1999 17:05:46 +0200
Sender: christof@to.wtal.de
Message-ID: <37F22ABD.50997341@wtal.de>
Date: Wed, 29 Sep 1999 17:05:34 +0200
From: Christof Petig <christof.petig@wtal.de>
Organization: Adolf Petig GmbH. & Co. KG
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.7 i586)
X-Accept-Language: de
MIME-Version: 1.0
To: Lamar Owen <lamar.owen@wgcr.org>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Regression tests on intel for 6.5.2
References: <28004.938476013@sss.pgh.pa.us>
<99092720011203.07044@lowen.wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lamar Owen wrote:

On Mon, 27 Sep 1999, Tom Lane wrote:

which is evidently doing the wrong thing on your platform. What does
your man page for exp() say about error return conventions?

I checked it twice, I can't find any error in the current sources. I even wrote a test program:
#include <math.h>
#include <stdio.h>
#include <errno.h>

int main()
{ double e;
errno=0;
e=pow(100,200);
if (errno) perror("pow");
if (!finite(e)) puts("!finite\n");
else printf("%f\n",e);
}

Output:
pow: Numerical result out of range
!finite

So both methods seem to work. (finite is a function on glibc-2.1 systems)

Perhaps (strange thoughts come in to my mind ...) the compiler optimizes the function call into a
machine instruction ...
/tmp> cc -O2 -o test test.c -lm
/tmp> ./test
!finite

Looks like this is the case. So (I use gcc-2.95) what to do? Complain about a compiler/library bug
(doesn't set errno)? I would propose another autoconf test. (I could easily do it.)

Christof

PS: I found the offending inline routines in /usr/include/bits/mathinline.h

From bouncefilter Wed Sep 29 11:09:33 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 LAA89344
for <hackers@postgresql.org>; Wed, 29 Sep 1999 11:08:39 -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 PAA10490;
Wed, 29 Sep 1999 15:07:53 GMT
Sender: lockhart@hub.org
Message-ID: <37F22B49.8C3E4B7F@alumni.caltech.edu>
Date: Wed, 29 Sep 1999 15:07:53 +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: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: New notices?
References: <199909291414.KAA26120@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I updated my current tree and now this message comes out on even
simple queries. Is it supposed to be there? If so, why??

Strange. I don't get it:

I'll bet it is coming from my using expandAll() to support the new
join syntax, and as a kludge I am feeding it a dummy parse state as a
placeholder. As I try to implement table and column aliases, I'll be
mucking around in all of these areas. It isn't at all clear to me from
the notes or from the checks that there was some specific case this
was intended to catch...

In the meantime, I've bracketed my local copy of the code:

#ifdef EMIT_ANNOYING_MESSAGES
elog(NOTICE,"Adding missing FROM-clause entry%s for table %s",
pstate->parentParseState != NULL ? " in subquery" : "",
refname);
#endif

;)

- Thomas

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

From bouncefilter Wed Sep 29 11:23:34 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 LAA91512
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 11:22:37 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11WLSs-0003kLC; Wed, 29 Sep 99 17:16 MET DST
Message-Id: <m11WLSs-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Planner drops unreferenced tables --- bug, no?
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Wed, 29 Sep 1999 17:16:18 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <3863.938617492@sss.pgh.pa.us> from "Tom Lane" at Sep 29,
99 11:04:52 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

wieck@debis.com (Jan Wieck) writes:

It seems to me that the latter query must yield 9 rows (three
occurrences of each value) to satisfy the SQL spec. The spec defines
the result of a two-query FROM clause to be the Cartesian product of the
two tables, period. It doesn't say anything about "only if one or more
columns of each table are actually used somewhere".

Caution here!

After rewriting there can be many unused rangetable entries
floating around. Especially if you SELECT from a view, the
view's relation is still mentioned in the rangetable.

I was thinking of forcing rangetable entries that are marked as
'inFromCl' to be included in the planner's target relation set,
but those not so marked would only get added if referenced, same as now.
Do you think that will not work?

I'm not sure and don't have the time to dive into. Just
wanted to point on an area of (maybe unexpected) side
effects.

Jan

From bouncefilter Wed Sep 29 11:25:38 1999
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA91789
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 11:24:36 -0400 (EDT)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA24859;
Wed, 29 Sep 1999 08:23:08 -0700 (PDT)
Message-Id: <3.0.1.32.19990929082158.00a563d0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 29 Sep 1999 08:21:58 -0700
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Planner drops unreferenced tables --- bug, no?
In-Reply-To: <3624.938615683@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:34 AM 9/29/99 -0400, Tom Lane wrote:

play=> select x.f1 from x, x as x2;
f1
--
1
2
3
(3 rows)

It seems to me that the latter query must yield 9 rows (three
occurrences of each value) to satisfy the SQL spec. The spec defines
the result of a two-query FROM clause to be the Cartesian product of the
two tables, period. It doesn't say anything about "only if one or more
columns of each table are actually used somewhere".

AFAIK, this is correct. For the heck of it, I tried it in
Oracle, and indeed the full cartesian product's returned:

SQL> select x2.i from x, x x2;

I
----------
1
1
1
2
2
2
3
3
3

9 rows selected.

play=> select count(1) from x;
count
-----
1
(1 row)

Again, Oracle 8:

SQL> select count(1) from x, x x2;

COUNT(1)
----------
9

SQL>

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Wed Sep 29 11:31:33 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 LAA93439
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 11:31: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 PAA10520;
Wed, 29 Sep 1999 15:30:26 GMT
Sender: lockhart@hub.org
Message-ID: <37F23092.23270CDB@alumni.caltech.edu>
Date: Wed, 29 Sep 1999 15:30:26 +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: Zakkr <zakkr@zf.jcu.cz>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] string function
References: <Pine.LNX.3.96.990929151357.28808B-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Try somebody implemeny strftime(),strcat() to PSQL ? -
(is any problem in PSQL, that not exist more string/date/..etc functions or
is problem with programmer absence (only) ?)

It is some combination of: 1) a mild reluctance to add too many
specialty functions, 2) no specific need, at least from a programmer
who can make it happen, 3) unclear tradeoffs between bigger hammers
causing more damage than they help, and 4) existing functionality
which already does it. Oh, and 5) simply that no one has done it yet!

In (almost) all cases, extensions can be put into the contrib area,
and that is a good way to test out new functionality. In some cases,
new functionality should go into the main tree directly. Of the cases
you just mentioned:

1) strftime() allows arbitrary formatting of date/time strings.
Certainly useful, though one can easily format a string that is no
longer recognizable to Postgres as a date which is one reason why I
didn't code it up previously. Perhaps we should focus on an
Oracle-compatible routine for this; I think it uses tochar() to do
formatting. Someone recently volunteered to send in code which could
be used for this, but I haven't seen the code yet :(

2) strcat() concatenates two strings? There is a full set of functions
which do this, and they are used to support the SQL92 concatenation
operator "||".

But in general, more functionality is A Good Thing, and discussing it
on the hackers list is a good way to get people used to a new idea, or
to evolve a new idea into something people like even better.

- Thomas

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

From bouncefilter Wed Sep 29 11:49:33 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 LAA96085
for <hackers@postgresql.org>; Wed, 29 Sep 1999 11:42:49 -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 LAA01831;
Wed, 29 Sep 1999 11:39:55 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909291539.LAA01831@candle.pha.pa.us>
Subject: Re: New notices?
In-Reply-To: <37F22B49.8C3E4B7F@alumni.caltech.edu> from Thomas Lockhart at
"Sep 29, 1999 03:07:53 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Wed, 29 Sep 1999 11:39:55 -0400 (EDT)
CC: Postgres Hackers List <hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I updated my current tree and now this message comes out on even
simple queries. Is it supposed to be there? If so, why??

Strange. I don't get it:

I'll bet it is coming from my using expandAll() to support the new
join syntax, and as a kludge I am feeding it a dummy parse state as a
placeholder. As I try to implement table and column aliases, I'll be
mucking around in all of these areas. It isn't at all clear to me from
the notes or from the checks that there was some specific case this
was intended to catch...

This was added to address the long-standing error reports of problems
when addressing aliased and non-aliased columns in the same query. We
don't issue an error, but go ahead and auto-create a from entry, very
non-standard SQL:

SELECT tab.* FROM tab t

Tom Lane and I agreed we need to issue a NOTICE for this type of
auto-FROM creation.

-- 
  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 Wed Sep 29 13:00:01 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA09069
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 12:59:18 -0400 (EDT) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA04150;
Wed, 29 Sep 1999 17:50:25 +0200
Date: Wed, 29 Sep 1999 17:50:25 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] string function
In-Reply-To: <37F23092.23270CDB@alumni.caltech.edu>
Message-ID: <Pine.LNX.3.96.990929172058.2711A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

1) strftime() allows arbitrary formatting of date/time strings.
Certainly useful, though one can easily format a string that is no
longer recognizable to Postgres as a date which is one reason why I
didn't code it up previously. Perhaps we should focus on an
Oracle-compatible routine for this; I think it uses tochar() to do
formatting. Someone recently volunteered to send in code which could
be used for this, but I haven't seen the code yet :(

If I good understand you, you don't reject strftime idea. I try it..

2) strcat() concatenates two strings? There is a full set of functions
which do this, and they are used to support the SQL92 concatenation
operator "||".

:-)) yes '||' is good. I said it bad. I think exapmle inetcat() (I
programming this for my project):

select inetcat('160.217.1.0/24', 50);
inetcat
------------
160.217.1.50

In my prev. letter I said it generally. (I'am finding a more function
in PSQL.. and I can try write it.).

Zakkr

From bouncefilter Wed Sep 29 12:04:33 1999
Received: from localhost (hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA98288
for <hackers@postgresql.org>; Wed, 29 Sep 1999 11:59:13 -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 PAA10591;
Wed, 29 Sep 1999 15:57:06 GMT
Sender: lockhart@hub.org
Message-ID: <37F236D2.B2A27832@alumni.caltech.edu>
Date: Wed, 29 Sep 1999 15:57:06 +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: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: New notices?
References: <199909291539.LAA01831@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This was added to address the long-standing error reports of problems
when addressing aliased and non-aliased columns in the same query. We
don't issue an error, but go ahead and auto-create a from entry, very
non-standard SQL:
SELECT tab.* FROM tab t
Tom Lane and I agreed we need to issue a NOTICE for this type of
auto-FROM creation.

OK, but I may happily break it when implementing table and column
aliases for join syntax. Don't know yet what the ramifications will
be...

- Thomas

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

From bouncefilter Wed Sep 29 12:28:08 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA04185
for <pgsql-hackers@postgresql.org>;
Wed, 29 Sep 1999 12:27:41 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:3842 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rwXrk186626>;
Wed, 29 Sep 1999 18:27:28 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11WMaj-00006D-00; Wed, 29 Sep 1999 18:28:29 +0200
Date: Wed, 29 Sep 1999 18:28:28 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: TODO items
In-Reply-To: <199909271519.LAA14759@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.9909291731070.364-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

Just my 0.02 kronor . . .

On Sep 27, Bruce Momjian noted:

* Update table SET table.value = 3 fails

AFAICS, the SQL92 syntax allows only a bare <column name> as the
target of a SET clause. Not sure it's worth expending any effort
on this one...

Marked now as:

* Update table SET table.value = 3 fails(SQL standard says this is OK)

In my opinion this should definitely _not_ be allowed. Let's be glad the
UPDATE command is so conceptually simple (cf. SELECT). The next thing they
want is ALTER TABLE foo RENAME foo.colum [ TO bar.something ??? -- moving
columns between tables, why not :) ] and then CREATE TABLE foo (foo.a int,
...); and it won't stop :)

MISC

* Do autocommit so always in a transaction block(?)

Huh? What is this supposed to mean?

Some people want the SQL session to start inside a transaction, and you
have to explicity use COMMIT, at which point you are in a new
transaction that lasts until the next commit. Ingres SQL does this, and
it is a pain, I think.

I have been wondering about this, too. Oracle does this as well. This is
also how they taught me SQL in university, so it is probably not out of
the blue. What do the standards say?

Then again, while I think that client programmers won't die if they type
an extra BEGIN here or there, this might be useful as a psql feature. Too
many times I've seen people type DELETE FROM <table>; by accident.

What do y'all think? (Besides the fact that this might be a pain to
implement.)

Peter

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

From bouncefilter Wed Sep 29 12:36:01 1999
Received: from chi-mx.truenorth.com (interlock.truenorth.com [199.221.98.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA05792
for <hackers@postgreSQL.org>; Wed, 29 Sep 1999 12:35:42 -0400 (EDT)
(envelope-from djackson@cpsgroup.com)
Received: from cpsmail.cpsgroup.com (cpsmail.cpsgroup.com [144.210.12.10])
by chi-mx.truenorth.com (8.9.3/8.9.3) with ESMTP id LAA09919;
Wed, 29 Sep 1999 11:32:14 -0500 (CDT)
Received: by cpsmail with Internet Mail Service (5.5.2448.0)
id <QPCGKXC2>; Wed, 29 Sep 1999 11:32:06 -0500
Message-ID: <D05EF808F2DFD211AE4A00105AA1B5D25CB2BE@cpsmail>
From: "Jackson, DeJuan" <djackson@cpsgroup.com>
To: wieck@debis.com, lockhart@alumni.caltech.edu
Cc: tgl@sss.pgh.pa.us, hackers@postgreSQL.org
Subject: RE: RI and PARSER (was: Re: [HACKERS] RI status report #1)
Date: Wed, 29 Sep 1999 11:31:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

What does PENDANT imply/mean in terms of RI? I could figure out all of the
other syntax.

-----Original Message-----
From: wieck@debis.com [SMTP:wieck@debis.com]
Sent: Wednesday, September 29, 1999 9:03 AM
To: lockhart@alumni.caltech.edu
Cc: wieck@debis.com; tgl@sss.pgh.pa.us; hackers@postgreSQL.org
Subject: Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)

Thomas Lockhart wrote:

CONSTRAINTS
DEFERRABLE
DEFERRED
IMMEDIATE
INITIALLY
PENDANT
RESTRICT

O.K. - I was able to add them all to ColId without conflicts
for now. Let's see what happens after adding the syntax for
CREATE CONSTRAINT TRIGGER.

Right. Anything which causes trouble can be demoted to ColLabel.

I'm not sure which of them are SQL92 or SQL3, at least they
are all SQL3 "reserved" words according to the SQL3 draft.

According to my Date and Darwen (which is mostly SQL92), all of these
except "PENDANT" are SQL92 reserved words. PENDANT is not mentioned,
so is presumably an SQL3-ism.

Do you want me to update syntax.sgml?

Please be so kind. CREATE CONSTRAINT TRIGGER did not mess up
anything, so all these new reserved words appear in ColId and
are still available.

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 Wed Sep 29 13:17:02 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA12879
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 13:16:52 -0400 (EDT) (envelope-from wieck@debis.com)
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by trends.net (8.8.8/8.8.8) with SMTP id NAA11136
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 13:16:48 -0400 (EDT)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11WNFP-0003kLC; Wed, 29 Sep 99 19:10 MET DST
Message-Id: <m11WNFP-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: RI status report #2
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Wed, 29 Sep 1999 19:10:31 +0200 (MET DST)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

ATTENTION: catalog changes - initdb required!

General support for deferred constraint triggers is finished
and committed to CURRENT tree.

Implemented so far:

CREATE CONSTRAINT TRIGGER <constraint_name>
AFTER <event> ON <relation_name>
[ FROM <referencing_relation_name> ]
[ [ NOT ] DEFERRABLE ]
[ INITIALLY { IMMEDIATE | DEFERRED } ]
FOR EACH ROW EXECUTE PROCEDURE <procedure_name> ( <args> )

SET CONSTRAINTS { <constraint_names> | ALL } { IMMEDIATE | DEFERRED }

Details on CREATE CONSTRAINT TRIGGER:

<constraint_name>

Can be a usual identifier or "" for unnamed
constraints. Since the same constraint can result in
multiple pg_trigger entries for different tables,
there's no check for duplicates. This is the name to
later identify constraints in SET CONSTRAINTS.

FROM <referencing_relation_name>

If given, causes that this trigger are automatically
removed when the referencing relation is dropped.
This is useful for referential action triggers (like
ON DELETE CASCADE), which are fired on changes to the
PK table. Dropping the FK table without removing the
triggers from the PK table would make it unusable.

[ NOT ] DEFERRABLE

Specifies if the trigger is deferrable or not.
Defaults to NOT DEFERRABLE if INITIALLY is IMMEDIATE.
Defaults to DEFERRABLE if INITIALLY is DEFERRED.

INITIALLY { IMMEDIATE | DEFERRED }

Specifies the deferred state of the trigger at
session start. Defaults to IMMEDIATE.

<procedure_name> ( <args> )

The usual trigger procedure definition.

The trigger itself in pg_trigger is created with a tgname
of RI_ConstraintTrigger_<newoid>, which should be unique
enough.

Details on SET CONSTRAINTS:

<constraint_names>

A comma separated list of constraint identifiers. An
attempt to set named constraints to DEFERRED where at
least one of the pg_trigger entries with this name
isn't deferrable raises an ERROR.

Using ALL with DEFERRED sets all deferrable
constraint triggers (named and unnamed) to deferred,
leaving not deferrable ones immediate.

If SET CONSTRAINTS is used outside of a transaction block
(BEGIN/COMMIT), it sets the default behaviour on session
level. All constraint triggers begin each transaction
(explicit block or implicit single statement) in these
states.

All AFTER ROW triggers (regular ones) are treated like
IMMEDIATE constraint triggers now so they are fired at
the end of the entire statement instead of during it.
This interfered with the funny_dup17 test in the
regression suite which is commented out now.

Trigger events for deferred triggers are condensed during
a transaction. That means, that executing multiple
UPDATE commands affecting the same row would finally
invoke only one trigger call which receives the original
tuple (before BEGIN) as OLD and the final tuple (after
last UPDATE) as NEW. Similar INSERT/DELETE of same row
will fire no trigger at all.

There are checks done if IMMEDIATE or BEFORE ROW triggers
have already been fired when a row is touched multiple
times in the same transaction. In that case, an error is
raised because this might violate referential integrity.

Needless to say that COMMIT causes an implicit SET
CONSTRAINTS ALL IMMEDIATE. All deferred triggers are run
then, so COMMIT could raise trigger generated errors now!

Next we need:

1. Generic trigger procs that are argument driven. I'll make
a separate thread for this topic.

2. Support in CREATE TABLE that issues the appropriate
CREATE CONSTRAINT TRIGGER statements for FOREIGN KEY in
the same manner as CREATE INDEX for PRIMARY KEY is done.
This must wait until we have an accepted call interface
for the generic trigger procs from 1..

3. Support for pg_dump to emit the correct CREATE CONSTRAINT
TRIGGER statements. Who wants to pick up this topic?

4. Add the ability to swap out huge amounts of deferred
trigger events to disk (actually I'm collecting them in
memory - so large transactions affecting millions of rows
of a table where triggers are defined are likely to blow
up the backend). This is my topic - sorry.

5. Write a regression test for the new FOREIGN KEY support.
Surely an important thing but one of the last steps after
anything else works properly.

6. Remove the "not supported yet" note for FOREIGN KEY from
the docs along with correcting to the full syntax
supported finally :-)

Hmmmm - the more I work on it the longer the TODO becomes.

Jan

From bouncefilter Wed Sep 29 13:24:02 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA14096
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 13:23:46 -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 NAA03450;
Wed, 29 Sep 1999 13:21:48 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909291721.NAA03450@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: TODO items
In-Reply-To: <Pine.LNX.4.10.9909291731070.364-100000@peter-e.yi.org> from
Peter
Eisentraut at "Sep 29, 1999 06:28:28 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Wed, 29 Sep 1999 13:21:48 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Just my 0.02 kronor . . .

On Sep 27, Bruce Momjian noted:

* Update table SET table.value = 3 fails

AFAICS, the SQL92 syntax allows only a bare <column name> as the
target of a SET clause. Not sure it's worth expending any effort
on this one...

Marked now as:

* Update table SET table.value = 3 fails(SQL standard says this is OK)

In my opinion this should definitely _not_ be allowed. Let's be glad the
UPDATE command is so conceptually simple (cf. SELECT). The next thing they
want is ALTER TABLE foo RENAME foo.colum [ TO bar.something ??? -- moving
columns between tables, why not :) ] and then CREATE TABLE foo (foo.a int,
...); and it won't stop :)

OK, let's leave it in so people know it is not implemented.

Some people want the SQL session to start inside a transaction, and you
have to explicity use COMMIT, at which point you are in a new
transaction that lasts until the next commit. Ingres SQL does this, and
it is a pain, I think.

I have been wondering about this, too. Oracle does this as well. This is
also how they taught me SQL in university, so it is probably not out of
the blue. What do the standards say?

Then again, while I think that client programmers won't die if they type
an extra BEGIN here or there, this might be useful as a psql feature. Too
many times I've seen people type DELETE FROM <table>; by accident.

No one has really been passionate about it either way.

-- 
  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 Wed Sep 29 13:33:03 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA15782
for <hackers@postgreSQL.org>; Wed, 29 Sep 1999 13:32:16 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by trends.net (8.8.8/8.8.8) with SMTP id NAA11976
for <hackers@postgreSQL.org>; Wed, 29 Sep 1999 13:32:13 -0400 (EDT)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgreSQL.org
id m11WNTw-0003kLC; Wed, 29 Sep 99 19:25 MET DST
Message-Id: <m11WNTw-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)
To: djackson@cpsgroup.com (Jackson, DeJuan)
Date: Wed, 29 Sep 1999 19:25:32 +0200 (MET DST)
Cc: wieck@debis.com, lockhart@alumni.caltech.edu, tgl@sss.pgh.pa.us,
hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <D05EF808F2DFD211AE4A00105AA1B5D25CB2BE@cpsmail> from "Jackson,
DeJuan" at Sep 29, 99 11:31:58 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

What does PENDANT imply/mean in terms of RI? I could figure out all of the
other syntax.

As far as I understood it:

CREATE TABLE t1 (a1 integer PRIMARY KEY NOT NULL, b1 text);

CREATE TABLE t2 (a2 integer NOT NULL, b2 text,
CONSTRAINT check_a2
FOREIGN KEY (a2)
REFERENCES t1 (a1)
PENDANT
ON DELETE CASCADE
ON UPDATE CASCADE
INITIALLY DEFERRED);

This setup requires, that for each key in t1.a1 at least one
reference from t2.a2 MUST exist. So this is a cyclic
integrity check. I'm not sure if removing the last reference
automatically removes the PK row from t1 or if it raises an
error. Can someone clearify here?

Jan

From bouncefilter Wed Sep 29 13:38:02 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 NAA16565
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 13:37:30 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11WNZ4-0003l1C; Wed, 29 Sep 99 19:30 MET DST
Message-Id: <m11WNZ4-0003l1C@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] RI status report #2
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Wed, 29 Sep 1999 19:30:50 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199909291730.NAA03595@candle.pha.pa.us> from "Bruce Momjian" at
Sep 29, 99 01:30:55 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

Man, that's a heap of additions.

Only the top of the iceberg :-)

Jan

From bouncefilter Wed Sep 29 13:32:02 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA15710
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 13:31:23 -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 NAA03595;
Wed, 29 Sep 1999 13:30:55 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909291730.NAA03595@candle.pha.pa.us>
Subject: Re: [HACKERS] RI status report #2
In-Reply-To: <m11WNFP-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Sep 29, 1999 07:10:31 pm"
To: Jan Wieck <wieck@debis.com>
Date: Wed, 29 Sep 1999 13:30:55 -0400 (EDT)
CC: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Man, that's a heap of additions.

ATTENTION: catalog changes - initdb required!

General support for deferred constraint triggers is finished
and committed to CURRENT tree.

Implemented so far:

CREATE CONSTRAINT TRIGGER <constraint_name>
AFTER <event> ON <relation_name>
[ FROM <referencing_relation_name> ]
[ [ NOT ] DEFERRABLE ]
[ INITIALLY { IMMEDIATE | DEFERRED } ]
FOR EACH ROW EXECUTE PROCEDURE <procedure_name> ( <args> )

SET CONSTRAINTS { <constraint_names> | ALL } { IMMEDIATE | DEFERRED }

Details on CREATE CONSTRAINT TRIGGER:

<constraint_name>

Can be a usual identifier or "" for unnamed
constraints. Since the same constraint can result in
multiple pg_trigger entries for different tables,
there's no check for duplicates. This is the name to
later identify constraints in SET CONSTRAINTS.

FROM <referencing_relation_name>

If given, causes that this trigger are automatically
removed when the referencing relation is dropped.
This is useful for referential action triggers (like
ON DELETE CASCADE), which are fired on changes to the
PK table. Dropping the FK table without removing the
triggers from the PK table would make it unusable.

[ NOT ] DEFERRABLE

Specifies if the trigger is deferrable or not.
Defaults to NOT DEFERRABLE if INITIALLY is IMMEDIATE.
Defaults to DEFERRABLE if INITIALLY is DEFERRED.

INITIALLY { IMMEDIATE | DEFERRED }

Specifies the deferred state of the trigger at
session start. Defaults to IMMEDIATE.

<procedure_name> ( <args> )

The usual trigger procedure definition.

The trigger itself in pg_trigger is created with a tgname
of RI_ConstraintTrigger_<newoid>, which should be unique
enough.

Details on SET CONSTRAINTS:

<constraint_names>

A comma separated list of constraint identifiers. An
attempt to set named constraints to DEFERRED where at
least one of the pg_trigger entries with this name
isn't deferrable raises an ERROR.

Using ALL with DEFERRED sets all deferrable
constraint triggers (named and unnamed) to deferred,
leaving not deferrable ones immediate.

If SET CONSTRAINTS is used outside of a transaction block
(BEGIN/COMMIT), it sets the default behaviour on session
level. All constraint triggers begin each transaction
(explicit block or implicit single statement) in these
states.

All AFTER ROW triggers (regular ones) are treated like
IMMEDIATE constraint triggers now so they are fired at
the end of the entire statement instead of during it.
This interfered with the funny_dup17 test in the
regression suite which is commented out now.

Trigger events for deferred triggers are condensed during
a transaction. That means, that executing multiple
UPDATE commands affecting the same row would finally
invoke only one trigger call which receives the original
tuple (before BEGIN) as OLD and the final tuple (after
last UPDATE) as NEW. Similar INSERT/DELETE of same row
will fire no trigger at all.

There are checks done if IMMEDIATE or BEFORE ROW triggers
have already been fired when a row is touched multiple
times in the same transaction. In that case, an error is
raised because this might violate referential integrity.

Needless to say that COMMIT causes an implicit SET
CONSTRAINTS ALL IMMEDIATE. All deferred triggers are run
then, so COMMIT could raise trigger generated errors now!

Next we need:

1. Generic trigger procs that are argument driven. I'll make
a separate thread for this topic.

2. Support in CREATE TABLE that issues the appropriate
CREATE CONSTRAINT TRIGGER statements for FOREIGN KEY in
the same manner as CREATE INDEX for PRIMARY KEY is done.
This must wait until we have an accepted call interface
for the generic trigger procs from 1..

3. Support for pg_dump to emit the correct CREATE CONSTRAINT
TRIGGER statements. Who wants to pick up this topic?

4. Add the ability to swap out huge amounts of deferred
trigger events to disk (actually I'm collecting them in
memory - so large transactions affecting millions of rows
of a table where triggers are defined are likely to blow
up the backend). This is my topic - sorry.

5. Write a regression test for the new FOREIGN KEY support.
Surely an important thing but one of the last steps after
anything else works properly.

6. Remove the "not supported yet" note for FOREIGN KEY from
the docs along with correcting to the full syntax
supported finally :-)

Hmmmm - the more I work on it the longer the TODO becomes.

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

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

-- 
  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 Wed Sep 29 13:53:04 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA18778
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 13:52:12 -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 NAA03864;
Wed, 29 Sep 1999 13:51:50 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909291751.NAA03864@candle.pha.pa.us>
Subject: Re: [HACKERS] RI status report #2
In-Reply-To: <m11WNZ4-0003l1C@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Sep 29, 1999 07:30:50 pm"
To: Jan Wieck <wieck@debis.com>
Date: Wed, 29 Sep 1999 13:51:50 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Man, that's a heap of additions.

Only the top of the iceberg :-)

Yikes. I was just talking to Thomas Lockhart by phone, and was saying
that I thought 6.6 would be a small, incremental release after the
changes in 6.5.*. Obviously, 6.6 is going to be as full-featured as
earlier releases.

-- 
  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 Wed Sep 29 14:54:17 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 OAA32493
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 14:53:35 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11WOl4-0003kuC; Wed, 29 Sep 99 20:47 MET DST
Message-Id: <m11WOl4-0003kuC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: RI generic trigger procs
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Wed, 29 Sep 1999 20:47:18 +0200 (MET DST)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

So co-developers,

let's go.

I think the best is if all RI triggers share the same call
interface. My favorite for now is this:

RI_FKey_<operation>_<event> ( <args> )

Where <operation> is one of check, cascade, restrict, setnull
or setdefault and where <event> is one of ins, upd or del.
Thus, the trigger proc to check foreign key on insert would
be RI_FKey_check_ins() and the one to do cascaded deletes
becomes RI_FKey_cascade_del().

The <args> is allways '<constraint_name>', '<FK_table_name>',
'<PK_table_name>' and a variable length list of
'<FK_attribute_name>', '<PK_attribute_name>' pairs. In the
case of an unnamed constraint, the <constraint_name> is given
as '(unnamed)'. It is up to CREATE TABLE parsing/utility to
build these arguments properly.

All the procs should use prepared and saved SPI plans
wherever possible.

Any combination of attributes in a table referenced to by one
or more FOREIGN KEY ... REFERENCES constraint of another
table shall have a UNIQUE and NOT NULL constraint. I don't
think that it's easy to assure this and to avoid that the
underlying unique index isn't dropped later. First it shall
be enough to document and leave it up to the
creator/maintainer of the database schema. So we assume here
that any PK is unique and cannot contain NULL's.

The FOREIGN KEY itself might allow NULL's, but since we
implement only MATCH FULL right now, either all or none of
the FK attributes may contain NULL. We'll check this in
RI_FKey_check_ins() and RI_FKey_check_upd().

The behaviour of the procs in detail (this is what ya shall
write - they don't exist):

RI_FKey_check_ins()

Implements "FOREIGN KEY ... REFERENCES ..." at insert
time.

Fired AFTER INSERT on FK table.

First off, either all or none of the FK attributes in NEW
must be NULL. If all are NULL, nothing is checked and
operation goes through. Otherwise it raises an ERROR if
the given key isn't present in the PK table.

RI_FKey_check_upd()

Implements "FOREIGN KEY ... REFERENCES ..." at update
time.

Fired AFTER UPDATE on FK table.

If all FK attributes in OLD and NEW are the same, nothing
is done. Otherwise, the operation is the same as for
RI_FKey_check_ins().

RI_FKey_cascade_del()

Implements "FOREIGN KEY ... ON DELETE CASCADE".

Fired AFTER DELETE on PK table.

It deletes all occurences of the deleted key in the FK
table.

RI_FKey_cascade_upd()

Implements "FOREIGN KEY ... ON UPDATE CASCADE".

Fired AFTER UPDATE on PK table.

Nothing happens if OLD and NEW keys in PK are identical.
Otherwise it updates all occurences of the OLD key to the
NEW key in the FK table.

RI_FKey_restrict_del()

Implements "FOREIGN KEY ... ON DELETE RESTRICT".

Fired AFTER DELETE on PK table.

Checks if the deleted key is still referenced from the FK
table and raises an ERROR if so.

RI_FKey_restrict_upd()

Fired AFTER UPDATE on PK table.

Nothing happens if OLD and NEW keys in PK are identical.
Otherwise checks if the OLD key is still referenced from
the FK table and raises an ERROR if so.

RI_FKey_setnull_del()

Implements "FOREIGN KEY ... ON DELETE SET NULL"

Fired AFTER DELETE on PK table.

Updates all occurences of the OLD key to NULL values in
the FK table.

RI_FKey_setnull_upd()

Implements "FOREIGN KEY ... ON UPDATE SET NULL"

Fired AFTER UPDATE on PK table.

Nothing happens if OLD and NEW keys in PK are identical.
Otherwise updates all occurences of the OLD key to NULL
values in the FK table.

RI_FKey_setdefault_del()

Implements "FOREIGN KEY ... ON DELETE SET DEFAULT"

Fired AFTER DELETE on PK table.

Updates all occurences of the OLD key in FK table to the
default values defined in the schema of the FK table.

RI_FKey_setdefault_upd()

Implements "FOREIGN KEY ... ON UPDATE SET DEFAULT"

Fired AFTER UPDATE on PK table.

Nothing happens if OLD and NEW keys in PK are identical.
Otherwise updates all occurences of the OLD key in FK
table to the default values defined in the schema of the
FK table.

This all is the behaviour of FOREIGN KEY ... MATCH FULL
according to the SQL3 standard - as I understood it. I know
that the above trigger procs aren't easy to implement. But
after all, many of the referential action ones look very
similar to each other.

One general thing required is IMHO some hashtable(s) living
in the cache context where any trigger once fired can cache
information needed again and again (like the saved plans,
functions for equality checks on OLD vs. NEW, etc.).

The bazar is open - come in.

Jan

From bouncefilter Wed Sep 29 15:09:16 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 PAA36476
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 15:09:03 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11WOzk-0003kuC; Wed, 29 Sep 99 21:02 MET DST
Message-Id: <m11WOzk-0003kuC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] RI status report #2
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Wed, 29 Sep 1999 21:02:28 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199909291751.NAA03864@candle.pha.pa.us> from "Bruce Momjian" at
Sep 29, 99 01:51:50 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

Man, that's a heap of additions.

Only the top of the iceberg :-)

Yikes. I was just talking to Thomas Lockhart by phone, and was saying
that I thought 6.6 would be a small, incremental release after the
changes in 6.5.*. Obviously, 6.6 is going to be as full-featured as
earlier releases.

Wasn't it YOU who asked ME to become active again? Your
above thought is a little silly if ya really wanted to
interrupt my sleep mode ;-)

OTOH Vadim is close to WAL and I see activity on
(outer/left/right?) join support too. Maybe there wouldn't be
a v6.6 at all.

WAL is IMHO the only real reason not to choose PostgreSQL for
production. Beeing able to recover (roll forward) from a
backup using transaction log is a required feature for
mission critical data. Thus, having all this (WAL, FOREIGN
KEY etc.) is a greater step forward that that between v6.4
and v6.5.

If all that really materializes in our next release, it's
time to number it v7.0 - no?

Jan

From bouncefilter Wed Sep 29 15:10:19 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA36671
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 15:09:53 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id PAA25405;
Wed, 29 Sep 1999 15:08:47 -0400
Message-ID: <37F263B6.90EFAF29@wgcr.org>
Date: Wed, 29 Sep 1999 15:08:38 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RI status report #2
References: <199909291751.NAA03864@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Yikes. I was just talking to Thomas Lockhart by phone, and was saying
that I thought 6.6 would be a small, incremental release after the
changes in 6.5.*. Obviously, 6.6 is going to be as full-featured as
earlier releases.

And that surprises you?? Even in the short two years I've used
PostgreSQL, I have grown accustomed to major changes every major
version. First there was the NOT NULL (and scads of other) features to
compel me to go from 6.1.1 to 6.2, then there were subselects (and
vastly improved documentation) to get me up to 6.3, then there were
views, rules, and the new protocol to make 6.4 a must-cc event, then
MVCC.... And now I'm maintaining RPM's so I can stay on the released
bleeding edge without breaking my server policies. Whoda thunk it?

Of course, my measly list above doesn't do the development justice -- as
one look at the changelog will show.

Lamar Owen
WGCR Internet Radio

From bouncefilter Wed Sep 29 15:43:57 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA44194
for <pgsql-hackers@postgresql.org>;
Wed, 29 Sep 1999 15:43:29 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from www.wgcr.org (root@www.wgcr.org [206.74.232.194])
by trends.net (8.8.8/8.8.8) with ESMTP id PAA19697
for <pgsql-hackers@postgresql.org>;
Wed, 29 Sep 1999 15:33:27 -0400 (EDT)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id PAA25539;
Wed, 29 Sep 1999 15:33:16 -0400
Message-ID: <37F26973.8DBAAF1@wgcr.org>
Date: Wed, 29 Sep 1999 15:33:07 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: lockhart@alumni.caltech.edu, pgsql-hackers@postgreSQL.org
Subject: Non-beta RPMS for RedHat Linux -- PostgreSQL 6.5.2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have, after testing by myself and others, verified the integrity of
the upgrade procedure I released with the 6.5.1-0.7lo and 6.5.2-0.2lo
RPM sets -- after squashing some bugs and misconceptions (thanks
primarily goes to Dale at RedHat, as he saw what I didn't -- then I
relayed how to fix it).

THEREFORE, I am announcing NON-BETA UPGRADING RPM's for RedHat Linux 6.0
and 5.2, available from http://www.ramifordistat.net. These RPMs carry
a release of 1, no lo appended. Upgrading from a previous release of
PostgreSQL on RedHat Linux is as simple as typing 'rpm -Uvh postgresql*'
, then reading the file /usr/doc/postgresql-6.5.2/README.rpm to get an
idea of what you need to do next.

These RPMS include a fully functional pgaccess 0.98 -- as the 6.5.2
tarball didn't. Also, Thomas' gram.y patches are incorporated at his
urging.

In order to rebuild from the source RPM, you must be running at least
RPM 3.0.2, and must have a full development environment installed --
particularly python-devel, which is not installed by default on RedHat
6.0.

I will be continuing to make improvements and bug fixes to the
packaging, as well as keeping up with the latest and greatest PostgreSQL
released version. If there is demand, I am willing to try to package the
snapshots, for those bleeding edge testers -- however, it is probably
more productive to only package the 'official' PostgreSQL betas. I am,
as always, open to suggestions.

I have, in this line, reorganized my postgres RPM information on
ramifordistat.net to reflect dual development tracks, with a released
non-beta rpm always available in parallel to the beta rpms. If Marc and
the rest of the group want to place the non-beta rpms on
ftp.postgresql.org, be my guest.

Many thanks to those who, in this list particularly, who have helped
with testing these (and Thomas') RPMS and have provided patches. Most
were incorporated by me or had already by incorporated by the fine folks
at RedHat (I particularly liked the init script modification to remove
stale locks in /tmp). Many thanks to Thomas for starting this snowball
rolling and for allowing me to be flattened by it (;-D). Very many
thanks to Oliver Elphick, as he's already been down a similar road with
the Debian packages -- I learned alot from his work, and am using
modified copies of two of his scripts (one of which is a modified
pg_dumpall). And many many thanks to the fine folks at RedHat (in
particular, Cristian, Jeff and Dale), who helped a great deal in lots of
different ways!

Enjoy!
Lamar Owen
WGCR Internet Radio

From bouncefilter Wed Sep 29 16:34:53 1999
Received: from kodu.home.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA53706
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 16:32:53 -0400 (EDT) (envelope-from hannu@trust.ee)
Received: from trust.ee (hannu@localhost [127.0.0.1])
by kodu.home.ee (8.8.7/8.8.7) with ESMTP id XAA00564;
Wed, 29 Sep 1999 23:37:50 +0300
Sender: hannu@kodu.home.ee
Message-ID: <37F2789E.FD90C49F@trust.ee>
Date: Wed, 29 Sep 1999 23:37:50 +0300
From: Hannu Krosing <hannu@trust.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.2.6 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] RI generic trigger procs
References: <m11WOl4-0003kuC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Wieck wrote:

Any combination of attributes in a table referenced to by one
or more FOREIGN KEY ... REFERENCES constraint of another
table shall have a UNIQUE and NOT NULL constraint.

...

So we assume here that any PK is unique and cannot contain NULL's.

What is the reasoning behind requiring this ?

I can't see anything that would mandate this -
* NULLs are'nt equal anyway and ar even disregarded under your
current description.
Or are you just protecting yourself against the case where the
foreign key field is set to null - could this be handled the
same as deleting for cascaded constraints ?
* UNIQUE would save us the check for existing other possible
referenced values - is this mandated by SQL spec ?

-------------
Hannu

From bouncefilter Wed Sep 29 17:30:09 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 RAA67751
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 17:29:12 -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 RAA07237;
Wed, 29 Sep 1999 17:03:43 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909292103.RAA07237@candle.pha.pa.us>
Subject: Re: [HACKERS] RI status report #2
In-Reply-To: <m11WOzk-0003kuC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Sep 29, 1999 09:02:28 pm"
To: Jan Wieck <wieck@debis.com>
Date: Wed, 29 Sep 1999 17:03:43 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Man, that's a heap of additions.

Only the top of the iceberg :-)

Yikes. I was just talking to Thomas Lockhart by phone, and was saying
that I thought 6.6 would be a small, incremental release after the
changes in 6.5.*. Obviously, 6.6 is going to be as full-featured as
earlier releases.

Wasn't it YOU who asked ME to become active again? Your
above thought is a little silly if ya really wanted to
interrupt my sleep mode ;-)

I specialize in silly. :-)

Full-featured is good, much better than small, incremental.

I certainly interrupted your sleep mode.

OTOH Vadim is close to WAL and I see activity on
(outer/left/right?) join support too. Maybe there wouldn't be
a v6.6 at all.

Do I read 7.0 in there?

WAL is IMHO the only real reason not to choose PostgreSQL for
production. Beeing able to recover (roll forward) from a
backup using transaction log is a required feature for
mission critical data. Thus, having all this (WAL, FOREIGN
KEY etc.) is a greater step forward that that between v6.4
and v6.5.

If all that really materializes in our next release, it's
time to number it v7.0 - no?

Yes, I am starting to see 7.0 too.

-- 
  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 Wed Sep 29 17:30:08 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 RAA67799
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 17:29:33 -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 RAA07284;
Wed, 29 Sep 1999 17:06:42 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909292106.RAA07284@candle.pha.pa.us>
Subject: Re: [HACKERS] RI status report #2
In-Reply-To: <37F263B6.90EFAF29@wgcr.org> from Lamar Owen at "Sep 29,
1999 03:08:38 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Wed, 29 Sep 1999 17:06:42 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Yikes. I was just talking to Thomas Lockhart by phone, and was saying
that I thought 6.6 would be a small, incremental release after the
changes in 6.5.*. Obviously, 6.6 is going to be as full-featured as
earlier releases.

And that surprises you?? Even in the short two years I've used
PostgreSQL, I have grown accustomed to major changes every major
version. First there was the NOT NULL (and scads of other) features to
compel me to go from 6.1.1 to 6.2, then there were subselects (and
vastly improved documentation) to get me up to 6.3, then there were
views, rules, and the new protocol to make 6.4 a must-cc event, then
MVCC.... And now I'm maintaining RPM's so I can stay on the released
bleeding edge without breaking my server policies. Whoda thunk it?

Of course, my measly list above doesn't do the development justice -- as
one look at the changelog will show.

Yes, it still shocks me. I was telling Thomas, every release I think,
man, this is so great, no reason anyone should be using a prior release.
And then the next release is the same thing.

The basic issue for me is that each of the new features requsted looks
so hard, I can't imagine how it could be done, but by release time, it
does get done. Amazing.

-- 
  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 Wed Sep 29 17:17:04 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 RAA65763
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 17:16:24 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11WQzD-0003kLC; Wed, 29 Sep 99 23:10 MET DST
Message-Id: <m11WQzD-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] another DECIMAL problem
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Wed, 29 Sep 1999 23:10:03 +0200 (MET DST)
Cc: jose@sferacarta.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199909271805.OAA10180@candle.pha.pa.us> from "Bruce Momjian" at
Sep 27, 99 02:05:29 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

ERROR: Can't find a default operator class for type 1700.

We have the TODO item:

* Add index on NUMERIC/DECIMAL type

Nbtree operator class for NUMERIC is committed.

Item closed.

Jan

From bouncefilter Wed Sep 29 17:17:05 1999
Received: from thelab.hub.org (nat194.229.mpoweredpc.net [142.177.194.229])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA65753
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 17:16:21 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA65525;
Wed, 29 Sep 1999 18:15:35 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 29 Sep 1999 18:15:35 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Jan Wieck <wieck@debis.com>,
PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] RI status report #1
In-Reply-To: <199909271931.PAA12551@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909291815120.33998-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 27 Sep 1999, Bruce Momjian wrote:

Most of the activities after "Second" next step can be
done parallel. I'll commit my changes after that, because
then I'm able to run a full test of deferred constraints
to be sure I'm really on the right track. All co-
developers can join then using the CURRENT tree.

Any comments?

Great. How's that for a comment? :-)

Damn, I was gonna say that but figured it wasn't enough...:)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Wed Sep 29 17:42:01 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA69776
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 17:41:21 -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 RAA07847;
Wed, 29 Sep 1999 17:40:55 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909292140.RAA07847@candle.pha.pa.us>
Subject: Re: [HACKERS] another DECIMAL problem
In-Reply-To: <m11WQzD-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Sep 29, 1999 11:10:03 pm"
To: Jan Wieck <wieck@debis.com>
Date: Wed, 29 Sep 1999 17:40:55 -0400 (EDT)
CC: jose@sferacarta.com, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

ERROR: Can't find a default operator class for type 1700.

We have the TODO item:

* Add index on NUMERIC/DECIMAL type

Nbtree operator class for NUMERIC is committed.

Item closed.

TODO item marked as completed:

* -Add index on NUMERIC/DECIMAL type

-- 
  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 Wed Sep 29 17:43:03 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA69926
for <hackers@postgreSQL.org>; Wed, 29 Sep 1999 17:42:29 -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 RAA07912;
Wed, 29 Sep 1999 17:41:53 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909292141.RAA07912@candle.pha.pa.us>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-Reply-To: <m11Vi2G-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Sep 27, 1999 11:10:12 pm"
To: Jan Wieck <wieck@debis.com>
Date: Wed, 29 Sep 1999 17:41:53 -0400 (EDT)
CC: dz@wizard.net, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Removed manually. Thanks. I have been far behind in keeping up with
patches.

Looks like :)

Well, actually running regression test emits alot of

NOTICE: Auto-creating query reference to table <table-name>

from inside the parser - which make most of the regression
tests fail. Not sure which of the patches introduced them
and why. Could you please take a look at it? On the things
I'm doing right now (adding fields + indices to system
catalogs and modifying code that's invoked during heap_open()
or the like) I feel much better if I get identical (+
correct) regression results before'n'after.

I have backed this change out. I will re-enable it when things are
quiet and the regression tests can be re-generated.

-- 
  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 Wed Sep 29 17:50:01 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 RAA71039
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 17:49:32 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11WRVM-0003kLC; Wed, 29 Sep 99 23:43 MET DST
Message-Id: <m11WRVM-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] RI generic trigger procs
To: hannu@trust.ee (Hannu Krosing)
Date: Wed, 29 Sep 1999 23:43:16 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37F2789E.FD90C49F@trust.ee> from "Hannu Krosing" at Sep 29,
99 11:37:50 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Hannu Krosing wrote:

Jan Wieck wrote:

Any combination of attributes in a table referenced to by one
or more FOREIGN KEY ... REFERENCES constraint of another
table shall have a UNIQUE and NOT NULL constraint.

...

So we assume here that any PK is unique and cannot contain NULL's.

What is the reasoning behind requiring this ?

I can't see anything that would mandate this -
* NULLs are'nt equal anyway and ar even disregarded under your
current description.
Or are you just protecting yourself against the case where the
foreign key field is set to null - could this be handled the
same as deleting for cascaded constraints ?

MATCH FULL (as I planned to implement for now) mandates that
either none or all fields of foreign key are NULL.

Of course, we could handle the UPDATE of referenced key (PK)
from none NULL to some/all NULL as if the operation was
DELETE. And similar treating UPDATE/DELETE where OLD had
NULL(s) as nothing, since according to MATCH FULL absolutely
no reference can exist.

When looking ahead it's better to add one more argument to
the trigger proc's specifying the MATCH type. That way we
could add support for MATCH PARTIAL by only working on the
trigger procs with no need to touch anything else in the
system. This will be the 4th argument before the attribute
name pairs and containts either 'FULL' or 'PARTIAL'.

Support for MATCH PARTIAL is alot more complicated though -
thus I left it for later. Let's see how fast we could get
this all to work and then decide if it's something to include
in this or one of the next releases.

* UNIQUE would save us the check for existing other possible
referenced values - is this mandated by SQL spec ?

SQL3 specification X3H2-93-359 and MUN-003

11.9 <referential constraint definition>

2) Case:

a) If the <referenced table and columns> specifies a <reference
column list>, then the set of column names of that <refer-
ence column list> shall be equal to the set of column names
in the unique columns of a unique constraint of the refer-
enced table. Let referenced columns be the column or columns
identified by that <reference column list> and let refer-
enced column be one such column. Each referenced column shall
identify a column of the referenced table and the same column
shall not be identified more than once.

b) If the <referenced table and columns> does not specify a
<reference column list>, then the table descriptor of the
referenced table shall include a unique constraint that spec-
ifies PRIMARY KEY. Let referenced columns be the column or
columns identified by the unique columns in that unique con-
straint and let referenced column be one such column. The
<referenced table and columns> shall be considered to implic-
itly specify a <reference column list> that is identical to
that <unique column list>.

So the UNIQUE constraint on the referenced columns of the
referenced table is mandatory.

And the spec also tells that the UNIQUE constrain on the
referenced columns shall NOT be deferrable, so our (mis)usage
of a unique index for uniqueness doesn't break the specs
here.

Jan

From bouncefilter Wed Sep 29 18:23:02 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 SAA76491
for <hackers@postgreSQL.org>; Wed, 29 Sep 1999 18:22:41 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgreSQL.org
id m11WS1K-0003kLC; Thu, 30 Sep 99 00:16 MET DST
Message-Id: <m11WS1K-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] PostgreSQL 6.5.2
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Thu, 30 Sep 1999 00:16:18 +0200 (MET DST)
Cc: wieck@debis.com, dz@wizard.net, hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199909292141.RAA07912@candle.pha.pa.us> from "Bruce Momjian" at
Sep 29, 99 05:41:53 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

Removed manually. Thanks. I have been far behind in keeping up with
patches.

Looks like :)

Well, actually running regression test emits alot of

NOTICE: Auto-creating query reference to table <table-name>

from inside the parser - which make most of the regression
tests fail. Not sure which of the patches introduced them
and why. Could you please take a look at it? On the things
I'm doing right now (adding fields + indices to system
catalogs and modifying code that's invoked during heap_open()
or the like) I feel much better if I get identical (+
correct) regression results before'n'after.

I have backed this change out. I will re-enable it when things are
quiet and the regression tests can be re-generated.

[pgsql@hot] ~/devel/src/test/regress > ./checkresults
====== int2 ======
10c10
< ERROR: pg_atoi: error reading "100000": Numerical result out of range
---

ERROR: pg_atoi: error reading "100000": Math result not representable

====== int4 ======
10c10
< ERROR: pg_atoi: error reading "1000000000000": Numerical result out of range
---

ERROR: pg_atoi: error reading "1000000000000": Math result not representable

[pgsql@hot] ~/devel/src/test/regress >

Such a regression result while we're in the middle of feature
development.

I'm really impressed - if we only can keep it on this level!

Jan

From bouncefilter Wed Sep 29 18:28:02 1999
Received: from idiom.com (root@idiom.com [216.240.32.1])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA77318
for <pgsql-hackers@hub.org>; Wed, 29 Sep 1999 18:27:12 -0400 (EDT)
(envelope-from jason@idiom.com)
Received: from idiom.com (jason@localhost [127.0.0.1])
by idiom.com (8.9.3/8.9.3) with ESMTP id PAA09905
for <pgsql-hackers@hub.org>; Wed, 29 Sep 1999 15:26:44 -0700 (PDT)
Message-Id: <199909292226.PAA09905@idiom.com>
To: pgsql-hackers@hub.org
Subject: shared memory 651, freebsd 2.2.7
Date: Wed, 29 Sep 1999 15:26:44 -0700
From: Jason Venner <jason@idiom.com>

How much shared memory do you need?

options SHMMNI=96 # number of shared memory identifiers default is 32
options SHMMAXPGS=20480 # number of pages a shgment can have and the total number of pages? default 1024
# max seg size is 25meg
options SHMSEG=64 # number of segments per process
options SEMMNI=40 # number of semaphore identifiers
options SEMMNS=240 # number of semaphores in the system
options MSGSEG=4096 # max number of message segments is this

With Postgres set for 512 backends, I can't start it.
I can run with 128, but at 10240 have been running out during large transactions.
I am hoping I can get it at 20480.

From bouncefilter Wed Sep 29 19:41:02 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 TAA90608
for <hackers@postgreSQL.org>; Wed, 29 Sep 1999 19:40:30 -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 TAA05432;
Wed, 29 Sep 1999 19:38:37 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: New notices?
In-reply-to: Your message of Wed, 29 Sep 1999 15:57:06 +0000
<37F236D2.B2A27832@alumni.caltech.edu>
Date: Wed, 29 Sep 1999 19:38:37 -0400
Message-ID: <5430.938648317@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Tom Lane and I agreed we need to issue a NOTICE for this type of
auto-FROM creation.

OK, but I may happily break it when implementing table and column
aliases for join syntax. Don't know yet what the ramifications will
be...

Well, it's certainly a second-order feature. How about you leave the
message turned off until the dust has settled from JOIN, and then we
can see what it takes to make it work right...

regards, tom lane

From bouncefilter Wed Sep 29 19:49:59 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 TAA91870
for <pgsql-hackers@hub.org>; Wed, 29 Sep 1999 19:49: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 TAA05540;
Wed, 29 Sep 1999 19:48:14 -0400 (EDT)
To: Jason Venner <jason@idiom.com>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] shared memory 651, freebsd 2.2.7
In-reply-to: Your message of Wed, 29 Sep 1999 15:26:44 -0700
<199909292226.PAA09905@idiom.com>
Date: Wed, 29 Sep 1999 19:48:14 -0400
Message-ID: <5538.938648894@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Jason Venner <jason@idiom.com> writes:

How much shared memory do you need?

What's probably getting you is the SEMMNS & SEMMNI limits --- we need a
semaphore per backend, and an identifier for every 16 semas.

I thought there was a discussion of kernel resource settings
somewhere in the documentation, but I'm not sure where offhand.

regards, tom lane

From bouncefilter Wed Sep 29 21:16:22 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA19509
for <hackers@postgreSQL.org>; Wed, 29 Sep 1999 21:16:17 -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 VAA10719;
Wed, 29 Sep 1999 21:15:46 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909300115.VAA10719@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: New notices?
In-Reply-To: <5430.938648317@sss.pgh.pa.us> from Tom Lane at "Sep 29,
1999 07:38:37 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 29 Sep 1999 21:15:46 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Tom Lane and I agreed we need to issue a NOTICE for this type of
auto-FROM creation.

OK, but I may happily break it when implementing table and column
aliases for join syntax. Don't know yet what the ramifications will
be...

Well, it's certainly a second-order feature. How about you leave the
message turned off until the dust has settled from JOIN, and then we
can see what it takes to make it work right...

Yes, I think that's the plan.

-- 
  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 Wed Sep 29 21:24:30 1999
Received: from ext04.sra.co.jp (IDENT:root@ykh28DS23.kng.mesh.ad.jp
[133.205.214.23]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA20382
for <hackers@postgreSQL.org>; Wed, 29 Sep 1999 21:24:02 -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 KAA01268
for <hackers@postgreSQL.org>; Thu, 30 Sep 1999 10:15:59 +0900
Message-Id: <199909300115.KAA01268@ext16.sra.co.jp>
To: hackers@postgreSQL.org
Subject: Announcement: pgbench-1.1 released
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
Date: Thu, 30 Sep 1999 10:15:59 +0900
Sender: t-ishii@ext04.sra.co.jp

Hi,

I have made a small tool called "pgbench," that may be useful for
some stress testings and performance measurements for PostgreSQL.
pgbench can be obtained from:

ftp://ftp.sra.co.jp/pub/cmd/postgres/pgbench/

Pgbench runs small transactions similar to TPC-B concurrently and
reports the number of transactions actually done per second (tps).
Pgbench uses the asynchronous functions of libpq to simulate
concurrent clients. Example outputs from pgbench are shown below:

number of clients: 4
number of transactions per client: 100
number of processed transactions: 400/400
tps = 19.875015(including connections establishing)
tps = 20.098827(excluding connections establishing)

(above result was reported on my PowerBook with 603e CPU(180MHz), 80MB
mem running PostgreSQL 6.5.2 with -F option, and Linux 2.2.1 kernel)

Pgbench does not require any special libraries other than libpq. It
comes with a configure script and should be very easy to build.

*CAUTION*
pgbench will blow away tables named accounts, branches, history and
tellers. It is best to create a new database for pgbench before
running it.

BTW, the greatest tps I have ever seen was around 260 on a Linux box
running RedHat 6.0, having 2 Pentiumn III 600MHz CPUs and 512MB mem.

Enjoy,
---
Tatsuo Ishii

From bouncefilter Wed Sep 29 21:23:35 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 VAA20299
for <pgsql-hackers@hub.org>; Wed, 29 Sep 1999 21:22:39 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@hub.org
id m11WUpa-0003kLC; Thu, 30 Sep 99 03:16 MET DST
Message-Id: <m11WUpa-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] shared memory 651, freebsd 2.2.7
To: jason@idiom.com (Jason Venner)
Date: Thu, 30 Sep 1999 03:16:22 +0200 (MET DST)
Cc: pgsql-hackers@hub.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199909292226.PAA09905@idiom.com> from "Jason Venner" at Sep 29,
99 03:26:44 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

How much shared memory do you need?

options SHMMNI=96 # number of shared memory identifiers default is 32
options SHMMAXPGS=20480 # number of pages a shgment can have and the total number of pages? default 1024
# max seg size is 25meg
options SHMSEG=64 # number of segments per process
options SEMMNI=40 # number of semaphore identifiers
options SEMMNS=240 # number of semaphores in the system
options MSGSEG=4096 # max number of message segments is this

With Postgres set for 512 backends, I can't start it.
I can run with 128, but at 10240 have been running out during large transactions.
I am hoping I can get it at 20480.

What do you need 512 backends for? Such a high concurrency
doesn't make things better (locking, spin locks etc.).

Would eventually some kind of a middle tear application with
a limited number of work processes which connect to the
database help?

Jan

From bouncefilter Wed Sep 29 23:06:14 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 XAA40148
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 23:05:10 -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 XAA12432
for <pgsql-hackers@postgreSQL.org>;
Wed, 29 Sep 1999 23:04:28 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: postmaster dead on startup from unportable SSL patch
Date: Wed, 29 Sep 1999 23:04:28 -0400
Message-ID: <12430.938660668@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Someone had the bright idea that the postmaster's -i switch could
be redefined as
-i same as it ever was
-is accept only SSL connections

Unfortunately, implementing that requires a getopt() that understands
the GNU double-colon extension ("i::"). HPUX's getopt, which claims
to be fully conformant to POSIX.2 and about six other standards,
doesn't grok it. Net result: postmaster is quitting on startup with
a "usage" message for me. Doubtless it will also fail on most other
non-GNU-libc platforms.

Unless we want to get into the business of supplying a substitute
optarg() library routine, we're going to have to pick a more portable
switch syntax for SSL. (I might also point out that "-is" used to
have a quite different interpretation, ie "-i -s", which could trip
up someone somewhere.)

I can see two reasonable choices: (a) pick a currently-unused
switch letter that you specify *in addition to* -i, if you want
only secure connections; (b) pick a currently-unused switch letter
that you specify *instead of* -i, if you want only secure connections.

I'd lean towards (a) except that both of the obvious choices, -s and -S,
are already taken. If we go with (b), -I is available and perhaps not
a totally off-the-wall choice, but I can't say I really like it.

Comments? Ideas? Is it time to give up on getopt and go to multiletter
switch names? (Of course that would break a lot of people's startup
scripts... but we may someday be forced into it... maybe it's better
to bite the bullet now.)

regards, tom lane

From bouncefilter Thu Sep 30 00:33:44 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA52755
for <pgsql-hackers@hub.org>; Thu, 30 Sep 1999 00:33:23 -0400 (EDT)
(envelope-from dhogaza@pacifier.com)
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by trends.net (8.8.8/8.8.8) with ESMTP id AAA10600
for <pgsql-hackers@hub.org>; Thu, 30 Sep 1999 00:06:29 -0400 (EDT)
Received: from desktop (dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA29976;
Wed, 29 Sep 1999 21:06:19 -0700 (PDT)
Message-Id: <3.0.1.32.19990929205223.00a7a8c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 29 Sep 1999 20:52:23 -0700
To: wieck@debis.com (Jan Wieck), jason@idiom.com (Jason Venner)
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] shared memory 651, freebsd 2.2.7
Cc: pgsql-hackers@hub.org
In-Reply-To: <m11WUpa-0003kLC@orion.SAPserv.Hamburg.dsh.de>
References: <199909292226.PAA09905@idiom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 03:16 AM 9/30/99 +0200, Jan Wieck wrote:

Would eventually some kind of a middle tear application with
a limited number of work processes which connect to the
database help?

This is exactly how some web servers, i.e. AOLServer (which
I use) help to throttle traffic. This server lets you
limit the number of pooled backends, when the pool's exhausted,
the web server blocks new threads until there's a free back
end.

This means you can configure your web server to service the
number of concurrent back-ends you think it can deal with,
based on its hardware configuration and the load placed on
it due to your specific queries and database contents, and
web load.

AOLServer's been doing this for at least five years. For
web work, it's seems to be the right place to do it, because
there are other things that impact the load the server can
deal with. The db access throttle is just one of various
throttles one can imagine when trying to tune the entire
site.

Of course, this is web specific in detail. Not necessarily
in concept, though...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Thu Sep 30 01:24:44 1999
Received: from nadia.s.bawue.de (root@nadia.s.bawue.de [193.197.11.52])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA60897
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 01:24:35 -0400 (EDT)
(envelope-from E.Mergl@bawue.de)
Received: from bawue.de (sls.s.bawue.de [193.197.11.90])
by nadia.s.bawue.de (8.9.3/8.9.3) with ESMTP id HAA24799;
Thu, 30 Sep 1999 07:24:33 +0200 (CEST)
Posted-Date: Thu, 30 Sep 1999 07:24:33 +0200 (CEST)
Sender: mergl@nadia.s.bawue.de
Message-ID: <37F2F412.80ADD2D2@bawue.de>
Date: Thu, 30 Sep 1999 07:24:34 +0200
From: Edmund Mergl <E.Mergl@bawue.de>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL Hackers Mailing List <pgsql-hackers@postgreSQL.org>
Subject: Win32 =?iso-8859-1?Q?p=FCort?= of libpq
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit

Hi,

in the last few days I compiled libpq on Windows NT
using MS Visual Studio 6.0. I followed the instructions
given by Bob Kline <bkline@rksystems.com> in his mail from
Fri, 3 Sep 1999.
Unfortuanetely he sent his mail only to dbi-users, so I would
like to repeat one major problem on this list.

Here is an excerpt from his mail:

4. The DllMain function in src/interfaces/libpq/libpqdll.c of the
PostgreSQL 6.5 sources, in which WSAStartup is invoked, is never called,
which causes gethostbyname calls to fail. Solution (more properly,
"kludge" -- I know there's a cleaner fix somewhere, but this works for
now): immediately after the local declarations for the connectDB function
in src/interfaces/libpq/fe-connect.c:

#ifdef WIN32
static int WeHaveCalledWSAStartup;

if (!WeHaveCalledWSAStartup) {
WSADATA wsaData;
if (WSAStartup(MAKEWORD(1, 1), &wsaData)) {
sprintf(conn->errorMessage,
"WSAStartup failed: errno=%d\n", h_errno);
goto connect_errReturn;
}
WeHaveCalledWSAStartup = 1;
}
#endif

Besides the effort to port the complete server om Win32
using the Cygnus environment, it would be nice to be able
to compile at least the client part (libpq) with a standard
MS-compiler.

So please apply this patch or an equivalent cleaner solution.

thanks
Edmund

--
Edmund Mergl
mailto:E.Mergl@bawue.de
http://www.bawue.de/~mergl

From bouncefilter Thu Sep 30 01:55:45 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 BAA64889
for <pgsql-hackers@postgresql.org>;
Thu, 30 Sep 1999 01:54:52 -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 FAA11846;
Thu, 30 Sep 1999 05:53:43 GMT
Sender: lockhart@hub.org
Message-ID: <37F2FAE7.C9C109EA@alumni.caltech.edu>
Date: Thu, 30 Sep 1999 05:53:43 +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: "Marc G. Fournier" <scrappy@hub.org>
CC: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgresql.org
Subject: Re: Non-beta RPMS for RedHat Linux -- PostgreSQL 6.5.2
References: <37F26973.8DBAAF1@wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

THEREFORE, I am announcing NON-BETA UPGRADING RPM's for RedHat Linux 6.0
and 5.2, available from http://www.ramifordistat.net.

Marc, we should have these posted at ftp.postgresql.org. Is there a
way to allow Lamar to deposit files into /pub/RPMS and /pub/SRPMS?
afaik his web site only allows http transfers, so I don't find it
convenient to relay them through a remote machine (one at work). My
home machine has a narrow pipe, so that won't work either...

I can help with the file transfers once I'm at work, but that isn't
particularly timely or convenient.

- Thomas

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

From bouncefilter Thu Sep 30 02:04:45 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 CAA66546
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 02:03:59 -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 GAA11894;
Thu, 30 Sep 1999 06:03:26 GMT
Sender: lockhart@hub.org
Message-ID: <37F2FD2E.81B045A6@alumni.caltech.edu>
Date: Thu, 30 Sep 1999 06:03:26 +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: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster dead on startup from unportable SSL patch
References: <12430.938660668@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Comments? Ideas? Is it time to give up on getopt and go to multiletter
switch names? (Of course that would break a lot of people's startup
scripts... but we may someday be forced into it... maybe it's better
to bite the bullet now.)

Break it ;)

The single-character switches are definitely non-intuitive. Implement
-I for now if you want, but if/when we release v7.0 breakage should be
OK. And with Jan's and Vadim's projects (among others) it looks like
v7.0 is coming up soon :)

- Thomas

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

From bouncefilter Thu Sep 30 02:09:45 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 CAA67136
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 02:08:52 -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 GAA11906;
Thu, 30 Sep 1999 06:08:18 GMT
Sender: lockhart@hub.org
Message-ID: <37F2FE52.AC28EAE8@alumni.caltech.edu>
Date: Thu, 30 Sep 1999 06:08: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: Zakkr <zakkr@zf.jcu.cz>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] string function
References: <Pine.LNX.3.96.990929172058.2711A-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If I good understand you, you don't reject strftime idea. I try it..

But I was trying to nudge you to look at a slightly different idea
which would be compatible with Oracle, for no particularly good reason
other than that would help some folks when they try to port apps over
to Postgres.

- Thomas

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

From bouncefilter Fri Oct 1 00:56:03 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA74566
for <pgsql-hackers@postgresql.org>; Fri, 1 Oct 1999 00:51:47 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from localhost (root@hectic-2.jpl.nasa.gov [128.149.68.204])
by trends.net (8.8.8/8.8.8) with ESMTP id WAA04548
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 22:42:15 -0400 (EDT)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id GAA11925;
Thu, 30 Sep 1999 06:17:01 GMT
Sender: lockhart@trends.net
Message-ID: <37F3005C.3B0514C8@alumni.caltech.edu>
Date: Thu, 30 Sep 1999 06:17:00 +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: Christof Petig <christof.petig@wtal.de>
CC: Lamar Owen <lamar.owen@wgcr.org>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Regression tests on intel for 6.5.2
References: <28004.938476013@sss.pgh.pa.us>
<99092720011203.07044@lowen.wgcr.org> <37F22ABD.50997341@wtal.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

which is evidently doing the wrong thing on your platform. What does
your man page for exp() say about error return conventions?

I checked it twice, I can't find any error in the current sources. I even wrote a test
program...
So both methods seem to work. (finite is a function on glibc-2.1 systems)

And that is the problem. I didn't have enough platforms to test on, so
when I improved the code I did so in a way that I would get a better
result on at least my platform (probably RH4.2 or earlier) without
breaking the behavior on other platforms.

So, I test locally for finite() being defined as a macro! But on newer
glibc systems it is a real function, so you are seeing the old
behavior.

A better thing to do would be to define HAVE_FINITE, and to have a
./configure test for it. That should be easy enough; do you have time
to look at it? Then code like

#ifndef finite
if (errno == ERANGE)
#else
/* infinity implies overflow, zero implies underflow */
if (!finite(*result) || *result == 0.0)
#endif

Could become

...
#if HAVE_FINITE
...

- Thomas

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

From bouncefilter Thu Sep 30 05:28:47 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA96478
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 05:27:52 -0400 (EDT) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA20313;
Thu, 30 Sep 1999 10:19:00 +0200
Date: Thu, 30 Sep 1999 10:19:00 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] string function
In-Reply-To: <37F2FE52.AC28EAE8@alumni.caltech.edu>
Message-ID: <Pine.LNX.3.96.990930095535.17787B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 30 Sep 1999, Thomas Lockhart wrote:

If I good understand you, you don't reject strftime idea. I try it..

But I was trying to nudge you to look at a slightly different idea
which would be compatible with Oracle, for no particularly good reason
other than that would help some folks when they try to port apps over
to Postgres.

My first idea was write to PSQL strftime full compatible with 'C'
strftime(). Now I see Oracle documentation for TO_CHAR(), ..hmm it is not
easy, it is very specific (unique) function, but I agree - your idea
(compatible with Oracle) is better :-)). I try to_char()..

Think for your time Thomas.

Zakkr

From bouncefilter Thu Sep 30 06:42:48 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 GAA06654
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 06:42:26 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11WdZP-0003kLC; Thu, 30 Sep 99 12:36 MET DST
Message-Id: <m11WdZP-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: prosrc index removed
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Thu, 30 Sep 1999 12:36:15 +0200 (MET DST)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

It's gone!

I've just removed the pg_proc_prosrc_index and all it's
related things like functions and the syscache for it.

Actually, this index made problems (I was able to corrupt the
index by using 2700 byte sized PL procedures) and it wasn't
used at all. The only reference I found to it was when the
system automagically creates a SET function from a
specialized node - but first this code is #ifdef'd out
(SETS_FIXED) and second I wasn't able to figure out which SQL
construct would force this to happen.

If someone in the future does this SETS_FIXED, the lookup in
catalog/pg_proc.c must fallback to a heap scan or do
something smarter (maybe a separate system catalog for these
SET functions to quickly find them). For now it would throw
an elog(ERROR) if ever hit.

Jan

From bouncefilter Thu Sep 30 07:44:48 1999
Received: from ritchie.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA14531
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 07:43:59 -0400 (EDT)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by ritchie.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id PAA19814;
Thu, 30 Sep 1999 15:43:37 +0400 (MSK/MSD)
X-Real-To: pgsql-hackers@postgreSQL.org
Received: (from dms@localhost)
by woland.wplus.net (8.9.2/8.9.1/wplus.2) id PAA24090;
Thu, 30 Sep 1999 15:43:37 +0400 (MSD)
Message-ID: <XFMail.990930154337.dms@wplus.net>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <37F2F412.80ADD2D2@bawue.de>
Date: Thu, 30 Sep 1999 15:43:37 +0400 (MSD)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: Edmund Mergl <E.Mergl@bawue.de>
Subject: RE: [HACKERS] Win32=?KOI8-R?Q?_p=FCort?= of libpq
Cc: PostgreSQL Hackers Mailing List <pgsql-hackers@postgreSQL.org>

On 30-Sep-99 Edmund Mergl wrote:

Hi,

in the last few days I compiled libpq on Windows NT
using MS Visual Studio 6.0. I followed the instructions
given by Bob Kline <bkline@rksystems.com> in his mail from
Fri, 3 Sep 1999.
Unfortuanetely he sent his mail only to dbi-users, so I would
like to repeat one major problem on this list.

Here is an excerpt from his mail:

4. The DllMain function in src/interfaces/libpq/libpqdll.c of the
PostgreSQL 6.5 sources, in which WSAStartup is invoked, is never called,
which causes gethostbyname calls to fail. Solution (more properly,
"kludge" -- I know there's a cleaner fix somewhere, but this works for
now): immediately after the local declarations for the connectDB function
in src/interfaces/libpq/fe-connect.c:

#ifdef WIN32
static int WeHaveCalledWSAStartup;

if (!WeHaveCalledWSAStartup) {
WSADATA wsaData;
if (WSAStartup(MAKEWORD(1, 1), &wsaData)) {
sprintf(conn->errorMessage,
"WSAStartup failed: errno=%d\n", h_errno);
goto connect_errReturn;
}
WeHaveCalledWSAStartup = 1;
}
#endif

You need not to take care wether WSAStartup is alredy called or not.
Windows handle it automatically.

---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

From bouncefilter Thu Sep 30 08:06:49 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id IAA18066
for <pgsql-hackers@postgresql.org>;
Thu, 30 Sep 1999 08:06:30 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 12573 invoked by uid 1001); 30 Sep 1999 12:06:31 -0000
Date: Thu, 30 Sep 1999 08:06:31 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Dmitry Samersoff <dms@wplus.net>
cc: Edmund Mergl <E.Mergl@bawue.de>,
PostgreSQL Hackers Mailing List <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] Win32=?KOI8-R?Q?_p=FCort?= of libpq
In-Reply-To: <XFMail.990930154337.dms@wplus.net>
Message-ID: <Pine.BSF.4.05.9909300805320.12281-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 30 Sep 1999, Dmitry Samersoff wrote:

On 30-Sep-99 Edmund Mergl wrote:

Hi,

in the last few days I compiled libpq on Windows NT
using MS Visual Studio 6.0. I followed the instructions
given by Bob Kline <bkline@rksystems.com> in his mail from
Fri, 3 Sep 1999.
Unfortuanetely he sent his mail only to dbi-users, so I would
like to repeat one major problem on this list.

Here is an excerpt from his mail:

4. The DllMain function in src/interfaces/libpq/libpqdll.c of the
PostgreSQL 6.5 sources, in which WSAStartup is invoked, is never called,
which causes gethostbyname calls to fail. Solution (more properly,
"kludge" -- I know there's a cleaner fix somewhere, but this works for
now): immediately after the local declarations for the connectDB function
in src/interfaces/libpq/fe-connect.c:

#ifdef WIN32
static int WeHaveCalledWSAStartup;

if (!WeHaveCalledWSAStartup) {
WSADATA wsaData;
if (WSAStartup(MAKEWORD(1, 1), &wsaData)) {
sprintf(conn->errorMessage,
"WSAStartup failed: errno=%d\n", h_errno);
goto connect_errReturn;
}
WeHaveCalledWSAStartup = 1;
}
#endif

You need not to take care wether WSAStartup is alredy called or not.
Windows handle it automatically.

By calling it yourself you have more control over which minimum version
will be loaded.

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

From bouncefilter Thu Sep 30 08:53:49 1999
Received: from ritchie.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA25073
for <pgsql-hackers@postgresql.org>;
Thu, 30 Sep 1999 08:52:55 -0400 (EDT)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by ritchie.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id QAA24469;
Thu, 30 Sep 1999 16:52:04 +0400 (MSK/MSD)
X-Real-To: E.Mergl@bawue.de
Received: (from dms@localhost)
by woland.wplus.net (8.9.2/8.9.1/wplus.2) id QAA24163;
Thu, 30 Sep 1999 16:52:04 +0400 (MSD)
Message-ID: <XFMail.990930165204.dms@wplus.net>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.BSF.4.05.9909300805320.12281-100000@paprika.michvhf.com>
Date: Thu, 30 Sep 1999 16:52:04 +0400 (MSD)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: Vince Vielhaber <vev@michvhf.com>
Subject: RE: [HACKERS] Win32=?KOI8-R?Q?_p=FCort?= of libpq
Cc: PostgreSQL Hackers Mailing List <pgsql-hackers@postgresql.org>,
Edmund Mergl <E.Mergl@bawue.de>

On 30-Sep-99 Vince Vielhaber wrote:

On Thu, 30 Sep 1999, Dmitry Samersoff wrote:

On 30-Sep-99 Edmund Mergl wrote:

Hi,

in the last few days I compiled libpq on Windows NT
using MS Visual Studio 6.0. I followed the instructions
given by Bob Kline <bkline@rksystems.com> in his mail from
Fri, 3 Sep 1999.
Unfortuanetely he sent his mail only to dbi-users, so I would
like to repeat one major problem on this list.

Here is an excerpt from his mail:

4. The DllMain function in src/interfaces/libpq/libpqdll.c of the
PostgreSQL 6.5 sources, in which WSAStartup is invoked, is never called,
which causes gethostbyname calls to fail. Solution (more properly,
"kludge" -- I know there's a cleaner fix somewhere, but this works for
now): immediately after the local declarations for the connectDB function
in src/interfaces/libpq/fe-connect.c:

#ifdef WIN32
static int WeHaveCalledWSAStartup;

if (!WeHaveCalledWSAStartup) {
WSADATA wsaData;
if (WSAStartup(MAKEWORD(1, 1), &wsaData)) {
sprintf(conn->errorMessage,
"WSAStartup failed: errno=%d\n", h_errno);
goto connect_errReturn;
}
WeHaveCalledWSAStartup = 1;
}
#endif

You need not to take care wether WSAStartup is alredy called or not.
Windows handle it automatically.

By calling it yourself you have more control over which minimum version
will be loaded.

Yes, but you can just call

WSADATA wsaData;
if (WSAStartup(MAKEWORD(1, 1), &wsaData)) {
sprintf(conn->errorMessage,
"WSAStartup failed: errno=%d\n", h_errno);
goto connect_errReturn;
}

without WeHaveCalledWSAStartup at all.

---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

From bouncefilter Thu Sep 30 09:17:50 1999
Received: from trooper.velocet.ca (trooper.velocet.net [216.126.82.226] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id JAA28850
for <pgsql-hackers@postgresql.org>;
Thu, 30 Sep 1999 09:17:26 -0400 (EDT)
(envelope-from dgilbert@trooper.velocet.ca)
Received: (from dgilbert@localhost)
by trooper.velocet.ca (8.9.3/8.9.3) id JAA58569;
Thu, 30 Sep 1999 09:17:26 -0400 (EDT) (envelope-from dgilbert)
From: David Gilbert <dgilbert@velocet.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14323.25317.750866.864553@trooper.velocet.ca>
Date: Thu, 30 Sep 1999 09:17:25 -0400 (EDT)
To: pgsql-hackers@postgresql.org

OK... doing some serious report hacking... and I decided I wanted to
do this:

select acct_id,
sum(case when recd > ('now'::date - '30 days'::timespan)::date
then amt else 0) as current
from payable where not paid_p group by acct_id order by acct_id;

but pgsql gives me:

ERROR: parser: parse error at or near ")"

Now... I also thought I might be able to contruct
sum(amt * <boolean>), but this also isn't allowed. I think that we
should make an int(boolean) function.

Dave.

From bouncefilter Thu Sep 30 09:28:49 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA30383
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 09:28:15 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <T2ZVSPCZ>; Thu, 30 Sep 1999 15:28:11 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C0EA@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'David Gilbert'" <dgilbert@velocet.ca>, pgsql-hackers@postgreSQL.org
Subject: RE:
Date: Thu, 30 Sep 1999 15:23:26 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Use the stuff that just got sent for Access (Interfaces list, header ->
"ODBC-client->Linux-server: datatype boolean not recognized?"). Same
principle.

MikeA

-----Original Message-----
From: David Gilbert [mailto:dgilbert@velocet.ca]
Sent: Thursday, September 30, 1999 3:17 PM
To: pgsql-hackers@postgreSQL.org
Subject:

OK... doing some serious report hacking... and I decided I wanted to
do this:

select acct_id,
sum(case when recd > ('now'::date - '30 days'::timespan)::date
then amt else 0) as current
from payable where not paid_p group by acct_id order by acct_id;

but pgsql gives me:

ERROR: parser: parse error at or near ")"

Now... I also thought I might be able to contruct
sum(amt * <boolean>), but this also isn't allowed. I think that we
should make an int(boolean) function.

Dave.

--
=============================================================
===============
|David Gilbert, Velocet Communications. | Two things
can only be |
|Mail: dgilbert@velocet.net | equal if
and only if they |
|http://www.velocet.net/~dgilbert | are
precisely opposite. |
=========================================================GLO=
===============

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

From bouncefilter Thu Sep 30 09:26:49 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 JAA30222
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 09:26:40 -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 JAA13735;
Thu, 30 Sep 1999 09:25:04 -0400 (EDT)
To: Christof Petig <christof.petig@wtal.de>
cc: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Regression tests on intel for 6.5.2
In-reply-to: Your message of Wed, 29 Sep 1999 17:05:34 +0200
<37F22ABD.50997341@wtal.de>
Date: Thu, 30 Sep 1999 09:25:04 -0400
Message-ID: <13733.938697904@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Christof Petig <christof.petig@wtal.de> writes:

Perhaps (strange thoughts come in to my mind ...) the compiler
optimizes the function call into a machine instruction ...
/tmp> cc -O2 -o test test.c -lm
/tmp> ./test
!finite

Looks like this is the case.

Bingo! I think you've got it.

I would propose another autoconf test. (I could easily do it.)

Yes, we should not be assuming that finite() is a macro, which is what
that #ifdef coding does. We need a HAVE_FINITE configuration test.
If you have time to prepare the diffs it'd be great.

regards, tom lane

From bouncefilter Thu Sep 30 09:34:50 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 JAA31332
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 09:33:57 -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 JAA13842;
Thu, 30 Sep 1999 09:33:10 -0400 (EDT)
To: David Gilbert <dgilbert@velocet.ca>
cc: pgsql-hackers@postgreSQL.org
In-reply-to: Your message of Thu, 30 Sep 1999 09:17:25 -0400 (EDT)
<14323.25317.750866.864553@trooper.velocet.ca>
Date: Thu, 30 Sep 1999 09:33:09 -0400
Message-ID: <13840.938698389@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

David Gilbert <dgilbert@velocet.ca> writes:

select acct_id,
sum(case when recd > ('now'::date - '30 days'::timespan)::date
then amt else 0) as current
from payable where not paid_p group by acct_id order by acct_id;
but pgsql gives me:
ERROR: parser: parse error at or near ")"

The case construct has to be terminated with an "end" keyword;
"... else 0 end)" ought to work.

Now... I also thought I might be able to contruct
sum(amt * <boolean>), but this also isn't allowed. I think that we
should make an int(boolean) function.

That's been suggested before, and I agree.

regards, tom lane

From bouncefilter Thu Sep 30 10:45:51 1999
Received: from mail.neroc.nl (mail.neroc.nl [212.52.0.12])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA41980
for <pgsql-hackers@postgresql.org>;
Thu, 30 Sep 1999 10:44:55 -0400 (EDT)
(envelope-from ruttenberg@mail.neroc.nl)
Received: from [212.52.7.230] (hermes.ehv.neroc.nl [212.52.7.230])
by mail.neroc.nl (8.9.3/8.9.3) with SMTP id QAA10002
for <pgsql-hackers@postgresql.org>; Thu, 30 Sep 1999 16:40:21 +0200
Message-Id: <199909301440.QAA10002@mail.neroc.nl>
Subject: ODBC-client->Linux-server: datatype boolean not recognized?
Date: Thu, 30 Sep 1999 16:46:16 +0200
x-sender: ruttenberg@mail.neroc.nl
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Jelle Ruttenberg <ruttenberg@neroc.nl>
To: <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"

Hello all,

I posted the following also to pgsql-interfaces/general, but got no
workable solution (yet).

The ODBC client-application I'm developping will be able to run on Mac
and WIN/NT, uses booleans itself and has to be able to be a frontend for
a range of SQL-databases.

Thanks,
Jelle

vvvv MESSAGE vvvv

Hello all,

I'm trying to connect from a ODBC-client to PostgreSQL on a Linux-server.
All is going well, except that the ODBC-client seems not to recognize the
PostgreSQL boolean-datatype.

Is this really caused by PostgreSQL? If yes: is there a workaround, like
altering the datatypename 'bool' in the proper places (pg_type?)? If no:
then it is another problem and can somebody give a hint?

Thanks,
Jelle.

I tested and encountered it in the following testsituations:

Situation 1:
Client: Mac via OpenLink ODBC-Client
Server: Linux RH 6.0 via OpenLink Requestbroker
Result: it looks like PostgreSQL-boolean is converted to SQL_C_CHAR, the
datatype itself is called 'bool'

Situation 2:
Client: NT with psqlODBC
Server: same Linux
Result: in MS-Query:
- viewing the table-definitions, it comes with the message that it
doesn't recognize datatype 'bool'
- selecting values it looks like PostgreSQL-boolean is converted to a
numeric

PostgreSQL: 6.5.1

--------------------------------------------------------------
NEROC Publishing Solutions

Jelle Ruttenberg

De Run 1131, 5503 LB Veldhoven Phone : +31-(0)40-2586641
P.O.Box 133, 5500 AC Veldhoven Fax : +31-(0)40-2541893
The Netherlands E-mail : ruttenberg@neroc.nl
--------------------------------------------------------------

From bouncefilter Thu Sep 30 11:03:51 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 LAA46488
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 11:03:20 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11Whdu-0003kLC; Thu, 30 Sep 99 16:57 MET DST
Message-Id: <m11Whdu-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: RI status report #3
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Thu, 30 Sep 1999 16:57:10 +0200 (MET DST)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

One more step forward,

I've created function shells and the appropriate pg_proc
entries for all the FOREIGN KEY constraint triggers.

The builtin language is now also accepted by CREATE TRIGGER.

The new trigger functions are in utils/adt/ri_triggers.c (new
file). They have no functionality up to now - just put a
NOTICE that they're called and that's it. Will work on some
general local functions soon.

Jan

From bouncefilter Thu Sep 30 11:46:51 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA52279
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 11:46:09 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id LAA26638;
Thu, 30 Sep 1999 11:46:07 -0400
Message-ID: <37F385B9.91BDA5F8@wgcr.org>
Date: Thu, 30 Sep 1999 11:46:01 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RI status report #2
References: <199909292106.RAA07284@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Lamr Owen wrote:

And that surprises you?? Even in the short two years I've used
PostgreSQL, I have grown accustomed to major changes every major

[snip]

Yes, it still shocks me. I was telling Thomas, every release I think,
man, this is so great, no reason anyone should be using a prior release.
And then the next release is the same thing.

The basic issue for me is that each of the new features requsted looks
so hard, I can't imagine how it could be done, but by release time, it
does get done. Amazing.

I find the enthusiasm of this particular development quite infectious.
While I'm only doing a very small part in packaging RPM's (thus far), I
feel quite good about it (it conjures back the same feeling that I had
at 15 years old when my Z80 disassembler first correctly disassembled
the opcodes of three-quarters of the instruction set -- no operands at
that time, but the opcode logic was WORKING... It felt uniquely
gratifying).

Just reading the web page and the release notes doesn't do this
development justice -- until I subscribed to this hackers list, I had no
idea that PostgreSQL development was so dynamic.

This beats following the linux kernel development, IMO.

Lamar Owen
WGCR Internet Radio

From bouncefilter Thu Sep 30 12:09:53 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id MAA55611
for <pgsql-hackers@postgresql.org>;
Thu, 30 Sep 1999 12:09:44 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 13050 invoked by uid 1001); 30 Sep 1999 16:09:46 -0000
Date: Thu, 30 Sep 1999 12:09:46 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Dmitry Samersoff <dms@wplus.net>
cc: PostgreSQL Hackers Mailing List <pgsql-hackers@postgresql.org>,
Edmund Mergl <E.Mergl@bawue.de>
Subject: RE: [HACKERS] Win32=?KOI8-R?Q?_p=FCort?= of libpq
In-Reply-To: <XFMail.990930165204.dms@wplus.net>
Message-ID: <Pine.BSF.4.05.9909301204580.13045-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 30 Sep 1999, Dmitry Samersoff wrote:

On 30-Sep-99 Vince Vielhaber wrote:

On Thu, 30 Sep 1999, Dmitry Samersoff wrote:

On 30-Sep-99 Edmund Mergl wrote:

Hi,

in the last few days I compiled libpq on Windows NT
using MS Visual Studio 6.0. I followed the instructions
given by Bob Kline <bkline@rksystems.com> in his mail from
Fri, 3 Sep 1999.
Unfortuanetely he sent his mail only to dbi-users, so I would
like to repeat one major problem on this list.

Here is an excerpt from his mail:

4. The DllMain function in src/interfaces/libpq/libpqdll.c of the
PostgreSQL 6.5 sources, in which WSAStartup is invoked, is never called,
which causes gethostbyname calls to fail. Solution (more properly,
"kludge" -- I know there's a cleaner fix somewhere, but this works for
now): immediately after the local declarations for the connectDB function
in src/interfaces/libpq/fe-connect.c:

#ifdef WIN32
static int WeHaveCalledWSAStartup;

if (!WeHaveCalledWSAStartup) {
WSADATA wsaData;
if (WSAStartup(MAKEWORD(1, 1), &wsaData)) {
sprintf(conn->errorMessage,
"WSAStartup failed: errno=%d\n", h_errno);
goto connect_errReturn;
}
WeHaveCalledWSAStartup = 1;
}
#endif

You need not to take care wether WSAStartup is alredy called or not.
Windows handle it automatically.

By calling it yourself you have more control over which minimum version
will be loaded.

Yes, but you can just call

WSADATA wsaData;
if (WSAStartup(MAKEWORD(1, 1), &wsaData)) {
sprintf(conn->errorMessage,
"WSAStartup failed: errno=%d\n", h_errno);
goto connect_errReturn;
}

without WeHaveCalledWSAStartup at all.

Accroding to the 1.1 spec, you must call WSACleanup() for EVERY WSAStartup
call made. So if you call WSAStartup() three times, you must call
WSACleanup() three times - the first two only decrement the internal
counter, the last one does the cleanup. This may have changed in versions
of Winsock after 1.1 and my spec is a bit old (20 Jan 1993).

From bouncefilter Thu Sep 30 14:22:59 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA76743
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 14:22:02 -0400 (EDT) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA04454;
Thu, 30 Sep 1999 19:13:12 +0200
Date: Thu, 30 Sep 1999 19:13:12 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: TO_CHAR()
In-Reply-To: <Pine.LNX.3.96.990930095535.17787B-100000@ara.zf.jcu.cz>
Message-ID: <Pine.LNX.3.96.990930190211.4165B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

this is my new (experimental) TO_CHAR() function (compatible with oracle),
it is available on: ftp://ftp2.zf.jcu.cz/users/zakkr/pg/TO_CHAR-0.1.tar.gz.

See example:

=======
abil=> select to_char('now', 'HH:MI:SS Day MON CC');
to_char
------------------------
20:12:02 Thursday Sep 19

abil=> select to_char('now', 'MM MON Month MONTH YYYY Y,YYY YYY YY Y');
to_char
----------------------------------------------
09 Sep September SEPTEMBER 1999 1,999 999 99 9

abil=> select to_char('now', 'DDD D WW SSSS');
to_char
--------------
273 4 39 72810

abil=> select to_char('now', 'hello year YYYY');
to_char
---------------
hello year 1999

========

Any comments ?
Zakkr

From bouncefilter Thu Sep 30 13:53:56 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA72090
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 13:53:37 -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 NAA03560;
Thu, 30 Sep 1999 13:53:16 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909301753.NAA03560@candle.pha.pa.us>
Subject: Re: [HACKERS] postmaster dead on startup from unportable SSL patch
In-Reply-To: <12430.938660668@sss.pgh.pa.us> from Tom Lane at "Sep 29,
1999 11:04:28 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 30 Sep 1999 13:53:16 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Someone had the bright idea that the postmaster's -i switch could
be redefined as
-i same as it ever was
-is accept only SSL connections

Unfortunately, implementing that requires a getopt() that understands
the GNU double-colon extension ("i::"). HPUX's getopt, which claims
to be fully conformant to POSIX.2 and about six other standards,
doesn't grok it. Net result: postmaster is quitting on startup with
a "usage" message for me. Doubtless it will also fail on most other
non-GNU-libc platforms.

Unless we want to get into the business of supplying a substitute
optarg() library routine, we're going to have to pick a more portable
switch syntax for SSL. (I might also point out that "-is" used to
have a quite different interpretation, ie "-i -s", which could trip
up someone somewhere.)

-is is a totally broken option flag.

I can see two reasonable choices: (a) pick a currently-unused
switch letter that you specify *in addition to* -i, if you want
only secure connections; (b) pick a currently-unused switch letter
that you specify *instead of* -i, if you want only secure connections.

I'd lean towards (a) except that both of the obvious choices, -s and -S,
are already taken. If we go with (b), -I is available and perhaps not
a totally off-the-wall choice, but I can't say I really like it.

I like option (a). Just pick any letter for the additional SSL flag
. It is SSL, you can use -L or -l. I would like to keep -i as
required, so when we tell people they have to use -i, they really have
to use -i for INET connection, not -i or -L.

Comments? Ideas? Is it time to give up on getopt and go to multiletter
switch names? (Of course that would break a lot of people's startup
scripts... but we may someday be forced into it... maybe it's better
to bite the bullet now.)

No, I don't think so. long opt names are more a headache than just
picking any new letter.

-- 
  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 Fri Oct 1 21:53:41 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA49990
for <pgsql-hackers@postgreSQL.org>; Fri, 1 Oct 1999 21:52:45 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by trends.net (8.8.8/8.8.8) with ESMTP id TAA25555
for <pgsql-hackers@postgresql.org>; Fri, 1 Oct 1999 19:41:00 -0400 (EDT)
Received: from uria.its.uu.se ([130.238.7.14]:2711 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rxINi168204>;
Sat, 2 Oct 1999 01:40:30 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11Wqsi-0002bs-00; Fri, 01 Oct 1999 02:49:04 +0200
Date: Fri, 1 Oct 1999 02:49:03 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster dead on startup from unportable SSL patch
In-Reply-To: <37F2FD2E.81B045A6@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.10.9910010238570.625-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Sep 30, Thomas Lockhart mentioned:

Comments? Ideas? Is it time to give up on getopt and go to multiletter
switch names? (Of course that would break a lot of people's startup
scripts... but we may someday be forced into it... maybe it's better
to bite the bullet now.)

Break it ;)

The single-character switches are definitely non-intuitive. Implement

It's a backend people! My man page shows 12 defined switches, so there are
at least 44 character switches left. A little imagination please.

I am implementing GNU style long options in psql but obviously that sort
of thing won't help anybody that doesn't have a GNU'ish system, in
particular the people affected by the -is thing in the first place.

Or do you *really* want to get into the business of writing your own
getopt replacement??? Then you are liable to end up with something even
less intuitive.

Meanwhile, how about something like -i for normal and -i SSL for what's
desired. (That is, change the "i" to "i:"). Then, if someone comes up with
something related (accept only ssh, ipv6, latest pgsql protocol, etc.
connections), you save a switch.

Peter

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

From bouncefilter Fri Oct 1 21:53:41 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA49981
for <pgsql-hackers@postgreSQL.org>; Fri, 1 Oct 1999 21:52:36 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by trends.net (8.8.8/8.8.8) with ESMTP id TAA25552
for <pgsql-hackers@postgresql.org>; Fri, 1 Oct 1999 19:40:59 -0400 (EDT)
Received: from uria.its.uu.se ([130.238.7.14]:2713 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rxINl131340>;
Sat, 2 Oct 1999 01:40:33 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2) id 11Wr6w-0002cG-00
for pgsql-hackers@postgresql.org; Fri, 01 Oct 1999 03:03:46 +0200
Date: Fri, 1 Oct 1999 03:03:46 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgreSQL.org
Subject: Tricky query, tricky response
Message-ID: <Pine.LNX.4.10.9910010253310.625-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

As you might recognize, this is supposed to be a psql \d imitation in one
shot:

SELECT usename as "Owner", relname as "Relation",
(CASE WHEN relkind='r' THEN
(CASE WHEN 0<(select count(*) from pg_views where viewname = relname)
THEN 'view' ELSE 'table' END)
WHEN relkind='i' THEN 'index'
WHEN relkind='S' THEN 'sequence'
ELSE 'other'
END) as "Type"
FROM pg_class, pg_user
WHERE usesysid = relowner AND
( relkind = 'r' OR
relkind = 'i' OR
relkind = 'S') AND
relname !~ '^pg_' AND
(relkind != 'i' OR relname !~ '^xinx') ORDER BY relname;
ERROR: flatten_tlistentry: Cannot handle node type 108

However, if you do 
-	(CASE WHEN 0<(select count(*) from pg_views where viewname = relname)
-	THEN 'view' ELSE 'table' END)      
+	'relation'
if works fine. No nested CASE's?

PostgreSQL 6.5.2 on i586-pc-linux-gnu, compiled by egcs

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

From bouncefilter Fri Oct 1 00:55:14 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA74549
for <pgsql-hackers@postgresql.org>; Fri, 1 Oct 1999 00:51:36 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from localhost (root@hectic-2.jpl.nasa.gov [128.149.68.204])
by trends.net (8.8.8/8.8.8) with ESMTP id WAA05217
for <pgsql-hackers@postgreSQL.org>;
Thu, 30 Sep 1999 22:57:41 -0400 (EDT)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id CAA13180;
Fri, 1 Oct 1999 02:57:06 GMT
Sender: lockhart@trends.net
Message-ID: <37F42302.8C1397ED@alumni.caltech.edu>
Date: Fri, 01 Oct 1999 02:57:06 +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: Zakkr <zakkr@zf.jcu.cz>
CC: pgsql-hackers@postgresql.org
Subject: Re: TO_CHAR()
References: <Pine.LNX.3.96.990930190211.4165B-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

this is my new (experimental) TO_CHAR() function (compatible with oracle),
it is available on: ftp://ftp2.zf.jcu.cz/users/zakkr/pg/TO_CHAR-0.1.tar.gz.
Any comments ?

Nice! So, there is a routine to go the other way in Oracle
(format()??) and if we have both then we're cookin'

- Thomas

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

From bouncefilter Fri Oct 1 07:48:18 1999
Received: from mail.kdt.de (mail.kdt.de [195.8.224.4])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA36925
for <pgsql-hackers@postgreSQL.org>; Fri, 1 Oct 1999 07:48:08 -0400 (EDT)
(envelope-from christof.petig@wtal.de)
Received: from gateway.petig.de (line0067lf.kdt.de [195.8.241.67])
by mail.kdt.de (8.8.8/8.8.8) with ESMTP id NAA22407;
Fri, 1 Oct 1999 13:48:05 +0200
Received: from wtal.de (christof@[192.168.230.9])
by gateway (8.8.8/8.8.8) with ESMTP id MAA27088;
Fri, 1 Oct 1999 12:53:02 +0200
Sender: christof@to.wtal.de
Message-ID: <37F44859.FD1B3D52@wtal.de>
Date: Fri, 01 Oct 1999 07:36:26 +0200
From: Christof Petig <christof.petig@wtal.de>
Organization: Adolf Petig GmbH. & Co. KG
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.7 i586)
X-Accept-Language: de
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Regression tests on intel for 6.5.2
References: <13733.938697904@sss.pgh.pa.us>
Content-Type: multipart/mixed; boundary="------------2ABD5ADEBAD9FB247A2F8148"

This is a multi-part message in MIME format.
--------------2ABD5ADEBAD9FB247A2F8148
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Yes, we should not be assuming that finite() is a macro, which is what
that #ifdef coding does. We need a HAVE_FINITE configuration test.
If you have time to prepare the diffs it'd be great.

Here they are
Christof

--------------2ABD5ADEBAD9FB247A2F8148
Content-Type: text/plain; charset=us-ascii;
name="diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="diff"

diff -ru /home/christof/pgsql-cvs/pgsql/src/backend/utils/adt/float.c pgsql/src/backend/utils/adt/float.c
--- /home/christof/pgsql-cvs/pgsql/src/backend/utils/adt/float.c	Mon Sep 27 10:07:29 1999
+++ pgsql/src/backend/utils/adt/float.c	Fri Oct  1 11:49:32 1999
@@ -1157,11 +1157,11 @@

tmp1 = *arg1;
tmp2 = *arg2;
-#ifndef finite
+#ifndef HAVE_FINITE
errno = 0;
#endif
*result = (float64data) pow(tmp1, tmp2);
-#ifndef finite
+#ifndef HAVE_FINITE
if (errno != 0) /* on some machines both EDOM & ERANGE can
* occur */
#else
@@ -1189,11 +1189,11 @@
result = (float64) palloc(sizeof(float64data));

 	tmp = *arg1;
-#ifndef finite
+#ifndef HAVE_FINITE
 	errno = 0;
 #endif
 	*result = (float64data) exp(tmp);
-#ifndef finite
+#ifndef HAVE_FINITE
 	if (errno == ERANGE)
 #else
 	/* infinity implies overflow, zero implies underflow */
diff -ru /home/christof/pgsql-cvs/pgsql/src/configure.in pgsql/src/configure.in
--- /home/christof/pgsql-cvs/pgsql/src/configure.in	Mon Sep 13 08:44:37 1999
+++ pgsql/src/configure.in	Fri Oct  1 11:39:25 1999
@@ -769,6 +769,12 @@
 	      AC_DEFINE(HAVE_RINT),
 	      AC_CHECK_LIB(m, rint, AC_DEFINE(HAVE_RINT), , $HPUXMATHLIB))

+AC_MSG_CHECKING(for finite() macro or function)
+AC_TRY_LINK([#include <math.h>],
+	[int dummy=finite(1.0);],
+	[AC_DEFINE(HAVE_FINITE) AC_MSG_RESULT(yes)],
+	AC_MSG_RESULT(no))
+
 dnl Check to see if we have a working 64-bit integer type.
 dnl This breaks down into two steps:
 dnl (1) figure out if the compiler has a 64-bit int type with working
diff -ru /home/christof/pgsql-cvs/pgsql/src/include/config.h.in pgsql/src/include/config.h.in
--- /home/christof/pgsql-cvs/pgsql/src/include/config.h.in	Mon Sep 13 08:44:38 1999
+++ pgsql/src/include/config.h.in	Fri Oct  1 11:46:23 1999
@@ -359,6 +359,9 @@
 /* Set to 1 if you have rint() */
 #undef HAVE_RINT

+/* Set to 1 if you have finite() */
+#undef HAVE_FINITE
+
 /* Set to 1 if you have memmove() */
 #undef HAVE_MEMMOVE

--------------2ABD5ADEBAD9FB247A2F8148--

From bouncefilter Fri Oct 1 07:48:18 1999
Received: from mail.kdt.de (mail.kdt.de [195.8.224.4])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA36922
for <pgsql-hackers@postgresql.org>; Fri, 1 Oct 1999 07:48:05 -0400 (EDT)
(envelope-from christof.petig@wtal.de)
Received: from gateway.petig.de (line0067lf.kdt.de [195.8.241.67])
by mail.kdt.de (8.8.8/8.8.8) with ESMTP id NAA22401
for <pgsql-hackers@postgresql.org>; Fri, 1 Oct 1999 13:48:05 +0200
Received: from wtal.de (christof@[192.168.230.9])
by gateway (8.8.8/8.8.8) with ESMTP id NAA27243
for <pgsql-hackers@postgresql.org>; Fri, 1 Oct 1999 13:41:02 +0200
Sender: christof@to.wtal.de
Message-ID: <37F45393.2C94D722@wtal.de>
Date: Fri, 01 Oct 1999 08:24:22 +0200
From: Christof Petig <christof.petig@wtal.de>
Organization: Adolf Petig GmbH. & Co. KG
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.7 i586)
X-Accept-Language: de
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: are subtransactions not nestable?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

is it correct that a nesting of subtransactions is not possible with
postgres at the moment?
(I didn't find a TODO entry for this (even at 'exotic' features))

christof=> begin;
BEGIN
christof=> begin;
NOTICE: BeginTransactionBlock and not in default state
BEGIN
christof=> commit;
END
christof=> commit;
NOTICE: EndTransactionBlock and not inprogress/abort state
END

Regards
Christof

From bouncefilter Fri Oct 1 04:52:16 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA14550
for <pgsql-hackers@postgreSQL.org>; Fri, 1 Oct 1999 04:52:07 -0400 (EDT)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA19693;
Fri, 1 Oct 1999 09:43:14 +0200
Date: Fri, 1 Oct 1999 09:43:14 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: TO_CHAR()
In-Reply-To: <37F42302.8C1397ED@alumni.caltech.edu>
Message-ID: <Pine.LNX.3.96.991001092309.17420A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 1 Oct 1999, Thomas Lockhart wrote:

this is my new (experimental) TO_CHAR() function (compatible with oracle),
it is available on: ftp://ftp2.zf.jcu.cz/users/zakkr/pg/TO_CHAR-0.1.tar.gz.
Any comments ?

Nice! So, there is a routine to go the other way in Oracle
(format()??) and if we have both then we're cookin'

Thank! But.. sorry, I don't understand you. What other way in the Oracle
(format()??) ?

What make with this code next? Is it interesting for developers (hmm, to this
discussion join you (Thomas) and me only, but others probably needn't
TO_CHAR, TO_NUMBER, TO_DATE) ..?

Zakkr

From bouncefilter Fri Oct 1 04:23:20 1999
Received: from mail.psn.ne.jp (mail.psn.ne.jp [210.167.249.5])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA10661;
Fri, 1 Oct 1999 04:22:37 -0400 (EDT)
(envelope-from sakaida@psn.co.jp)
Received: from ppp119 (ppp119.psn.ne.jp [210.167.249.119])
by mail.psn.ne.jp (8.9.1/3.7W) with SMTP id RAA25874;
Fri, 1 Oct 1999 17:22:35 +0900 (JST)
Date: Fri, 01 Oct 1999 17:24:57 +0900
From: SAKAIDA <sakaida@psn.co.jp>
To: hackers@postgreSQL.org
Cc: pgsql-interfaces@postgreSQL.org
Subject: pgbash-1.1.1 release
In-Reply-To: <199909300115.KAA01268@ext16.sra.co.jp>
References: <199909300115.KAA01268@ext16.sra.co.jp>
Message-Id: <37F46FD92D0.D25FSAKAIDA@smtp.psn.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.25.07

Hi,

With many cooperators, I have made a *bash built-in command* for
PostgreSQL called "pgbash".

The pgbash is the system which offers the 'direct SQL'/'embedded
SQL' interface for PostgreSQL by being included in the bash-2.x
shell.

Features of pgbash
-------------------

1.The pgbash has a function which is equivalent to psql except for
the interactive input processing function.

2.It is possible that pgbash carries out the interactive input
processing using the hysteresis editing function ( history, !,
fc command ) of bash.

3.An output of retrieval result and database information of pgbash
uses PSprint() which improved PQprint(). By PSprint(), it is
possible to output by plain table type, plain table + outer frame
type and HTML table type. And, it is possible to display NULL
value string(like '-NULL-') and bit zero string(like '-0-').

4.It is possible that pgbash manipulates multiple databases using
CONNECT, DISCONNECT and SET CONNECTION (or -d option ).

5.The pgbash has a function which substitutes the retrieval result
for the shell variable using FETCH INTO statement.

6.It is possible to set CGI mode. In CGI mode, the pgbash switches
the output to HTML, and read the datat by GET/POST method, and
read the data of HTTP_COOKIE.

7.The pgbash sets "error code", "error message", "number of tuples",
etc to the shell variable. Therefore, it is possible to know the
condition after the SQL execution.

Details is as follows.
http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html

# I am very glad, if many people will use the pgbash.

--
Regards.

SAKAIDA Masaaki -- Osaka, Japan$B!!(B
# Sorry, I am not good at English.

From bouncefilter Fri Oct 1 07:45:18 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 HAA35921;
Fri, 1 Oct 1999 07:39:20 -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 PAA09632;
Fri, 1 Oct 1999 15:38:12 +0400 (MSD)
Date: Fri, 1 Oct 1999 15:38:11 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: SAKAIDA <sakaida@psn.co.jp>
cc: hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
Subject: Re: [HACKERS] pgbash-1.1.1 release
In-Reply-To: <37F46FD92D0.D25FSAKAIDA@smtp.psn.ne.jp>
Message-ID: <Pine.GSO.3.96.SK.991001153404.16613a-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=koi8-r

That's really cool !
I just install and played a little bit.
I found a minor problem :
I have to connect to any database to issue
exec_sql -l database
I have no my personal database
Here is a log:

bash-2.03$ exec_sql -l database
(-402)FATAL 1: Database megera does not exist in pg_database
bash-2.03$ exec_sql "connect to discovery"
# PostgreSQL 6.5.2 on i586-pc-linux-gnulibc1, compiled by gcc 2.95.1
# CONNECT TO discovery:5432 AS discovery USER megera

bash-2.03$ exec_sql -l database
# Databases list

I don't understand this requirements just to list all databases

Regards,

Oleg

On Fri, 1 Oct 1999, SAKAIDA wrote:

Date: Fri, 01 Oct 1999 17:24:57 +0900
From: SAKAIDA <sakaida@psn.co.jp>
To: hackers@postgreSQL.org
Cc: pgsql-interfaces@postgreSQL.org
Subject: [HACKERS] pgbash-1.1.1 release

Hi,

With many cooperators, I have made a *bash built-in command* for
PostgreSQL called "pgbash".

The pgbash is the system which offers the 'direct SQL'/'embedded
SQL' interface for PostgreSQL by being included in the bash-2.x
shell.

Features of pgbash
-------------------

1.The pgbash has a function which is equivalent to psql except for
the interactive input processing function.

2.It is possible that pgbash carries out the interactive input
processing using the hysteresis editing function ( history, !,
fc command ) of bash.

3.An output of retrieval result and database information of pgbash
uses PSprint() which improved PQprint(). By PSprint(), it is
possible to output by plain table type, plain table + outer frame
type and HTML table type. And, it is possible to display NULL
value string(like '-NULL-') and bit zero string(like '-0-').

4.It is possible that pgbash manipulates multiple databases using
CONNECT, DISCONNECT and SET CONNECTION (or -d option ).

5.The pgbash has a function which substitutes the retrieval result
for the shell variable using FETCH INTO statement.

6.It is possible to set CGI mode. In CGI mode, the pgbash switches
the output to HTML, and read the datat by GET/POST method, and
read the data of HTTP_COOKIE.

7.The pgbash sets "error code", "error message", "number of tuples",
etc to the shell variable. Therefore, it is possible to know the
condition after the SQL execution.

Details is as follows.
http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html

# I am very glad, if many people will use the pgbash.

--
Regards.

SAKAIDA Masaaki -- Osaka, Japan$B!!(B
# Sorry, I am not good at English.

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

From bouncefilter Fri Oct 1 08:13:21 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 IAA40933
for <hackers@postgreSQL.org>; Fri, 1 Oct 1999 08:12:37 -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 QAA10315
for <hackers@postgreSQL.org>; Fri, 1 Oct 1999 16:12:29 +0400 (MSD)
Date: Fri, 1 Oct 1999 16:12:29 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: hackers@postgreSQL.org
Subject: problem compiling current sources with gcc 2.95.1
Message-ID: <Pine.GSO.3.96.SK.991001160854.16613b-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I trried to compile today's current sources and got a problem:

make[2]: Entering directory /u/postgres/cvs/pgsql/src/interfaces/libpq++'
c++ -I../../backend -I../../include -I../../interfaces/libpq -I../../include -I../../backend -O2 -mpentium -Wall -Wmissing-prototypes -fpic -c pgdatabase.cc -o pgdatabase.o
pgdatabase.cc: In method `int PgDatabase::CmdTuples()':
pgdatabase.cc:66: return to `nt' from `const char *' lacks a cast
make[2]: *** [pgdatabase.o] Error 1
make[2]: Leaving directory /u/postgres/cvs/pgsql/src/interfaces/libpq++'

I'm using gcc 2.95.1 and have no problem to compile 6.5.2
on my Linux box 2.2.12

regards,

Oleg

From bouncefilter Fri Oct 1 10:11:20 1999
Received: from mail.psn.ne.jp (mail.psn.ne.jp [210.167.249.5])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA55578
for <hackers@postgreSQL.org>; Fri, 1 Oct 1999 10:11:16 -0400 (EDT)
(envelope-from sakaida@psn.co.jp)
Received: from g6o9i2 (ppp058.psn.ne.jp [210.167.249.58])
by mail.psn.ne.jp (8.9.1/3.7W) with SMTP id XAA02171
for <hackers@postgreSQL.org>; Fri, 1 Oct 1999 23:11:13 +0900 (JST)
Date: Fri, 01 Oct 1999 23:08:10 +0900
From: SAKAIDA Masaaki <sakaida@psn.co.jp>
To: hackers@postgreSQL.org
Subject: Re: [HACKERS] pgbash-1.1.1 release
In-Reply-To: <Pine.GSO.3.96.SK.991001153404.16613a-100000@ra>
References: <37F46FD92D0.D25FSAKAIDA@smtp.psn.ne.jp>
<Pine.GSO.3.96.SK.991001153404.16613a-100000@ra>
Message-Id: <37F4C04A1B8.A39FSAKAIDA@smtp.psn.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.25.07

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

That's really cool !

Thank you.

I just install and played a little bit.
I found a minor problem :
I have to connect to any database to issue
exec_sql -l database
I have no my personal database
Here is a log:

bash-2.03$ exec_sql -l database
(-402)FATAL 1: Database megera does not exist in pg_database

If CONNECT have not been executed yet, "CONNECT TO DEFAULT"
will be automatically issued when -l option is executed.

If user name is "megera", then "CONNECT TO DEFAULT" is equal
to "CONNECT TO megera USER megera".

bash-2.03$ exec_sql "connect to discovery"
# PostgreSQL 6.5.2 on i586-pc-linux-gnulibc1, compiled by gcc 2.95.1
# CONNECT TO discovery:5432 AS discovery USER megera

bash-2.03$ exec_sql -l database
# Databases list

datname |datdba|encoding|datpath
---------+------+--------+---------
template1| 505| 16|template1
apod | 11| 16|apod

I don't understand this requirements just to list all databases

This approach is equal to psql.

# However, I consider that "CONNECT TO template1" may be better
than "CONNECT TO <User_naame>" in the case of "-l database".

--
Regard.

SAKAIDA Masaaki -- Osaka, Japan
# Sorry, I am not good at English.

From bouncefilter Fri Oct 1 10:57:21 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 KAA60897
for <pgsql-hackers@postgreSQL.org>; Fri, 1 Oct 1999 10:56:50 -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 OAA17411;
Fri, 1 Oct 1999 14:54:45 GMT
Sender: lockhart@hub.org
Message-ID: <37F4CB35.429C8003@alumni.caltech.edu>
Date: Fri, 01 Oct 1999 14:54:45 +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: Zakkr <zakkr@zf.jcu.cz>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: TO_CHAR()
References: <Pine.LNX.3.96.991001092309.17420A-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

this is my new (experimental) TO_CHAR() function (compatible with oracle),
it is available on: ftp://ftp2.zf.jcu.cz/users/zakkr/pg/TO_CHAR-0.1.tar.gz.
Any comments ?

Nice! So, there is a routine to go the other way in Oracle
(format()??) and if we have both then we're cookin'

Thank! But.. sorry, I don't understand you. What other way in the Oracle
(format()??) ?

Ah, something to go from a random character string to an internal
date/time type. We have a fairly generic way to do this already, but
since to_char() can insert random garbage at the user's behest then it
would be nice to have a related routine which can be told how to
decode a string containing random garbage. I'm pretty sure that Oracle
has such a beast, but I don't have the docs. I would think that it
could be done as a thin layer on top of datetime_in().

What make with this code next? Is it interesting for developers (hmm, to this
discussion join you (Thomas) and me only, but others probably needn't
TO_CHAR, TO_NUMBER, TO_DATE) ..?

People have requested to_char(), or at least inquired about it, though
of course there are always ways to work around not having it. After
all, it *is* non-standard ;) But we already have some Oracle
compatibility functions, and a few more won't hurt.

There are two possibilities:

1) we incorporate it into the main tree
2) we distribute it as a contrib package

I'd prefer the former, though right now the code has problems since it
converts input to timestamp to take advantage of localtime(). Can you
look at, and perhaps use directly, datetime2tm()? That should get you
the structure you need to work with, and it is not limited to just
Unix system time ranges. Just be aware that the year field contains a
real year, not year modulo 1900 as in a real Unix tm structure.

Let me know if this is possible.

- Thomas

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

From bouncefilter Fri Oct 1 11:05:21 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 LAA61938
for <pgsql-hackers@postgreSQL.org>; Fri, 1 Oct 1999 11:04:25 -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 PAA17455;
Fri, 1 Oct 1999 15:03:44 GMT
Sender: lockhart@hub.org
Message-ID: <37F4CD50.42C2D5F3@alumni.caltech.edu>
Date: Fri, 01 Oct 1999 15:03:44 +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: Christof Petig <christof.petig@wtal.de>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] are subtransactions not nestable?
References: <37F45393.2C94D722@wtal.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

is it correct that a nesting of subtransactions is not possible with
postgres at the moment?
(I didn't find a TODO entry for this (even at 'exotic' features))

There has been some discussion of this. The fact that it is disallowed
by SQL92 is *not* the reason we don't have the feature, but it may be
responsible for it not yet being done...

- Thomas

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

From bouncefilter Fri Oct 1 11:47:22 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA68455
for <pgsql-hackers@postgreSQL.org>; Fri, 1 Oct 1999 11:46:23 -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 LAA01305;
Fri, 1 Oct 1999 11:45:40 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910011545.LAA01305@candle.pha.pa.us>
Subject: Re: [HACKERS] are subtransactions not nestable?
In-Reply-To: <37F45393.2C94D722@wtal.de> from Christof Petig at "Oct 1, 1999
08:24:22 am"
To: Christof Petig <christof.petig@wtal.de>
Date: Fri, 1 Oct 1999 11:45:40 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello,

is it correct that a nesting of subtransactions is not possible with
postgres at the moment?
(I didn't find a TODO entry for this (even at 'exotic' features))

We don't support it, but will add to TODO now.

-- 
  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 Fri Oct 1 12:07:25 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 MAA71787
for <pgsql-hackers@postgreSQL.org>; Fri, 1 Oct 1999 12:06:48 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11X56P-0003kLC; Fri, 1 Oct 99 18:00 MET DST
Message-Id: <m11X56P-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: TO_CHAR()
To: lockhart@alumni.caltech.edu (Thomas Lockhart)
Date: Fri, 1 Oct 1999 18:00:09 +0200 (MET DST)
Cc: zakkr@zf.jcu.cz, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37F4CB35.429C8003@alumni.caltech.edu> from "Thomas Lockhart" at
Oct 1, 99 02:54:45 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

discussion join you (Thomas) and me only, but others probably needn't
TO_CHAR, TO_NUMBER, TO_DATE) ..?

People have requested to_char(), or at least inquired about it, though
of course there are always ways to work around not having it. After
all, it *is* non-standard ;) But we already have some Oracle
compatibility functions, and a few more won't hurt.

There are two possibilities:

1) we incorporate it into the main tree
2) we distribute it as a contrib package

If incorporating into main tree, don't forget that TO_CHAR()
must also be capable to handle NUMERIC/DECIMAL/INTEGER with a
rich set of fomatting styles. Actually I'm in doubt if you
both are a little too much focusing on DATE/TIME.

This means that there could be different input arguments
(type and number!) to TO_CHAR().

Jan

From bouncefilter Fri Oct 1 12:15:25 1999
Received: from fep04-svc.tin.it (mta04-acc.tin.it [212.216.176.35])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA73091
for <pgsql-hackers@postgresql.org>; Fri, 1 Oct 1999 12:15:02 -0400 (EDT)
(envelope-from rcorna@tin.it)
Received: from tin.it ([212.216.151.59]) by fep04-svc.tin.it
(InterMail v4.01.01.02 201-229-111-106) with ESMTP
id <19991001161424.FIKG11717.fep04-svc@tin.it>
for <pgsql-hackers@postgresql.org>; Fri, 1 Oct 1999 18:14:24 +0200
Sender: root
Message-ID: <37F4DD47.C5FA064F@tin.it>
Date: Fri, 01 Oct 1999 18:11:51 +0200
From: Roberto Cornacchia <rcorna@tin.it>
Organization: tin.it
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: attribute distinct values estimate
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

We need to estimate the number of distinct values of an attribute from
inside optimizer, for an extension we are working on.
Should we use stacommonfrac from pg_statistic, or attdisbursion, or what
else?

From bouncefilter Fri Oct 1 14:17:27 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 OAA93317;
Fri, 1 Oct 1999 14:17:09 -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 WAA18744;
Fri, 1 Oct 1999 22:16:44 +0400 (MSD)
Date: Fri, 1 Oct 1999 22:16:44 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
Reply-To: Oleg Bartunov <oleg@sai.msu.su>
To: pgsql-hackers@postgreSQL.org
cc: pgsql-interfaces@postgreSQL.org, M.Hessling@qut.edu.au
Subject: Rexx interface po postgres ?
Message-ID: <Pine.GSO.3.96.SK.991001203045.16613l-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

Is anybody tried Rexx to work with postgres ?
I found RexxSQL ( http://www.lightlink.com/hessling/)
which claimed to work via ODBC but I didn't work
work with ODBC and would like to know if it's worth to play
and what I need to install/

Regards,

Oleg

From bouncefilter Fri Oct 1 15:03:27 1999
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net
[194.217.242.41]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA99689
for <hackers@postgresql.org>; Fri, 1 Oct 1999 15:03:05 -0400 (EDT)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 11X7xN-000Jhm-0C; Fri, 1 Oct 1999 19:03:01 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id UAA28875; Fri, 1 Oct 1999 20:02:54 +0100 (BST)
Message-Id: <199910011902.UAA28875@mtcc.demon.co.uk>
Date: Fri, 1 Oct 1999 20:02:54 +0100 (BST)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
To: wieck@debis.com
Cc: hackers@postgresql.org, maillist@candle.pha.pa.us
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 5WhedWjW6qsXzA3gLahyJw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

wieck@debis.com

[pgsql@hot] ~/devel/src/test/regress > ./checkresults
====== int2 ======
10c10
< ERROR: pg_atoi: error reading "100000": Numerical result out of range
---

ERROR: pg_atoi: error reading "100000": Math result not representable

====== int4 ======
10c10
< ERROR: pg_atoi: error reading "1000000000000": Numerical result out of range
---

ERROR: pg_atoi: error reading "1000000000000": Math result not representable

[pgsql@hot] ~/devel/src/test/regress >

Such a regression result while we're in the middle of feature
development.

I'm really impressed - if we only can keep it on this level!

I'm sure we could get rid of even those errors if we were to
incorporate some test like the following and then mangle the
expected results accordingly.

Trouble is I'm not sure how portable the code is:-

SPARCLinux compiles and gives "Math result not representable"
Solaris7 compiles and gives "Result too large"

Comments?

#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
int main(void)
{
char *s = "10000000000000000000000000000000000000000000000000";
long l = 0;
char *badp = (char *) NULL;

errno = 0;

l = strtol(s, &badp, 10);
if (errno) {
printf("%s\n",strerror(errno));
exit(0);
} else {
printf("Error - No Error.");
exit(1);
}
}

From bouncefilter Fri Oct 1 16:12:28 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA09060
for <hackers@postgreSQL.org>; Fri, 1 Oct 1999 16:11:41 -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 QAA04954;
Fri, 1 Oct 1999 16:11:28 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910012011.QAA04954@candle.pha.pa.us>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-Reply-To: <199910011902.UAA28875@mtcc.demon.co.uk> from Keith Parks at "Oct
1, 1999 08:02:54 pm"
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Date: Fri, 1 Oct 1999 16:11:28 -0400 (EDT)
CC: wieck@debis.com, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

wieck@debis.com

[pgsql@hot] ~/devel/src/test/regress > ./checkresults
====== int2 ======
10c10
< ERROR: pg_atoi: error reading "100000": Numerical result out of range
---

ERROR: pg_atoi: error reading "100000": Math result not representable

====== int4 ======
10c10
< ERROR: pg_atoi: error reading "1000000000000": Numerical result out of range
---

ERROR: pg_atoi: error reading "1000000000000": Math result not representable

[pgsql@hot] ~/devel/src/test/regress >

I am inclined to strip off error messages after the second : and the do
the compare so:

ERROR: pg_atoi: error reading "1000000000000": Math result not representa..

becomes:

ERROR: pg_atoi: error reading "1000000000000":

They we just have to make sure all calls to perror have a colon before
them.

-- 
  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 Fri Oct 1 17:33:29 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 RAA25164
for <hackers@postgreSQL.org>; Fri, 1 Oct 1999 17:32:54 -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 RAA20539;
Fri, 1 Oct 1999 17:32:13 -0400 (EDT)
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
cc: hackers@postgreSQL.org, maillist@candle.pha.pa.us
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-reply-to: Your message of Fri, 1 Oct 1999 20:02:54 +0100 (BST)
<199910011902.UAA28875@mtcc.demon.co.uk>
Date: Fri, 01 Oct 1999 17:32:12 -0400
Message-ID: <20536.938813532@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Keith Parks <emkxp01@mtcc.demon.co.uk> writes:

I'm sure we could get rid of even those errors if we were to
incorporate some test like the following and then mangle the
expected results accordingly.

I don't see much value in getting rid of the discrepancies in strerror()
messages unless you have some proposal for getting rid of platform-
specific float roundoff differences. On my machine, the diffs in the
float8 and geometry regress tests are *much* larger and much harder to
validate by eyeball than the piddling little diffs in int2 and int4.
(I suppose I should submit platform-specific expected files for HPUX,
but have never gotten round to it...)

However, if people like this approach, why not just print out
"strerror(ERANGE)" instead of fooling with strtol?

regards, tom lane

From bouncefilter Fri Oct 1 17:40:30 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 RAA26179
for <hackers@postgreSQL.org>; Fri, 1 Oct 1999 17:40:16 -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 RAA20559;
Fri, 1 Oct 1999 17:39:00 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Keith Parks <emkxp01@mtcc.demon.co.uk>, wieck@debis.com,
hackers@postgreSQL.org
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-reply-to: Your message of Fri, 1 Oct 1999 16:11:28 -0400 (EDT)
<199910012011.QAA04954@candle.pha.pa.us>
Date: Fri, 01 Oct 1999 17:38:59 -0400
Message-ID: <20557.938813939@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

They we just have to make sure all calls to perror have a colon before
them.

IIRC, perror is defined to supply the colon for you. But this approach
won't really work unless you want to guarantee that colons never appear
for any other reason in the regress outputs... horology, for one, is
going to have a problem with that...

It does seem that the majority of the platform-specific expected files
we have are for this one issue in int2/int4, so maybe Keith's idea of
substituting the correct error message as a localization string is not a
bad one. We already have all the mechanism for that.

regards, tom lane

From bouncefilter Fri Oct 1 18:28:36 1999
Received: from chi-mx.truenorth.com (interlock.truenorth.com [199.221.98.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA32258;
Fri, 1 Oct 1999 18:28:18 -0400 (EDT)
(envelope-from djackson@cpsgroup.com)
Received: from cpsmail.cpsgroup.com (cpsmail.cpsgroup.com [144.210.12.10])
by chi-mx.truenorth.com (8.9.3/8.9.3) with ESMTP id RAA21013;
Fri, 1 Oct 1999 17:27:43 -0500 (CDT)
Received: by cpsmail with Internet Mail Service (5.5.2448.0)
id <QPCGK7M5>; Fri, 1 Oct 1999 17:27:41 -0500
Message-ID: <D05EF808F2DFD211AE4A00105AA1B5D25FB12D@cpsmail>
From: "Jackson, DeJuan" <djackson@cpsgroup.com>
To: PGSQL Admin <pgsql-admin@postgreSQL.org>, PGSQL Announce
<pgsql-announce@postgreSQL.org>, PGSQL General
<pgsql-general@postgreSQL.org>, PGSQL Hackers <pgsql-hackers@hub.org>,
PGSQL Interfaces <pgsql-interfaces@postgreSQL.org>, PGSQL Patches
<pgsql-patches@postgreSQL.org>, PGSQL Ports <pgsql-ports@postgreSQL.org>,
PGSQL SQL <pgsql-sql@postgreSQL.org>
Subject: testing unsubscribe
Date: Fri, 1 Oct 1999 17:27:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

I have a new job, Marc, sorry for the inconvenience, but I was on almost all
of the lists so I thought I'd make sure I unsubscribed from them all rather
than have the bounced messages going back to senders or my box here filling
up.

JUST IGNORE THIS, thanks
DEJ

From bouncefilter Sat Oct 2 14:06:51 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA76109
for <hackers@postgresql.org>; Sat, 2 Oct 1999 14:06:48 -0400 (EDT)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11XTYU-000Dbc-0K; Sat, 2 Oct 1999 18:06:47 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id XAA02004; Fri, 1 Oct 1999 23:55:00 +0100 (BST)
Message-Id: <199910012255.XAA02004@mtcc.demon.co.uk>
Date: Fri, 1 Oct 1999 23:55:00 +0100 (BST)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
To: emkxp01@mtcc.demon.co.uk, tgl@sss.pgh.pa.us
Cc: hackers@postgresql.org, maillist@candle.pha.pa.us
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: kRUSqbK/VerAKsfREFZX8g==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

From: Tom Lane <tgl@sss.pgh.pa.us>

Keith Parks <emkxp01@mtcc.demon.co.uk> writes:

I'm sure we could get rid of even those errors if we were to
incorporate some test like the following and then mangle the
expected results accordingly.

I don't see much value in getting rid of the discrepancies in strerror()
messages unless you have some proposal for getting rid of platform-
specific float roundoff differences. On my machine, the diffs in the
float8 and geometry regress tests are *much* larger and much harder to
validate by eyeball than the piddling little diffs in int2 and int4.
(I suppose I should submit platform-specific expected files for HPUX,
but have never gotten round to it...)

However, if people like this approach, why not just print out
"strerror(ERANGE)" instead of fooling with strtol?

Trust me to make things over complex!!

Keith.

From bouncefilter Fri Oct 1 21:59:06 1999
Received: from roberts.dialup.access.net (IDENT:root@roberts.dialup.access.net
[166.84.193.218]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA50773
for <pgsql-hackers@postgreSQL.org>; Fri, 1 Oct 1999 21:58:27 -0400 (EDT)
(envelope-from roberts@panix.com)
Received: (from roland@localhost)
by roberts.dialup.access.net (8.9.3/8.9.3) id VAA02614;
Fri, 1 Oct 1999 21:58:25 -0400
Sender: roland@tycho.rlent.pnet
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: TO_CHAR()
References: <Pine.LNX.3.96.991001092309.17420A-100000@ara.zf.jcu.cz>
<37F4CB35.429C8003@alumni.caltech.edu>
Reply-To: roberts@panix.com
From: Roland Roberts <roberts@panix.com>
Date: 01 Oct 1999 21:58:25 -0400
In-Reply-To: Thomas Lockhart's message of "Fri, 01 Oct 1999 14:54:45 +0000"
Message-ID: <m2vh8qcym6.fsf@tycho.rlent.pnet>
Lines: 28
X-Mailer: Gnus v5.7/Emacs 20.4

-----BEGIN PGP SIGNED MESSAGE-----

"Thomas" == Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Thomas> Ah, something to go from a random character string to an
Thomas> internal date/time type. [...] I'm pretty sure that Oracle
Thomas> has such a beast, but I don't have the docs.

Just FYI, it's to_date().

roland
- --
PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD Custom Software Solutions
roberts@panix.com 76-15 113th Street, Apt 3B
rbroberts@acm.org Forest Hills, NY 11375

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface

iQCVAwUBN/VmwOoW38lmvDvNAQElOQP/dFLgEyjpuKrtF9Ahu682joAegub4TbyW
RJUT8oVoMgchw0iIhZ4d5y6X7PNYc0ynJfdd5DmIawJuCdw79fvmpQrl+XVkft33
78mTJFkSyilqYfl/uT2zq5i+P/k6ARZYYJ+OpvUIJG0ttuDit5Xf/LRIM3N+UJ6l
mATOFpUCn9E=
=kmuG
-----END PGP SIGNATURE-----

From bouncefilter Fri Oct 1 23:38:08 1999
Received: from mail.psn.ne.jp (mail.psn.ne.jp [210.167.249.5])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA64263
for <pgsql-hackers@postgreSQL.org>; Fri, 1 Oct 1999 23:37:38 -0400 (EDT)
(envelope-from sakaida@psn.co.jp)
Received: from ppp119 (ppp119.psn.ne.jp [210.167.249.119])
by mail.psn.ne.jp (8.9.1/3.7W) with SMTP id MAA14562;
Sat, 2 Oct 1999 12:37:24 +0900 (JST)
Date: Sat, 02 Oct 1999 12:39:47 +0900
From: SAKAIDA <sakaida@psn.co.jp>
To: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pgbash-1.1.1 release
In-Reply-To: <Pine.GSO.3.96.SK.991002021011.16613m-100000@ra>
References: <37F4C04A1B8.A39FSAKAIDA@smtp.psn.ne.jp>
<Pine.GSO.3.96.SK.991002021011.16613m-100000@ra>
Message-Id: <37F57E83118.743FSAKAIDA@smtp.psn.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.25.07

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

Sakaida,

sorry for bothering you but I didn't find
TODO file and wondering what new features (if any)
you plan to implement to pgbash.

Please give me your opinion. My plan is not yet the concrete,
but a few of my new plan are:

1. Improvement of function of an HTML output.

exec_sql -H -O "<TABLE option>"
-O "*:<TH option1>" -O "name:<TH option2>"
-O "*:<TD option3>" -O "addr:<TD option4>"
-F "name:%-7.7s"
-F "addr:<fonr color='ff0000'>%s"
"select * from test where ..."

2. Snapshot cursor operation.
exec_sql -c cur "select * from test where ..."
exec_sql "open cur"
exec_sql "fetch in cur into :r1, :r2"
echo "r1=$r1 r2=$r2"
exec_sql "close cur"
# Declare cursor operation is already implemented.

I'm a little boried to enclose SQL statements
into double quotes. Is't really need ?

I think that it is necessary, because in the inside of the
double quotes, it can be used $variable and it is possible to
describe the SQL statement in the multiple line.

ex) exec_sql "select * from test
where name='$DATA' and
addr='$ADATA'"

I'm doubt it's possible, because
SQL statement must begins from valid SQL word.

If it's impossible to avoid probably pgbash
might have a possibility to redefine quote character,
so user could use
exec_sql [select * from test]
Notice, no need to press shift key !
I think with a little more effort this could be
achieved without explicit redefining of
quote character. But this is not a big problem,
I could use alias to define [] as a quote characters
just as an example:
alias sql='exec_sql -Q "[]"'
and then use sql instead of exec_sql.

I use alias too, but I do not know the method for aliasing
double quotes.

ex)
alias E='exec_sql'

(Shell program)
-----------------------------------------------------
#!/usr/local/bin/bash
function E { exec_sql "$@" }
-----------------------------------------------------
(KUBO Takehiro taught me this method.)

Anyway, I'm just speculating about enhancement
after playing for several hours with pgbash.
I like it !

I hope a new idea.

--
Regards.

SAKAIDA Masaaki -- Osaka, Japan$B!!(B
# Sorry, I am not good at English.

From bouncefilter Fri Oct 1 23:59:07 1999
Received: from mail.psn.ne.jp (mail.psn.ne.jp [210.167.249.5])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA66254
for <hackers@postgreSQL.org>; Fri, 1 Oct 1999 23:58:28 -0400 (EDT)
(envelope-from sakaida@psn.co.jp)
Received: from ppp119 (ppp119.psn.ne.jp [210.167.249.119])
by mail.psn.ne.jp (8.9.1/3.7W) with SMTP id MAA14803
for <hackers@postgreSQL.org>; Sat, 2 Oct 1999 12:58:26 +0900 (JST)
Date: Sat, 02 Oct 1999 13:00:49 +0900
From: SAKAIDA <sakaida@psn.co.jp>
To: hackers@postgreSQL.org
Subject: Re: [HACKERS] pgbash-1.1.1 release
In-Reply-To: <Pine.GSO.3.96.SK.991002021011.16613m-100000@ra>
References: <37F4C04A1B8.A39FSAKAIDA@smtp.psn.ne.jp>
<Pine.GSO.3.96.SK.991002021011.16613m-100000@ra>
Message-Id: <37F5837182.7440SAKAIDA@smtp.psn.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.25.07

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

Sakaida,

sorry for bothering you but I didn't find
TODO file and wondering what new features (if any)
you plan to implement to pgbash.

Please give me your opinion. My plan is not yet the concrete,
but a few of my new plan are:

1. Improvement of function of an HTML output.

I'm a little boried to enclose SQL statements
into double quotes. Is't really need ?

I think that it is necessary, because in the inside of the
double quotes, it can be used $variable and it is possible to
describe the SQL statement in the multiple line.

ex) exec_sql "select * from test
where name='$DATA' and
addr='$ADATA'"

I'm doubt it's possible, because
SQL statement must begins from valid SQL word.

If it's impossible to avoid probably pgbash
might have a possibility to redefine quote character,
so user could use
exec_sql [select * from test]
Notice, no need to press shift key !
I think with a little more effort this could be
achieved without explicit redefining of
quote character. But this is not a big problem,
I could use alias to define [] as a quote characters
just as an example:
alias sql='exec_sql -Q "[]"'
and then use sql instead of exec_sql.

I use alias too, but I do not know the method for aliasing
double quotes.

ex)
alias E='exec_sql'

Anyway, I'm just speculating about enhancement
after playing for several hours with pgbash.
I like it !

I hope a new idea.

--
Regards.

SAKAIDA Masaaki -- Osaka, Japan$B!!(B
# Sorry, I am not good at English.

From bouncefilter Sat Oct 2 07:26:13 1999
Received: from druid.net (root@druid.net [216.126.72.98])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA26534
for <pgsql-hackers@postgreSQL.org>; Sat, 2 Oct 1999 07:25:13 -0400 (EDT)
(envelope-from darcy@druid.net)
Received: from localhost (1713 bytes) by druid.net
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <darcy>) (ident <darcy> using unix)
id <m11XNHl-0000c2C@druid.net>
for <pgsql-hackers@postgreSQL.org>; Sat, 2 Oct 1999 07:25:05 -0400 (EDT)
(Smail-3.2.0.104 1998-Nov-20 #4 built 1999-Apr-13)
Message-Id: <m11XNHl-0000c2C@druid.net>
Subject: Re: [HACKERS] postmaster dead on startup from unportable SSL patch
In-Reply-To: <Pine.LNX.4.10.9910010238570.625-100000@peter-e.yi.org> from
Peter Eisentraut at "Oct 1, 1999 02:49:03 am"
To: peter_e@gmx.net (Peter Eisentraut)
Date: Sat, 2 Oct 1999 07:25:05 -0400 (EDT)
From: "D'Arcy" "J.M." Cain <darcy@druid.net>
Cc: lockhart@alumni.caltech.edu, tgl@sss.pgh.pa.us,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL50 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thus spake Peter Eisentraut

The single-character switches are definitely non-intuitive. Implement

It's a backend people! My man page shows 12 defined switches, so there are
at least 44 character switches left. A little imagination please.

My take is that on the CL I want single character flags for speed of
entry and in startup scripts I can comment if neccesary.

Or do you *really* want to get into the business of writing your own
getopt replacement??? Then you are liable to end up with something even
less intuitive.

Well, in fact I do and have. :-)

See http://www.druid.net/~darcy/files/getarg.c for a different type of
getopt. It uses a different programmer API to add some functionality
but looks the same to the user unless they know about the extras.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

From bouncefilter Sat Oct 2 10:49:20 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 KAA50885
for <pgsql-hackers@postgreSQL.org>; Sat, 2 Oct 1999 10:48:53 -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 OAA18920;
Sat, 2 Oct 1999 14:48:12 GMT
Sender: lockhart@hub.org
Message-ID: <37F61B2B.FBE8F847@alumni.caltech.edu>
Date: Sat, 02 Oct 1999 14:48:11 +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: zakkr@zf.jcu.cz, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: TO_CHAR()
References: <m11X56P-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If incorporating into main tree, don't forget that TO_CHAR()
must also be capable to handle NUMERIC/DECIMAL/INTEGER with a
rich set of fomatting styles. Actually I'm in doubt if you
both are a little too much focusing on DATE/TIME.
This means that there could be different input arguments
(type and number!) to TO_CHAR().

Not a problem. In some cases, we are only an alias away from having it
(e.g. to_char(int) == text(int4)). Not sure about *all* of the others,
but the ugliest will be the to_char(datetime) and to_date(text,format)
stuff, so that is a good place to start.

- Thomas

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

From bouncefilter Sat Oct 2 11:01:20 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 LAA52626
for <pgsql-hackers@postgreSQL.org>; Sat, 2 Oct 1999 11:01:00 -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 LAA01206;
Sat, 2 Oct 1999 11:00:23 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Tricky query, tricky response
In-reply-to: Your message of Fri, 1 Oct 1999 03:03:46 +0200 (CEST)
<Pine.LNX.4.10.9910010253310.625-100000@peter-e.yi.org>
Date: Sat, 02 Oct 1999 11:00:23 -0400
Message-ID: <1203.938876423@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

However, if you do 
-	(CASE WHEN 0<(select count(*) from pg_views where viewname = relname)
-	THEN 'view' ELSE 'table' END)      
+	'relation'
if works fine. No nested CASE's?

Nope: no sub-selects in target list.

I'm hoping to fix that soon, but if you want psql to continue to work
with pre-6.6 backends then you'll have to use a different approach.

regards, tom lane

From bouncefilter Sat Oct 2 11:02:21 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 LAA52703
for <pgsql-hackers@postgreSQL.org>; Sat, 2 Oct 1999 11:01:38 -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 PAA18946;
Sat, 2 Oct 1999 15:00:59 GMT
Sender: lockhart@hub.org
Message-ID: <37F61E2B.25C8E995@alumni.caltech.edu>
Date: Sat, 02 Oct 1999 15:00:59 +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: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Tricky query, tricky response
References: <Pine.LNX.4.10.9910010253310.625-100000@peter-e.yi.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

No nested CASE's?

Looks like not. I would guess that it is fairly straightforward to
fix, but am not sure. Tom Lane hunted down an killed most of the CASE
problems (thanks Tom!), and this is in an area he is working on now.
Maybe you can get him to look at it??

- Thomas

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

From bouncefilter Sat Oct 2 11:50:21 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 LAA59550
for <pgsql-hackers@postgreSQL.org>; Sat, 2 Oct 1999 11:49:54 -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 LAA01770;
Sat, 2 Oct 1999 11:49:20 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster dead on startup from unportable SSL patch
In-reply-to: Your message of Fri, 1 Oct 1999 02:49:03 +0200 (CEST)
<Pine.LNX.4.10.9910010238570.625-100000@peter-e.yi.org>
Date: Sat, 02 Oct 1999 11:49:20 -0400
Message-ID: <1768.938879360@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

The single-character switches are definitely non-intuitive. Implement

It's a backend people! My man page shows 12 defined switches, so there are
at least 44 character switches left. A little imagination please.

It's true that the postmaster isn't something you normally start by
hand, but the other side of that coin is that startup scripts are
usually made by people when they are new to Postgres, and it's not
hard to make a mistake...

I am implementing GNU style long options in psql but obviously that sort
of thing won't help anybody that doesn't have a GNU'ish system, in
particular the people affected by the -is thing in the first place.

Or do you *really* want to get into the business of writing your own
getopt replacement???

Er, you had better be writing your own getopt replacement if you want
to provide GNU-style options in psql. Or have you forgotten that the
code must be portable to non-GNU platforms? I don't think it would be
a good idea to support long options only on boxes with a suitable
getopt, either. That would create a documentation, scripting, and
support nightmare (because the same psql command line would work for
some people and not others).

If it weren't for the license conflict between BSD and GPL, I'd suggest
just dropping GNU getopt into the Postgres distribution, but having
GPL'd code in the distribution is a can of worms we'd best not open.

Meanwhile, how about something like -i for normal and -i SSL for what's
desired. (That is, change the "i" to "i:").

I tried that before I realized what the i:: was all about, but it still
breaks existing startup scripts, because i: means that there *must* be
an argument to -i --- so if you write something like -i -o "backend switches"
the -o gets swallowed as the argument to -i, and chaos ensues.

I do like the notion of specifying SSL as the argument of some new
switch letter, so that we have a way to add more connection
methods without using up more switch letters...

regards, tom lane

From bouncefilter Sat Oct 2 13:48:58 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 NAA73562
for <pgsql-hackers@postgreSQL.org>; Sat, 2 Oct 1999 13:48: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 NAA07941;
Sat, 2 Oct 1999 13:47:12 -0400 (EDT)
To: Christof Petig <christof.petig@wtal.de>
cc: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Regression tests on intel for 6.5.2
In-reply-to: Your message of Fri, 01 Oct 1999 07:36:26 +0200
<37F44859.FD1B3D52@wtal.de>
Date: Sat, 02 Oct 1999 13:47:11 -0400
Message-ID: <7939.938886431@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Christof Petig <christof.petig@wtal.de> writes:

Yes, we should not be assuming that finite() is a macro, which is what
that #ifdef coding does. We need a HAVE_FINITE configuration test.
If you have time to prepare the diffs it'd be great.

Here they are

Checked, applied to current. Thanks.

regards, tom lane

From bouncefilter Sat Oct 2 14:21:55 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 OAA78171
for <pgsql-hackers@postgreSQL.org>; Sat, 2 Oct 1999 14:20:52 -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 OAA08151;
Sat, 2 Oct 1999 14:19:38 -0400 (EDT)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: pgsql-hackers@postgreSQL.org,
Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions
In-reply-to: Your message of Mon, 27 Sep 1999 21:59:50 +0400 (MSD)
<Pine.GSO.3.96.SK.990927215550.8336p-100000@ra>
Date: Sat, 02 Oct 1999 14:19:38 -0400
Message-ID: <8149.938888378@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

this select produces error message:
test=> select test2(NULL);
ERROR: typeidTypeRelid: Invalid type - oid = 0

[ where test2 is a plpgsql function ]

Actually this is not a plpgsql issue; with current sources you get the
same error with any function, for example

regression=> select int4fac(NULL);
ERROR: typeidTypeRelid: Invalid type - oid = 0

Digging into this, I find that (a) make_const() in parse_node.c produces
a Const node for the NULL that has consttype = 0; (b) ParseFuncOrColumn
applies ISCOMPLEX() which tries to get the type tuple for the argument
of the function; (c) that fails because the type ID is 0.

I am not sure whether there are two bugs here or only one. It would
probably be better to mark the Const node as having type UNKNOWN instead
of type 0 (but make_const is not the only place that makes null
constants this way! we'd need to find all the others...). But I am not
sure whether ParseFuncOrColumn would then do the right thing in terms of
resolving the type of the function; for that matter I'm not real sure
what the right thing for it to do is.

Thomas, this stuff is mostly your bailiwick; what do you think?

regards, tom lane

From bouncefilter Sat Oct 2 18:40:43 1999
Received: from postal.dn.net (postal.dn.net [207.226.170.20])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA22984
for <pgsql-hackers@postgreSQL.org>; Sat, 2 Oct 1999 18:40:29 -0400 (EDT)
(envelope-from frankpit@pop.dn.net)
From: frankpit@pop.dn.net
Received: from pop.dn.net (pm-76.ppp.wdc.dn.net [207.226.188.76])
by postal.dn.net (8.9.3/postal) with ESMTP id SAA23365;
Sat, 2 Oct 1999 18:33:08 -0400 (EDT)
Sender: bernie@postal.dn.net
Message-ID: <37F64D6F.22B215C7@pop.dn.net>
Date: Sat, 02 Oct 1999 14:22:40 -0400
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.34 i686)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Doccumentation Patch for Create Function
References: <8295.938892436@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Bernard Frankpitt <frankpit@pop.dn.net> wrote (a couple weeks ago):

When I was altering the xfunc.sgml page I came across this:

" " "

That's talking about builtin functions, ie functions implemented by
statically-linked routines in the standard backend.

regards, tom lane

Oh, That explains it. It didn't occur to me that people adding custom
functionality to the backend wouldn't use a dynamically linked
interface. In fact it occured to me that it might be a good idea to
convert some of `poor relations' the stuff like gist, and perhaps rtrees
to dynamically linked modules in /contrib. They might then provide
better examples of how to develop and link major extensions into the
backend in a relatively painless way. Also an exercise like that would
really provide a good opportunity to define and document the backend
code interfaces between the executor and access methods, and between
access methods and the low-level database functionality (buffer
management, tuple time-validation etc.). Once I finish my dissertation,
I was sort of planning to start chipping away at some documentation for
the code internals.

To me, the extensibility features and open design of PostgreSQL are its
most exciting features, and I think that a good set of documents on the
internal functionality and interfaces would be rewarded in the long term
by innovative features and unusual applications from developers in a
wide variety of fields.

Bernie

From bouncefilter Sat Oct 2 14:24:56 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 OAA78580
for <pgsql-hackers@postgreSQL.org>; Sat, 2 Oct 1999 14:24:39 -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 OAA08179;
Sat, 2 Oct 1999 14:24:06 -0400 (EDT)
To: wieck@debis.com (Jan Wieck)
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RI status report #1
In-reply-to: Your message of Tue, 28 Sep 1999 13:58:09 +0200 (MET DST)
<m11VvtZ-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Sat, 02 Oct 1999 14:24:05 -0400
Message-ID: <8177.938888645@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

Tom Lane wrote:

I am in the middle of some fairly extensive revisions in
rewriteManip.c, rewriteHandler.c, and ruleutils.c --- ...
I intended to finish these up in the next few days and commit them,
but if you've already started major hacking in these files then maybe
we should find another way.

Do it - I'll wait for you (would you please give me a sign
then). But I'm 97.5% sure our work has no collision areas.

OK, I'm done with rewriter/ruleutils cleanups, at least for now.

regards, tom lane

From bouncefilter Sun Oct 3 08:08:42 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA18118
for <pgsql-hackers@postgresql.org>; Sun, 3 Oct 1999 08:08:14 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:3303 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rxoQP90377>;
Sun, 3 Oct 1999 14:07:55 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11XU5Z-0000PN-00; Sat, 02 Oct 1999 20:40:57 +0200
Date: Sat, 2 Oct 1999 20:40:57 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: getopt_long (was Re: [HACKERS] postmaster dead on startup ...)
In-Reply-To: <1768.938879360@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.10.9910022006080.371-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 2, Tom Lane mentioned:

Er, you had better be writing your own getopt replacement if you want
to provide GNU-style options in psql. Or have you forgotten that the
code must be portable to non-GNU platforms? I don't think it would be
a good idea to support long options only on boxes with a suitable
getopt, either. That would create a documentation, scripting, and
support nightmare (because the same psql command line would work for
some people and not others).

Naturally this whole thing will be #ifdef'ed out and depending on an
autoconf test for getopt_long. Also there will be a short option for every
long one and vice versa.

I also gave the documentation issue some thought and I agree that this
might not be fun to support. But then I don't really see too many support
questions regarding psql _invocation_.

At this point I'm just going to leave it undocumented, pending further
complaints. I just like the self-documenting elegancy of

$ psql --host=localhost --port=5432 --dbname=foo --username=joe
--from-file=myfile.sql --out-file=result.txt

But you can also get (actual output):
$ ./psql --list
This version of psql was compiled without support for long options.
Use -? for help on invocation options.

It's not too hard to check for that: just include "-" in your options list
for the regular getopt.

If it weren't for the license conflict between BSD and GPL, I'd suggest

Okay, while we're at it: Someone wrote me regarding readline (GPL) vs
libedit (BSD). If you look at the code, readline is pretty deeply
integrated. This is almost the same issue. But there has not been any
support nightmare I was aware of. On the other hand there are even
backslash commands (\s) that only work with readline.

I even wrote an SQL-aware readline tab completion which I intend to
incorporate in one form or another. This is true added functionality,
while you might get away with saying that long options are just a toy.

And of course we don't even want to talk about the requirements regarding
GNU make, GNU flex, GNU tar, or this whole autoconf business. Of course,
we could write ./configure -e locale -w perl, but that's no fun . . .

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

From bouncefilter Sat Oct 2 15:28:32 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 PAA85889
for <pgsql-hackers@postgreSQL.org>; Sat, 2 Oct 1999 15:27:52 -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 PAA08297;
Sat, 2 Oct 1999 15:27:16 -0400 (EDT)
To: Bernard Frankpitt <frankpit@pop.dn.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Doccumentation Patch for Create Function
In-reply-to: Your message of Thu, 16 Sep 1999 16:51:33 +0000
<37E12015.AFA0D0BA@pop.dn.net>
Date: Sat, 02 Oct 1999 15:27:16 -0400
Message-ID: <8295.938892436@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bernard Frankpitt <frankpit@pop.dn.net> wrote (a couple weeks ago):

When I was altering the xfunc.sgml page I came across this:

<title>Name Space Conflicts</title>
<para>
As of <productname>Postgres</productname> v6.5,
<command>CREATE FUNCTION</command> can decouple a C language
function name from the name of the entry point. This is now the
preferred technique to accomplish function overloading.
</para>

which seems to suggest that someone had a similar idea in the past. I
could find no evidence of this functionality in the 6.5 code though

That's talking about builtin functions, ie functions implemented by
statically-linked routines in the standard backend. The SQL name is
now distinct from the C-language name, but that wasn't true before 6.5.
I kind of thought you had seen this and realized it would be a good
idea to have the same functionality for dynamically linked routines.

If you came up with the idea independently, it must clearly be a good
thing ;-)

regards, tom lane

From bouncefilter Sat Oct 2 19:57: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 TAA31650
for <pgsql-hackers@postgreSQL.org>; Sat, 2 Oct 1999 19:57:37 -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 TAA10998
for <pgsql-hackers@postgreSQL.org>; Sat, 2 Oct 1999 19:57:02 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: 'iscachable' only partially solves premature constant coercion
Date: Sat, 02 Oct 1999 19:57:01 -0400
Message-ID: <10995.938908621@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I have finished installing the code changes associated with marking
functions 'iscachable' or not. I had hoped that this change would
eliminate the problems we have with premature coercion of datetime
constants in column defaults and rules. It turns out it doesn't :-(.
That's because there isn't any good way to postpone the evaluation of
a typinput function. Since the argument of a typinput function is a
null-terminated C string, and not a 'text' or any other full-fledged
Postgres type, there is no way to construct an expression tree
representing runtime evaluation of the typinput function. So, even
though the system knows it shouldn't evaluate the typinput function
before runtime, it has little choice.

We have talked about making 'C string' a genuine Postgres type, at
least to the extent of giving it an OID and making it representable
as a Const node. If we did that then we could represent a typinput
function call by an expression tree and make this problem go away.
I'm not going to tackle that right now, though, since there are
higher-priority problems to deal with.

The current state of affairs is that if you write a constant of UNKNOWN
type (ie, an unadorned quoted constant), it'll get coerced to the
destination type just as soon as the system can figure out what that
type is. So, it's still necessary to write "'now'::text" (or one of the
other syntaxes for type-casting) or "now()" as the default value for
a datetime column --- if you write unadorned 'now' then you will get
the time of table creation, same as before.

I am about to rip out and redo the crufty implementation of default and
constraint expressions, and I think that I can arrange for UNKNOWN
constants to remain UNKNOWN when they are stored into the pg_attrdef
table. This would mean that what gets into pg_attrdef is just the
unadorned string 'now', and then the coercion of this to a particular
timestamp will occur when an INSERT statement that uses the default
is parsed. So the right thing (approximately, anyway) should happen for
a typical run-of-the-mill INSERT. The wrong thing will still happen
for an INSERT written in a rule --- its default will be established when
the rule is created.

regards, tom lane

From bouncefilter Sun Oct 3 08:08:42 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA18107
for <pgsql-hackers@postgresql.org>; Sun, 3 Oct 1999 08:08:05 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:3299 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rxoQK16653>;
Sun, 3 Oct 1999 14:07:50 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11XeEp-00006Q-00; Sun, 03 Oct 1999 07:31:11 +0200
Date: Sun, 3 Oct 1999 07:31:11 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Tricky query, tricky response
In-Reply-To: <1203.938876423@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.10.9910030715590.366-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 2, Tom Lane mentioned:

Nope: no sub-selects in target list.

I'm hoping to fix that soon, but if you want psql to continue to work
with pre-6.6 backends then you'll have to use a different approach.

Question number one is: Do I? Yeah, okay :)

Anyway, I thought wouldn't a more, um, user-friendly error message like
ERROR: Subselects are not allowed in target list.
be more desirable than
ERROR: flatten_tlistentry: Cannot handle node type 108

If _I_ read the latter I can at least suspect that there is a problem in
the query tree, but Joe User that just learned about inodes the other day
is going to think his system is broken is all sorts of ways.

Another example is
FATAL 1: SetUserId: user 'joeschmoe' is not in 'pg_shadow'
clearly not as nice as
FATAL ERROR: 'joeschmoe' is not a valid database user.

(Also, if you want to be really secure you wouldn't give them the
information that 'joeschmoe' is not a valid user but rather just return
"Permission denied" or "Authentication failed". -- cf. login(1) )

I think that ought to be a TODO item, right above
* Allow international error message support and add error codes
Perhaps it's even the same in essence.

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

From bouncefilter Sun Oct 3 02:15:43 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 CAA76268
for <pgsql-hackers@postgreSQL.org>; Sun, 3 Oct 1999 02:15:04 -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 GAA20356;
Sun, 3 Oct 1999 06:14:16 GMT
Sender: lockhart@hub.org
Message-ID: <37F6F437.DD915876@alumni.caltech.edu>
Date: Sun, 03 Oct 1999 06:14:15 +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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions
References: <8149.938888378@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

probably be better to mark the Const node as having type UNKNOWN instead
of type 0 (but make_const is not the only place that makes null
constants this way! we'd need to find all the others...). But I am not
sure whether ParseFuncOrColumn would then do the right thing in terms of
resolving the type of the function; for that matter I'm not real sure
what the right thing for it to do is.
Thomas, this stuff is mostly your bailiwick; what do you think?

My recollection is that UNKNOWN usually applies to strings of
unspecified type, while "0" applies to NULL fields. I can put this on
my list to look at later.

Another side issue; any function called with a null parameter will
actually not get called at all! Postgres assumes that a function
called with null must return null, so doesn't bother calling the
routine...

- Thomas

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

From bouncefilter Sun Oct 3 04:55:40 1999
Received: from druid.net (root@druid.net [216.126.72.98])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA97214
for <pgsql-hackers@postgreSQL.org>; Sun, 3 Oct 1999 04:54:44 -0400 (EDT)
(envelope-from darcy@druid.net)
Received: from localhost (1691 bytes) by druid.net
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <darcy>) (ident <darcy> using unix)
id <m11XhPi-0000e5C@druid.net>
for <pgsql-hackers@postgreSQL.org>; Sun, 3 Oct 1999 04:54:38 -0400 (EDT)
(Smail-3.2.0.104 1998-Nov-20 #4 built 1999-Apr-13)
Message-Id: <m11XhPi-0000e5C@druid.net>
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions
In-Reply-To: <37F6F437.DD915876@alumni.caltech.edu> from Thomas Lockhart at
"Oct 3, 1999 06:14:15 am"
To: lockhart@alumni.caltech.edu (Thomas Lockhart)
Date: Sun, 3 Oct 1999 04:54:38 -0400 (EDT)
From: "D'Arcy" "J.M." Cain <darcy@druid.net>
Cc: pgsql-hackers@postgreSQL.org
Reply-To: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL50 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thus spake Thomas Lockhart

Another side issue; any function called with a null parameter will
actually not get called at all! Postgres assumes that a function
called with null must return null, so doesn't bother calling the
routine...

Did this get changed recently? AFAIK the routine gets called. It's just
that the result is ignored and null is then returned. This bit me in the
ass when I was working on the inet stuff. If I didn't check for NULL and
return something my function would dump core but if I tried to deal with
the NULL and return something sensible, the function returned NULL anyway.

There was a discussion at the time about fixing this so that the function
never got called as investigation showed that there were existing ones
that would also crash if given null inputs. Did this ever happen?

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

From bouncefilter Sun Oct 3 12:34: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 MAA50861
for <pgsql-hackers@postgreSQL.org>; Sun, 3 Oct 1999 12:34:02 -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 MAA20746;
Sun, 3 Oct 1999 12:32:46 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions
In-reply-to: Your message of Sun, 03 Oct 1999 06:14:15 +0000
<37F6F437.DD915876@alumni.caltech.edu>
Date: Sun, 03 Oct 1999 12:32:46 -0400
Message-ID: <20744.938968366@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

probably be better to mark the Const node as having type UNKNOWN instead
of type 0 (but make_const is not the only place that makes null
constants this way! we'd need to find all the others...). But I am not
sure whether ParseFuncOrColumn would then do the right thing in terms of
resolving the type of the function; for that matter I'm not real sure
what the right thing for it to do is.
Thomas, this stuff is mostly your bailiwick; what do you think?

My recollection is that UNKNOWN usually applies to strings of
unspecified type, while "0" applies to NULL fields. I can put this on
my list to look at later.

OK, but after mulling it over it seems that UNKNOWN is pretty much what
we want for an explicit null constant. If you want to consider NULL
as having a type different from UNKNOWN, then most of the places that
currently check for UNKNOWN would have to check for both, no?

Another side issue; any function called with a null parameter will
actually not get called at all! Postgres assumes that a function
called with null must return null, so doesn't bother calling the
routine...

Actually, it's even sillier than that: the function *is* called, but
then the OR of the input values' nullflags is attached to the output,
so you get back a null no matter what the function did. (This is why
all the functions that take pass-by-ref args have to be careful about
getting null pointers.)

In any case, I hope to see that fixed before 6.6/7.0/whatever our
next release is. So we do need a fix for the parser issue.

regards, tom lane

From bouncefilter Sun Oct 3 12:42: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 MAA52094
for <pgsql-hackers@postgreSQL.org>; Sun, 3 Oct 1999 12:42:21 -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 MAA20817
for <pgsql-hackers@postgreSQL.org>; Sun, 3 Oct 1999 12:41:50 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions
In-reply-to: Your message of Sun, 3 Oct 1999 04:54:38 -0400 (EDT)
<m11XhPi-0000e5C@druid.net>
Date: Sun, 03 Oct 1999 12:41:49 -0400
Message-ID: <20815.938968909@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"D'Arcy" "J.M." Cain <darcy@druid.net> writes:

There was a discussion at the time about fixing this so that the function
never got called as investigation showed that there were existing ones
that would also crash if given null inputs. Did this ever happen?

Nothing's changed yet, but you are right that one of the many problems
with the existing fmgr interface is that checking for null inputs is
both necessary and tedious (= frequently omitted).

I have a rough proposal on the table for cleaning this up so that null
handling is done properly, ie, a function can see *which* of its inputs
are null and can choose whether to return null or not. The most common
case of a "strict" function (any null input -> null result) would be
painless, but we wouldn't force all functions into that straitjacket.
See my pghackers message of 14 Jun 99.

regards, tom lane

From bouncefilter Sun Oct 3 12:54: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 MAA53517
for <pgsql-hackers@postgreSQL.org>; Sun, 3 Oct 1999 12:54:06 -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 MAA20892;
Sun, 3 Oct 1999 12:53:19 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Tricky query, tricky response
In-reply-to: Your message of Sun, 3 Oct 1999 07:31:11 +0200 (CEST)
<Pine.LNX.4.10.9910030715590.366-100000@peter-e.yi.org>
Date: Sun, 03 Oct 1999 12:53:18 -0400
Message-ID: <20890.938969598@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

Anyway, I thought wouldn't a more, um, user-friendly error message like
ERROR: Subselects are not allowed in target list.
be more desirable than
ERROR: flatten_tlistentry: Cannot handle node type 108

Yes, it would. Are you volunteering to try to make that happen?
(Not for this one case, but for everything?)

There's been some discussion of trying to clean up the error reporting
conventions, and in particular separate internal details (such as which
routine is reporting the error) from the "user level" information.
But a lot of the internal checks are pretty content-free from a user's
point of view, and there's little to be done about that. (Does
flatten_tlistentry have a clue *why* it got a node type it never heard
of? Nyet.) I do not think that a generic "Internal error" message
would be an improvement over what we have, messy though it is. It's
not a simple problem...

regards, tom lane

From bouncefilter Sun Oct 3 15:54:48 1999
Received: from thelab.hub.org (nat194.229.mpoweredpc.net [142.177.194.229])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA74922
for <pgsql-hackers@postgreSQL.org>; Sun, 3 Oct 1999 15:54:14 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA17417;
Sun, 3 Oct 1999 16:54:10 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 3 Oct 1999 16:54:10 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RI status report #2
In-Reply-To: <199909291751.NAA03864@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910031653380.485-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 29 Sep 1999, Bruce Momjian wrote:

Bruce Momjian wrote:

Man, that's a heap of additions.

Only the top of the iceberg :-)

Yikes. I was just talking to Thomas Lockhart by phone, and was saying
that I thought 6.6 would be a small, incremental release after the
changes in 6.5.*. Obviously, 6.6 is going to be as full-featured as
earlier releases.

Have we ever had a "small, incremental release", other then the
minor-minor releases? :)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Sun Oct 3 15:56:48 1999
Received: from thelab.hub.org (nat194.229.mpoweredpc.net [142.177.194.229])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA75341
for <pgsql-hackers@postgreSQL.org>; Sun, 3 Oct 1999 15:56:43 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA17425;
Sun, 3 Oct 1999 16:56:49 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 3 Oct 1999 16:56:48 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Jan Wieck <wieck@debis.com>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RI status report #2
In-Reply-To: <m11WOzk-0003kuC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.BSF.4.10.9910031655170.485-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 29 Sep 1999, Jan Wieck wrote:

Bruce Momjian wrote:

Man, that's a heap of additions.

Only the top of the iceberg :-)

Yikes. I was just talking to Thomas Lockhart by phone, and was saying
that I thought 6.6 would be a small, incremental release after the
changes in 6.5.*. Obviously, 6.6 is going to be as full-featured as
earlier releases.

Wasn't it YOU who asked ME to become active again? Your
above thought is a little silly if ya really wanted to
interrupt my sleep mode ;-)

OTOH Vadim is close to WAL and I see activity on
(outer/left/right?) join support too. Maybe there wouldn't be
a v6.6 at all.

WAL is IMHO the only real reason not to choose PostgreSQL for
production. Beeing able to recover (roll forward) from a
backup using transaction log is a required feature for
mission critical data. Thus, having all this (WAL, FOREIGN
KEY etc.) is a greater step forward that that between v6.4
and v6.5.

If all that really materializes in our next release, it's
time to number it v7.0 - no?

I was kinda starting to wonder that one myself... my feeling: its time
guys.

We're still in no more rush to get it out the door...sometime 1st quarter
of year 2000, but with everything that has changed up until now, I think
its time we up'd the major version number ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Sun Oct 3 15:57:48 1999
Received: from thelab.hub.org (nat194.229.mpoweredpc.net [142.177.194.229])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA75385
for <pgsql-hackers@postgreSQL.org>; Sun, 3 Oct 1999 15:57:28 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA17446;
Sun, 3 Oct 1999 16:57:30 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 3 Oct 1999 16:57:30 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RI status report #2
In-Reply-To: <199909292103.RAA07237@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910031657030.485-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 29 Sep 1999, Bruce Momjian wrote:

Yes, I am starting to see 7.0 too.

one motion, two second's...anyone disagree? *lifts mallet*

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Oct 4 07:23:05 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 HAA20312
for <pgsql-hackers@postgreSQL.org>; Mon, 4 Oct 1999 07:22:39 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11Y665-0003kLC; Mon, 4 Oct 99 13:16 MET DST
Message-Id: <m11Y665-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions
To: pgsql-hackers@postgreSQL.org
Date: Mon, 4 Oct 1999 13:16:01 +0200 (MET DST)
Cc: lockhart@alumni.caltech.edu
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <m11XhPi-0000e5C@druid.net> from "D'Arcy" "J.M." Cain" at Oct 3,
99 04:54:38 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

D'Arcy J.M. Cain wrote:

Thus spake Thomas Lockhart

Another side issue; any function called with a null parameter will
actually not get called at all! Postgres assumes that a function
called with null must return null, so doesn't bother calling the
routine...

Did this get changed recently? AFAIK the routine gets called. It's just
that the result is ignored and null is then returned. This bit me in the
ass when I was working on the inet stuff. If I didn't check for NULL and
return something my function would dump core but if I tried to deal with
the NULL and return something sensible, the function returned NULL anyway.

There was a discussion at the time about fixing this so that the function
never got called as investigation showed that there were existing ones
that would also crash if given null inputs. Did this ever happen?

It wasn't changed. But the isNull bool pointer (in-/out-
param) is only handed down as the second call argument if a
function is called via fmgr_c() and has exactly one argument
as defined in pg_proc.

Handling NULL on a per argument/return value base is one of
the long standing TODO's.

Jan

From bouncefilter Tue Oct 5 16:41:13 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA01422
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 16:39:51 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by trends.net (8.8.8/8.8.8) with ESMTP id OAA11843
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 14:11:13 -0400 (EDT)
Received: from uria.its.uu.se ([130.238.7.14]:4822 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.ryXwd250118>;
Tue, 5 Oct 1999 20:10:49 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2) id 11Y8iF-0000dY-00
for pgsql-hackers@postgresql.org; Mon, 04 Oct 1999 16:03:35 +0200
Date: Mon, 4 Oct 1999 16:03:34 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgresql.org
Subject: Database names with spaces
Message-ID: <Pine.LNX.4.10.9910041528220.2276-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

I see a todo item
* Views with spaces in view name fail when referenced

I have another one for you:
* Databases with spaces in name fail to be created and destroyed despite
responses to the contrary.

A sample session:
template1=> create database "with space";
CREATEDB
template1=> \q
$ psql -d "with space"
Connection to database 'with space' failed.
FATAL 1: InitPostgres could not validate that the database version is
compatible with this level of Postgres
even though the database system as a whole appears to be at a
compatible level.
You may need to recreate the database with SQL commands DROP
DATABASE and CREATE DATABASE.
File '/usr/local/pgsql/data/base/with space/PG_VERSION' does not
exist or no read permission.

(You can't do \c with space or \c "with space" yet. That will be (is) in
the new version.)

Further investigation shows that the directory
/usr/local/pgsql/data/base/with space is totally empty.

template1=> drop database "with space";
DESTROYDB

Yet, the mysterious empty directory is still there.

BUG?

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

From bouncefilter Mon Oct 4 11:12:07 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 LAA55862
for <pgsql-hackers@postgreSQL.org>; Mon, 4 Oct 1999 11:11:37 -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 LAA02326
for <pgsql-hackers@postgreSQL.org>; Mon, 4 Oct 1999 11:11:02 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Status of 'now' column defaults
In-reply-to: Your message of Sat, 02 Oct 1999 19:57:01 -0400
<10995.938908621@sss.pgh.pa.us>
Date: Mon, 04 Oct 1999 11:11:02 -0400
Message-ID: <2324.939049862@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I wrote:

I am about to rip out and redo the crufty implementation of default and
constraint expressions, and I think that I can arrange for UNKNOWN
constants to remain UNKNOWN when they are stored into the pg_attrdef
table. This would mean that what gets into pg_attrdef is just the
unadorned string 'now', and then the coercion of this to a particular
timestamp will occur when an INSERT statement that uses the default
is parsed. So the right thing (approximately, anyway) should happen for
a typical run-of-the-mill INSERT. The wrong thing will still happen
for an INSERT written in a rule --- its default will be established when
the rule is created.

I did this, and that's how it works now. Unless we choose to do
something about making C strings and typinput functions fit into the
Postgres type scheme, that's how it will continue to work.

To summarize: in current sources, "default 'now'" works as expected in
simple cases:

play=> create table valplustimestamp (val int, stamp datetime default 'now');
CREATE
play=> insert into valplustimestamp values(1);
INSERT 653323 1
play=> insert into valplustimestamp values(2);
INSERT 653324 1
play=> select * from valplustimestamp;
val|stamp
---+----------------------------
1|Mon Oct 04 10:58:47 1999 EDT
2|Mon Oct 04 10:58:49 1999 EDT
(2 rows)

but it still has a subtle failure mode:

play=> create view val as select val from valplustimestamp;
CREATE
play=> create rule val_ins as on insert to val do instead
play-> insert into valplustimestamp values(new.val);
CREATE
play=> insert into val values(3);
INSERT 653336 1
play=> insert into val values(4);
INSERT 653337 1
play=> select * from valplustimestamp;
val|stamp
---+----------------------------
1|Mon Oct 04 10:58:47 1999 EDT
2|Mon Oct 04 10:58:49 1999 EDT
3|Mon Oct 04 10:59:48 1999 EDT
4|Mon Oct 04 10:59:48 1999 EDT
(4 rows)

The default value inserted by the rule got frozen when the rule was
parsed, as can be seen by inspecting the back-parsing of the rule:

play=> select * from pg_rules;
tablename|rulename|definition
---------+--------+--------------------------------------------------------------------------------------------------------------------------------------------------------
val |val_ins |CREATE RULE val_ins AS ON INSERT TO val DO INSTEAD INSERT INTO valplustimestamp (val, stamp) VALUES (new.val, 'Mon Oct 04 10:59:48 1999 EDT'::datetime);
(1 row)

So, we should still recommend "DEFAULT now()" rather than "DEFAULT 'now'"
as the most reliable way of setting up a current-time default.

regards, tom lane

From bouncefilter Mon Oct 4 14:57:14 1999
Received: from nsi.edu (amethea.nsi.edu [198.133.185.9])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA84967
for <pgsql-hackers@postgreSQL.org>; Mon, 4 Oct 1999 14:56:15 -0400 (EDT)
(envelope-from reina@nsi.edu)
Received: from nsi.edu (o21.nsi.edu [204.128.156.216])
by nsi.edu (8.9.1/8.9.1) with ESMTP id LAA18310
for <pgsql-hackers@postgreSQL.org>; Mon, 4 Oct 1999 11:56:10 -0700 (PDT)
Sender: reina@nsi.edu
Message-ID: <37F8F914.CD20E5DC@nsi.edu>
Date: Mon, 04 Oct 1999 11:59:32 -0700
From: "G. Anthony Reina" <reina@nsi.edu>
Organization: The Neurosciences Institute
X-Mailer: Mozilla 4.61 [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: MATLAB mex file for PostgreSQL
Content-Type: multipart/mixed; boundary="------------C6189B8B3926327EC0EC7CA7"

This is a multi-part message in MIME format.
--------------C6189B8B3926327EC0EC7CA7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've written a little C mex file for MATLAB to interface to the my
PostgreSQL database. Currently, I have a compiled version for SGI IRIX
6.5.4, but I think this should be simple enough to port to any machine.

Currently, the mex file just brings data back as ASCII. I hope to
eventually add some ability for binary cursors and possibly even
lower-level functions like PQexec and PQntuples. But considering my list
of things to do that may take a while.

I've tried to compile it for Linux, however MATLAB was compiled on Linux
4.2 and so the mex compiler won't work properly under my RH 6.0. There
is a workaround by getting the version 5.0 C libraries for Linux and
compiling it with them. However, I am hoping that the Mathworks will
eventually compile the program on 6.0 so that I don't have to do the
workaround.

I hope people get some use out of it. Let me know if you find ways to
improve it. I think it would be a nice little interface to add to the
PostgreSQL distribution someday.

-Tony

--------------C6189B8B3926327EC0EC7CA7
Content-Type: text/plain; charset=us-ascii;
name="mat_psql.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="mat_psql.c"

/* psql.c
* MATLAB mex file which reads from the PostgreSQL database
*
* Usage: [a, b, c, ...] = psql(database_name_string, query_string);
*
* Example: [monkey, arm, cell] = psql('db01', 'select distinct monkey, arm, cell from cell');
*
* Tony Reina
* Motor Control Lab
* The Neurosciences Institute
* San Diego, CA
*
* Created: 1 Oct 1999
* Last Update: 1 Oct 1999 GAR
* To compile use the CMEX compiler:
* cmex mat_psql.c $SQL -output psql.mexsg
*/
#include <strings.h>
#include "mex.h"
#include "libpq-fe.h"

void mexFunction( int nlhs,
mxArray *plhs[],
int nrhs,
const mxArray *prhs[] )

{
char *db_name, *query_string;
char *buffer;

char *output_string[8192];

unsigned int buffer_length;

int i, j, status, number_of_tuples, number_of_fields;

/* SQL database variables */
/* ---------------------- */
char *pghost, *pgport, *pgoptions, *pgtty;
PGconn *conn;
PGresult *res;

/* Verify that there are 11 variables passed into the function */
/* rhs = right-hand side = input variables */
if (nrhs != 2) {
mexErrMsgTxt("ERROR! I need two input arguments: database name and query string.");
}

buffer_length = mxGetM(prhs[0]) * mxGetN(prhs[0]) + 1;
db_name = mxCalloc(buffer_length, sizeof(char));

status = mxGetString(prhs[0], db_name, buffer_length);
if (status != 0)
mexErrMsgTxt("Could not perform the database query because of input error!");

buffer_length = mxGetM(prhs[1]) * mxGetN(prhs[1]) + 1;
query_string = mxCalloc(buffer_length, sizeof(char));

status = mxGetString(prhs[1], query_string, buffer_length);
if (status != 0)
mexErrMsgTxt("Could not perform the database query because of input error!");

/* Initialize database variables */
/* ============================= */
pghost = NULL; /* host name of the backend server */
pgport = NULL; /* port of the backend server */
pgoptions = NULL; /* special options to start up the backend server */
pgtty = NULL; /* debugging tty for the backend server */

/* Open a connection to the database */
/* ================================= */
conn = PQsetdb (pghost, pgport, pgoptions, pgtty, db_name);

if (PQstatus (conn) == CONNECTION_BAD)
{
printf ("Connection to database '%s' failed.\n", db_name);
printf ("%s\n", PQerrorMessage (conn));
PQfinish(conn);
mexErrMsgTxt("Could not perform the database query because of connection error!");
} /* if (PQstatus(conn) == CONNECTION_BAD) */

res = PQexec(conn, query_string);

number_of_tuples = PQntuples(res);

if (number_of_tuples == 0) {
PQclear(res);
PQfinish(conn);
mexErrMsgTxt("Could not perform the database query because no data returned for query!");
}

number_of_fields = PQnfields(res);

if (nlhs > number_of_fields) {
printf("Too many output variables for the desired query.\n"
"I will only fill the first %d variables.\n", number_of_fields);
nlhs = number_of_fields;
}
else if (nlhs < number_of_fields) {
printf("Too few output variables for the desired query.\n"
"The last %d columns (fields) in the query will be dropped.\n",
number_of_fields - nlhs);
}

/* This declares the memory space in MATLAB for the left-handed arguments:
* coefficients, work, and error. These are the output variables.
*/
for (i = 0; i < nlhs; i++) {

for (j = 0; j < number_of_tuples; j++)
output_string[j] = PQgetvalue(res, j, i);

plhs[i] = mxCreateCharMatrixFromStrings(number_of_tuples, (const char **)output_string);

}

PQclear(res);
PQfinish(conn);

}

--------------C6189B8B3926327EC0EC7CA7--

From bouncefilter Mon Oct 4 17:39:16 1999
Received: from mail0.mco.bellsouth.net (mail0.mco.bellsouth.net
[205.152.48.12]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA15847
for <pgsql-hackers@postgreSQL.org>; Mon, 4 Oct 1999 17:38:34 -0400 (EDT)
(envelope-from fcheese@bellsouth.net)
Received: from default (host-209-214-130-98.jax.bellsouth.net
[209.214.130.98])
by mail0.mco.bellsouth.net (3.3.4alt/0.75.2) with SMTP id RAA09300
for <pgsql-hackers@postgreSQL.org>; Mon, 4 Oct 1999 17:38:44 -0400 (EDT)
Message-ID: <001301bf0eb0$ae6ee780$6282d6d1@default>
From: "Frederick Cheeseborough" <fcheese@bellsouth.net>
To: <pgsql-hackers@postgreSQL.org>
Subject: unsubscribe
Date: Mon, 4 Oct 1999 17:37:34 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0010_01BF0E8F.24B64360"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01BF0E8F.24B64360
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0010_01BF0E8F.24B64360
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0010_01BF0E8F.24B64360--

From bouncefilter Mon Oct 4 21:48: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 VAA51904
for <pgsql-hackers@postgreSQL.org>; Mon, 4 Oct 1999 21:47:59 -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 VAA04085;
Mon, 4 Oct 1999 21:46:49 -0400 (EDT)
To: wieck@debis.com (Jan Wieck), Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Planner drops unreferenced tables --- bug, no?
In-reply-to: Your message of Wed, 29 Sep 1999 17:16:18 +0200 (MET DST)
<m11WLSs-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Mon, 04 Oct 1999 21:46:48 -0400
Message-ID: <4083.939088008@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I wrote:

It seems to me that the latter query must yield 9 rows (three
occurrences of each value) to satisfy the SQL spec. The spec defines
the result of a two-query FROM clause to be the Cartesian product of the
two tables, period. It doesn't say anything about "only if one or more
columns of each table are actually used somewhere".

On further investigation, it turns out that there is actually code in
the planner that tries to do this right! (and at one time probably
did do it right...) add_missing_vars_to_tlist() in initsplan.c has the
specific mission of making sure any tables that are mentioned only in
the FROM clause get included into the planner's target relation set.
Unfortunately, it's been dead code for a while, because there are two
different upstream routines that do the wrong thing.

50% of the problem is in query_planner, which tries to short-circuit
the whole planning process if it doesn't see any vars at all in the
targetlist or qual. I think this code can simply be diked out as
misguided optimization, although there might be a couple of small
changes needed elsewhere to handle the case where the target relation
set is truly empty. (But this error is not what's preventing
"SELECT foo.f1 FROM foo, bar" from generating a join between foo and
bar; add_missing_vars_to_tlist() could still fire, so long as at least
one var appears in the query.)

wieck@debis.com (Jan Wieck) writes:

Caution here!

After rewriting there can be many unused rangetable entries
floating around. Especially if you SELECT from a view, the
view's relation is still mentioned in the rangetable.

The other 50% of the problem is that the rewriter is overly enthusiastic
about clearing the inFromCl flag in order to prevent views from being
taken as valid join targets. rewriteHandler.c has two different
routines that will clear inFromCl flags, and they're both bogus:

1. fireRIRrules will zap a table's inFromCl flag if the table is not
referenced by any Var in the parsetree, *whether or not the table
actually has any rules*. This is why add_missing_vars_to_tlist() is
currently dead code in all cases. It's wrong in another way too: if
the table has no referencing vars, fireRIRrules doesn't look for rules
applicable to the table. That's wrong for the same reasons that
removing the table from the join set is wrong: it can still affect
the results, so the lookup and substitution should still occur.

2. If ApplyRetrieveRule is fired, it resets the inFromCl flag on *all*
tables in the query, not only the one being substituted for. This is
just plain wrong.

I believe the right thing to do is remove ApplyRetrieveRule's change
of inFromCl entirely, and to modify fireRIRrules so that it only clears
a table's inFromCl flag if it finds an ON SELECT DO INSTEAD rule for it.
That will remove views from the join set without side-effects on the
behavior for normal tables. (Also, fireRIRrules should try to apply
rules for a table whether it finds references to it or not; which means
that rangeTableEntry_used() isn't needed at all.)

Jan, what do you think of this? In particular, what do you think should
happen in the following cases:
1. Table has an ON SELECT *not* INSTEAD rule.
2. There is an ON SELECT (with or without INSTEAD) rule for one or
more fields of the table, but not for the whole table.

I'm not at all clear on the semantics of those kinds of rules, so I
don't know if they should remove the original table from the join set
or not. (I'm also confused about ON SELECT INSTEAD where the INSTEAD
is not a select; is that even legal?)

Also, would it be a good idea to propagate a source view's inFromCl
flag into the substituted tables? (That is, when firing a select rule
for a table that wasn't marked inFromCl to begin with, clear the
inFromCl flags of all RTEs that it adds to the query.) I am not sure
if this is appropriate or not.

Actually, it would probably be cleanest if we split the functions of
inFromCl into two separate flags, say "inFromCl" and "inJoinSet".
The point of inFromCl is that when we add an implicit RTE using the
Postquel extension, it shouldn't suddenly become part of the available
namespace for unqualified column names processed later in the query.
So inFromCl controls the use of the RTE to look up unqualified names.
However, if we believe that the planner should subsequently treat that
implicit RTE as if it were a normal join target, then we need a separate
flag that carries that information.

This didn't use to be an issue, because the implicit RTE could only be
there if there were a Var reference to it; add_missing_vars_to_tlist()
should never need to do anything for it, because the RTE would have been
added to the join set already because of its Var, right? Well, that
*used* to be true up till last week. Now that we have a constant-
expression folder that understands about boolean and case expression
short-circuiting, it is possible for Var nodes to disappear from the
tree during optimization. It would be a bad thing if that changed the
join semantics. So, I think we need a flag that can force RTEs
to be included in the planner's join set regardless of whether their
Vars survive the optimizer. And that can't be the same as inFromCl,
or there's no such thing as an implicit RTE.

With this split, inFromCl would be looked at only by the parser code
that resolves unqualified names, and inJoinSet would be looked at
by add_missing_vars_to_tlist(). The rewriter's machinations would
only need to consider whether to set/clear inJoinSet or not.

(Thomas, does any of this strike a chord with your inner/outer join
stuff?)

regards, tom lane

From bouncefilter Mon Oct 4 21:49:47 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 VAA52080
for <pgsql-hackers@postgreSQL.org>; Mon, 4 Oct 1999 21:48: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 BAA23250;
Tue, 5 Oct 1999 01:48:44 GMT
Sender: lockhart@hub.org
Message-ID: <37F958FB.3A238C20@alumni.caltech.edu>
Date: Tue, 05 Oct 1999 01:48:43 +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: "G. Anthony Reina" <reina@nsi.edu>
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] MATLAB mex file for PostgreSQL
References: <37F8F914.CD20E5DC@nsi.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've written a little C mex file for MATLAB to interface to the my
PostgreSQL database.

I'll add it to the contrib area, unless someone else beats me to it.
Thanks.

- Thomas

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

From bouncefilter Tue Oct 5 01:31:58 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA84472
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 01:31:47 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by trends.net (8.8.8/8.8.8) with ESMTP id AAA11124
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 00:33:52 -0400 (EDT)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id AAA28614;
Tue, 5 Oct 1999 00:04:56 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910050404.AAA28614@candle.pha.pa.us>
Subject: Re: [HACKERS] Planner drops unreferenced tables --- bug, no?
In-Reply-To: <4083.939088008@sss.pgh.pa.us> from Tom Lane at "Oct 4,
1999 09:46:48 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 5 Oct 1999 00:04:56 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Actually, it would probably be cleanest if we split the functions of
inFromCl into two separate flags, say "inFromCl" and "inJoinSet".
The point of inFromCl is that when we add an implicit RTE using the
Postquel extension, it shouldn't suddenly become part of the available
namespace for unqualified column names processed later in the query.
So inFromCl controls the use of the RTE to look up unqualified names.
However, if we believe that the planner should subsequently treat that
implicit RTE as if it were a normal join target, then we need a separate
flag that carries that information.

Two different flags seems like the perfect way. Let me know if you need
any help adding the flag. I would be glad to do it.

-- 
  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 5 06:09:59 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id GAA21364
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 06:09:47 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 2306 invoked by uid 1001); 5 Oct 1999 10:09:48 -0000
Delivered-To: vev@paprika.michvhf.com
X-Received: (qmail 2124 invoked by alias); 5 Oct 1999 08:32:27 -0000
X-Received: from cinnamon.michvhf.com (209.57.60.10)
by paprika.michvhf.com with SMTP; 5 Oct 1999 08:32:27 -0000
X-Received: (qmail 6527 invoked by uid 201); 5 Oct 1999 08:32:20 -0000
Delivered-To: vev@cinnamon.michvhf.com
X-Received: (qmail 6516 invoked from network); 5 Oct 1999 08:32:18 -0000
X-Received: from basil.michvhf.com (209.57.60.17)
by cinnamon.michvhf.com with SMTP; 5 Oct 1999 08:32:18 -0000
X-Received: (qmail 27485 invoked by uid 1000); 5 Oct 1999 08:32:22 -0000
Delivered-To: vev@michvhf.com
X-Received: (qmail 27481 invoked by alias); 5 Oct 1999 08:32:21 -0000
X-Received: from hub.org (@216.126.84.1)
by basil.michvhf.com with SMTP; 5 Oct 1999 08:32:21 -0000
X-Received: from bom3.vsnl.net.in (bom3.vsnl.net.in [202.54.4.24])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA08147
for <webmaster@postgresql.org>; Tue, 5 Oct 1999 04:31:44 -0400 (EDT)
(envelope-from ugtech@bom3.vsnl.net.in)
X-Received: from Cosmos (PPP45-233.lvsb.vsnl.net.in [202.54.45.233])
by bom3.vsnl.net.in (8.9.0/8.9.0) with SMTP id OAA01483
for <webmaster@postgresql.org>; Tue, 5 Oct 1999 14:01:12 +0530 (IST)
Message-ID: <008601bf0f0d$3943cf40$030136ca@ugtech.com>
From: "Geeta Mahesh" <ugtech@bom3.vsnl.net.in>
To: <webmaster@postgreSQL.org>
Subject: initdb problem on sun solaris sparc
Date: Tue, 5 Oct 1999 14:10:03 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0083_01BF0F3B.517E1DD0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
ReSent-Date: Tue, 5 Oct 1999 06:09:41 -0400 (EDT)
ReSent-From: Vince Vielhaber <vev@michvhf.com>
ReSent-To: pgsql-hackers@postgreSQL.org
ReSent-Subject: initdb problem on sun solaris sparc
ReSent-Message-ID: <Pine.BSF.4.05.9910050609410.2191@paprika.michvhf.com>

This is a multi-part message in MIME format.

------=_NextPart_000_0083_01BF0F3B.517E1DD0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi..

I have installed postgreSQL 6.42 on Solaris sparc as per the =
instructions=20
given in readmesolaris.htm.
Now after installing successfully when I run initdb command I am getting
following error

$ initdb --username=3Dpgsql --pglib=3D/usr/local/pgsql/lib

ld.so.1: pg_id: fatal: libgen.so.1: open failed: No such file or =
directory
Unable to determine a valid username. If you are running
initdb without an explicit username specified, then there
may be a problem with finding the Postgres shared library
and/or the pg_id utility.

Please guide ..

Regards
Rajesh

------=_NextPart_000_0083_01BF0F3B.517E1DD0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>Hi.. I have installed postgreSQL 6.42 on =
Solaris sparc=20
as per the instructions given in readmesolaris.htm.</DIV>
<DIV>Now after installing successfully when I run initdb =
command I=20
am getting following error </DIV>
<DIV>$ initdb --username=3Dpgsql=20
--pglib=3D/usr/local/pgsql/lib</DIV>
<DIV> </DIV>
<DIV>ld.so.1: pg_id: fatal: libgen.so.1: open failed: No =
such file=20
or directory Unable to determine a valid username.  If you are=20
running initdb without an explicit username specified, then =
there may be a=20
problem with finding the Postgres shared library and/or the pg_id=20
utility.</DIV>
<DIV> </DIV>
<DIV>Please guide ..</DIV>
<DIV> </DIV>
<DIV>Regards</DIV>
<DIV>Rajesh</DIV></DIV></BODY></HTML>

------=_NextPart_000_0083_01BF0F3B.517E1DD0--

From bouncefilter Tue Oct 5 04:44:58 1999
Received: from oak.fernuni-hagen.de (oak.fernuni-hagen.de [132.176.114.41])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA09126
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 04:44:16 -0400 (EDT)
(envelope-from Jose-Antonio.Cotelo-Lema@FernUni-Hagen.de)
Received: from nansen.fernuni-hagen.de by oak.fernuni-hagen.de
via local-channel with SMTP; Tue, 5 Oct 1999 10:44:07 +0200
Received: from robinson.fernuni-hagen.de
by nansen.fernuni-hagen.de (SMI-8.6/SMI-SVR4) id KAA27848;
Tue, 5 Oct 1999 10:44:02 +0200
Received: from fernuni-hagen.de
by robinson.fernuni-hagen.de (SMI-8.6/SMI-SVR4) id KAA26474;
Tue, 5 Oct 1999 10:44:04 +0200
Sender: cotelo@FernUni-Hagen.de
Message-ID: <37F9BA53.683B9372@fernuni-hagen.de>
Date: Tue, 05 Oct 1999 10:44:03 +0200
From: Jose Antonio Cotelo lema <Jose-Antonio.Cotelo-Lema@FernUni-Hagen.de>
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL Hackers Mail List <pgsql-hackers@postgreSQL.org>
Subject: User types using large objects. Is it really possible?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

I am trying to implement a user type for PostgreSQL 6.5 whose size can
be arbitrarely large, so I am implementing it over a large oject.
However, I am getting in trobles with accessing to such large object
from the code of the data type functions (for example the in() and out()
fucntions) when this code is executed in the server side (as it happens
when the new type is registered in PostgreSQL). If I execute such
functions from a stand alone program, accessing to PostgreSQL as a
client aplication, and I add the command Qexec("begin") and Qexec("end")
to these functions (to access to the large object within a transaction,
otherwise I know it would not work), then I have no trouble accesing to
the large object ised by the data type. However, If I execute this code
in the server side (registering the new data type in PostgreSQL), I can
not execute the Qexec("begin") call (because both it would be wrong and
it fails), so as a result I get an error when trying to open the large
object.

The documentation of PostgreSQL says that for data types of more thatn
8Kb (even less) one needs to use large objects, but it says nothing
about how, so I assume the interface is the same than for stand alone
programs. But I do not get it working that way.

Is it a bug related with adding in PostgreSQL 6.5 the explicit
constraint that the access to a large object must be inside a
transaction, and forgetting something about the case of accessing to the
large object from the server side, or perhaps am I missing something?

I have not installed PostgreSQL 6.4.2, so I can not check whether before
adding the explicit constraint it was possible to access to the large
object from the server side with the code I have (This could discard my
hypotesis of a problem with the new constraint, if with previous
versions my code does not work either).

Any clue about the subject?

Thanks in advance,

Tony.

--
Jose Antonio Cotelo Lema. | Jose-Antonio.Cotelo-Lema@FernUni-Hagen.de
Praktische Informatik IV. Fernuniversitaet Hagen.
D-58084 Hagen. Germany.

From bouncefilter Tue Oct 5 05:24:02 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 FAA15483
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 05:23:01 -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 SAA00570; Tue, 05 Oct 1999 18:22:05 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>,
"Tom Lane" <tgl@sss.pgh.pa.us>
Subject: RE: [HACKERS] Recovery on incomplete write
Date: Tue, 5 Oct 1999 18:25:48 +0900
Message-ID: <000701bf0f13$9c0790c0$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
In-reply-to:
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: Tuesday, September 28, 1999 11:54 PM
To: Tom Lane
Cc: Hiroshi Inoue; pgsql-hackers
Subject: Re: [HACKERS] Recovery on incomplete write

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

I have wondered that md.c handles incomplete block(page)s
correctly.
Am I mistaken ?

I think you are right, and there may be some other trouble

spots in that

file too. I remember thinking that the code depended heavily on never
having a partial block at the end of the file.

But is it worth fixing? The only way I can see for the file length
to become funny is if we run out of disk space part way

through writing

a page, which seems unlikely...

That is how he got started, the TODO item about running out of disk
space causing corrupted databases. I think it needs a fix, if we can.

Maybe it isn't so difficult to fix.
I would provide a patch.

Here is a patch.

1) mdnblocks() ignores a partial block at the end of relation files.
2) mdread() ignores a partial block of block number 0.
3) mdextend() adjusts its position to a multiple of BLCKSZ
before writing.
4) mdextend() truncates extra bytes in case of incomplete write.

If there's no objection,I would commit this change to the current
tree.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

*** storage/smgr/md.c.orig	Thu Sep 30 10:50:58 1999
--- storage/smgr/md.c	Tue Oct  5 13:30:55 1999
***************
*** 233,239 ****
  int
  mdextend(Relation reln, char *buffer)
  {
! 	long		pos;
  	int			nblocks;
  	MdfdVec    *v;

--- 233,239 ----
  int
  mdextend(Relation reln, char *buffer)
  {
! 	long		pos, nbytes;
  	int			nblocks;
  	MdfdVec    *v;

***************
*** 243,250 ****
if ((pos = FileSeek(v->mdfd_vfd, 0L, SEEK_END)) < 0)
return SM_FAIL;

! if (FileWrite(v->mdfd_vfd, buffer, BLCKSZ) != BLCKSZ)
return SM_FAIL;

  	/* remember that we did a write, so we can sync at xact commit */
  	v->mdfd_flags |= MDFD_DIRTY;
--- 243,264 ----
  	if ((pos = FileSeek(v->mdfd_vfd, 0L, SEEK_END)) < 0)
  		return SM_FAIL;

! if (pos % BLCKSZ != 0) /* the last block is incomplete */
! {
! pos = BLCKSZ * (long)(pos / BLCKSZ);
! if (FileSeek(v->mdfd_vfd, pos, SEEK_SET) < 0)
! return SM_FAIL;
! }
!
! if ((nbytes = FileWrite(v->mdfd_vfd, buffer, BLCKSZ)) != BLCKSZ)
! {
! if (nbytes > 0)
! {
! FileTruncate(v->mdfd_vfd, pos);
! FileSeek(v->mdfd_vfd, pos, SEEK_SET);
! }
return SM_FAIL;
+ }

  	/* remember that we did a write, so we can sync at xact commit */
  	v->mdfd_flags |= MDFD_DIRTY;
***************
*** 432,437 ****
--- 446,453 ----
  	{
  		if (nbytes == 0)
  			MemSet(buffer, 0, BLCKSZ);
+ 		else if (blocknum == 0 && nbytes > 0 && mdnblocks(reln) == 0)
+ 			MemSet(buffer, 0, BLCKSZ);
  		else
  			status = SM_FAIL;
  	}
***************
*** 1067,1072 ****
  {
  	long		len;

! 	len = FileSeek(file, 0L, SEEK_END) - 1;
! 	return (BlockNumber) ((len < 0) ? 0 : 1 + len / blcksz);
  }
--- 1083,1088 ----
  {
  	long		len;

! len = FileSeek(file, 0L, SEEK_END);
! return (BlockNumber) (len / blcksz);
}

From bouncefilter Tue Oct 5 05:29:59 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 FAA16133
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 05:29:01 -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 SAA00575 for <pgsql-hackers@postgreSQL.org>;
Tue, 05 Oct 1999 18:29:00 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Questions about bufmgr
Date: Tue, 5 Oct 1999 18:32:44 +0900
Message-ID: <000801bf0f14$943495e0$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

Hi all,

I'm trying to fix a TODO item
* spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgr
.
But it's more difficult than I have thought.
IO_ERROR stuff in bufmgr.c has never been executed before
because of spinlock stuck abort.
As far as I see,I would have to change it.
Please help me.

Now I have a question about IO_IN_PROGRESS handling.

IO_IN_PROGRESS mask and io_in_progress_lock spinlock
are held while BufferAlloc() reads disk pages into buffer.

But seems they aren't held while writing buffers to disk,
We couldn't detect writing_IO_IN_PROGRESS and simultaneous
writing to a same page may occur.
No problem ?

And I have other questions which are irrevalent to the TODO item.

1. Why does BufferReplace() call smgrflush()(not smgrwrite()) ?
Are there any reasons that we couldn't postpone fsync() until
commit ?

2. Why does FlushRelationBuffers() call FlushBuffer() ?
Isn't it a overhead to call fsync() per page ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Oct 5 05:40:59 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 FAA17563
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 05:40:04 -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 RAA18101;
Tue, 5 Oct 1999 17:39:53 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37F9C766.1F753DC7@krs.ru>
Date: Tue, 05 Oct 1999 17:39:50 +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: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Questions about bufmgr
References: <000801bf0f14$943495e0$2801007e@cadzone.tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hiroshi Inoue wrote:

I'm trying to fix a TODO item
* spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgr

...

And I have other questions which are irrevalent to the TODO item.

1. Why does BufferReplace() call smgrflush()(not smgrwrite()) ?
Are there any reasons that we couldn't postpone fsync() until
commit ?

2. Why does FlushRelationBuffers() call FlushBuffer() ?
Isn't it a overhead to call fsync() per page ?

Pleeease don't touch bufmgr for the moment - it will be
changed due to WAL implementation. Currently I do data
base startup/shutdown stuff but will switch to bufmgr
in 1-2 days.

Vadim

From bouncefilter Tue Oct 5 05:49:59 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 FAA18667
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 05:49:22 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11YR81-0003kLC; Tue, 5 Oct 99 11:43 MET DST
Message-Id: <m11YR81-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Planner drops unreferenced tables --- bug, no?
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Tue, 5 Oct 1999 11:43:25 +0200 (MET DST)
Cc: wieck@debis.com, lockhart@alumni.caltech.edu, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <4083.939088008@sss.pgh.pa.us> from "Tom Lane" at Oct 4,
99 09:46:48 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Tom Lane wrote:

[...]

wieck@debis.com (Jan Wieck) writes:

Caution here!

After rewriting there can be many unused rangetable entries
floating around. Especially if you SELECT from a view, the
view's relation is still mentioned in the rangetable.

The other 50% of the problem is that the rewriter is overly enthusiastic
about clearing the inFromCl flag in order to prevent views from being
taken as valid join targets. rewriteHandler.c has two different
routines that will clear inFromCl flags, and they're both bogus:

[...]

Jan, what do you think of this? In particular, what do you think should
happen in the following cases:
1. Table has an ON SELECT *not* INSTEAD rule.
2. There is an ON SELECT (with or without INSTEAD) rule for one or
more fields of the table, but not for the whole table.

I'm not at all clear on the semantics of those kinds of rules, so I
don't know if they should remove the original table from the join set
or not. (I'm also confused about ON SELECT INSTEAD where the INSTEAD
is not a select; is that even legal?)

Also, would it be a good idea to propagate a source view's inFromCl
flag into the substituted tables? (That is, when firing a select rule
for a table that wasn't marked inFromCl to begin with, clear the
inFromCl flags of all RTEs that it adds to the query.) I am not sure
if this is appropriate or not.

Don't worry about it, those rules cannot occur and I'm sure
we'll never reincarnate them in the future.

The only allowed rule ON SELECT is one that

- IS INSTEAD
- is named "_RET<relation-name>"
- has one action which must be another SELECT with a
targetlist producing exactly the relations attribute list.

Again: If a relation has a rule ON SELECT, it IS A VIEW. No
relation can have more that one rule ON SELECT.

I've disabled all the other cases in RewriteDefine() on v6.4
- I think - because of the unclear semantics. Rules ON SELECT
where planned to have different actions or rewrite single
attributes too. But ON SELECT rules must be applied on all
relations which get scanned, so if there would be a rule ON
SELECT that inserts some logging into another relation, this
would actually occur ON UPDATE and ON DELETE to it's relation
too because to do the UPDATE/DELETE it's relation has to be
scanned.

I think it's correct to MOVE the inFromCl from the relation
rewritten to the join relations coming with the view's rule.
Thus clear it on the RTE rewritten and on the first two of
the rules (which are allways NEW and OLD for all rules). Then
set all other RTE's which come from the view to the former
inFromCl state of the rewritten RTE.

Jan

From bouncefilter Tue Oct 5 05:51:00 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 FAA19028
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 05:50:45 -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 SAA00585 for <pgsql-hackers@postgreSQL.org>;
Tue, 05 Oct 1999 18:50:43 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: How to add a new build-in operator
Date: Tue, 5 Oct 1999 18:54:28 +0900
Message-ID: <000901bf0f17$9d3f50a0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
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

Hi,

I'm planning to implement a new type of scan,scan by TID.
It's on TODO * Allow WHERE restriction on ctid.

First,I want to define an equal operator between TID.
Seems OID's 1700-1799 are reserved for numeric type.
Can I use 1800 as its OID ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Oct 5 07:52:01 1999
Received: from thelab.hub.org (nat194.229.mpoweredpc.net [142.177.194.229])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA33440
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 07:51:51 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id IAA32103;
Tue, 5 Oct 1999 08:52:07 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 5 Oct 1999 08:52:07 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
cc: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison
In-Reply-To: <7727DA5C1031.AAA74B8@smtp04.wxs.nl>
Message-ID: <Pine.BSF.4.10.9910050851050.17532-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Anyone want to comment on this one? Just tested with v6.5.0 and it still
exists there...

vhosts=> create table test ( a int, b char );
CREATE
vhosts=> insert into test values ( 1, 'a' );
INSERT 149258 1
vhosts=> select a from test group by a having a > 0;
ERROR: SELECT/HAVING requires aggregates to be valid

On Tue, 5 Oct 1999, Luuk de Boer wrote:

On 4 Oct 99, at 21:18, Bruce Momjian wrote:

<cut>

However, this is an old recollection, and I see on the current page that
this is no longer the case. The current page looks much better, though
somehow you show PostgreSQL doesn't have HAVING or support -- comments.
However, I realize such a test is a major project, and you are not going
to get everything right.

ps. I removed all the mailnglists to discuss some little things ...

hmmm do you mean having is now supported in postgresql. The
latest run of crash-me which I watched (last week I believe with
version 6.5.1) I believe I saw the message HAVING still not
supported in postgresql. Is that correct or did I do something wrong
with compiling postgres (just followed the normal procedure as
stated in the INSTALL file.

We have had HAVING since 6.3.* as I remember.

I looked into it this morning and found the following thing why crash-
me is saying that having is not supported.
We have a table (crash_me) with two columns (a (int)and b (char))
which are filled with one entry (1 and 'a').
The following thing is comming back to me ...
query3: select a from crash_me group by a having
a > 0

Got error from query: 'select a from crash_me
group by a having a > 0'
ERROR: SELECT/HAVING requires aggregates to be
valid

Checking connection
Having: no
Having with group function: query1: select a
from crash_me group by a having count(*) = 1
...(53)
yes
Order by alias: yes
Having on alias: query1: select a as ab from
crash_me group by a having ab > 0
...(53)

Got error from query: 'select a as ab from
crash_me group by a having ab > 0'
ERROR: attribute 'ab' not found

Checking connection
no

We had an if structure around testing having with group function if
having was supported and that if structure I removed.
Could you explain to me what's wrong to the above queries?

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 5 09:23:02 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 JAA45696
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 09:22:10 -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 NAA24345;
Tue, 5 Oct 1999 13:22:01 GMT
Sender: lockhart@hub.org
Message-ID: <37F9FB79.D3AA52B5@alumni.caltech.edu>
Date: Tue, 05 Oct 1999 13:22:01 +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: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] How to add a new build-in operator
References: <000901bf0f17$9d3f50a0$2801007e@cadzone.tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm planning to implement a new type of scan,scan by TID.
It's on TODO * Allow WHERE restriction on ctid.
First,I want to define an equal operator between TID.
Seems OID's 1700-1799 are reserved for numeric type.
Can I use 1800 as its OID ?

Certainly, or perhaps it would be better to recycle an OID from
farther down? We have some open values, and if you only need a few it
would work well.

You probably already know this, but just in case,

cd src/include/catalog
./unused_oids

will help you find some OIDs to use.

- Thomas

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

From bouncefilter Tue Oct 5 10:00:02 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 JAA49787
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 09:59:36 -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 NAA24388;
Tue, 5 Oct 1999 13:59:27 GMT
Sender: lockhart@hub.org
Message-ID: <37FA043E.E8ABA442@alumni.caltech.edu>
Date: Tue, 05 Oct 1999 13:59:27 +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: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-hackers@postgreSQL.org, Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
References: <Pine.BSF.4.10.9910050851050.17532-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anyone want to comment on this one? Just tested with v6.5.0 and it still
exists there...
vhosts=> create table test ( a int, b char );
CREATE
vhosts=> insert into test values ( 1, 'a' );
INSERT 149258 1
vhosts=> select a from test group by a having a > 0;
ERROR: SELECT/HAVING requires aggregates to be valid

Oh, don't get me started again on crashme :(

What is the purpose of the previous query? It seems to be equivalent
to

select distinct a where a > 0;

We do support the HAVING clause, but apparently disallow some
degenerate cases. If MySQL weren't just a toy db, perhaps they would
start putting real queries into their garbage crashme. There, I feel
better now ;)

postgres=> select b, avg(a) from test group by b having avg(a) > 0;
b|avg
-+---
a| 1
(1 row)

- Thomas

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

From bouncefilter Tue Oct 5 17:06:27 1999
Received: from hotmail.com (f236.law3.hotmail.com [209.185.241.236])
by hub.org (8.9.3/8.9.3) with SMTP id RAA08371
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 17:06:03 -0400 (EDT)
(envelope-from henrymolina@hotmail.com)
Received: (qmail 34708 invoked by uid 0); 5 Oct 1999 21:05:31 -0000
Message-ID: <19991005210531.34707.qmail@hotmail.com>
Received: from 216.72.7.52 by www.hotmail.com with HTTP;
Tue, 05 Oct 1999 14:05:31 PDT
X-Originating-IP: [216.72.7.52]
From: "Henry Molina" <henrymolina@hotmail.com>
To: pgsql-hackers@postgresql.org
Subject: Request inforamation
Date: Tue, 05 Oct 1999 14:05:31 PDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Hi,
I have problems witn postgres port to windows.

If I run "psql -p 5432 dataname" the psql cliente plug good.

But "telnet 192.168.100.2:5432" don't answer me.

The "ping" utility work good.

the pg_hba.conf file have the follow line:

host 192.168.100.10 255.255.255.0 trust

How can I read the port 5432???

thanks

Henry Molina
Bogota, Colombia

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From bouncefilter Tue Oct 5 10:10:03 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 KAA51123
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 10:09:25 -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 KAA10795;
Tue, 5 Oct 1999 10:08:16 -0400 (EDT)
To: wieck@debis.com (Jan Wieck)
cc: lockhart@alumni.caltech.edu, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Planner drops unreferenced tables --- bug, no?
In-reply-to: Your message of Tue, 5 Oct 1999 11:43:25 +0200 (MET DST)
<m11YR81-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Tue, 05 Oct 1999 10:08:16 -0400
Message-ID: <10793.939132496@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

I think it's correct to MOVE the inFromCl from the relation
rewritten to the join relations coming with the view's rule.
Thus clear it on the RTE rewritten and on the first two of
the rules (which are allways NEW and OLD for all rules). Then
set all other RTE's which come from the view to the former
inFromCl state of the rewritten RTE.

OK, I will do that. My first-cut code (attached, please look it over)
passes regress test without it, but we know how much that's worth ;-).

Actually I think moving inJoinSet is now the important thing...

regards, tom lane

All mention of inFromCl/inJoinSet removed from ApplyRetrieveRule;
fireRIRrules loop looks like:

rt_index = 0;
while (rt_index < length(parsetree->rtable))
{
++rt_index;

rte = nth(rt_index - 1, parsetree->rtable);

/*
* If the table is not one named in the original FROM clause
* then it must be referenced in the query, or we ignore it.
* This prevents infinite expansion loop due to new rtable
* entries inserted by expansion of a rule.
*/
if (! rte->inFromCl && rt_index != parsetree->resultRelation &&
! rangeTableEntry_used((Node *) parsetree, rt_index, 0))
{
/* Make sure the planner ignores it too... */
rte->inJoinSet = false;
continue;
}

rel = heap_openr(rte->relname, AccessShareLock);
rules = rel->rd_rules;
if (rules == NULL)
{
heap_close(rel, AccessShareLock);
continue;
}

locks = NIL;

/*
* Collect the RIR rules that we must apply
*/
for (i = 0; i < rules->numLocks; i++)
{
rule = rules->rules[i];
if (rule->event != CMD_SELECT)
continue;

if (rule->attrno > 0)
{
/* per-attr rule; do we need it? */
if (! attribute_used((Node *) parsetree,
rt_index,
rule->attrno, 0))
continue;
}
else
{
/* Rel-wide ON SELECT DO INSTEAD means this is a view.
* Remove the view from the planner's join target set,
* or we'll get no rows out because view itself is empty!
*/
if (rule->isInstead)
rte->inJoinSet = false;
}

locks = lappend(locks, rule);
}

/*
* Check permissions
*/
checkLockPerms(locks, parsetree, rt_index);

/*
* Now apply them
*/
foreach(l, locks)
{
rule = lfirst(l);

RIRonly.event = rule->event;
RIRonly.attrno = rule->attrno;
RIRonly.qual = rule->qual;
RIRonly.actions = rule->actions;

parsetree = ApplyRetrieveRule(parsetree,
&RIRonly,
rt_index,
RIRonly.attrno == -1,
rel,
&modified);
}

heap_close(rel, AccessShareLock);
}

From bouncefilter Tue Oct 5 10:48:03 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 KAA57505
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 10:47:42 -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 KAA10984;
Tue, 5 Oct 1999 10:46:31 -0400 (EDT)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org, Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-reply-to: Your message of Tue, 5 Oct 1999 08:52:07 -0300 (ADT)
<Pine.BSF.4.10.9910050851050.17532-100000@thelab.hub.org>
Date: Tue, 05 Oct 1999 10:46:31 -0400
Message-ID: <10982.939134791@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

The Hermit Hacker <scrappy@hub.org> writes:

Anyone want to comment on this one? Just tested with v6.5.0 and it still
exists there...

vhosts=> create table test ( a int, b char );
CREATE
vhosts=> insert into test values ( 1, 'a' );
INSERT 149258 1
vhosts=> select a from test group by a having a > 0;
ERROR: SELECT/HAVING requires aggregates to be valid

That's not a bug, it means what it says: HAVING clauses should contain
aggregate functions. Otherwise they might as well be WHERE clauses.
(In this example, flushing rows with negative a before the group step,
rather than after, is obviously a win, not least because it would
allow the use of an index on a.)

However, I can't see anything in the SQL92 spec that requires you to
use HAVING intelligently, so maybe this error should be downgraded to
a notice? "HAVING with no aggregates would be faster as a WHERE"
(but we'll do it anyway to satisfy pedants...)

regards, tom lane

From bouncefilter Tue Oct 5 10:59:03 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 KAA58825
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 10:58:42 -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 SAA11166
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 18:58:00 +0400 (MSD)
Date: Tue, 5 Oct 1999 18:58:00 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: pgsql-hackers@postgresql.org
Subject: 6.5.2 vacuum NOTICE messages
Message-ID: <Pine.GSO.3.96.SK.991005185227.4801Q-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

I have a cron job which vaccuming database every hour
(say for testing purposes) and sometimes I get following messages:

NOTICE: Index hits_pkey: NUMBER OF INDEX' TUPLES (10003) IS NOT THE SAME AS
HEAP' (10004)
NOTICE: Index hits_pkey: NUMBER OF INDEX' TUPLES (10003) IS NOT THE SAME AS
HEAP' (10004)

This happens on Linux 2.0.37, postgresql 6.5.2

What does it means ? Why it's happens not every time script runs ?
What's the best way to get rid off this problem except dump/reload ?

The script is here:

/usr/local/pgsql/bin/psql -tq discovery <vacuum_hits.sql

vacuum_hits.sql:

begin work;
vacuum analyze hits(msg_id);
drop index hits_pkey;
create unique index hits_pkey on hits(msg_id);
end work;

Regards,

Oleg

From bouncefilter Tue Oct 5 11:13:04 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 LAA61269
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 11:13:02 -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 LAA11127
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 11:12:30 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: CREATE RULE syntax simplification
Date: Tue, 05 Oct 1999 11:12:30 -0400
Message-ID: <11124.939136350@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

There are a couple of gripes in the pgsql-sql list this morning about
being unable to enter CREATE RULE commands that specify multiple
actions --- those folk are getting parser: parse error at or near ""
from what appears to be perfectly valid syntax. I suppose they are
getting burnt by a broken vendor-supplied yacc. But while looking at
this, I couldn't help noticing how crufty the syntax is:

RuleActionList: NOTHING { $$ = NIL; }
| SelectStmt { $$ = lcons($1, NIL); }
| RuleActionStmt { $$ = lcons($1, NIL); }
| '[' RuleActionBlock ']' { $$ = $2; }
| '(' RuleActionBlock ')' { $$ = $2; }
;

RuleActionBlock: RuleActionMulti { $$ = $1; }
| RuleActionStmt { $$ = lcons($1, NIL); }
;

RuleActionMulti: RuleActionMulti RuleActionStmt
{ $$ = lappend($1, $2); }
| RuleActionMulti RuleActionStmt ';'
{ $$ = lappend($1, $2); }
| RuleActionStmt ';'
{ $$ = lcons($1, NIL); }
;

RuleActionStmt: InsertStmt
| UpdateStmt
| DeleteStmt
| NotifyStmt
;

What's wrong with that you say? Well, it allows a RuleActionBlock to
be made up of RuleActionStmts that aren't separated by semicolons.
Specifically
stmt1 ; stmt2 stmt3 stmt4
has a production sequence.

I don't know if that was intentional or not, but it sure looks like
a shift/reduce conflict waiting to happen, as soon as the possible
RuleActionStmts get any more complicated. In any case, it's pretty
bizarre that a semi is only required after the first statement.

I suggest that we require separating semicolons and simplify the
RuleActionBlock production to a more conventional list style,

RuleActionBlock: RuleActionStmt
| RuleActionBlock ';' RuleActionStmt
| RuleActionBlock ';'

(the last alternative isn't normal list style, but it allows a trailing
semicolon which is accepted by the existing grammar).

Aside from forestalling future trouble with syntax extensions, this
might make us work a little better with old versions of yacc. I don't
know exactly why this area is a trouble spot for vendor yaccs, but it
seems to be. Simplifying the syntax may well help.

Comments? Anyone really in love with semicolon-less rule lists?

regards, tom lane

From bouncefilter Tue Oct 5 11:32:06 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 LAA64871
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 11:31:15 -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 LAA12762;
Tue, 5 Oct 1999 11:28:06 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910051528.LAA12762@candle.pha.pa.us>
Subject: Re: [HACKERS] How to add a new build-in operator
In-Reply-To: <000901bf0f17$9d3f50a0$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Oct 5, 1999 06:54:28 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 5 Oct 1999 11:28:06 -0400 (EDT)
CC: pgsql-hackers <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I'm planning to implement a new type of scan,scan by TID.
It's on TODO * Allow WHERE restriction on ctid.

First,I want to define an equal operator between TID.
Seems OID's 1700-1799 are reserved for numeric type.
Can I use 1800 as its OID ?

You can use any unused oid for your purposes.
-- 
  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 5 11:54:12 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA69467
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 11:53:41 -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 LAA13312;
Tue, 5 Oct 1999 11:50:13 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910051550.LAA13312@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <10982.939134791@sss.pgh.pa.us> from Tom Lane at "Oct 5,
1999 10:46:31 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 5 Oct 1999 11:50:13 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

That's not a bug, it means what it says: HAVING clauses should contain
aggregate functions. Otherwise they might as well be WHERE clauses.
(In this example, flushing rows with negative a before the group step,
rather than after, is obviously a win, not least because it would
allow the use of an index on a.)

However, I can't see anything in the SQL92 spec that requires you to
use HAVING intelligently, so maybe this error should be downgraded to
a notice? "HAVING with no aggregates would be faster as a WHERE"
(but we'll do it anyway to satisfy pedants...)

If we allow them, then people can do things like:

HAVING max(a) > b

which seems strange. Would we handle that?

-- 
  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 5 16:41:21 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA01440
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 16:39:53 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by trends.net (8.8.8/8.8.8) with ESMTP id OAA11846
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 14:11:15 -0400 (EDT)
Received: from uria.its.uu.se ([130.238.7.14]:4823 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.ryXwg250119>;
Tue, 5 Oct 1999 20:10:52 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2) id 11YZ4g-00005w-00
for pgsql-hackers@postgresql.org; Tue, 05 Oct 1999 20:12:30 +0200
Date: Tue, 5 Oct 1999 20:12:29 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgresql.org
Subject: psql Week 1
Message-ID: <Pine.LNX.4.10.9910052008410.367-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

Here's the summary of my wheelings and dealings. No code yet, but trust
me, you don't want it.

* Changed one file into many
* Changed few functions into countless
* Added GNU long option support (added test to configure.in,
definition to config.h.in)
[ This feature is under protest by Tom L. ]
* Extra arguments are now taken as dbname and username
(it used to fail if you have more than one extra)
* Added switch -V (--version) to display client and server version and
warn about possible incompatibilities
* Added \copyright command. Changed welcome message accordingly.
* Added a few long slash commands equivalent to short ones (e.g.,
\list = \l)
* Rewrote backslash command parser from scratch. Can now quote
arguments. (Only doublequotes. Single quotes to come.)
* Added message output channel as alternative to query output and
stderr. Might be useful to funnel output in scripts.
* SQL command help is now generated directly from the SGML sources at
build time.
[ Must have perl. Might be a problem on Windows. Perhaps package
preparsed version as well. ]
* \connect now asks for password when appropriate
* Added switch -U allowing you to specify username on cmd line
* -? prints out default username, host, port, etc. in help screen
* PSQLRC env variable can override the name of your startup script
* PSQL_EDITOR can set your prefered editor for \e and \E (overriding
EDITOR and VISUAL)
* Fixed flat tire on bike ...
* when \connect fails, it now keeps the previous connection (formerly
aborted program)
* Custom prompts in tcsh style
(No, I am not partial to tcsh. In fact, I don't even use it. But
using % as escape character rather than \ saves a lot of headaches.)
* Increased abstraction of input routines.
[ Cheers to Matthew D.! ]
* Started to clean up \copy. Can now specify delimiters and "with
oids". Still needs some work though, especially regarding binary and
quoting/escaping. I'll probably end up writing a better strtok()
before this is all over.

More in a week . . .

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

From bouncefilter Tue Oct 5 16:41:37 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA01486
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 16:39:57 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by trends.net (8.8.8/8.8.8) with ESMTP id OAA12016
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 14:13:47 -0400 (EDT)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id OAA22735;
Tue, 5 Oct 1999 14:13:17 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910051813.OAA22735@candle.pha.pa.us>
Subject: Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison
In-Reply-To: From "(env:" "maillist)" at "Oct 5, 1999 11:39:29 am"
To: maillist@candle.pha.pa.us
Date: Tue, 5 Oct 1999 14:13:17 -0400 (EDT)
CC: luuk@wxs.nl, "The Hermit Hacker"@candle.pha.pa.us, scrappy@hub.org,
PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM939147197-13140-0_
Content-Transfer-Encoding: 7bit

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

hmmm that's strange. I tested this also this morning with a pretty
simple program. I will attach the program to this email and place
the output here. It's a quiet simple program. Just create a table, fill
it and do select * from test1 -- comment ...and see what it does.
This is the output:

DBD::Pg::st execute failed: ERROR: parser:
parse error at or near "-"
DBD::Pg::st fetchrow_array failed: no statement
executing
can't execute -- comment: ERROR: parser: parse
error at or near "-"

this is why I thought it was done in the front end and not in the
backend. Is there a way to solve this. PS the comment with /* */ is
going okay this way.

I just connected to the backend and did it directly, and it worked:

postgres -D /u/pg/data test

POSTGRES backend interactive interface
$Revision: 1.130 $ $Date: 1999/09/29 16:06:10 $

backend> select * from test1 -- comment
blank
1: x (typeid = 23, len = 4, typmod = -1, byval = t)
----
backend>

So, there must be something in the perl interface that is causing the
problem. I don't have pgperl defined here, so I am not sure, but I can
record it as a bug.

Now, if I do this:

backend> -- testssdf
ERROR: parser: parse error at or near ""
ERROR: parser: parse error at or near ""

it shouldn't throw an error, but it does. psql doesn't mind it, though.
Strange. Same with /* lkjas;ldfjk */. Seems we have a bug there
because non-psql interfaces can send these queries.

OK, I am applying the following patch to fix the above problem. The old
code, which I wrote, took care of trailing semicolons, but did not
really fix the problems of comment-only lines, and lines containing many
semicolons next to each other. This code is much cleaner, and
regression tests seem to like it.

I know this problem was reported before, and Thomas had made some
comment about needing it fixed.

This will be applied to 6.6 only. Seems to dangerous for 6.5.*.

[Not sure if the perl test is going to be OK after this fix. Looks like
something inside perl may be the problem. Maybe there is some code in
the perl interface to strip out -- comments? ]

-- 
  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
echo: cannot create /dev/ttyp5: permission denied

--ELM939147197-13140-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/bjm/diff"
Content-Transfer-Encoding: 7bit

Index: gram.y
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/gram.y,v
retrieving revision 2.106
diff -c -r2.106 gram.y
*** gram.y	1999/10/03 23:55:30	2.106
--- gram.y	1999/10/05 18:01:41
***************
*** 365,384 ****
  %left		UNION INTERSECT EXCEPT
  %%

! stmtblock: stmtmulti opt_semi
{ parsetree = $1; }
;

stmtmulti: stmtmulti ';' stmt
! { $$ = lappend($1, $3); }
| stmt
! { $$ = lcons($1,NIL); }
;

- opt_semi:	';'
- 		|	/*EMPTY*/
- 		;
- 		
  stmt :	  AddAttrStmt
  		| AlterUserStmt
  		| ClosePortalStmt
--- 365,393 ----
  %left		UNION INTERSECT EXCEPT
  %%

! /*
! * Handle comment-only lines, and ;; SELECT * FROM pg_class ;;;
! * psql already handles such cases, but other interfaces don't.
! * bjm 1999/10/05
! */
! stmtblock: stmtmulti
{ parsetree = $1; }
;

stmtmulti: stmtmulti ';' stmt
! { if ($3 != (Node *)NIL)
! $$ = lappend($1, $3);
! else
! $$ = $1;
! }
| stmt
! { if ($1 != (Node *)NIL)
! $$ = lcons($1,NIL);
! else
! $$ = (Node *)NIL;
! }
;

  stmt :	  AddAttrStmt
  		| AlterUserStmt
  		| ClosePortalStmt
***************
*** 423,428 ****
--- 432,439 ----
  		| VariableShowStmt
  		| VariableResetStmt
  		| ConstraintsSetStmt
+ 		|	/*EMPTY*/
+ 				{ $$ = (Node *)NIL; }
  		;

/*****************************************************************************

--ELM939147197-13140-0_

--ELM939147197-13140-0_--

From bouncefilter Wed Oct 6 12:15:28 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA92747
for <pgsql-hackers@postgresql.org>; Wed, 6 Oct 1999 12:14:31 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:2482 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.ryrJF215324>;
Wed, 6 Oct 1999 18:14:09 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11Yb8Z-0000P1-00; Tue, 05 Oct 1999 22:24:39 +0200
Date: Tue, 5 Oct 1999 22:24:39 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgresql.org,
Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <10982.939134791@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.10.9910052218490.1358-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 5, Tom Lane mentioned:

However, I can't see anything in the SQL92 spec that requires you to
use HAVING intelligently, so maybe this error should be downgraded to
a notice? "HAVING with no aggregates would be faster as a WHERE"
(but we'll do it anyway to satisfy pedants...)

Oh please God, NO! The next thing they want is SELECT FROM HAVING to
replace WHERE. That is merely the reverse case of what you so humbly
suggested. HAVING doesn't stand after GROUP BY for no reason, AFAIC.

Of course personally, I would love to kill SQL altogether and invent
something better, but not by the end of this day . . .

Peter

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e/

From bouncefilter Wed Oct 6 12:15:24 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA92720
for <pgsql-hackers@postgresql.org>; Wed, 6 Oct 1999 12:14:22 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:2473 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.ryrJ6207132>;
Wed, 6 Oct 1999 18:14:00 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11YbEK-0000P3-00; Tue, 05 Oct 1999 22:30:36 +0200
Date: Tue, 5 Oct 1999 22:30:35 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Error messages (was Re: [HACKERS] Tricky query, tricky response)
In-Reply-To: <20890.938969598@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.10.9910052225590.1358-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 3, Tom Lane mentioned:

Peter Eisentraut <peter_e@gmx.net> writes:

Anyway, I thought wouldn't a more, um, user-friendly error message like
ERROR: Subselects are not allowed in target list.
be more desirable than
ERROR: flatten_tlistentry: Cannot handle node type 108

Yes, it would. Are you volunteering to try to make that happen?

Hmm, I'll put it on the List O' Things to consider right after I clear out
all the crap that has accumulated in psql over the years which will take
an unpredictable amount of time still.

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e/

From bouncefilter Wed Oct 6 12:15:24 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA92759
for <pgsql-hackers@postgresql.org>; Wed, 6 Oct 1999 12:14:41 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:2489 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.ryrJO229658>;
Wed, 6 Oct 1999 18:14:18 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11YbSH-0000PN-00; Tue, 05 Oct 1999 22:45:01 +0200
Date: Tue, 5 Oct 1999 22:45:01 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Message-ID: <Pine.LNX.4.10.9910052235030.1358-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

Tom, I suspect that this is your work:
./psql: error in loading shared libraries : undefined symbol:
createPQExpBuffer

which happens if you run several versions of everything all at once and
forget to set all your lib paths right.

How about version numbering libpq properly? It has been 2.0 ever since I
can remember (not very long :). At least do ++0.0.1 when you change
something. Is there any particular reason why this is not done?

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e/

From bouncefilter Tue Oct 5 17:11:27 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 RAA09624
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 17:11:05 -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 BAA20321;
Wed, 6 Oct 1999 01:10:22 +0400 (MSD)
Date: Wed, 6 Oct 1999 01:10:21 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql Week 1
In-Reply-To: <Pine.LNX.4.10.9910052008410.367-100000@peter-e.yi.org>
Message-ID: <Pine.GSO.3.96.SK.991006010738.4801T-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Peter,

what I miss on pgsql is ability to keep commands I issued in history file
as bash does for example. Say, ~/.pgsqlhistory
Of course, not to save passwords.

Regards,
Oleg

On Tue, 5 Oct 1999, Peter Eisentraut wrote:

Date: Tue, 5 Oct 1999 20:12:29 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] psql Week 1

Here's the summary of my wheelings and dealings. No code yet, but trust
me, you don't want it.

* Changed one file into many
* Changed few functions into countless
* Added GNU long option support (added test to configure.in,
definition to config.h.in)
[ This feature is under protest by Tom L. ]
* Extra arguments are now taken as dbname and username
(it used to fail if you have more than one extra)
* Added switch -V (--version) to display client and server version and
warn about possible incompatibilities
* Added \copyright command. Changed welcome message accordingly.
* Added a few long slash commands equivalent to short ones (e.g.,
\list = \l)
* Rewrote backslash command parser from scratch. Can now quote
arguments. (Only doublequotes. Single quotes to come.)
* Added message output channel as alternative to query output and
stderr. Might be useful to funnel output in scripts.
* SQL command help is now generated directly from the SGML sources at
build time.
[ Must have perl. Might be a problem on Windows. Perhaps package
preparsed version as well. ]
* \connect now asks for password when appropriate
* Added switch -U allowing you to specify username on cmd line
* -? prints out default username, host, port, etc. in help screen
* PSQLRC env variable can override the name of your startup script
* PSQL_EDITOR can set your prefered editor for \e and \E (overriding
EDITOR and VISUAL)
* Fixed flat tire on bike ...
* when \connect fails, it now keeps the previous connection (formerly
aborted program)
* Custom prompts in tcsh style
(No, I am not partial to tcsh. In fact, I don't even use it. But
using % as escape character rather than \ saves a lot of headaches.)
* Increased abstraction of input routines.
[ Cheers to Matthew D.! ]
* Started to clean up \copy. Can now specify delimiters and "with
oids". Still needs some work though, especially regarding binary and
quoting/escaping. I'll probably end up writing a better strtok()
before this is all over.

More in a week . . .

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

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

From bouncefilter Tue Oct 5 17:13:28 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA09856
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 17:12:35 -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 RAA26875;
Tue, 5 Oct 1999 17:11:34 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910052111.RAA26875@candle.pha.pa.us>
Subject: Re: [HACKERS] Database names with spaces
In-Reply-To: <Pine.LNX.4.10.9910041528220.2276-100000@peter-e.yi.org> from
Peter Eisentraut at "Oct 4, 1999 04:03:34 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 5 Oct 1999 17:11:34 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Looks like bug to me.

I see a todo item
* Views with spaces in view name fail when referenced

I have another one for you:
* Databases with spaces in name fail to be created and destroyed despite
responses to the contrary.

A sample session:
template1=> create database "with space";
CREATEDB
template1=> \q
$ psql -d "with space"
Connection to database 'with space' failed.
FATAL 1: InitPostgres could not validate that the database version is
compatible with this level of Postgres
even though the database system as a whole appears to be at a
compatible level.
You may need to recreate the database with SQL commands DROP
DATABASE and CREATE DATABASE.
File '/usr/local/pgsql/data/base/with space/PG_VERSION' does not
exist or no read permission.

(You can't do \c with space or \c "with space" yet. That will be (is) in
the new version.)

Further investigation shows that the directory
/usr/local/pgsql/data/base/with space is totally empty.

But:
template1=> select * from pg_database;
datname |datdba|encoding|datpath
----------+------+--------+----------
template1 | 100| 0|template1
. . .
with space| 101| 0|with space
(4 rows)

template1=> drop database "with space";
DESTROYDB

Yet, the mysterious empty directory is still there.

BUG?

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

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

-- 
  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 5 17:14:27 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA09980
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 17:13:29 -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 RAA26882;
Tue, 5 Oct 1999 17:11:50 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910052111.RAA26882@candle.pha.pa.us>
Subject: Re: [HACKERS] Database names with spaces
In-Reply-To: <Pine.LNX.4.10.9910041528220.2276-100000@peter-e.yi.org> from
Peter Eisentraut at "Oct 4, 1999 04:03:34 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 5 Oct 1999 17:11:50 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Looks like a bug. Added to TODO list.

I see a todo item
* Views with spaces in view name fail when referenced

I have another one for you:
* Databases with spaces in name fail to be created and destroyed despite
responses to the contrary.

A sample session:
template1=> create database "with space";
CREATEDB
template1=> \q
$ psql -d "with space"
Connection to database 'with space' failed.
FATAL 1: InitPostgres could not validate that the database version is
compatible with this level of Postgres
even though the database system as a whole appears to be at a
compatible level.
You may need to recreate the database with SQL commands DROP
DATABASE and CREATE DATABASE.
File '/usr/local/pgsql/data/base/with space/PG_VERSION' does not
exist or no read permission.

(You can't do \c with space or \c "with space" yet. That will be (is) in
the new version.)

Further investigation shows that the directory
/usr/local/pgsql/data/base/with space is totally empty.

But:
template1=> select * from pg_database;
datname |datdba|encoding|datpath
----------+------+--------+----------
template1 | 100| 0|template1
. . .
with space| 101| 0|with space
(4 rows)

template1=> drop database "with space";
DESTROYDB

Yet, the mysterious empty directory is still there.

BUG?

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

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

-- 
  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 5 17:33:28 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA13379
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 17:32:32 -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 RAA28373;
Tue, 5 Oct 1999 17:30:37 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910052130.RAA28373@candle.pha.pa.us>
Subject: Re: [HACKERS] psql Week 1
In-Reply-To: <Pine.GSO.3.96.SK.991006010738.4801T-100000@ra> from Oleg
Bartunov
at "Oct 6, 1999 01:10:21 am"
To: Oleg Bartunov <oleg@sai.msu.su>
Date: Tue, 5 Oct 1999 17:30:37 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Peter,

what I miss on pgsql is ability to keep commands I issued in history file
as bash does for example. Say, ~/.pgsqlhistory
Of course, not to save passwords.

readline has the capability. We would just need to enable it. Good
idea.

-- 
  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 5 18:08:28 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 SAA17338
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 18:07:39 -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 SAA12369;
Tue, 5 Oct 1999 18:05:30 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-reply-to: Your message of Tue, 5 Oct 1999 11:50:13 -0400 (EDT)
<199910051550.LAA13312@candle.pha.pa.us>
Date: Tue, 05 Oct 1999 18:05:30 -0400
Message-ID: <12367.939161130@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

However, I can't see anything in the SQL92 spec that requires you to
use HAVING intelligently, so maybe this error should be downgraded to
a notice? "HAVING with no aggregates would be faster as a WHERE"
(but we'll do it anyway to satisfy pedants...)

If we allow them, then people can do things like:
HAVING max(a) > b

Er ... what's wrong with that? Assuming b is a group by column,
of course...

regards, tom lane

From bouncefilter Tue Oct 5 18:20:28 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA18631
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 18:19:11 -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 SAA29400;
Tue, 5 Oct 1999 18:16:38 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910052216.SAA29400@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <12367.939161130@sss.pgh.pa.us> from Tom Lane at "Oct 5,
1999 06:05:30 pm"
To: "Tom Lane"@candle.pha.pa.us, tgl@sss.pgh.pa.us, luuk@wxs.nl
Date: Tue, 5 Oct 1999 18:16:38 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

However, I can't see anything in the SQL92 spec that requires you to
use HAVING intelligently, so maybe this error should be downgraded to
a notice? "HAVING with no aggregates would be faster as a WHERE"
(but we'll do it anyway to satisfy pedants...)

If we allow them, then people can do things like:
HAVING max(a) > b

Er ... what's wrong with that? Assuming b is a group by column,
of course...

But can we compare aggs and non-aggs? I see now that our code is fine:

select relowner
from pg_class
group by relowner
having max(relowner) = relowner;

This returns the proper result, namely the relowner _having_ the max
id.

Having is using an aggregate and non-aggregate, so when I said we only
support aggregates in the HAVING clause, I was wrong. Looks fine.

-- 
  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 5 18:31:28 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 SAA20230
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 18:30:55 -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 SAA12472;
Tue, 5 Oct 1999 18:29:45 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: luuk@wxs.nl, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-reply-to: Your message of Tue, 5 Oct 1999 18:16:38 -0400 (EDT)
<199910052216.SAA29400@candle.pha.pa.us>
Date: Tue, 05 Oct 1999 18:29:45 -0400
Message-ID: <12470.939162585@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

But can we compare aggs and non-aggs? I see now that our code is fine:

No, you're barking up the wrong tree. The issue is whether a HAVING
clause that doesn't contain *any* aggregates is legal/reasonable.
It can contain non-aggregated references to GROUP BY columns in
any case. But without aggregates, there's no semantic difference
from putting the same condition in WHERE.

I believe that planner.c currently has an implementation assumption
that HAVING must have an aggregate (because it hangs the HAVING clause
onto the Agg plan node as a qual clause --- if no Agg node, no place to
perform the HAVING test). This could be fixed if we felt it was worth
doing.

I can't get excited about changing this from the standpoint of
functionality, because AFAICS there is no added functionality.
But if we're looking bad on a recognized benchmark maybe we
should do something about it.

regards, tom lane

From bouncefilter Tue Oct 5 18:35:28 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA20754
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 18:34:39 -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 SAA29584;
Tue, 5 Oct 1999 18:34:07 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910052234.SAA29584@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <12470.939162585@sss.pgh.pa.us> from Tom Lane at "Oct 5,
1999 06:29:45 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 5 Oct 1999 18:34:07 -0400 (EDT)
CC: luuk@wxs.nl, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

But can we compare aggs and non-aggs? I see now that our code is fine:

No, you're barking up the wrong tree. The issue is whether a HAVING
clause that doesn't contain *any* aggregates is legal/reasonable.
It can contain non-aggregated references to GROUP BY columns in
any case. But without aggregates, there's no semantic difference
from putting the same condition in WHERE.

I believe that planner.c currently has an implementation assumption
that HAVING must have an aggregate (because it hangs the HAVING clause
onto the Agg plan node as a qual clause --- if no Agg node, no place to
perform the HAVING test). This could be fixed if we felt it was worth
doing.

I can't get excited about changing this from the standpoint of
functionality, because AFAICS there is no added functionality.
But if we're looking bad on a recognized benchmark maybe we
should do something about it.

Agreed. I think there are too many people who get HAVING confused to
allow it. Better that we should prevent it and make them do it right.

-- 
  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 5 18:44:28 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 SAA22318
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 18:43: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 SAA12510;
Tue, 5 Oct 1999 18:42:31 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Database names with spaces
In-reply-to: Your message of Tue, 5 Oct 1999 17:11:50 -0400 (EDT)
<199910052111.RAA26882@candle.pha.pa.us>
Date: Tue, 05 Oct 1999 18:42:31 -0400
Message-ID: <12508.939163351@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Looks like a bug. Added to TODO list.

I see a todo item
* Views with spaces in view name fail when referenced

I have another one for you:
* Databases with spaces in name fail to be created and destroyed despite
responses to the contrary.

IIRC, createdb and destroydb use "cp -r" and "rm -r" respectively.
Lack of careful quoting in the system calls is probably what's
causing the problem here.

However, I wonder if it wouldn't be a better idea to forbid funny
characters in things that will become Unix filenames. In particular,
something like CREATE DATABASE "../../../something" could have real
bad consequences...

regards, tom lane

From bouncefilter Tue Oct 5 22:11:08 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA41120
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 22:10:51 -0400 (EDT)
(envelope-from vadim@krs.ru)
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by trends.net (8.8.8/8.8.8) with ESMTP id VAA03335
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 21:17:21 -0400 (EDT)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id JAA21438;
Wed, 6 Oct 1999 09:16:36 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37FAA2F4.4F45EDA4@krs.ru>
Date: Wed, 06 Oct 1999 09:16:36 +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: Oleg Bartunov <oleg@sai.msu.su>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 6.5.2 vacuum NOTICE messages
References: <Pine.GSO.3.96.SK.991005185227.4801Q-100000@ra>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oleg Bartunov wrote:

Hi,

I have a cron job which vaccuming database every hour
(say for testing purposes) and sometimes I get following messages:

NOTICE: Index hits_pkey: NUMBER OF INDEX' TUPLES (10003) IS NOT THE SAME AS
HEAP' (10004)
NOTICE: Index hits_pkey: NUMBER OF INDEX' TUPLES (10003) IS NOT THE SAME AS
HEAP' (10004)

This happens on Linux 2.0.37, postgresql 6.5.2

What does it means ? Why it's happens not every time script runs ?
What's the best way to get rid off this problem except dump/reload ?

Re-build indices.

The script is here:

/usr/local/pgsql/bin/psql -tq discovery <vacuum_hits.sql

vacuum_hits.sql:

begin work;
vacuum analyze hits(msg_id);

You MUST NOT run vacuum inside BEGIN/END!

drop index hits_pkey;
create unique index hits_pkey on hits(msg_id);
end work;

Vadim

From bouncefilter Tue Oct 5 21:25:34 1999
Received: from thelab.hub.org (nat194.229.mpoweredpc.net [142.177.194.229])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA37694
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 21:25:09 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA36982;
Tue, 5 Oct 1999 22:23:14 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 5 Oct 1999 22:23:13 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org, luuk@wxs.nl,
Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <10982.939134791@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9910052215260.17532-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Luuk...

I brought this up with the -hackers list, and, in generally, it
appears to be felt that the query, which you use in the crashme test to
test HAVING, isn't necessarily valid ...

Basically:

select a from test group by a having a > 0;

could be more efficiently written as:

select a from test where a > 0 group by a;

I'm personally curious, though...how does Oracle/Informix and
other RDBMS systems handle this? Do they let it pass, or do they give an
error also?

I think the general concensus, at this time, is to change the
ERROR to a NOTICE, with a comment that using a WHERE would be more
efficient then the HAVING...and, unless someone can come up with an
instance that would make sense (ie. why you'd do it with HAVING vs WHERE),
I'm in agreement with them...

Since we obviously do support HAVING, and, I believe, follow the
SQL92 spec on it, is there any way of getting the crashme test fixed to
not use the above query as a basis for whether an RDBMS supports HAVING or
not?

thanks...

On Tue, 5 Oct 1999, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

Anyone want to comment on this one? Just tested with v6.5.0 and it still
exists there...

vhosts=> create table test ( a int, b char );
CREATE
vhosts=> insert into test values ( 1, 'a' );
INSERT 149258 1
vhosts=> select a from test group by a having a > 0;
ERROR: SELECT/HAVING requires aggregates to be valid

That's not a bug, it means what it says: HAVING clauses should contain
aggregate functions. Otherwise they might as well be WHERE clauses.
(In this example, flushing rows with negative a before the group step,
rather than after, is obviously a win, not least because it would
allow the use of an index on a.)

However, I can't see anything in the SQL92 spec that requires you to
use HAVING intelligently, so maybe this error should be downgraded to
a notice? "HAVING with no aggregates would be faster as a WHERE"
(but we'll do it anyway to satisfy pedants...)

regards, tom lane

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 5 22:48:03 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id WAA60212
for <hackers@postgresql.org>; Tue, 5 Oct 1999 22:47:38 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 10136 invoked by uid 1001); 6 Oct 1999 02:47:42 -0000
Message-ID: <XFMail.991005224742.vev@michvhf.com>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Tue, 05 Oct 1999 22:47:42 -0400 (EDT)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: hackers@postgresql.org
Subject: libpq++ doc error?

I'm beginning to think I created my own error! After looking over the
sources I'm thinking I did the cut-n-paste from the same source but a
different function (if that makes sense).

I just sent patches for libpq++ to return an int (I'll also submit changes
to the sgml docs) and return a -1 if PQcmdTuples() returns a NULL pointer.
I just haven't been able to convince it to return a NULL.

From bouncefilter Tue Oct 5 23:11:04 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA66111
for <pgsql-hackers@postgresql.org>; Tue, 5 Oct 1999 23:10:39 -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 XAA05984;
Tue, 5 Oct 1999 23:08:47 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910060308.XAA05984@candle.pha.pa.us>
Subject: Re: [HACKERS] Database names with spaces
In-Reply-To: <12508.939163351@sss.pgh.pa.us> from Tom Lane at "Oct 5,
1999 06:42:31 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 5 Oct 1999 23:08:47 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Looks like a bug. Added to TODO list.

I see a todo item
* Views with spaces in view name fail when referenced

I have another one for you:
* Databases with spaces in name fail to be created and destroyed despite
responses to the contrary.

IIRC, createdb and destroydb use "cp -r" and "rm -r" respectively.
Lack of careful quoting in the system calls is probably what's
causing the problem here.

However, I wonder if it wouldn't be a better idea to forbid funny
characters in things that will become Unix filenames. In particular,
something like CREATE DATABASE "../../../something" could have real
bad consequences...

I just tried it:

test=> create database "../../pg_hba.conf"
test-> \g
ERROR: Unable to locate path '../../pg_hba.conf'
This may be due to a missing environment variable in the server

Seems we are safe.

-- 
  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 5 23:17:04 1999
Received: from roberts.dialup.access.net (IDENT:root@roberts.dialup.access.net
[166.84.193.218]) by hub.org (8.9.3/8.9.3) with ESMTP id XAA67259
for <pgsql-hackers@postgreSQL.org>; Tue, 5 Oct 1999 23:16:32 -0400 (EDT)
(envelope-from roberts@panix.com)
Received: (from roland@localhost)
by roberts.dialup.access.net (8.9.3/8.9.3) id XAA28076;
Tue, 5 Oct 1999 23:16:30 -0400
Sender: roland@tycho.rlent.pnet
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql Week 1
References: <Pine.LNX.4.10.9910052008410.367-100000@peter-e.yi.org>
Reply-To: roberts@panix.com
From: Roland Roberts <roberts@panix.com>
Date: 05 Oct 1999 23:16:30 -0400
In-Reply-To: Peter Eisentraut's message of "Tue,
5 Oct 1999 20:12:29 +0200 (CEST)"
Message-ID: <m2iu4lkwkx.fsf@tycho.rlent.pnet>
Lines: 27
X-Mailer: Gnus v5.7/Emacs 20.4

-----BEGIN PGP SIGNED MESSAGE-----

Peter> * \connect now asks for password when appropriate

Does this include the initial connect? I has password authentication
enabled and think it would be nice if psql just prompted me rather
than failed....

roland
- --
PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD Custom Software Solutions
roberts@panix.com 76-15 113th Street, Apt 3B
rbroberts@acm.org Forest Hills, NY 11375

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface

iQCVAwUBN/q/B+oW38lmvDvNAQHUwwP/dLhX5AP05+v1lcpVEzx3gSK+9vWxySfx
lK521D3fsMrWmUQOYn0mqEtLPv/bVUcYgAT+rL3L6dPdvXAHNg1rz64dmZwcsHhy
Erm7GSH4OfCh6msNAhlF0vwgJQams+uRTbYf9AZ3UA6OBgTUCrQ3zR7Q4PSVM9O+
+v2y2Y+FJlo=
=hgOk
-----END PGP SIGNATURE-----

From bouncefilter Wed Oct 6 01:00:16 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 AAA84849
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 00:59:23 -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 AAA17143;
Wed, 6 Oct 1999 00:59:21 -0400 (EDT)
Date: Wed, 6 Oct 1999 00:59:21 -0400 (EDT)
From: "Matthew N. Dodd" <winter@jurai.net>
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql Week 1
In-Reply-To: <Pine.LNX.4.10.9910052008410.367-100000@peter-e.yi.org>
Message-ID: <Pine.BSF.4.10.9910060057560.25333-100000@sasami.jurai.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 5 Oct 1999, Peter Eisentraut wrote:

* when \connect fails, it now keeps the previous connection (formerly
aborted program)

This is bad.

Consider some process that connects to various DBs and does stuff like
drop foo.

If connect fails assume that the user no longer wanted to be connected to
the old connection.

From bouncefilter Wed Oct 6 02:01:17 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 CAA91372
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 02:01:06 -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 BAA23414;
Wed, 6 Oct 1999 01:53:03 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910060553.BAA23414@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <7727DABD11F8.AAB3CE2@smtp01.wxs.nl> from Luuk de Boer at "Oct 6,
1999 07:51:27 am"
To: luuk@wxs.nl
Date: Wed, 6 Oct 1999 01:53:03 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thanks bruce and hermit for all the comments,
I looked into the book "The SQL Standard" fourth edition of Date
and in the appendixes page 439 they have an example which they
discuss. The example is: select count(*) as x from mt having 0 = 0;
with an empty table they say logically correct it should return one
column and no rows but sql gives a table of one column and one
row. So I think it's true that HAVING has to have an aggregation
but it will also be possible use a non-aggregation.

If I look in our crash-me output page (this is a handy thing for this
kind of questions) and look for all the other db's to see what they
do I can say the following thing:
Informix,Access,Adabas,db2,empress,ms-sql,oracle,solid and
sybase are all supporting non-aggregation in having clause.
At this moment everyone except postgres is supporting it.

The change which I can made is to remove the if structure around
the having tests so that having with group functions will also be
tested in the crash-me test.

I will try the patch of bruce for the comment part. It shouldn't be the
way that the perl module is stripping the comments of the querie
but it is possible and if it is possible it will be a bug in the DBD
postgresql perl module.

Maybe we should support the HAVING without aggregates. What do others
think?

-- 
  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 Wed Oct 6 01:47:17 1999
Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA89828
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 01:46:40 -0400 (EDT)
(envelope-from luuk@pop.wxs.nl)
Received: from luuk ([195.121.180.141]) by smtp01.wxs.nl
(Netscape Messaging Server 3.61) with ESMTP id AAB3CE2;
Wed, 6 Oct 1999 07:46:02 +0200
From: "Luuk de Boer" <luuk@wxs.nl>
To: The Hermit Hacker <scrappy@hub.org>
Date: Wed, 6 Oct 1999 07:51:27 +1.00
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
Reply-to: luuk@wxs.nl
CC: pgsql-hackers@postgreSQL.org, Bruce Momjian <maillist@candle.pha.pa.us>
Priority: normal
References: <10982.939134791@sss.pgh.pa.us>
In-reply-to: <Pine.BSF.4.10.9910052215260.17532-100000@thelab.hub.org>
X-mailer: Pegasus Mail for Win32 (v3.12a)
Message-ID: <7727DABD11F8.AAB3CE2@smtp01.wxs.nl>

On 5 Oct 99, at 22:23, The Hermit Hacker wrote:

Luuk...

I brought this up with the -hackers list, and, in generally, it
appears to be felt that the query, which you use in the crashme test to
test HAVING, isn't necessarily valid ...

Basically:

select a from test group by a having a > 0;

could be more efficiently written as:

select a from test where a > 0 group by a;

I'm personally curious, though...how does Oracle/Informix and
other RDBMS systems handle this? Do they let it pass, or do they give an
error also?

I think the general concensus, at this time, is to change the
ERROR to a NOTICE, with a comment that using a WHERE would be more
efficient then the HAVING...and, unless someone can come up with an
instance that would make sense (ie. why you'd do it with HAVING vs WHERE),
I'm in agreement with them...

Since we obviously do support HAVING, and, I believe, follow the
SQL92 spec on it, is there any way of getting the crashme test fixed to
not use the above query as a basis for whether an RDBMS supports HAVING or
not?

Thanks bruce and hermit for all the comments,
I looked into the book "The SQL Standard" fourth edition of Date
and in the appendixes page 439 they have an example which they
discuss. The example is: select count(*) as x from mt having 0 = 0;
with an empty table they say logically correct it should return one
column and no rows but sql gives a table of one column and one
row. So I think it's true that HAVING has to have an aggregation
but it will also be possible use a non-aggregation.

If I look in our crash-me output page (this is a handy thing for this
kind of questions) and look for all the other db's to see what they
do I can say the following thing:
Informix,Access,Adabas,db2,empress,ms-sql,oracle,solid and
sybase are all supporting non-aggregation in having clause.
At this moment everyone except postgres is supporting it.

The change which I can made is to remove the if structure around
the having tests so that having with group functions will also be
tested in the crash-me test.

I will try the patch of bruce for the comment part. It shouldn't be the
way that the perl module is stripping the comments of the querie
but it is possible and if it is possible it will be a bug in the DBD
postgresql perl module.

PS. the benchmark results of postgres 6.5.2 are also added to the
benchmark result page.

Greetz...

Luuk

From bouncefilter Wed Oct 6 04:09:18 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA08809
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 04:08:05 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <4H5AVQFC>; Wed, 6 Oct 1999 10:07:33 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C11E@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Matthew N. Dodd'" <winter@jurai.net>, Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] psql Week 1
Date: Wed, 6 Oct 1999 09:46:23 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Perhaps an option for the command:
\connect dbname /nofail
or something

-----Original Message-----
From: Matthew N. Dodd [mailto:winter@jurai.net]
Sent: Wednesday, October 06, 1999 6:59 AM
To: Peter Eisentraut
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql Week 1

On Tue, 5 Oct 1999, Peter Eisentraut wrote:

* when \connect fails, it now keeps the previous

connection (formerly

aborted program)

This is bad.

Consider some process that connects to various DBs and does
stuff like
drop foo.

If connect fails assume that the user no longer wanted to be
connected to
the old connection.

--
| 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 Wed Oct 6 04:34:19 1999
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA14885
for <hackers@postgresql.org>; Wed, 6 Oct 1999 04:33:50 -0400 (EDT)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id KAA221624;
Wed, 6 Oct 1999 10:33:08 +0200
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <TTV34HZ9>; Wed, 6 Oct 1999 10:33:06 +0200
Message-ID:
<219F68D65015D011A8E000006F8590C60339E109@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas IZ5 <ZeugswetterA@wien.spardat.at>
To: "'Peter Eisentraut'" <peter_e@gmx.net>
Cc: "'hackers@postgresql.org'" <hackers@postgresql.org>
Subject: AW: [HACKERS] psql Week 1
Date: Wed, 6 Oct 1999 10:33:00 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

* when \connect fails, it now keeps the previous connection (formerly
aborted program)

This was the behavior at one time, but it was regarded as very dangerous
and thus changed to the current behavior.

The problem was, that scripts would do things to the wrong database if a
connect failed.

The ultimate solution would be an unconnected state, where only
\connect or help commands would be accepted.

Andreas

From bouncefilter Wed Oct 6 09:44:22 1999
Received: from thelab.hub.org (nat194.229.mpoweredpc.net [142.177.194.229])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA67445
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 09:43:24 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id KAA42046;
Wed, 6 Oct 1999 10:43:31 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 6 Oct 1999 10:43:31 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <199910060553.BAA23414@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910061042440.17532-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 6 Oct 1999, Bruce Momjian wrote:

Thanks bruce and hermit for all the comments,
I looked into the book "The SQL Standard" fourth edition of Date
and in the appendixes page 439 they have an example which they
discuss. The example is: select count(*) as x from mt having 0 = 0;
with an empty table they say logically correct it should return one
column and no rows but sql gives a table of one column and one
row. So I think it's true that HAVING has to have an aggregation
but it will also be possible use a non-aggregation.

If I look in our crash-me output page (this is a handy thing for this
kind of questions) and look for all the other db's to see what they
do I can say the following thing:
Informix,Access,Adabas,db2,empress,ms-sql,oracle,solid and
sybase are all supporting non-aggregation in having clause.
At this moment everyone except postgres is supporting it.

The change which I can made is to remove the if structure around
the having tests so that having with group functions will also be
tested in the crash-me test.

I will try the patch of bruce for the comment part. It shouldn't be the
way that the perl module is stripping the comments of the querie
but it is possible and if it is possible it will be a bug in the DBD
postgresql perl module.

Maybe we should support the HAVING without aggregates. What do others
think?

If we are the only one that doesn't, it just makes it harder for those
moving from Oracle/Informix/etc if they happen to be using such queries...

How hard would it be to implement?

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Wed Oct 6 09:44:22 1999
Received: from thelab.hub.org (nat194.229.mpoweredpc.net [142.177.194.229])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA67484
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 09:43:40 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id KAA42050;
Wed, 6 Oct 1999 10:43:58 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 6 Oct 1999 10:43:58 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Luuk de Boer <luuk@wxs.nl>
cc: pgsql-hackers@postgreSQL.org, Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <7727DABD11F8.AAB3CE2@smtp01.wxs.nl>
Message-ID: <Pine.BSF.4.10.9910061043460.17532-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Can someone remind me where these benchmark pages are again? :)

On Wed, 6 Oct 1999, Luuk de Boer wrote:

On 5 Oct 99, at 22:23, The Hermit Hacker wrote:

Luuk...

I brought this up with the -hackers list, and, in generally, it
appears to be felt that the query, which you use in the crashme test to
test HAVING, isn't necessarily valid ...

Basically:

select a from test group by a having a > 0;

could be more efficiently written as:

select a from test where a > 0 group by a;

I'm personally curious, though...how does Oracle/Informix and
other RDBMS systems handle this? Do they let it pass, or do they give an
error also?

I think the general concensus, at this time, is to change the
ERROR to a NOTICE, with a comment that using a WHERE would be more
efficient then the HAVING...and, unless someone can come up with an
instance that would make sense (ie. why you'd do it with HAVING vs WHERE),
I'm in agreement with them...

Since we obviously do support HAVING, and, I believe, follow the
SQL92 spec on it, is there any way of getting the crashme test fixed to
not use the above query as a basis for whether an RDBMS supports HAVING or
not?

Thanks bruce and hermit for all the comments,
I looked into the book "The SQL Standard" fourth edition of Date
and in the appendixes page 439 they have an example which they
discuss. The example is: select count(*) as x from mt having 0 = 0;
with an empty table they say logically correct it should return one
column and no rows but sql gives a table of one column and one
row. So I think it's true that HAVING has to have an aggregation
but it will also be possible use a non-aggregation.

If I look in our crash-me output page (this is a handy thing for this
kind of questions) and look for all the other db's to see what they
do I can say the following thing:
Informix,Access,Adabas,db2,empress,ms-sql,oracle,solid and
sybase are all supporting non-aggregation in having clause.
At this moment everyone except postgres is supporting it.

The change which I can made is to remove the if structure around
the having tests so that having with group functions will also be
tested in the crash-me test.

I will try the patch of bruce for the comment part. It shouldn't be the
way that the perl module is stripping the comments of the querie
but it is possible and if it is possible it will be a bug in the DBD
postgresql perl module.

PS. the benchmark results of postgres 6.5.2 are also added to the
benchmark result page.

Greetz...

Luuk

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Wed Oct 6 09:46:22 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA67997
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 09:46:02 -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 JAA08594;
Wed, 6 Oct 1999 09:45:27 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910061345.JAA08594@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <Pine.BSF.4.10.9910061042440.17532-100000@thelab.hub.org> from
The
Hermit Hacker at "Oct 6, 1999 10:43:31 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Wed, 6 Oct 1999 09:45:27 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I will try the patch of bruce for the comment part. It shouldn't be the
way that the perl module is stripping the comments of the querie
but it is possible and if it is possible it will be a bug in the DBD
postgresql perl module.

Maybe we should support the HAVING without aggregates. What do others
think?

If we are the only one that doesn't, it just makes it harder for those
moving from Oracle/Informix/etc if they happen to be using such queries...

How hard would it be to implement?

Not hard. I will add it to the TODO list.

-- 
  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 Wed Oct 6 09:49:22 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 JAA68313
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 09:48:50 -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 NAA26084;
Wed, 6 Oct 1999 13:47:07 GMT
Sender: lockhart@hub.org
Message-ID: <37FB52DB.3318DEA9@alumni.caltech.edu>
Date: Wed, 06 Oct 1999 13:47:07 +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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <maillist@candle.pha.pa.us>, luuk@wxs.nl,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
References: <12470.939162585@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I can't get excited about changing this from the standpoint of
functionality, because AFAICS there is no added functionality.
But if we're looking bad on a recognized benchmark maybe we
should do something about it.

We are looking bad on a benchmark designed to show MySQL in the best
possible light, and to show other DBs at their worst. The maintainers
of that benchmark have no interest in changing that emphasis (e.g. we
are still reported as not supporting HAVING, even though we have
demonstrated to them that we do; this is the same pattern we have seen
earlier).

The last time I looked at it, there were ~30% factual errors in the
reported results for Postgres; no telling what errors are there for
other products. imho it is a waste of time to address a bogus
benchmark, unless someone wants to take it up as a hobby. I'm a bit
busy right now ;)

- Thomas

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

From bouncefilter Wed Oct 6 10:02:24 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 KAA70536
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 10:01:29 -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 JAA09036;
Wed, 6 Oct 1999 09:54:29 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910061354.JAA09036@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <37FB52DB.3318DEA9@alumni.caltech.edu> from Thomas Lockhart at
"Oct 6, 1999 01:47:07 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Wed, 6 Oct 1999 09:54:29 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, luuk@wxs.nl, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I can't get excited about changing this from the standpoint of
functionality, because AFAICS there is no added functionality.
But if we're looking bad on a recognized benchmark maybe we
should do something about it.

We are looking bad on a benchmark designed to show MySQL in the best
possible light, and to show other DBs at their worst. The maintainers
of that benchmark have no interest in changing that emphasis (e.g. we
are still reported as not supporting HAVING, even though we have
demonstrated to them that we do; this is the same pattern we have seen
earlier).

The last time I looked at it, there were ~30% factual errors in the
reported results for Postgres; no telling what errors are there for
other products. imho it is a waste of time to address a bogus
benchmark, unless someone wants to take it up as a hobby. I'm a bit
busy right now ;)

On a separate note, should we support HAVING without any aggregates?

-- 
  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 Wed Oct 6 10:08:23 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 KAA71593
for <hackers@postgresql.org>; Wed, 6 Oct 1999 10:07: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 OAA26183;
Wed, 6 Oct 1999 14:07:41 GMT
Sender: lockhart@hub.org
Message-ID: <37FB57AD.5BA86412@alumni.caltech.edu>
Date: Wed, 06 Oct 1999 14:07:41 +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: Peter Eisentraut <peter_e@gmx.net>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: psql and comments
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

While you're at it...

The following example shows psql correctly clearing its input buffer
when a line containing *only* a comment is seen, but not completely
clearing the buffer (or not realizing that it is cleared; note the
changed prompt) if the comment is at the end of a valid query.

postgres=> -- comment
postgres=> select 'hi'; -- comment
?column?
--------
hi
(1 row)

postgres->

- Thomas

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

From bouncefilter Wed Oct 6 10:12:22 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 KAA72433
for <hackers@postgreSQL.org>; Wed, 6 Oct 1999 10:11: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 KAA13511;
Wed, 6 Oct 1999 10:10:18 -0400 (EDT)
To: Vince Vielhaber <vev@michvhf.com>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] libpq++ doc error?
In-reply-to: Your message of Tue, 05 Oct 1999 22:47:42 -0400 (EDT)
<XFMail.991005224742.vev@michvhf.com>
Date: Wed, 06 Oct 1999 10:10:17 -0400
Message-ID: <13509.939219017@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Vince Vielhaber <vev@michvhf.com> writes:

I just sent patches for libpq++ to return an int (I'll also submit changes
to the sgml docs) and return a -1 if PQcmdTuples() returns a NULL pointer.
I just haven't been able to convince it to return a NULL.

It won't. If you look at the source, it's quite clear that it never
returns NULL. It will return an empty string ("") if it notices a
problem.

Also, if you wanted to be really paranoid you'd check that what it
returns actually looks like it is a number, because PQcmdTuples doesn't
check that there is a number in the right spot in the command status
returned by the backend.

These two points together are why I suggested testing for an initial
digit...

regards, tom lane

From bouncefilter Wed Oct 6 10:15:22 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id KAA73309
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 10:15:11 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 11402 invoked by uid 1001); 6 Oct 1999 14:15:12 -0000
Date: Wed, 6 Oct 1999 10:15:12 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: The Hermit Hacker <scrappy@hub.org>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <Pine.BSF.4.10.9910061042440.17532-100000@thelab.hub.org>
Message-ID: <Pine.BSF.4.05.9910061013360.11236-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 6 Oct 1999, The Hermit Hacker wrote:

Maybe we should support the HAVING without aggregates. What do others
think?

If we are the only one that doesn't, it just makes it harder for those
moving from Oracle/Informix/etc if they happen to be using such queries...

I just tried it on a very old Sybase (ver 4 something, before ODBC was
available for it) and it works on that.

From bouncefilter Wed Oct 6 10:22:22 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA74483
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 10:21:23 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <4H5AVQ91>; Wed, 6 Oct 1999 16:21:07 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C128@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Thomas Lockhart'" <lockhart@alumni.caltech.edu>, Tom Lane
<tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <maillist@candle.pha.pa.us>, luuk@wxs.nl,
pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql c
omparison
Date: Wed, 6 Oct 1999 16:16:21 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Save yourself (left hand on forehead, right hand on back of head, elbows up)
Thomas, save yourself ;-)

-----Original Message-----
From: Thomas Lockhart [mailto:lockhart@alumni.caltech.edu]
Sent: Wednesday, October 06, 1999 3:47 PM
To: Tom Lane
Cc: Bruce Momjian; luuk@wxs.nl; pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re:
PostgreSQL vs Mysql
comparison

I can't get excited about changing this from the standpoint of
functionality, because AFAICS there is no added functionality.
But if we're looking bad on a recognized benchmark maybe we
should do something about it.

We are looking bad on a benchmark designed to show MySQL in the best
possible light, and to show other DBs at their worst. The maintainers
of that benchmark have no interest in changing that emphasis (e.g. we
are still reported as not supporting HAVING, even though we have
demonstrated to them that we do; this is the same pattern we
have seen
earlier).

The last time I looked at it, there were ~30% factual errors in the
reported results for Postgres; no telling what errors are there for
other products. imho it is a waste of time to address a bogus
benchmark, unless someone wants to take it up as a hobby. I'm a bit
busy right now ;)

- Thomas

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

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

From bouncefilter Wed Oct 6 10:24:22 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 KAA74896
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 10:23:57 -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 KAA13577;
Wed, 6 Oct 1999 10:17:47 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: luuk@wxs.nl, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-reply-to: Your message of Wed, 6 Oct 1999 01:53:03 -0400 (EDT)
<199910060553.BAA23414@candle.pha.pa.us>
Date: Wed, 06 Oct 1999 10:17:47 -0400
Message-ID: <13575.939219467@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

If I look in our crash-me output page (this is a handy thing for this
kind of questions) and look for all the other db's to see what they
do I can say the following thing:
Informix,Access,Adabas,db2,empress,ms-sql,oracle,solid and
sybase are all supporting non-aggregation in having clause.
At this moment everyone except postgres is supporting it.

Maybe we should support the HAVING without aggregates. What do others
think?

Kinda looks like we gotta, just for compatibility reasons. Also, if I
read the SQL spec correctly, it does not forbid HAVING w/out aggregates,
so those guys are adhering to the spec.

I'll put it on my todo list --- I'm busy making some other fixes in that
general area anyway.

Next question is should we emit a NOTICE or just silently do it?
(For that matter, should we go so far as to push the HAVING condition
over to become part of WHERE when it has no agg? Then the speed issue
goes away.) I kind of like emitting a NOTICE on the grounds of helping
to educate users about the difference between WHERE and HAVING, but
maybe people would just see it as obnoxious.

regards, tom lane

From bouncefilter Wed Oct 6 10:40:23 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA77989
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 10:40:04 -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 KAA10225;
Wed, 6 Oct 1999 10:39:18 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910061439.KAA10225@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <13575.939219467@sss.pgh.pa.us> from Tom Lane at "Oct 6,
1999 10:17:47 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 6 Oct 1999 10:39:18 -0400 (EDT)
CC: luuk@wxs.nl, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Next question is should we emit a NOTICE or just silently do it?
(For that matter, should we go so far as to push the HAVING condition
over to become part of WHERE when it has no agg? Then the speed issue
goes away.) I kind of like emitting a NOTICE on the grounds of helping
to educate users about the difference between WHERE and HAVING, but
maybe people would just see it as obnoxious.

That is a tough call. My personal vote is that HAVING is misunderstood
enough to emit a warning.

-- 
  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 Wed Oct 6 10:53:23 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id KAA80165
for <hackers@postgreSQL.org>; Wed, 6 Oct 1999 10:52:46 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 11774 invoked by uid 1001); 6 Oct 1999 14:52:34 -0000
Date: Wed, 6 Oct 1999 10:52:34 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] libpq++ doc error?
In-Reply-To: <13509.939219017@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.05.9910061040590.11236-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 6 Oct 1999, Tom Lane wrote:

Vince Vielhaber <vev@michvhf.com> writes:

I just sent patches for libpq++ to return an int (I'll also submit changes
to the sgml docs) and return a -1 if PQcmdTuples() returns a NULL pointer.
I just haven't been able to convince it to return a NULL.

It won't. If you look at the source, it's quite clear that it never
returns NULL. It will return an empty string ("") if it notices a
problem.

Also, if you wanted to be really paranoid you'd check that what it
returns actually looks like it is a number, because PQcmdTuples doesn't
check that there is a number in the right spot in the command status
returned by the backend.

These two points together are why I suggested testing for an initial
digit...

Ok, I'm looking for an empty string now and that will return a -1. The
other return possibilities *should* be handled correctly by atoi() since
it doesn't care if there's any leading blanks/spaces, as long as it's
not a non-numeric non-space character. If it's going to get that crazy
with differing possibilities then we'd be further ahead to fix it in
either the backend or in libpq (by adding a new function and letting
this one fade away). Is there an atoi() out there that would not return
a 123 if passed the string " 123 " ?? It does the right thing in
hpux8 and in FreeBSD 3.2.

From bouncefilter Wed Oct 6 11:15:23 1999
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA84158
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 11:14:20 -0400 (EDT)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA16557;
Wed, 6 Oct 1999 08:12:55 -0700 (PDT)
Message-Id: <3.0.1.32.19991006081149.0207a9f0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 06 Oct 1999 08:11:49 -0700
To: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <maillist@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
Cc: luuk@wxs.nl, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgreSQL.org
In-Reply-To: <13575.939219467@sss.pgh.pa.us>
References: <Your message of Wed, 6 Oct 1999 01:53:03 -0400 (EDT)
<199910060553.BAA23414@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:17 AM 10/6/99 -0400, Tom Lane wrote:

Next question is should we emit a NOTICE or just silently do it?
(For that matter, should we go so far as to push the HAVING condition
over to become part of WHERE when it has no agg? Then the speed issue
goes away.) I kind of like emitting a NOTICE on the grounds of helping
to educate users about the difference between WHERE and HAVING, but
maybe people would just see it as obnoxious.

People used to commercial servers like Oracle would just see it as
being obnoxious, I suspect.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Wed Oct 6 11:32:24 1999
Received: from thelab.hub.org (nat194.229.mpoweredpc.net [142.177.194.229])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA86437
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 11:31:30 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA42895;
Wed, 6 Oct 1999 12:29:44 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 6 Oct 1999 12:29:43 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, luuk@wxs.nl, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <199910061439.KAA10225@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910061229260.17532-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 6 Oct 1999, Bruce Momjian wrote:

Next question is should we emit a NOTICE or just silently do it?
(For that matter, should we go so far as to push the HAVING condition
over to become part of WHERE when it has no agg? Then the speed issue
goes away.) I kind of like emitting a NOTICE on the grounds of helping
to educate users about the difference between WHERE and HAVING, but
maybe people would just see it as obnoxious.

That is a tough call. My personal vote is that HAVING is misunderstood
enough to emit a warning.

Agreed from here...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Wed Oct 6 11:43:24 1999
Received: from thelab.hub.org (nat194.229.mpoweredpc.net [142.177.194.229])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA87889
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 11:42:40 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA43003;
Wed, 6 Oct 1999 12:41:40 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 6 Oct 1999 12:41:39 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <maillist@candle.pha.pa.us>,
luuk@wxs.nl, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <37FB52DB.3318DEA9@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.10.9910061231030.17532-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 6 Oct 1999, Thomas Lockhart wrote:

I can't get excited about changing this from the standpoint of
functionality, because AFAICS there is no added functionality.
But if we're looking bad on a recognized benchmark maybe we
should do something about it.

We are looking bad on a benchmark designed to show MySQL in the best
possible light, and to show other DBs at their worst. The maintainers
of that benchmark have no interest in changing that emphasis (e.g. we
are still reported as not supporting HAVING, even though we have
demonstrated to them that we do; this is the same pattern we have seen
earlier).

The last time I looked at it, there were ~30% factual errors in the
reported results for Postgres; no telling what errors are there for
other products. imho it is a waste of time to address a bogus
benchmark, unless someone wants to take it up as a hobby. I'm a bit
busy right now ;)

My opinion on this tends to be that, in the HAVING case, we are the only
one that doesn't support it w/o aggregates, so we altho we do follow the
spec, we are making it slightly more difficult to migrate from 'the
others' to us...

So far, Luuk has appeared to be relatively open as far as investigating
the discrepencies in the report...but, since he doesn't *know* PostgreSQL,
he has no way of knowing what is wrong, and that is where, I think, we
should be trying to help support our end of things...

If Luuk were to come back and tell us that he absolutely won't change
anything, then, IMHO, there is a problem...but, thanks to his test, Bruce
made some changes to how we handle our comments to fix a bug...and Luuk
told us that he fixed the HAVING test such that HAVING w/o aggregates
doesn't fail the test...

Benchmarks, IMHO, always try to favor the 'base product' that is being
advertised...but, more often then not, its because the person doing the
benchmarking knows that product well enough to be able to 'tweak' it to
perform better...Luuk, so far as I believe, is willing to be "educated in
PostgreSQL"...I don't think its right for us to stifle that, is it?

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Wed Oct 6 17:57:28 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA43990
for <pgsql-hackers@postgresql.org>; Wed, 6 Oct 1999 17:56:49 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:3250 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rywKA239896>;
Wed, 6 Oct 1999 23:56:28 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11Yttx-0000SA-00; Wed, 06 Oct 1999 18:26:49 +0200
Date: Wed, 6 Oct 1999 18:26:49 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Oleg Bartunov <oleg@sai.msu.su>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql Week 1
In-Reply-To: <Pine.GSO.3.96.SK.991006010738.4801T-100000@ra>
Message-ID: <Pine.LNX.4.10.9910061824250.1744-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 6, Oleg Bartunov mentioned:

what I miss on pgsql is ability to keep commands I issued in history file
as bash does for example. Say, ~/.pgsqlhistory

Consider it done. (Because it is done.)

Of course, not to save passwords.

Usernames and passwords are entered through a different channel. This will
not be a problem.

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e/

From bouncefilter Wed Oct 6 17:57:28 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA43988
for <pgsql-hackers@postgresql.org>; Wed, 6 Oct 1999 17:56:47 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:3244 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rywK6248089>;
Wed, 6 Oct 1999 23:56:24 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11YtwD-0000SD-00; Wed, 06 Oct 1999 18:29:09 +0200
Date: Wed, 6 Oct 1999 18:29:09 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: "Matthew N. Dodd" <winter@jurai.net>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql Week 1
In-Reply-To: <Pine.BSF.4.10.9910060057560.25333-100000@sasami.jurai.net>
Message-ID: <Pine.LNX.4.10.9910061828000.1744-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 6, Matthew N. Dodd mentioned:

On Tue, 5 Oct 1999, Peter Eisentraut wrote:

* when \connect fails, it now keeps the previous connection (formerly
aborted program)

This is bad.

Consider some process that connects to various DBs and does stuff like
drop foo.

If connect fails assume that the user no longer wanted to be connected to
the old connection.

I forgot to mention that this only happens in interactive mode for the
very reason you cited. I do not see a problem there.

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e/

From bouncefilter Wed Oct 6 17:58:21 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA43983
for <hackers@postgresql.org>; Wed, 6 Oct 1999 17:56:44 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:3252 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rywKF215304>;
Wed, 6 Oct 1999 23:56:33 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11Yu1V-0000SF-00; Wed, 06 Oct 1999 18:34:37 +0200
Date: Wed, 6 Oct 1999 18:34:37 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Zeugswetter Andreas IZ5 <ZeugswetterA@wien.spardat.at>
cc: "'hackers@postgresql.org'" <hackers@postgresql.org>
Subject: Re: AW: [HACKERS] psql Week 1
In-Reply-To:
<219F68D65015D011A8E000006F8590C60339E109@sdexcsrv1.f000.d0188.sd.spardat.at>
Message-ID: <Pine.LNX.4.10.9910061831100.1744-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 6, Zeugswetter Andreas IZ5 mentioned:

* when \connect fails, it now keeps the previous connection (formerly
aborted program)

This was the behavior at one time, but it was regarded as very dangerous
and thus changed to the current behavior.

The problem was, that scripts would do things to the wrong database if a
connect failed.

See earlier response. Only in interactive mode. The idea was that a typo
should not bomb you out of the program.

The ultimate solution would be an unconnected state, where only
\connect or help commands would be accepted.

I had that idea, too, but that would open a whole new can of worms
code-wise. Can you guys out there comment if this feature would be
desirable?

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e/

From bouncefilter Wed Oct 6 14:18:25 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA11594
for <hackers@postgreSQL.org>; Wed, 6 Oct 1999 14:17:56 -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 OAA15421;
Wed, 6 Oct 1999 14:17:20 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910061817.OAA15421@candle.pha.pa.us>
Subject: Re: [HACKERS] psql and comments
In-Reply-To: <37FB57AD.5BA86412@alumni.caltech.edu> from Thomas Lockhart at
"Oct 6, 1999 02:07:41 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Wed, 6 Oct 1999 14:17:20 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

While you're at it...

The following example shows psql correctly clearing its input buffer
when a line containing *only* a comment is seen, but not completely
clearing the buffer (or not realizing that it is cleared; note the
changed prompt) if the comment is at the end of a valid query.

postgres=> -- comment
postgres=> select 'hi'; -- comment
?column?
--------
hi
(1 row)

postgres->

But aren't they _in_ a new statement, that begins with '--'?

-- 
  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 Wed Oct 6 15:07:26 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 PAA20877
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 15:06:41 -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 XAA17434
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 23:06:26 +0400 (MSD)
Date: Wed, 6 Oct 1999 23:06:26 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: pgsql-hackers@postgreSQL.org
Subject: union and LIMIT problem
Message-ID: <Pine.GSO.3.96.SK.991006230035.4801e-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Does anybody know how to use UNION and LIMIT together ?
I want to get 10 rows from publications and 10 rows
from keys.

select msg_id from publications limit 10 union
select key_id from keys limit 10
produces
ERROR: parser: parse error at or near "union

select msg_id from publications union
select key_id from keys limit 10
produces something I wasn't expected

Regards,

Oleg

From bouncefilter Wed Oct 6 15:25:26 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA23147
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 15:24:35 -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 PAA20736;
Wed, 6 Oct 1999 15:23:37 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910061923.PAA20736@candle.pha.pa.us>
Subject: Re: [HACKERS] union and LIMIT problem
In-Reply-To: <Pine.GSO.3.96.SK.991006230035.4801e-100000@ra> from Oleg
Bartunov
at "Oct 6, 1999 11:06:26 pm"
To: Oleg Bartunov <oleg@sai.msu.su>
Date: Wed, 6 Oct 1999 15:23:37 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Does anybody know how to use UNION and LIMIT together ?
I want to get 10 rows from publications and 10 rows
from keys.

select msg_id from publications limit 10 union
select key_id from keys limit 10
produces
ERROR: parser: parse error at or near "union

select msg_id from publications union
select key_id from keys limit 10
produces something I wasn't expected

I have on the TODO list:

* UNION with LIMIT fails

-- 
  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 Wed Oct 6 17:58:28 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA43968
for <hackers@postgresql.org>; Wed, 6 Oct 1999 17:56:31 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:3238 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rywJy241944>;
Wed, 6 Oct 1999 23:56:14 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11Yx0z-0000SW-00; Wed, 06 Oct 1999 21:46:17 +0200
Date: Wed, 6 Oct 1999 21:46:17 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: psql and comments
In-Reply-To: <37FB57AD.5BA86412@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.10.9910062138470.1744-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 6, Thomas Lockhart mentioned:

The following example shows psql correctly clearing its input buffer
when a line containing *only* a comment is seen, but not completely
clearing the buffer (or not realizing that it is cleared; note the
changed prompt) if the comment is at the end of a valid query.

postgres=> -- comment
postgres=> select 'hi'; -- comment
?column?
--------
hi
(1 row)

postgres->

That has been noted by me as well. From looking at the code I see that
someone intended to do something quite different in this case, like print
the comment on top of the query being echoed, I think. But I couldn't
really follow that.

Anyway, I'm going to end up rewriting that parser anyway, so that will be
taken care of. I was almost about to use flex but the Windows crowd
probably wouldn't find that too funny. (The Windows crowd won't find this
thing funny anyway, since I have no clue what #ifdef's I need for that.
Someone else will have to do a looong compile&fix session.)

The question I have though is, is there a reason, besides efficiency, that
psql doesn't just send the comment to the backend with the query? The
backend does accept comments last time I checked. Perhaps someone will one
day write something that makes some use of those comments on the backend
(thus conflicting with the very definition of "comment", but maybe a
logger) and it would remove some load out of psql.

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e/

From bouncefilter Wed Oct 6 17:58:22 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA43967
for <pgsql-hackers@postgresql.org>; Wed, 6 Oct 1999 17:56:30 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:3242 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rywK1215304>;
Wed, 6 Oct 1999 23:56:19 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11Yx7W-0000Ss-00; Wed, 06 Oct 1999 21:53:02 +0200
Date: Wed, 6 Oct 1999 21:53:02 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Roland Roberts <roberts@panix.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql Week 1
Message-ID: <Pine.LNX.4.10.9910062151220.1744-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 5, Roland Roberts mentioned:

Peter> * \connect now asks for password when appropriate

Does this include the initial connect? I has password authentication
enabled and think it would be nice if psql just prompted me rather
than failed....

There was a design flaw in psql in that the -u switch always asked for
username *and* password. Those are essentially two separate things: Do you
want a different username than the default? and Do you need to enter a
password because you use that as authentication?

I resolved that by adding a switch -U to specifiy username and -P to
request a password prompt. If and only if you start psql with -P you will
get a password prompt any time you reconnect. (This is still not ideal
since the new database might not require a password, but there is no way
to read the pg_hba.conf from the front end obviously.) For backward
compatibility the -u switch essentially simulates "-U ? -P". (Username "?"
means prompt for username. You guys don't use question marks as username,
do you?)

I hope that solves it.

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e/

From bouncefilter Wed Oct 6 16:18:27 1999
Received: from megazone.bigpanda.com ([209.218.81.130])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA30944
for <pgsql-hackers@postgresql.org>; Wed, 6 Oct 1999 16:17:56 -0400 (EDT)
(envelope-from acroyear@megazone.bigpanda.com)
Received: from megazone.bigpanda.com (localhost.bigpanda.com [127.0.0.1])
by megazone.bigpanda.com (8.8.8/8.8.5) with ESMTP id QAA26005
for <pgsql-hackers@postgresql.org>; Wed, 6 Oct 1999 16:17:39 -0400 (EDT)
Message-Id: <199910062017.QAA26005@megazone.bigpanda.com>
To: pgsql-hackers@postgresql.org
From: sszabo@bigpanda.com
Subject: Re: [HACKERS] Database names with spaces
Date: Wed, 06 Oct 1999 16:17:39 -0400
Sender: acroyear@bigpanda.com

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

Looks like a bug. Added to TODO list.

I see a todo item
* Views with spaces in view name fail when referenced

I have another one for you:
* Databases with spaces in name fail to be created and destroyed despite
responses to the contrary.

IIRC, createdb and destroydb use "cp -r" and "rm -r" respectively.
Lack of careful quoting in the system calls is probably what's
causing the problem here.

However, I wonder if it wouldn't be a better idea to forbid funny
characters in things that will become Unix filenames. In particular,
something like CREATE DATABASE "../../../something" could have real
bad consequences...

I just tried it:

test=> create database "../../pg_hba.conf"
test-> \g
ERROR: Unable to locate path '../../pg_hba.conf'
This may be due to a missing environment variable in the server

Seems we are safe.

(This is my first time going through the code, so I could be getting alot of
things wrong, but here's what I see...)

The function createdb in backend/commands/dbcommands.c (I assume this is right
because it seems to do the correct thing and actually define the above error
message) tries to get the path to the database using ExpandDatabasePath on
either dbpath/dbname or just dbname depending on whether dbpath is null (or
same as dbname).

ExpandDatabasePath in backend/utils/misc/database.c seems to assume that anything
that has the separator character ('/' i would assume) is of the form
environmentvariable/<rest> which seems to be rewritten into
<value of environment variable>/base/<rest>
So with your example it fails because it can't find the environment variable
'..' (although if you had one, it might actually attempt to put it wherever
that would point)

It then makes a command and systems:
COPY_CMD DataDir/base/template1/ <return from ExpandDatabasePath>

When i tried to do a:
create database "`a.sh`" on a little shell script in the PATH, it decided
to copy the stuff from template1 into my data/base directory. The shell
script touches a file in tmp, which was touched.

It seems like the current implementation would let someone run a command in
backticks that is in the postgres user's path as long as there are no
directory name separators in the command.

Stephan Szabo

From bouncefilter Wed Oct 6 16:20:27 1999
Received: from megazone.bigpanda.com ([209.218.81.130])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA31086
for <pgsql-hackers@postgresql.org>; Wed, 6 Oct 1999 16:19:52 -0400 (EDT)
(envelope-from acroyear@megazone.bigpanda.com)
Received: from megazone.bigpanda.com (localhost.bigpanda.com [127.0.0.1])
by megazone.bigpanda.com (8.8.8/8.8.5) with ESMTP id QAA26016
for <pgsql-hackers@postgresql.org>; Wed, 6 Oct 1999 16:19:43 -0400 (EDT)
Message-Id: <199910062019.QAA26016@megazone.bigpanda.com>
To: pgsql-hackers@postgresql.org
From: sszabo@bigpanda.com
Subject: Re: [HACKERS] Database names with space (II)
Date: Wed, 06 Oct 1999 16:19:43 -0400
Sender: acroyear@bigpanda.com

I forgot to mention that I was looking at 6.5.2 source, so
someone might have changed it, and if they have I'm sorry
for hitting the list. (I have a more recent snapshot on
my machine at home, but I can't seem to get in right now
to check).

Stephan Szabo

From bouncefilter Wed Oct 6 18:23:28 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA48077
for <hackers@postgreSQL.org>; Wed, 6 Oct 1999 18:23:15 -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 SAA23693;
Wed, 6 Oct 1999 18:22:35 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910062222.SAA23693@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: psql and comments
In-Reply-To: <Pine.LNX.4.10.9910062138470.1744-100000@peter-e.yi.org> from
Peter Eisentraut at "Oct 6, 1999 09:46:17 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Wed, 6 Oct 1999 18:22:35 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Anyway, I'm going to end up rewriting that parser anyway, so that will be
taken care of. I was almost about to use flex but the Windows crowd
probably wouldn't find that too funny. (The Windows crowd won't find this
thing funny anyway, since I have no clue what #ifdef's I need for that.
Someone else will have to do a looong compile&fix session.)

The question I have though is, is there a reason, besides efficiency, that
psql doesn't just send the comment to the backend with the query? The
backend does accept comments last time I checked. Perhaps someone will one
day write something that makes some use of those comments on the backend
(thus conflicting with the very definition of "comment", but maybe a
logger) and it would remove some load out of psql.

Remove it. Send it to the backend.

-- 
  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 Wed Oct 6 18:29:28 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 SAA48667
for <hackers@postgreSQL.org>; Wed, 6 Oct 1999 18:28:47 -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 GAA27917
for <hackers@postgreSQL.org>; Thu, 7 Oct 1999 06:28:42 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37FBCD10.75BBC025@krs.ru>
Date: Thu, 07 Oct 1999 06:28:32 +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: PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: WAL Bootstrap/Startup/Shutdown committed...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

gmake clean + initdb (also changed) required.

WAL still doesn't anything but eats 16Mb disk space on bootstrap -:)

Data base system shutdown is changed!

Now, after receiving SIGTERM, postmaster disallows new
connections but let active backend to end their works
and shutdown data base only after all of them terminated
(by client request) - Smart Shutdown.

SIGINT: postmaster disallows new connections,
sends all active backends SIGTERM (abort+exit),
waits for children exits and shutdowns data base
- Fast Shutdown.

SIGQUIT: postmaster terminates children with SIGUSR1
and exits (without shutdowning data base)
- Immediate Shutdown (results in recovery on startup).

I started to clean up backend initialization code: MUST use
locking when read catalog relations and setup MyProc before
acquiring any (except for ProcStructLock) spinlocks.

Also, now FATAL is ERROR + exit.

Vadim

From bouncefilter Wed Oct 6 19:02:28 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 TAA55039
for <pgsql-hackers@postgresql.org>; Wed, 6 Oct 1999 19:01:42 -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 TAA15309;
Wed, 6 Oct 1999 19:00:56 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgresql.org
In-reply-to: Your message of Tue, 5 Oct 1999 22:45:01 +0200 (CEST)
<Pine.LNX.4.10.9910052235030.1358-100000@peter-e.yi.org>
Date: Wed, 06 Oct 1999 19:00:56 -0400
Message-ID: <15307.939250856@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

How about version numbering libpq properly? It has been 2.0 ever since I
can remember (not very long :). At least do ++0.0.1 when you change
something. Is there any particular reason why this is not done?

We've been pretty lax about version numbering during development cycles.
It could be a problem if you are keeping several versions around,
I suppose. But I think what you are asking for is a major-version bump
anytime a subroutine gets added (else it's not going to help a dynamic
linker distinguish two versions anyway). That seems not very workable.

regards, tom lane

From bouncefilter Wed Oct 6 23:26:32 1999
Received: from roberts.dialup.access.net (IDENT:root@roberts.dialup.access.net
[166.84.193.218]) by hub.org (8.9.3/8.9.3) with ESMTP id XAA88727
for <pgsql-hackers@postgreSQL.org>; Wed, 6 Oct 1999 23:26:06 -0400 (EDT)
(envelope-from roberts@panix.com)
Received: (from roland@localhost)
by roberts.dialup.access.net (8.9.3/8.9.3) id XAA13858;
Wed, 6 Oct 1999 23:26:04 -0400
Sender: roland@tycho.rlent.pnet
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql Week 1
References: <Pine.LNX.4.10.9910062151220.1744-100000@peter-e.yi.org>
From: Roland Roberts <roberts@panix.com>
Date: 06 Oct 1999 23:26:03 -0400
In-Reply-To: Peter Eisentraut's message of "Wed,
6 Oct 1999 21:53:02 +0200 (CEST)"
Message-ID: <m2emf7lulw.fsf@tycho.rlent.pnet>
Lines: 29
X-Mailer: Gnus v5.7/Emacs 20.4

-----BEGIN PGP SIGNED MESSAGE-----

"Peter" == Peter Eisentraut <peter_e@gmx.net> writes:

Peter> (This is still not ideal since the new database might not
Peter> require a password, but there is no way to read the
Peter> pg_hba.conf from the front end obviously.)

Couldn't you just prompt for the password *after* the backend
complains about needing it?

roland
- --
PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD Custom Software Solutions
roberts@panix.com 76-15 113th Street, Apt 3B
rbroberts@acm.org Forest Hills, NY 11375

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface

iQCVAwUBN/wSyuoW38lmvDvNAQFa9gP/YMZ9yN7OgR1N+2O2wkSAfmqHRGBocwis
zw5qg+U/mJop+1OWX6bujY3oOk2GypQGSppCkWgvV5j7sDeBLJ5cNczQLepqZxHB
ABYMAaRr6jE7JPLHua1lWxmp58CIPGz9wp1niLRap2UeFE0jgCUa3z3TsnzkgcmS
UCaMV9kLlVE=
=p2+8
-----END PGP SIGNATURE-----

From bouncefilter Thu Oct 7 07:03:37 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA46266
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 07:03:30 -0400 (EDT)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA00214
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 11:54:43 +0200
Date: Thu, 7 Oct 1999 11:54:42 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: password in pg_shadow
Message-ID: <Pine.LNX.3.96.991007113437.30842A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Is all in next example good? See:

abil=> CREATE USER myname WITH PASSWORD BuBuBuBu;
CREATE USER ^^^^^^^^^^

Why is in pg_shadow.passwd low case only?

Zakkr

From bouncefilter Thu Oct 7 05:54:36 1999
Received: from sd.tpf.co.jp (mail.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA39682
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 05:54:17 -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 SAA01635; Thu, 07 Oct 1999 18:53:06 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Thomas Lockhart" <lockhart@alumni.caltech.edu>,
"Bruce Momjian" <maillist@candle.pha.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Scan by TID (was RE: [HACKERS] How to add a new build-in operator)
Date: Thu, 7 Oct 1999 18:56:52 +0900
Message-ID: <000b01bf10aa$4816c600$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
In-Reply-To: <37F9FB79.D3AA52B5@alumni.caltech.edu>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

I'm planning to implement a new type of scan,scan by TID.
It's on TODO * Allow WHERE restriction on ctid.
First,I want to define an equal operator between TID.

Certainly, or perhaps it would be better to recycle an OID from
farther down? We have some open values, and if you only need a few it
would work well.

You probably already know this, but just in case,

cd src/include/catalog
./unused_oids

I didn't know it.
Thanks.
I would use OIDs for '=' operator between TIDs as follows.
387 for = (tid, tid)
1292 for tideq(tid, tid)

Unfortunately,TIDs are changed by UPDATE operations.
So we would need some functions in order to get the latest
TID of a specified tuple such as
currtid(relationid/name, tid) which returns tid.
I would provide functions for both relid and relname and
use 1293-1294 for OIDs of these functions.

Comments ?
If there's no objection,I would commit them to the current tree.

Moreover,we would need to know TIDs of inserted tuples.
What is a reasonable way to do so ?
1. Add TID to return_info of INSERT commands.
2. Provide a function to get TID of the last inserted tuple
of the session(backend).
...

Any ideas ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Thu Oct 7 06:06:36 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 GAA41219
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 06:05:57 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11ZALW-0003kLC; Thu, 7 Oct 99 12:00 MET DST
Message-Id: <m11ZALW-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] union and LIMIT problem
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Thu, 7 Oct 1999 12:00:22 +0200 (MET DST)
Cc: oleg@sai.msu.su, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199910061923.PAA20736@candle.pha.pa.us> from "Bruce Momjian" at
Oct 6, 99 03:23:37 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

Does anybody know how to use UNION and LIMIT together ?
I want to get 10 rows from publications and 10 rows
from keys.

select msg_id from publications limit 10 union
select key_id from keys limit 10
produces
ERROR: parser: parse error at or near "union

select msg_id from publications union
select key_id from keys limit 10
produces something I wasn't expected

I have on the TODO list:

* UNION with LIMIT fails

and must fail by it's implementation. LIMIT is handled by the
outermost executor loop, suppressing OFFSET result tuples and
stopping execution after LIMIT results sent to the client.

Jan

From bouncefilter Thu Oct 7 07:57:37 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA51375
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 07:57:03 -0400 (EDT)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA05670;
Thu, 7 Oct 1999 12:48:12 +0200
Date: Thu, 7 Oct 1999 12:48:11 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: Peter Mount <petermount@it.maidstone.gov.uk>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] password in pg_shadow
In-Reply-To:
<1B3D5E532D18D311861A00600865478C25E69F@exchange1.nt.maidstone.gov.uk>
Message-ID: <Pine.LNX.3.96.991007123915.5015A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 7 Oct 1999, Peter Mount wrote:

I think its because the parser forces everything outside of quotes to
being lowercase.

Yes, it is right, but in tutorial is nothing about it, In tutorial is
this bad example:

CREATE USER davide WITH PASSWORD jw8s0F4

Password is very important....

Zakkr

From bouncefilter Thu Oct 7 07:20:38 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA47704
for <pgsql-hackers@postgresql.org>; Thu, 7 Oct 1999 07:18:40 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11ZBXt-0009lM-0K; Thu, 7 Oct 1999 11:17:13 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id NAA10802;
Thu, 7 Oct 1999 13:17:37 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5JGL>; Thu, 7 Oct 1999 12:14:06 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E69F@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Zakkr'" <zakkr@zf.jcu.cz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] password in pg_shadow
Date: Thu, 7 Oct 1999 12:14:05 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

I think its because the parser forces everything outside of quotes to
being lowercase.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Zakkr [mailto:zakkr@zf.jcu.cz]
Sent: 07 October 1999 10:55
To: pgsql-hackers
Subject: [HACKERS] password in pg_shadow

Is all in next example good? See:

abil=> CREATE USER myname WITH PASSWORD BuBuBuBu;
CREATE USER ^^^^^^^^^^

Why is in pg_shadow.passwd low case only?

Zakkr

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

From bouncefilter Thu Oct 7 07:44:37 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA50066
for <pgsql-hackers@postgresql.org>; Thu, 7 Oct 1999 07:43:38 -0400 (EDT)
(envelope-from alessio@albourne.com)
Received: from albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.6X) with ESMTP id
OAA09785 for <pgsql-hackers@postgresql.org>;
Thu, 7 Oct 1999 14:46:29 +0300 (EET DST)
Sender: alessio@albourne.com
Message-ID: <37FC8762.5CCABA6B@albourne.com>
Date: Thu, 07 Oct 1999 14:43:30 +0300
From: Alessio Bragadini <alessio@albourne.com>
Organization: APL Financial Services (Overseas) Ltd.
X-Mailer: Mozilla 4.61 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: it, en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--
Alessio F. Bragadini alessio@albourne.com
APL Financial Services http://staff.dsnet.it/~alessio
Nicosia, Cyprus phone: +357-2-750652

You are welcome, sir, to Cyprus. -- Shakespeare's "Othello"

From bouncefilter Thu Oct 7 09:23:38 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 JAA60550
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 09:22:42 -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 NAA27965;
Thu, 7 Oct 1999 13:15:55 GMT
Sender: lockhart@hub.org
Message-ID: <37FC9D0A.A37F79F2@alumni.caltech.edu>
Date: Thu, 07 Oct 1999 13:15:54 +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: The Hermit Hacker <scrappy@hub.org>, luuk@wxs.nl
CC: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <maillist@candle.pha.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
References: <Pine.BSF.4.10.9910061231030.17532-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

My opinion on this tends to be that, in the HAVING case, we are the only
one that doesn't support it w/o aggregates, so we altho we do follow the
spec, we are making it slightly more difficult to migrate from 'the
others' to us...

We follow the spec in what we support, but the spec *does* allow
HAVING w/o aggregates (and w/o any GROUP BY clause).

Tom, imho we absolutely should *not* emit warnings for unusual but
legal constructs. Our chapter on "syntax" can start addressing these
kinds of topics, but the backend probably isn't the place to teach SQL
style...

Benchmarks, IMHO, always try to favor the 'base product' that is being
advertised...but, more often then not, its because the person doing the
benchmarking knows that product well enough to be able to 'tweak' it to
perform better...Luuk, so far as I believe, is willing to be "educated in
PostgreSQL"...I don't think its right for us to stifle that, is it?

Right. Sorry Luuk for going off on ya...

- Thomas

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

From bouncefilter Thu Oct 7 09:34:40 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 JAA61812
for <hackers@postgreSQL.org>; Thu, 7 Oct 1999 09:34:08 -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 NAA27986;
Thu, 7 Oct 1999 13:30:44 GMT
Sender: lockhart@hub.org
Message-ID: <37FCA084.ADB71A9B@alumni.caltech.edu>
Date: Thu, 07 Oct 1999 13:30:44 +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: Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and comments
References: <199910061817.OAA15421@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The following example shows psql correctly clearing its input buffer
when a line containing *only* a comment is seen, but not completely
clearing the buffer (or not realizing that it is cleared; note the
changed prompt) if the comment is at the end of a valid query.

postgres=> -- comment
postgres=> select 'hi'; -- comment
?column?
--------
hi
(1 row)

postgres->

But aren't they _in_ a new statement, that begins with '--'?

?? Sure, that's what psql thinks. But the first case shown above
should also begin a new statement, changing the prompt (it doesn't,
because after stripping the comment there are zero blanks in the
line). I don't think that is the right behavior though.

Things aren't a big problem the way they stand, but istm that a
completely blank line (after stripping single-line comments) may as
well be the same as an empty line,and that psql could figure that out.

- Thomas

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

From bouncefilter Thu Oct 7 11:02:40 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA80129
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 11:02:00 -0400 (EDT)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA15433
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 15:53:07 +0200
Date: Thu, 7 Oct 1999 15:53:07 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Privilege for attribute (columns)
Message-ID: <Pine.LNX.3.96.991007154606.6168B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

have somebody trigger for attr. privilege setting? Or exist other
resolution? (Please) - I need it for my project and if this not exist I
will must write this myself :-((

Zakkr

From bouncefilter Thu Oct 7 10:17:39 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 KAA73740
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 10:16:41 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11ZEGJ-0003kLC; Thu, 7 Oct 99 16:11 MET DST
Message-Id: <m11ZEGJ-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: PostgreSQL Help
To: huffmana@ppc.pims.org (Allan Huffman)
Date: Thu, 7 Oct 1999 16:11:15 +0200 (MET DST)
Cc: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37FCA9B0.DA8AE0F9@ppc.pims.org> from "Allan Huffman" at Oct 7,
99 04:09:53 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Dear Jan,

Don't know why you're asking me - I'm not involved in JDBC
nor am I in the multibyte stuff.

I've included the hackers list into this response - maybe
someone else can comment on it?

Jan

I am using Java with JDBC (from a PC using VisualCafe Database Edition)
to run an application using PostgreSQL 6.2.1 (on a Sparc). Everything
is running fine except for a string problem. The Postmaster says (when
loading data from the database into the text fields of the GUI):
"ERROR: MultiByte strings (MB) must be enabled to use this function"

The DOS prompt (where the Visual Cafe development environment runs an
Applet) tells me:
"The maximum width size for column 3 is: 17"

And this is for a varchar(43) field. When I enter a string into the
column from my Java text field I get the diagnostic:
"Invalid value for the column: product_name"

I figure that all I have to do is enable MB but I can't find it. If you
have not encountered this problem before, do you know of a user group
where I can post a question.

Sincerely,

Allan in Belgique

Allan@ppc.pims.org

From bouncefilter Thu Oct 7 10:36:39 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 KAA76464
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 10:36:09 -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 KAA29060;
Thu, 7 Oct 1999 10:34:28 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: luuk@wxs.nl, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-reply-to: Your message of Thu, 07 Oct 1999 13:15:54 +0000
<37FC9D0A.A37F79F2@alumni.caltech.edu>
Date: Thu, 07 Oct 1999 10:34:27 -0400
Message-ID: <29058.939306867@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

We follow the spec in what we support, but the spec *does* allow
HAVING w/o aggregates (and w/o any GROUP BY clause).

Tom, imho we absolutely should *not* emit warnings for unusual but
legal constructs.

Yeah, I came to the same conclusion while I was working on it last
night. What I committed will still complain about HAVING that
references an ungrouped variable --- that *is* incorrect per spec ---
but otherwise it will take degenerate cases like
select 2+2 having 1<2;
without complaint.

Hmm... here is a boundary condition that may or may not be right yet:

regression=> select f1 from int4_tbl having 1 < 2;
ERROR: Illegal use of aggregates or non-group column in target list

Is this query legal, or not? The spec sez about HAVING:

1) If neither a <where clause> nor a <group by clause> is speci-
fied, then let T be the result of the preceding <from clause>;
[snip]

1) Let T be the result of the preceding <from clause>, <where
clause>, or <group by clause>. If that clause is not a <group
by clause>, then T consists of a single group and does not have
a grouping column.
[snip]

2) Each <column reference> contained in a <subquery> in the <search
condition> that references a column of T shall reference a
grouping column of T or shall be specified within a <set func-
tion specification>.

In the absence of a GROUP BY clause, it's clearly illegal for the HAVING
condition to reference any columns of the source table except via
aggregates. It's not quite so clear whether the target list has the same
restriction --- my just-committed code assumes so, but is that right?

I guess the real question here is whether a query like the above should
deliver one row or N. AFAICS the spec defines the result of this query
as a "grouped table" with one group, and in every other context
involving grouped tables you get only one output row per group; but
I don't see that spelled out for this case.

Comments? Anyone want to opine on the legality of this, or try it on
some other DBMSes?

regards, tom lane

From bouncefilter Thu Oct 7 10:52:39 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA78782
for <pgsql-hackers@postgresql.org>; Thu, 7 Oct 1999 10:52:23 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11ZEu2-000D2D-0K; Thu, 7 Oct 1999 14:52:18 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id QAA11474;
Thu, 7 Oct 1999 16:54:02 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5J2R>; Thu, 7 Oct 1999 15:50:26 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E6A2@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: huffmana@ppc.pims.org
Cc: pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] Re: PostgreSQL Help
Date: Thu, 7 Oct 1999 15:50:25 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

The column width bug was fixed in 6.5.2, so it should return the correct
result. However, the 6.5.2 driver won't work with 6.2.1, as they use a
different protocol.

As for MultiByte strings, you need to compile the backend to accept them
(someone correct me if I'm wrong here).

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: wieck@debis.com [mailto:wieck@debis.com]
Sent: 07 October 1999 15:11
To: huffmana@ppc.pims.org
Cc: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] Re: PostgreSQL Help

Dear Jan,

Don't know why you're asking me - I'm not involved in JDBC
nor am I in the multibyte stuff.

I've included the hackers list into this response - maybe
someone else can comment on it?

Jan

I am using Java with JDBC (from a PC using VisualCafe Database

Edition)

to run an application using PostgreSQL 6.2.1 (on a Sparc). Everything
is running fine except for a string problem. The Postmaster says (when
loading data from the database into the text fields of the GUI):
"ERROR: MultiByte strings (MB) must be enabled to use this function"

The DOS prompt (where the Visual Cafe development environment runs an
Applet) tells me:
"The maximum width size for column 3 is: 17"

And this is for a varchar(43) field. When I enter a string into the
column from my Java text field I get the diagnostic:
"Invalid value for the column: product_name"

I figure that all I have to do is enable MB but I can't find it. If

you

have not encountered this problem before, do you know of a user group
where I can post a question.

Sincerely,

Allan in Belgique

Allan@ppc.pims.org

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

From bouncefilter Thu Oct 7 13:46:42 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA07969
for <hackers@postgresql.org>; Thu, 7 Oct 1999 13:46:14 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:3543 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rzBlE251940>;
Thu, 7 Oct 1999 19:45:52 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11ZEz5-0000Ej-00; Thu, 07 Oct 1999 16:57:31 +0200
Date: Thu, 7 Oct 1999 16:57:31 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] psql and comments
In-Reply-To: <199910061817.OAA15421@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.9910071638570.848-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 6, Bruce Momjian mentioned:

postgres=> select 'hi'; -- comment

But aren't they _in_ a new statement, that begins with '--'?

Good point. But it's still kind of counterintuitive, isn't it? Especially
since something that begins with a '--' can't ever become a useful
statement. The problem seems to be in the parsing stages: the query is
send off before the comment is encountered.

The alternative solution of putting query and comment on the same line
would be
=> select 'hi' -- comment ;
but that doesn't work at all obviously.

Meanwhile it might be worth pondering if
=> select 'hi' -- comment \g
should be allowed, since
=> select 'hi' \g -- comment
does something different. (And try removing that file if you're an
unexperienced user.)

Regarding that last line, I just discovered a possible incompatibility
between the official and my current version. The official version creates
a file "-- comment" whereas mine makes a file "--" because I now have word
splitting and quoting rules and the like (so \g '-- comment' would
work). Something to else ponder.

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e/

From bouncefilter Thu Oct 7 11:32:42 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 LAA83808
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 11:31:47 -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 PAA28114;
Thu, 7 Oct 1999 15:27:07 GMT
Sender: lockhart@hub.org
Message-ID: <37FCBBCB.A4E1B486@alumni.caltech.edu>
Date: Thu, 07 Oct 1999 15:27:07 +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: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
References: <199910061354.JAA09036@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

On a separate note, should we support HAVING without any aggregates?

Sure, it is allowed by the SQL92 spec (as are various other
combinations with and without GROUP and HAVING). But it adds no real
functionality, and this is the first report of anyone even trying it,
since the same behavior is covered by simpler, more common queries.
Doesn't seem to be a high priority...

- Thomas

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

From bouncefilter Thu Oct 7 11:33:40 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 LAA83908
for <hackers@postgresql.org>; Thu, 7 Oct 1999 11:33:25 -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 PAA28120;
Thu, 7 Oct 1999 15:30:08 GMT
Sender: lockhart@hub.org
Message-ID: <37FCBC80.970E2C07@alumni.caltech.edu>
Date: Thu, 07 Oct 1999 15:30:08 +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: Peter Eisentraut <peter_e@gmx.net>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: psql and comments
References: <Pine.LNX.4.10.9910062138470.1744-100000@peter-e.yi.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The question I have though is, is there a reason, besides efficiency, that
psql doesn't just send the comment to the backend with the query? The
backend does accept comments last time I checked. Perhaps someone will one
day write something that makes some use of those comments on the backend
(thus conflicting with the very definition of "comment", but maybe a
logger) and it would remove some load out of psql.

Efficiency is all, along with (probably) the backend being unhappy
getting *only* a comment and no query.

- Thomas

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

From bouncefilter Thu Oct 7 12:31:41 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 MAA91234
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 12:31: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 MAA01318;
Thu, 7 Oct 1999 12:17:40 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910071617.MAA01318@candle.pha.pa.us>
Subject: Re: [HACKERS] password in pg_shadow
In-Reply-To: <Pine.LNX.3.96.991007113437.30842A-100000@ara.zf.jcu.cz> from
Zakkr at "Oct 7, 1999 11:54:42 am"
To: Zakkr <zakkr@zf.jcu.cz>
Date: Thu, 7 Oct 1999 12:17:40 -0400 (EDT)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Is all in next example good? See:

abil=> CREATE USER myname WITH PASSWORD BuBuBuBu;
CREATE USER ^^^^^^^^^^

abil=> select * from pg_shadow;
usename |usesysid|usecreatedb|usetrace|usesuper|usecatupd|passwd |valuntil
myname | 5808|f |f |f |f |bubububu |
^^^^^^^^
(4 rows)

Why is in pg_shadow.passwd low case only?

Try putting quotes aroud the password.

-- 
  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 Thu Oct 7 12:31:41 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 MAA91238
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 12:31:28 -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 MAA01325;
Thu, 7 Oct 1999 12:17:57 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910071617.MAA01325@candle.pha.pa.us>
Subject: Re: [HACKERS] password in pg_shadow
In-Reply-To: <Pine.LNX.3.96.991007113437.30842A-100000@ara.zf.jcu.cz> from
Zakkr at "Oct 7, 1999 11:54:42 am"
To: Zakkr <zakkr@zf.jcu.cz>
Date: Thu, 7 Oct 1999 12:17:57 -0400 (EDT)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Is all in next example good? See:

abil=> CREATE USER myname WITH PASSWORD BuBuBuBu;
CREATE USER ^^^^^^^^^^

abil=> select * from pg_shadow;
usename |usesysid|usecreatedb|usetrace|usesuper|usecatupd|passwd |valuntil
myname | 5808|f |f |f |f |bubububu |
^^^^^^^^
(4 rows)

Why is in pg_shadow.passwd low case only?

Sorry, try putting _double_ quotes aroud the password.

-- 
  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 Thu Oct 7 12:36:48 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA91935
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 12:35:52 -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 MAA01926;
Thu, 7 Oct 1999 12:35:19 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910071635.MAA01926@candle.pha.pa.us>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
In-Reply-To: <000b01bf10aa$4816c600$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Oct 7, 1999 06:56:52 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Thu, 7 Oct 1999 12:35:19 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

I'm planning to implement a new type of scan,scan by TID.
It's on TODO * Allow WHERE restriction on ctid.
First,I want to define an equal operator between TID.

Certainly, or perhaps it would be better to recycle an OID from
farther down? We have some open values, and if you only need a few it
would work well.

You probably already know this, but just in case,

cd src/include/catalog
./unused_oids

I didn't know it.
Thanks.

Oops, no mention of that in the developers FAQ. Let me do that now.

I would use OIDs for '=' operator between TIDs as follows.
387 for = (tid, tid)
1292 for tideq(tid, tid)

Unfortunately,TIDs are changed by UPDATE operations.
So we would need some functions in order to get the latest
TID of a specified tuple such as
currtid(relationid/name, tid) which returns tid.
I would provide functions for both relid and relname and
use 1293-1294 for OIDs of these functions.

Comments ?
If there's no objection,I would commit them to the current tree.

Sounds good.

Moreover,we would need to know TIDs of inserted tuples.
What is a reasonable way to do so ?
1. Add TID to return_info of INSERT commands.
2. Provide a function to get TID of the last inserted tuple
of the session(backend).

Either sounds good.

-- 
  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 Thu Oct 7 12:38:58 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA92226
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 12:38:33 -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 MAA01976;
Thu, 7 Oct 1999 12:36:57 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910071636.MAA01976@candle.pha.pa.us>
Subject: Re: [HACKERS] union and LIMIT problem
In-Reply-To: <m11ZALW-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 7, 1999 12:00:22 pm"
To: Jan Wieck <wieck@debis.com>
Date: Thu, 7 Oct 1999 12:36:57 -0400 (EDT)
CC: oleg@sai.msu.su, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Does anybody know how to use UNION and LIMIT together ?
I want to get 10 rows from publications and 10 rows
from keys.

select msg_id from publications limit 10 union
select key_id from keys limit 10
produces
ERROR: parser: parse error at or near "union

select msg_id from publications union
select key_id from keys limit 10
produces something I wasn't expected

I have on the TODO list:

* UNION with LIMIT fails

and must fail by it's implementation. LIMIT is handled by the
outermost executor loop, suppressing OFFSET result tuples and
stopping execution after LIMIT results sent to the client.

Ah, but it works sometimes:

so we would need to get it working, or disable it from happening.

-- 
  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 Thu Oct 7 12:41:41 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA92776
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 12:40:41 -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 MAA02069;
Thu, 7 Oct 1999 12:38:50 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910071638.MAA02069@candle.pha.pa.us>
Subject: Re: [HACKERS] password in pg_shadow
In-Reply-To: <Pine.LNX.3.96.991007123915.5015A-100000@ara.zf.jcu.cz> from
Zakkr
at "Oct 7, 1999 12:48:11 pm"
To: Zakkr <zakkr@zf.jcu.cz>
Date: Thu, 7 Oct 1999 12:38:50 -0400 (EDT)
CC: Peter Mount <petermount@it.maidstone.gov.uk>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 7 Oct 1999, Peter Mount wrote:

I think its because the parser forces everything outside of quotes to
being lowercase.

Yes, it is right, but in tutorial is nothing about it, In tutorial is
this bad example:

CREATE USER davide WITH PASSWORD jw8s0F4

Password is very important....

Zakkr

Fixed documentation. Thanks.

-- 
  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 Thu Oct 7 12:44:41 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA93239
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 12:44:04 -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 MAA02123;
Thu, 7 Oct 1999 12:41:53 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910071641.MAA02123@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <37FC9D0A.A37F79F2@alumni.caltech.edu> from Thomas Lockhart at
"Oct 7, 1999 01:15:54 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Thu, 7 Oct 1999 12:41:53 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>, luuk@wxs.nl,
Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

My opinion on this tends to be that, in the HAVING case, we are the only
one that doesn't support it w/o aggregates, so we altho we do follow the
spec, we are making it slightly more difficult to migrate from 'the
others' to us...

We follow the spec in what we support, but the spec *does* allow
HAVING w/o aggregates (and w/o any GROUP BY clause).

Tom, imho we absolutely should *not* emit warnings for unusual but
legal constructs. Our chapter on "syntax" can start addressing these
kinds of topics, but the backend probably isn't the place to teach SQL
style...

OK. Agreed.

-- 
  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 Thu Oct 7 12:44:43 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA93255
for <hackers@postgreSQL.org>; Thu, 7 Oct 1999 12:44:14 -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 MAA02150;
Thu, 7 Oct 1999 12:43:48 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910071643.MAA02150@candle.pha.pa.us>
Subject: Re: [HACKERS] psql and comments
In-Reply-To: <37FCA084.ADB71A9B@alumni.caltech.edu> from Thomas Lockhart at
"Oct 7, 1999 01:30:44 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Thu, 7 Oct 1999 12:43:48 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

The following example shows psql correctly clearing its input buffer
when a line containing *only* a comment is seen, but not completely
clearing the buffer (or not realizing that it is cleared; note the
changed prompt) if the comment is at the end of a valid query.

postgres=> -- comment
postgres=> select 'hi'; -- comment
?column?
--------
hi
(1 row)

postgres->

But aren't they _in_ a new statement, that begins with '--'?

?? Sure, that's what psql thinks. But the first case shown above
should also begin a new statement, changing the prompt (it doesn't,
because after stripping the comment there are zero blanks in the
line). I don't think that is the right behavior though.

Things aren't a big problem the way they stand, but istm that a
completely blank line (after stripping single-line comments) may as
well be the same as an empty line,and that psql could figure that out.

I see your point in the above example. I will wait for the psql/libpq
cleaner-upper to finish, and take a look at it.

-- 
  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 Thu Oct 7 12:59:42 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 MAA95468
for <hackers@postgreSQL.org>; Thu, 7 Oct 1999 12:59:32 -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 MAA02332;
Thu, 7 Oct 1999 12:54:12 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910071654.MAA02332@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: psql and comments
In-Reply-To: <37FCBC80.970E2C07@alumni.caltech.edu> from Thomas Lockhart at
"Oct 7, 1999 03:30:08 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Thu, 7 Oct 1999 12:54:12 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

The question I have though is, is there a reason, besides efficiency, that
psql doesn't just send the comment to the backend with the query? The
backend does accept comments last time I checked. Perhaps someone will one
day write something that makes some use of those comments on the backend
(thus conflicting with the very definition of "comment", but maybe a
logger) and it would remove some load out of psql.

Efficiency is all, along with (probably) the backend being unhappy
getting *only* a comment and no query.

That is fixed now. External interfaces showed problems, as the perl
MySQL test showed.

-- 
  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 Thu Oct 7 13:32:42 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 NAA00864
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 13:32:01 -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 NAA29689;
Thu, 7 Oct 1999 13:29:43 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Jan Wieck <wieck@debis.com>, oleg@sai.msu.su, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] union and LIMIT problem
In-reply-to: Your message of Thu, 7 Oct 1999 12:36:57 -0400 (EDT)
<199910071636.MAA01976@candle.pha.pa.us>
Date: Thu, 07 Oct 1999 13:29:42 -0400
Message-ID: <29687.939317382@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

* UNION with LIMIT fails

and must fail by it's implementation. LIMIT is handled by the
outermost executor loop, suppressing OFFSET result tuples and
stopping execution after LIMIT results sent to the client.

Ah, but it works sometimes:

Well, the real question is what do you mean by "works" or "fails".
In particular, do you think that LIMIT applies to the overall result
of the whole query, or to any one sub-select?

IIRC, ORDER BY is supposed to apply to the end result (and you can
only write it at the very end of the query, not after a sub-select),
and I'd vote for making LIMIT work the same. In which case the
executor should be fine, and we probably just have a problem with
the parser hanging the info on the wrong node of the querytree...

regards, tom lane

From bouncefilter Thu Oct 7 13:37:42 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 NAA06351
for <hackers@postgreSQL.org>; Thu, 7 Oct 1999 13:36:56 -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 NAA29726;
Thu, 7 Oct 1999 13:35:37 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and comments
In-reply-to: Your message of Thu, 7 Oct 1999 12:43:48 -0400 (EDT)
<199910071643.MAA02150@candle.pha.pa.us>
Date: Thu, 07 Oct 1999 13:35:36 -0400
Message-ID: <29724.939317736@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Things aren't a big problem the way they stand, but istm that a
completely blank line (after stripping single-line comments) may as
well be the same as an empty line,and that psql could figure that out.

There was talk earlier of changing the behavior so that psql would
forward comments to the backend, rather than stripping them. One
potential annoyance if we do that is that (I think) all the regress
test expected outputs will change because comments will then appear
in them.

I'd be inclined to maintain the current behavior. psql has to have a
simple parser in it anyway to know when it has a complete query it can
send to the backend --- so it must know what is a comment and what is
not. Removing the comments is not really going to add much complexity
AFAICS.

regards, tom lane

From bouncefilter Thu Oct 7 13:40:42 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA07031
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 13:40:07 -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 NAA02643;
Thu, 7 Oct 1999 13:39:40 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910071739.NAA02643@candle.pha.pa.us>
Subject: Re: [HACKERS] union and LIMIT problem
In-Reply-To: <29687.939317382@sss.pgh.pa.us> from Tom Lane at "Oct 7,
1999 01:29:42 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 7 Oct 1999 13:39:40 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>, oleg@sai.msu.su, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

* UNION with LIMIT fails

and must fail by it's implementation. LIMIT is handled by the
outermost executor loop, suppressing OFFSET result tuples and
stopping execution after LIMIT results sent to the client.

Ah, but it works sometimes:

Well, the real question is what do you mean by "works" or "fails".
In particular, do you think that LIMIT applies to the overall result
of the whole query, or to any one sub-select?

Should apply to overall result, like ORDER BY.

IIRC, ORDER BY is supposed to apply to the end result (and you can
only write it at the very end of the query, not after a sub-select),
and I'd vote for making LIMIT work the same. In which case the
executor should be fine, and we probably just have a problem with
the parser hanging the info on the wrong node of the querytree...

regards, tom lane

-- 
  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 Thu Oct 7 13:47:42 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 NAA08070
for <hackers@postgreSQL.org>; Thu, 7 Oct 1999 13:47: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 NAA29775;
Thu, 7 Oct 1999 13:45:10 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: psql and comments
In-reply-to: Your message of Thu, 7 Oct 1999 12:54:12 -0400 (EDT)
<199910071654.MAA02332@candle.pha.pa.us>
Date: Thu, 07 Oct 1999 13:45:10 -0400
Message-ID: <29773.939318310@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Efficiency is all, along with (probably) the backend being unhappy
getting *only* a comment and no query.

That is fixed now.

Is it? postgres.c treats an all-whitespace input as an empty query,
but if you pass it a comment and nothing else it will cycle the parser/
planner/executor, and I'm not sure every phase of that process behaves
reasonably on empty input. Also, that path will not produce the
"empty query" response code that you get from all-whitespace input.
I *think* libpq doesn't depend on that anymore, but other frontend
libraries might...

regards, tom lane

From bouncefilter Thu Oct 7 13:51:42 1999
Received: from fep10-svc.tin.it (mta10-acc.tin.it [212.216.176.41])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA08709
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 13:50:43 -0400 (EDT)
(envelope-from rcorna@tin.it)
Received: from tin.it ([212.216.128.206]) by fep10-svc.tin.it
(InterMail v4.01.01.02 201-229-111-106) with ESMTP
id <19991007175006.EFKU29514.fep10-svc@tin.it>;
Thu, 7 Oct 1999 19:50:06 +0200
Sender: root
Message-ID: <37FCDCA9.219C3FB8@tin.it>
Date: Thu, 07 Oct 1999 19:47:21 +0200
From: Roberto Cornacchia <rcorna@tin.it>
Organization: tin.it
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Top N queries and disbursion
References: <27827.936719839@sss.pgh.pa.us> <37D56459.F99B649B@tin.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

We have finished our work on optimization of Top N queries (with clauses
STOP AFTER ... FOR EACH ... RANK BY ...) now it's time of validating it
with performance tests: since we are working on snapshots of the 6.6
release (now we are using snapshot dated 9/13/99) we are afraid of
instability problems to affect the results. Could you give us any
suggestion about this? We are quite close to the degree day, so we have
to optimize time usage...
BTW, first results seem to be interesting.

We would ask you for a last thing.
We need to estimate the number of distinct values of an attribute. We
thought 1/disbursion was the right solution, but the results were quite
wrong:
with 100 distinct values of an attribute uniformly distribuited in a
relation of 10000 tuples, disbursion was estimated as 0.002275, giving
us 440 distinct values. We have seen this disbursion estimates
result also in bad join selectivities estimate.
Could this be due to a bad disbursion estimate or is our solution
completely wrong?
Thanks a lot

Roberto Cornacchia
Andrea Ghidini

From bouncefilter Thu Oct 7 13:52:42 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA08880
for <hackers@postgreSQL.org>; Thu, 7 Oct 1999 13:52:31 -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 NAA02744;
Thu, 7 Oct 1999 13:50:30 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910071750.NAA02744@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: psql and comments
In-Reply-To: <29773.939318310@sss.pgh.pa.us> from Tom Lane at "Oct 7,
1999 01:45:10 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 7 Oct 1999 13:50:30 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Efficiency is all, along with (probably) the backend being unhappy
getting *only* a comment and no query.

That is fixed now.

Is it? postgres.c treats an all-whitespace input as an empty query,
but if you pass it a comment and nothing else it will cycle the parser/
planner/executor, and I'm not sure every phase of that process behaves
reasonably on empty input. Also, that path will not produce the
"empty query" response code that you get from all-whitespace input.
I *think* libpq doesn't depend on that anymore, but other frontend
libraries might...

postgres -D /u/pg/data test

POSTGRES backend interactive interface
$Revision: 1.130 $ $Date: 1999/09/29 16:06:10 $

backend> -- test
backend>

Is that what you mean?

-- 
  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 Sat Oct 9 08:38:19 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA47201
for <hackers@postgresql.org>; Sat, 9 Oct 1999 08:37:32 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:1757 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rznPu168225>;
Sat, 9 Oct 1999 14:37:14 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11ZLO4-0000Ye-00; Thu, 07 Oct 1999 23:47:44 +0200
Date: Thu, 7 Oct 1999 23:47:43 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] psql and comments
In-Reply-To: <199910071643.MAA02150@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.9910072343450.848-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 7, Bruce Momjian mentioned:

Things aren't a big problem the way they stand, but istm that a
completely blank line (after stripping single-line comments) may as
well be the same as an empty line,and that psql could figure that out.

I see your point in the above example. I will wait for the psql/libpq
cleaner-upper to finish, and take a look at it.

Oh, now I'm cleaning up libpq as well??? 8-}

Well anyway, by a vote of 1 1/2 to 1 psql will strip all comments before
sending a query, probably in a C pre-processor kind of way.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sat Oct 9 08:38:19 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA47200
for <hackers@postgresql.org>; Sat, 9 Oct 1999 08:37:27 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:1751 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rznPk180513>;
Sat, 9 Oct 1999 14:37:04 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11ZLjL-0000ZR-00; Fri, 08 Oct 1999 00:09:43 +0200
Date: Fri, 8 Oct 1999 00:09:43 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] psql and comments
In-Reply-To: <29724.939317736@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.10.9910072348440.848-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 7, Tom Lane mentioned:

There was talk earlier of changing the behavior so that psql would
forward comments to the backend, rather than stripping them. One
potential annoyance if we do that is that (I think) all the regress
test expected outputs will change because comments will then appear
in them.

That is a somewhat separate issue, but good that you bring it up. In my
cleaning ways I noticed that the -e vs. -E switches weren't applied
correctly so I set that straight to an extent. The regression tests rely
on -e to echo the query back correctly, not the one actually sent to the
backend, so that could be tweaked.

Luckily, the regression tests don't make extensive use of the backslash
commands, the issue being that their output might change. I only found
three backslash commands in the whole regression tests. One occurence does
something like this:

some query;
*** comment
*** comment
\p
\r
more queries;

which should probably be changed anyway to something like

-- comment
-- comment

The other case is
CREATE TEMP TABLE temptest(col int);
-- test temp table deletion
\c regression
SELECT * FROM temptest;
which still works as I just confirmed, and the output of \c gets eaten in
-q mode anyway.

Seems it's still safe.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Oct 7 19:17: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 TAA55207
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 19:17:34 -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 TAA01080;
Thu, 7 Oct 1999 19:16:59 -0400 (EDT)
To: Roberto Cornacchia <rcorna@tin.it>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: Top N queries and disbursion
In-reply-to: Your message of Thu, 07 Oct 1999 19:47:21 +0200
<37FCDCA9.219C3FB8@tin.it>
Date: Thu, 07 Oct 1999 19:16:58 -0400
Message-ID: <1078.939338218@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Roberto Cornacchia <rcorna@tin.it> writes:

... since we are working on snapshots of the 6.6
release (now we are using snapshot dated 9/13/99) we are afraid of
instability problems to affect the results. Could you give us any
suggestion about this? We are quite close to the degree day, so we have
to optimize time usage...

If you don't want to spend time tracking development changes then you
probably ought to stick with the snapshot you have. I don't see any
reason that you should try to track changes right now...

We need to estimate the number of distinct values of an attribute. We
thought 1/disbursion was the right solution, but the results were quite
wrong:

No, it's certainly not the right thing. To my understanding, disbursion
is a measure of the frequency of the most common value of an attribute;
but that tells you very little about how many other values there are.
1/disbursion is a lower bound on the number of values, but it wouldn't
be a good estimate unless you had reason to think that the values were
pretty evenly distributed. There could be a *lot* of very-infrequent
values.

with 100 distinct values of an attribute uniformly distribuited in a
relation of 10000 tuples, disbursion was estimated as 0.002275, giving
us 440 distinct values.

This is an illustration of the fact that Postgres' disbursion-estimator
is pretty bad :-(. It usually underestimates the frequency of the most
common value, unless the most common value is really frequent
(probability > 0.2 or so). I've been trying to think of a more accurate
way of figuring the statistic that wouldn't be unreasonably slow.
Or, perhaps, we should forget all about disbursion and adopt some other
statistic(s).

regards, tom lane

From bouncefilter Thu Oct 7 19:29: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 TAA56410
for <hackers@postgresql.org>; Thu, 7 Oct 1999 19:29:37 -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 TAA01130;
Thu, 7 Oct 1999 19:28:15 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Re: psql and comments
In-reply-to: Your message of Thu, 7 Oct 1999 13:50:30 -0400 (EDT)
<199910071750.NAA02744@candle.pha.pa.us>
Date: Thu, 07 Oct 1999 19:28:15 -0400
Message-ID: <1128.939338895@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

That is fixed now.

Is it? postgres.c treats an all-whitespace input as an empty query,
but if you pass it a comment and nothing else it will cycle the parser/
planner/executor, and I'm not sure every phase of that process behaves
reasonably on empty input. Also, that path will not produce the
"empty query" response code that you get from all-whitespace input.
I *think* libpq doesn't depend on that anymore, but other frontend
libraries might...

postgres -D /u/pg/data test

POSTGRES backend interactive interface
$Revision: 1.130 $ $Date: 1999/09/29 16:06:10 $

backend> -- test
backend>

Is that what you mean?

OK, so the parser/planner/executor can cope with dummy input. That's
good. There's still the problem of returning an 'empty query' response
to the frontend. I think you'd probably need to hack up postgres.c
so that when the querytree list produced by the parser is NIL, the
IsEmptyQuery flag gets set --- this could be done instead of, rather
than in addition to, the current test for an all-whitespace input
buffer.

regards, tom lane

From bouncefilter Thu Oct 7 19:55:46 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA58945
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 19:54:52 -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 TAA09358;
Thu, 7 Oct 1999 19:53:17 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910072353.TAA09358@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Top N queries and disbursion
In-Reply-To: <1078.939338218@sss.pgh.pa.us> from Tom Lane at "Oct 7,
1999 07:16:58 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 7 Oct 1999 19:53:17 -0400 (EDT)
CC: Roberto Cornacchia <rcorna@tin.it>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

No, it's certainly not the right thing. To my understanding, disbursion
is a measure of the frequency of the most common value of an attribute;
but that tells you very little about how many other values there are.
1/disbursion is a lower bound on the number of values, but it wouldn't
be a good estimate unless you had reason to think that the values were
pretty evenly distributed. There could be a *lot* of very-infrequent
values.

with 100 distinct values of an attribute uniformly distribuited in a
relation of 10000 tuples, disbursion was estimated as 0.002275, giving
us 440 distinct values.

This is an illustration of the fact that Postgres' disbursion-estimator
is pretty bad :-(. It usually underestimates the frequency of the most
common value, unless the most common value is really frequent
(probability > 0.2 or so). I've been trying to think of a more accurate
way of figuring the statistic that wouldn't be unreasonably slow.
Or, perhaps, we should forget all about disbursion and adopt some other
statistic(s).

Yes, you have the crux of the issue. I wrote it because it was the best
thing I could think of, but it is non-optimimal. Because all the
optimal solutions seemed too slow to me, I couldn't think of a better
one.

Here is my narrative on it from vacuum.c:

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

* We compute the column min, max, null and non-null counts.
* Plus we attempt to find the count of the value that occurs most
* frequently in each column
* These figures are used to compute the selectivity of the column
*
* We use a three-bucked cache to get the most frequent item
* The 'guess' buckets count hits. A cache miss causes guess1
* to get the most hit 'guess' item in the most recent cycle, and
* the new item goes into guess2. Whenever the total count of hits
* of a 'guess' entry is larger than 'best', 'guess' becomes 'best'.
*
* This method works perfectly for columns with unique values, and columns
* with only two unique values, plus nulls.
*
* It becomes less perfect as the number of unique values increases and
* their distribution in the table becomes more random.

-- 
  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 Thu Oct 7 19:56:47 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA59266
for <hackers@postgresql.org>; Thu, 7 Oct 1999 19:56:18 -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 TAA09368;
Thu, 7 Oct 1999 19:54:29 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910072354.TAA09368@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: psql and comments
In-Reply-To: <1128.939338895@sss.pgh.pa.us> from Tom Lane at "Oct 7,
1999 07:28:15 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 7 Oct 1999 19:54:29 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

OK, so the parser/planner/executor can cope with dummy input. That's
good. There's still the problem of returning an 'empty query' response
to the frontend. I think you'd probably need to hack up postgres.c
so that when the querytree list produced by the parser is NIL, the
IsEmptyQuery flag gets set --- this could be done instead of, rather
than in addition to, the current test for an all-whitespace input
buffer.

The system may already return that. My gram.y code tests for empty
queries, and should be doing the right thing. Not sure, because I am
not sure what to check for.

-- 
  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 Thu Oct 7 21:41:47 1999
Received: from ext04.sra.co.jp (IDENT:root@ykh28DS45.kng.mesh.ad.jp
[133.205.214.45]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA72062
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 21:41:44 -0400 (EDT)
(envelope-from t-ishii@ext04.sra.co.jp)
Received: from ext04.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext04.sra.co.jp (8.8.8/8.8.8) with ESMTP id KAA14848;
Fri, 8 Oct 1999 10:34:39 +0900
Message-Id: <199910080134.KAA14848@ext04.sra.co.jp>
To: Peter Mount <petermount@it.maidstone.gov.uk>
cc: huffmana@ppc.pims.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: PostgreSQL Help
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Thu, 07 Oct 1999 15:50:25 +0100.
<1B3D5E532D18D311861A00600865478C25E6A2@exchange1.nt.maidstone.gov.uk>
Date: Fri, 08 Oct 1999 10:34:39 +0900
Sender: t-ishii@ext04.sra.co.jp

Peter,

As for MultiByte strings, you need to compile the backend to accept them
(someone correct me if I'm wrong here).

I suspect he is not running PostgreSQL 6.2.1 becasue the multibyte
capability has been introduced since 6.3.2. Anyway, the particular
message:

"ERROR: MultiByte strings (MB) must be enabled to use this function"

is raised if getdatabaseencoding() is called and the backend is not
compiled with MB option as you said. But the question is: does
the standard PostgreSQL JDBC driver call getdatabaseencoding()?
---
Tatsuo Ishii

From bouncefilter Thu Oct 7 21:48:47 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA72647
for <pgsql-hackers@postgreSQL.org>; Thu, 7 Oct 1999 21:47:56 -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 VAA19377;
Thu, 7 Oct 1999 21:47:53 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910080147.VAA19377@candle.pha.pa.us>
Subject: Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison
In-Reply-To: <7727DB8032.AAB336B@smtp02.wxs.nl> from Luuk de Boer at "Oct 8,
1999 02:06:18 am"
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Thu, 7 Oct 1999 21:47:53 -0400 (EDT)
CC: luuk@wxs.nl
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM939347273-2540-2_
Content-Transfer-Encoding: 7bit

--ELM939347273-2540-2_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

tested your patch and there was no change in result. I think it
wouldn't be nice if this will point out a bug in the perl pg driver
because I can't imagine that you would like to do such things in
there ...

the new crash-me tests results are sent to monty so I think he will
put them online tomorrow (today for you I think). I also did a test
run on oracle and on a microsoft sql 7 server on windows nt (oracle
on linux).

Enclosed is a patch that shows our perl interface can't handle '--'
comments, even though psql and the backend directly can handle them.

To add complexity to this, the backend -d3 log from the perl test
session shows the same query that works perfectly in a direct backend
connection.

Can anyone suggest a cause for this?

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

StartTransactionCommand
query: CREATE TABLE person (id int4, name char(16)) --test
ERROR: parser: parse error at or near "--"
AbortCurrentTransaction

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

--ELM939347273-2540-2_
Content-Type: text/plain
Content-Disposition: inline; filename="/bjm/diff"
Content-Transfer-Encoding: 7bit

*** ./interfaces/perl5/test.pl.orig	Thu Oct  7 20:25:13 1999
--- ./interfaces/perl5/test.pl	Thu Oct  7 20:41:40 1999
***************
*** 147,153 ****

######################### create and insert into table

! $result = $conn->exec("CREATE TABLE person (id int4, name char(16))");
  die $conn->errorMessage unless PGRES_COMMAND_OK eq $result->resultStatus;
  my $cmd = $result->cmdStatus;
  ( "CREATE" eq $cmd )
--- 147,153 ----

######################### create and insert into table

! $result = $conn->exec("CREATE TABLE person (id int4, name char(16)) -- /* test*/");
die $conn->errorMessage unless PGRES_COMMAND_OK eq $result->resultStatus;
my $cmd = $result->cmdStatus;
( "CREATE" eq $cmd )

--ELM939347273-2540-2_

--ELM939347273-2540-2_--

From bouncefilter Fri Oct 8 00:15:49 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA90483
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 00:15:03 -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 AAA29775
for pgsql-hackers@postgreSQL.org; Fri, 8 Oct 1999 00:14:31 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910080414.AAA29775@candle.pha.pa.us>
Subject: Cleanup of debugging flags, SSL
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Fri, 8 Oct 1999 00:14: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

I have cleaned up the SSL -is mess. Flag is no -l, with check that if
they use -l, they also must use -i or they get an error message on
startup.

I fixed some -d debug handling that was broken in postmaster and
postgres programs.

Another PERL variable name fix.

Documentation updates.

-- 
  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 Fri Oct 8 00:27:49 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA04561
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 00:26:58 -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 AAA01687;
Fri, 8 Oct 1999 00:26:30 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910080426.AAA01687@candle.pha.pa.us>
Subject: Re: [HACKERS] Cleanup of debugging flags, SSL
In-Reply-To: <199910080414.AAA29775@candle.pha.pa.us> from Bruce Momjian at
"Oct 8, 1999 00:14:31 am"
To: Bruce Momjian <maillist@candle.pha.pa.us>
Date: Fri, 8 Oct 1999 00:26:29 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have cleaned up the SSL -is mess. Flag is no -l, with check that if

^^
now a -l flag for SSL

Sorry.

-- 
  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 Fri Oct 8 01:03:50 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA08155
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 01:03:30 -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 BAA09219;
Fri, 8 Oct 1999 01:03:22 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910080503.BAA09219@candle.pha.pa.us>
Subject: Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison
In-Reply-To: From "(env:" "maillist)" at "Oct 7, 1999 09:47:53 pm"
To: luuk@wxs.nl
Date: Fri, 8 Oct 1999 01:03:22 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM939359002-23595-0_
Content-Transfer-Encoding: 7bit

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

tested your patch and there was no change in result. I think it
wouldn't be nice if this will point out a bug in the perl pg driver
because I can't imagine that you would like to do such things in
there ...

the new crash-me tests results are sent to monty so I think he will
put them online tomorrow (today for you I think). I also did a test
run on oracle and on a microsoft sql 7 server on windows nt (oracle
on linux).

Enclosed is a patch that shows our perl interface can't handle '--'
comments, even though psql and the backend directly can handle them.

To add complexity to this, the backend -d3 log from the perl test
session shows the same query that works perfectly in a direct backend
connection.

Can anyone suggest a cause for this?

OK, fix attached. Seems our "--" comments required a newline on the
end, which was not being done in interfaces like Perl. Added a test in
the perl code for the trailing comments, and patched scan.l.

Seems this should only be applied to 6.6. Applied to 6.6.

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

--ELM939359002-23595-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/bjm/diff"
Content-Transfer-Encoding: 7bit

? doc/src/sgml/install.htm
? src/log
? src/config.log
? src/config.cache
? src/config.status
? src/GNUmakefile
? src/Makefile.global
? src/Makefile.custom
? src/backend/fmgr.h
? src/backend/parse.h
? src/backend/postgres
? src/backend/global1.bki.source
? src/backend/local1_template1.bki.source
? src/backend/global1.description
? src/backend/local1_template1.description
? src/backend/bootstrap/bootparse.c
? src/backend/bootstrap/bootstrap_tokens.h
? src/backend/bootstrap/bootscanner.c
? src/backend/catalog/genbki.sh
? src/backend/catalog/global1.bki.source
? src/backend/catalog/global1.description
? src/backend/catalog/local1_template1.bki.source
? src/backend/catalog/local1_template1.description
? src/backend/port/Makefile
? src/backend/utils/Gen_fmgrtab.sh
? src/backend/utils/fmgr.h
? src/backend/utils/fmgrtab.c
? src/bin/cleardbdir/cleardbdir
? src/bin/createdb/createdb
? src/bin/createlang/createlang
? src/bin/createuser/createuser
? src/bin/destroydb/destroydb
? src/bin/destroylang/destroylang
? src/bin/destroyuser/destroyuser
? src/bin/initdb/initdb
? src/bin/initlocation/initlocation
? src/bin/ipcclean/ipcclean
? src/bin/pg_dump/Makefile
? src/bin/pg_dump/pg_dump
? src/bin/pg_id/pg_id
? src/bin/pg_passwd/pg_passwd
? src/bin/pg_version/Makefile
? src/bin/pg_version/pg_version
? src/bin/pgtclsh/mkMakefile.tcldefs.sh
? src/bin/pgtclsh/mkMakefile.tkdefs.sh
? src/bin/pgtclsh/Makefile.tkdefs
? src/bin/pgtclsh/Makefile.tcldefs
? src/bin/pgtclsh/pgtclsh
? src/bin/pgtclsh/pgtksh
? src/bin/psql/Makefile
? src/bin/psql/psql
? src/include/version.h
? src/include/config.h
? src/interfaces/ecpg/lib/Makefile
? src/interfaces/ecpg/lib/libecpg.so.3.0.1
? src/interfaces/ecpg/lib/libecpg.so.3.0.3
? src/interfaces/ecpg/preproc/ecpg
? src/interfaces/libpgtcl/Makefile
? src/interfaces/libpgtcl/libpgtcl.so.2.0
? src/interfaces/libpq/Makefile
? src/interfaces/libpq/libpq.so.2.0
? src/interfaces/libpq++/Makefile
? src/interfaces/libpq++/libpq++.so.3.0
? src/interfaces/odbc/GNUmakefile
? src/interfaces/odbc/Makefile.global
? src/interfaces/perl5/blib
? src/interfaces/perl5/pm_to_blib
? src/interfaces/perl5/Pg.c
? src/interfaces/perl5/Pg.bs
? src/interfaces/perl5/Makefile
? src/lextest/lex.yy.c
? src/lextest/lextest
? src/pl/plpgsql/src/Makefile
? src/pl/plpgsql/src/mklang.sql
? src/pl/plpgsql/src/pl_gram.c
? src/pl/plpgsql/src/pl.tab.h
? src/pl/plpgsql/src/pl_scan.c
? src/pl/plpgsql/src/libplpgsql.so.1.0
? src/pl/tcl/mkMakefile.tcldefs.sh
? src/pl/tcl/Makefile.tcldefs
? src/test/regress/regress.out
? src/test/regress/regression.diffs
? src/test/regress/expected/copy.out
? src/test/regress/expected/create_function_1.out
? src/test/regress/expected/create_function_2.out
? src/test/regress/expected/misc.out
? src/test/regress/expected/constraints.out
? src/test/regress/expected/install_plpgsql.out
? src/test/regress/results/boolean.out
? src/test/regress/results/char.out
? src/test/regress/results/name.out
? src/test/regress/results/varchar.out
? src/test/regress/results/text.out
? src/test/regress/results/strings.out
? src/test/regress/results/int2.out
? src/test/regress/results/int4.out
? src/test/regress/results/int8.out
? src/test/regress/results/oid.out
? src/test/regress/results/float4.out
? src/test/regress/results/float8.out
? src/test/regress/results/numerology.out
? src/test/regress/results/point.out
? src/test/regress/results/lseg.out
? src/test/regress/results/box.out
? src/test/regress/results/path.out
? src/test/regress/results/polygon.out
? src/test/regress/results/circle.out
? src/test/regress/results/geometry.out
? src/test/regress/results/timespan.out
? src/test/regress/results/datetime.out
? src/test/regress/results/reltime.out
? src/test/regress/results/abstime.out
? src/test/regress/results/tinterval.out
? src/test/regress/results/horology.out
? src/test/regress/results/inet.out
? src/test/regress/results/comments.out
? src/test/regress/results/oidjoins.out
? src/test/regress/results/type_sanity.out
? src/test/regress/results/opr_sanity.out
? src/test/regress/results/create_function_1.out
? src/test/regress/results/create_type.out
? src/test/regress/results/create_table.out
? src/test/regress/results/create_function_2.out
? src/test/regress/results/constraints.out
? src/test/regress/results/triggers.out
? src/test/regress/results/copy.out
? src/test/regress/results/onek.data
? src/test/regress/sql/copy.sql
? src/test/regress/sql/create_function_1.sql
? src/test/regress/sql/create_function_2.sql
? src/test/regress/sql/misc.sql
? src/test/regress/sql/constraints.sql
? src/test/regress/sql/install_plpgsql.sql
? src/tools/backend/flow.eps
? src/tools/backend/flow.ps
? src/tools/backend/flow.png
? src/tools/backend/flow.tif
Index: src/backend/parser/scan.l
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/scan.l,v
retrieving revision 1.57
diff -c -r1.57 scan.l
*** src/backend/parser/scan.l	1999/09/28 03:41:36	1.57
--- src/backend/parser/scan.l	1999/10/08 04:58:23
***************
*** 167,173 ****

param \${integer}

! comment ("--"|"//").*\n

  space			[ \t\n\f]
  other			.
--- 167,173 ----

param \${integer}

! comment ("--"|"//").*

  space			[ \t\n\f]
  other			.
Index: src/interfaces/perl5/test.pl
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/interfaces/perl5/test.pl,v
retrieving revision 1.9
diff -c -r1.9 test.pl
*** src/interfaces/perl5/test.pl	1998/09/27 19:12:26	1.9
--- src/interfaces/perl5/test.pl	1999/10/08 04:58:30
***************
*** 147,153 ****

######################### create and insert into table

! $result = $conn->exec("CREATE TABLE person (id int4, name char(16))");
  die $conn->errorMessage unless PGRES_COMMAND_OK eq $result->resultStatus;
  my $cmd = $result->cmdStatus;
  ( "CREATE" eq $cmd )
--- 147,153 ----

######################### create and insert into table

! $result = $conn->exec("CREATE TABLE person (id int4, name char(16)) -- test");
die $conn->errorMessage unless PGRES_COMMAND_OK eq $result->resultStatus;
my $cmd = $result->cmdStatus;
( "CREATE" eq $cmd )

--ELM939359002-23595-0_

--ELM939359002-23595-0_--

From bouncefilter Fri Oct 8 07:16:56 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id HAA51034
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 07:16:42 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 17263 invoked by uid 1001); 8 Oct 1999 11:16:43 -0000
Date: Fri, 8 Oct 1999 07:16:43 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: pgsql-hackers@postgreSQL.org
Subject: mysql-PostgreSQL comparisons
Message-ID: <Pine.BSF.4.05.9910080705590.17006-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I'm putting together a comparison chart for mysql vs PostgreSQL. The
beginnings are at: http://hub.org/~vev/pgsql-my.html. Take a look
and tell me what's incorrect, missing, etc for the PostgreSQL stuff
for version 6.5.2. I've set up a seperate mailbox for it so none of
it gets lost. Send changes to: pgsql@michvhf.com. The address is
also on the web page.

From bouncefilter Fri Oct 8 08:38:57 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 IAA58225
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 08:37:57 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11ZZCK-0003kLC; Fri, 8 Oct 99 14:32 MET DST
Message-Id: <m11ZZCK-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: RI status report #4 (come and join)
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Fri, 8 Oct 1999 14:32:32 +0200 (MET DST)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Co-developers,

I've prepared some things and it's time now to start
contributing to this subproject.

What's done so far (I've included a little SQL script at the
end that show's what's working):

- The parser recognizes the new syntax for constraint
triggers and hands down all the new attributes into the
utility function for CREATE TRIGGER.

- The utility function for CREATE TRIGGER handles all the
new attributes so constraints can be defined with a bunch
of

CREATE CONSTRAINT TRIGGER ...

statements after CREATE TABLE.

- The parser recognizes the new SET CONSTRAINTS command.

- The trigger manager handles trigger deferred states
correctly so that circular constraint checks would be
possible by deferring trigger invocation until COMMIT.
Also it traces multiple operations on the same row and
invokes only that trigger that is defined for the
resulting operation if all operations during a transaction
are condensed.

- In backend/utils/adt/ri_triggers.c are some support
routines and the first real trigger procedures that
implement:

FOREIGN KEY ... REFERENCES ... MATCH FULL
(checks for FK existance in PK table on INSERT and
UPDATE)

FOREIGN KEY ... MATCH FULL ... ON DELETE CASCADE
(constraint deletes references from FK table on
DELETE of PK row)

I hope that's enough example implementation to get started
for you. If not, ask, ask, ask.

What we need next (what y'all shall do) is:

1. Add all functionality to ri_triggers.c required for

ON UPDATE CASCADE
ON DELETE SET NULL
ON UPDATE SET NULL
ON DELETE SET DEFAULT
ON UPDATE SET DEFAULT

2. Add full FOREIGN KEY syntax to the parser and arrange
that the appropriate CREATE CONSTRAINT TRIGGER statements
are executed at CREATE TABLE just like the CREATE INDEX
is done for PRIMARY KEY.

3. Building a test suite for FOREIGN KEY ... MATCH FULL
support.

Anyone who wants to contribute to this should at least drop
us a note on which detail he's starting to work - just to
avoid frustration. Patches should be sent to me directly and
I'll incorporate them into the CVS tree.

I'll keep my hands off from all the above now and continue to
work on the deferred trigger manager (the disk buffering
during huge transactions).

Jan

drop table t1;
drop table t2;

-- **********
-- * Create a PK and an FK table.
-- **********
create table t1 (a1 int4, b1 int4, c1 text, PRIMARY KEY (a1, b1));
create table t2 (a2 int4, b2 int4, c2 text);

-- **********
-- * Manually setup constraint triggers for t2 as if
-- *
-- * CONSTRAINT check_t2_key
-- * FOREIGN KEY (a2, b2) REFERENCES t1 (a1, b1)
-- * MATCH FULL
-- * ON DELETE CASCADE
-- *
-- * was specified in the table schema. These are the commands
-- * which should later be executed automatically during CREATE TABLE
-- * like done for the index t1_pkey due to the PRIMARY KEY constraint.
-- **********
create constraint trigger "check_t2_key" after insert on t2
deferrable initially immediate
for each row execute procedure
"RI_FKey_check_ins" ('check_t2_key', 't2', 't1', 'FULL',
'a2', 'a1', 'b2', 'b1');
create constraint trigger "check_t2_key" after update on t2
deferrable initially immediate
for each row execute procedure
"RI_FKey_check_upd" ('check_t2_key', 't2', 't1', 'FULL',
'a2', 'a1', 'b2', 'b1');
create constraint trigger "check_t2_key" after delete on t1
deferrable initially immediate
for each row execute procedure
"RI_FKey_cascade_del" ('check_t2_key', 't2', 't1', 'FULL',
'a2', 'a1', 'b2', 'b1');

-- **********
-- * Insert some PK values
-- **********
insert into t1 values (1, 1, 'key 1');
insert into t1 values (2, 2, 'key 2');
insert into t1 values (3, 3, 'key 3');

-- **********
-- * Check FK on insert
-- **********
-- The first two are O.K.
insert into t2 values (1, 1, 'ref 1');
insert into t2 values (2, 2, 'ref 2');
-- This one must fail
insert into t2 values (4, 3, 'ref 4');
-- The following one is O.K. again since all FK attributes are NULL
insert into t2 (c2) values ('null');
-- This one not - MATCH FULL does not allow mixing of NULL/notNULL
insert into t2 (a2, c2) values (1, 'full violation');

-- **********
-- * Check FK on update
-- **********
-- These two should fail
update t2 set a2 = 4 where a2 = 1;
update t2 set a2 = 3 where a2 = 2;
-- These two should succeed
update t2 set a2 = 3, b2 = 3 where a2 = 2;
update t2 set c2 = '' where a2 = 1;

-- **********
-- * Check the cascaded delete
-- **********
select * from t2;
delete from t1 where a1 = 1 and b1 = 1;
select * from t2;

-- **********
-- * Now for deferred constraint checks
-- **********
-- First the case that doesn't work
begin;
insert into t2 values (6, 6, 'ref 6');
insert into t1 values (6, 6, 'key 6');
commit;
-- But it must work this way
begin;
set constraints check_t2_key deferred;
insert into t2 values (7, 7, 'ref 7');
insert into t1 values (7, 7, 'key 7');
commit;

From bouncefilter Fri Oct 8 09:29:21 1999
Received: from fep04-svc.tin.it (mta04-acc.tin.it [212.216.176.35])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA63282
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 09:28:30 -0400 (EDT)
(envelope-from rcorna@tin.it)
Received: from tin.it ([212.216.129.172]) by fep04-svc.tin.it
(InterMail v4.01.01.02 201-229-111-106) with ESMTP
id <19991008132756.JBKJ11717.fep04-svc@tin.it>;
Fri, 8 Oct 1999 15:27:56 +0200
Sender: root
Message-ID: <37FDEF32.DDE759AC@tin.it>
Date: Fri, 08 Oct 1999 15:18:42 +0200
From: Roberto Cornacchia <rcorna@tin.it>
Organization: tin.it
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Top N queries and disbursion
References: <199910072353.TAA09358@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

No, it's certainly not the right thing. To my understanding, disbursion
is a measure of the frequency of the most common value of an attribute;
but that tells you very little about how many other values there are.
1/disbursion is a lower bound on the number of values, but it wouldn't
be a good estimate unless you had reason to think that the values were
pretty evenly distributed. There could be a *lot* of very-infrequent
values.

with 100 distinct values of an attribute uniformly distribuited in a
relation of 10000 tuples, disbursion was estimated as 0.002275, giving
us 440 distinct values.

This is an illustration of the fact that Postgres' disbursion-estimator
is pretty bad :-(. It usually underestimates the frequency of the most
common value, unless the most common value is really frequent
(probability > 0.2 or so). I've been trying to think of a more accurate
way of figuring the statistic that wouldn't be unreasonably slow.
Or, perhaps, we should forget all about disbursion and adopt some other
statistic(s).

Yes, you have the crux of the issue. I wrote it because it was the best
thing I could think of, but it is non-optimimal. Because all the
optimal solutions seemed too slow to me, I couldn't think of a better
one.

Thank you, Tom and Bruce.
This is not a good news for us :-(. In any case, is 1/disbursion the
best estimate we can have by now, even if not optimal?

Roberto Cornacchia
Andrea Ghidini

From bouncefilter Fri Oct 8 09:43:59 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA64751
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 09:43:12 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <4H5AV4H6>; Fri, 8 Oct 1999 15:42:49 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C131@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] Re: Top N queries and disbursion
Date: Fri, 8 Oct 1999 15:38:07 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Surely we could store more information (using vacuum) about each table, to
be able to produce good stats relatively quickly? This would mean that the
estimates would be dependent on vacuum, but there are worse options. Also,
can't we do something similar to what Oracle does, where you can define your
optimisation to be rule-based, or stats-based. If it's rule based, the
optimizer looks only at the schema to decide how to optimize. If
stats-based, then it has a huge amount of information at its disposal to
determine how to optimise. However, those stats are compiled by something
like vacuum.

MikeA

-----Original Message-----
From: Roberto Cornacchia [mailto:rcorna@tin.it]
Sent: Friday, October 08, 1999 3:19 PM
To: Bruce Momjian
Cc: Tom Lane; pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Top N queries and disbursion

Bruce Momjian wrote:

No, it's certainly not the right thing. To my

understanding, disbursion

is a measure of the frequency of the most common value

of an attribute;

but that tells you very little about how many other

values there are.

1/disbursion is a lower bound on the number of values,

but it wouldn't

be a good estimate unless you had reason to think that

the values were

pretty evenly distributed. There could be a *lot* of

very-infrequent

values.

with 100 distinct values of an attribute uniformly

distribuited in a

relation of 10000 tuples, disbursion was estimated as

0.002275, giving

us 440 distinct values.

This is an illustration of the fact that Postgres'

disbursion-estimator

is pretty bad :-(. It usually underestimates the

frequency of the most

common value, unless the most common value is really frequent
(probability > 0.2 or so). I've been trying to think of

a more accurate

way of figuring the statistic that wouldn't be unreasonably slow.
Or, perhaps, we should forget all about disbursion and

adopt some other

statistic(s).

Yes, you have the crux of the issue. I wrote it because

it was the best

thing I could think of, but it is non-optimimal. Because all the
optimal solutions seemed too slow to me, I couldn't think

of a better

one.

Thank you, Tom and Bruce.
This is not a good news for us :-(. In any case, is 1/disbursion the
best estimate we can have by now, even if not optimal?

Roberto Cornacchia
Andrea Ghidini

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

From bouncefilter Fri Oct 8 09:48:58 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 JAA65267
for <pgsql-hackers@postgresql.org>; Fri, 8 Oct 1999 09:48:00 -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 JAA02750;
Fri, 8 Oct 1999 09:47:04 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: luuk@wxs.nl, PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-reply-to: Your message of Fri, 8 Oct 1999 01:03:22 -0400 (EDT)
<199910080503.BAA09219@candle.pha.pa.us>
Date: Fri, 08 Oct 1999 09:47:03 -0400
Message-ID: <2748.939390423@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

*** src/backend/parser/scan.l	1999/09/28 03:41:36	1.57
--- src/backend/parser/scan.l	1999/10/08 04:58:23
***************
*** 167,173 ****
param \${integer}

! comment ("--"|"//").*\n
space			[ \t\n\f]
other			.
--- 167,173 ----
param \${integer}

! comment ("--"|"//").*

space [ \t\n\f]
other .

Ah, so the problem was that the perl interface didn't append a newline?
Good catch. I don't like this fix, however, since I fear it will
alter behavior for the case where there is an embedded newline in the
query buffer. For example
CREATE TABLE mytab -- comment \n (f1 int)
can be sent to the backend as one string (though not via psql). With
the above change in scan.l I think the comment will be taken to include
everything from -- to the end of the buffer, which is wrong.

A better solution IMHO is to leave scan.l as it was and instead
always append a \n to the presented query string before we parse.

BTW, might be a good idea to add \r to that list of "space" characters
so we don't mess up on DOS-style newlines (\r\n).

regards, tom lane

From bouncefilter Fri Oct 8 10:03:58 1999
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA67089
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 10:03:28 -0400 (EDT)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
IAA05825;
Fri, 8 Oct 1999 08:03:18 -0600 (MDT)
Date: Fri, 8 Oct 1999 08:03:18 -0600 (MDT)
Message-Id: <199910081403.IAA05825@biology.nmsu.edu>
X-Authentication-Warning: biology.nmsu.edu: brook set sender to
brook@biology.nmsu.edu using -f
From: Brook Milligan <brook@biology.nmsu.edu>
To: wieck@debis.com
CC: pgsql-hackers@postgreSQL.org
In-reply-to: <m11ZZCK-0003kLC@orion.SAPserv.Hamburg.dsh.de> (wieck@debis.com)
Subject: Re: [HACKERS] RI status report #4 (come and join)
References: <m11ZZCK-0003kLC@orion.SAPserv.Hamburg.dsh.de>

What we need next (what y'all shall do) is:

4.? Add glue so that these contraints can be recreated via pgdump?

Cheers,
Brook

From bouncefilter Fri Oct 8 10:10:58 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 KAA68091
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 10:10:49 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11Zae6-0003kLC; Fri, 8 Oct 99 16:05 MET DST
Message-Id: <m11Zae6-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] RI status report #4 (come and join)
To: brook@biology.nmsu.edu (Brook Milligan)
Date: Fri, 8 Oct 1999 16:05:18 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199910081403.IAA05825@biology.nmsu.edu> from "Brook Milligan" at
Oct 8, 99 08:03:18 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

What we need next (what y'all shall do) is:

4.? Add glue so that these contraints can be recreated via pgdump?

Yepp - forgot that and

5. Write documentation.

too.

Thanks, Jan

From bouncefilter Fri Oct 8 10:25:58 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 KAA69825
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 10:25:38 -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 KAA02977;
Fri, 8 Oct 1999 10:24:44 -0400 (EDT)
To: Roberto Cornacchia <rcorna@tin.it>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Top N queries and disbursion
In-reply-to: Your message of Fri, 08 Oct 1999 15:18:42 +0200
<37FDEF32.DDE759AC@tin.it>
Date: Fri, 08 Oct 1999 10:24:43 -0400
Message-ID: <2975.939392683@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Roberto Cornacchia <rcorna@tin.it> writes:

1/disbursion is a lower bound on the number of values, but it wouldn't
be a good estimate unless you had reason to think that the values were
pretty evenly distributed.

Thank you, Tom and Bruce.
This is not a good news for us :-(. In any case, is 1/disbursion the
best estimate we can have by now, even if not optimal?

I don't have a better idea right at the moment. I'm open to the idea
that VACUUM should compute more or different statistics, though ---
as long as it doesn't slow things down too much. (How much is too much
would probably depend on how much win the new stats would provide for
normal query-planning. For example, I'd resist making two passes over
the table during VACUUM ANALYZE, but I wouldn't rule it out completely;
you could sell me on it if the advantages were great enough.)

Hey, you guys are the researchers ... give us a better approach to
keeping table statistics ;-)

regards, tom lane

From bouncefilter Fri Oct 8 10:30:58 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 KAA70339
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 10:30:35 -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 KAA03029;
Fri, 8 Oct 1999 10:29:47 -0400 (EDT)
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Top N queries and disbursion
In-reply-to: Your message of Fri, 8 Oct 1999 15:38:07 +0200
<1BF7C7482189D211B03F00805F8527F748C131@S-NATH-EXCH2>
Date: Fri, 08 Oct 1999 10:29:46 -0400
Message-ID: <3027.939392986@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:

can't we do something similar to what Oracle does, where you can define your
optimisation to be rule-based, or stats-based. If it's rule based, the
optimizer looks only at the schema to decide how to optimize. If
stats-based, then it has a huge amount of information at its disposal to
determine how to optimise. However, those stats are compiled by something
like vacuum.

We pretty much do that already; the "rules" are embodied in the default
cost estimates that get used if there's no statistical data from VACUUM.

regards, tom lane

From bouncefilter Fri Oct 8 11:07:59 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 LAA75048
for <hackers@postgresql.org>; Fri, 8 Oct 1999 11:07:39 -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 PAA30065
for <hackers@postgresql.org>; Fri, 8 Oct 1999 15:07:33 GMT
Sender: lockhart@hub.org
Message-ID: <37FE08B5.9BA2B3C1@alumni.caltech.edu>
Date: Fri, 08 Oct 1999 15:07:33 +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: Postgres Hackers List <hackers@postgresql.org>
Subject: Features for next release
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hmm. I see a problem coming up for myself :(

I'm working on JOIN syntax and (hopefully) OUTER JOIN capabilities for
the next release. That will take a lot of time afaik. We also have
lots of great new features (almost certainly) coming up, such as WAL
and RI. Lots of stuff, and taken together it should lead to a v7.0
release.

However! I've been waiting for v7.0 to do internal remapping of the
datetime types (and possibly other types; I'm not remembering right
now) so that the 4-byte TIMESTAMP becomes, internally, what is
currently DATETIME and so that the current DATETIME becomes a synonym
for TIMESTAMP. If we are releasing v7.0 rather than v6.6, then I
should work on that now to ensure it is completed. If we might release
as v6.6, I should continue to work on OUTER JOIN, since the type
changes shouldn't go in yet.

Any opinions/comments on the right path to take? With code changes and
docs changes I would think that the datetime stuff is two or a few
weeks work with my off-work time, which I suppose wouldn't impace a
release schedule too much...

- Thomas

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

From bouncefilter Fri Oct 8 12:22:00 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA84731
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 12:21:14 -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 MAA26171;
Fri, 8 Oct 1999 12:19:31 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910081619.MAA26171@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Top N queries and disbursion
In-Reply-To: <37FDEF32.DDE759AC@tin.it> from Roberto Cornacchia at "Oct 8,
1999
03:18:42 pm"
To: Roberto Cornacchia <rcorna@tin.it>
Date: Fri, 8 Oct 1999 12:19:31 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yes, you have the crux of the issue. I wrote it because it was the best
thing I could think of, but it is non-optimimal. Because all the
optimal solutions seemed too slow to me, I couldn't think of a better
one.

Thank you, Tom and Bruce.
This is not a good news for us :-(. In any case, is 1/disbursion the
best estimate we can have by now, even if not optimal?

That is the best one maintained by the database.

-- 
  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 Fri Oct 8 12:22:01 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA84722
for <pgsql-hackers@postgresql.org>; Fri, 8 Oct 1999 12:21:10 -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 MAA26209;
Fri, 8 Oct 1999 12:20:41 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910081620.MAA26209@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Top N queries and disbursion
In-Reply-To: <1BF7C7482189D211B03F00805F8527F748C131@S-NATH-EXCH2> from
"Ansley, Michael" at "Oct 8, 1999 03:38:07 pm"
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
Date: Fri, 8 Oct 1999 12:20:41 -0400 (EDT)
CC: pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Surely we could store more information (using vacuum) about each table, to
be able to produce good stats relatively quickly? This would mean that the
estimates would be dependent on vacuum, but there are worse options. Also,
can't we do something similar to what Oracle does, where you can define your
optimisation to be rule-based, or stats-based. If it's rule based, the
optimizer looks only at the schema to decide how to optimize. If
stats-based, then it has a huge amount of information at its disposal to
determine how to optimise. However, those stats are compiled by something
like vacuum.

Stats are compiled by vacuum analyze, and every column is analyzed the
same way.

-- 
  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 Fri Oct 8 12:32:00 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 MAA86372
for <hackers@postgreSQL.org>; Fri, 8 Oct 1999 12:31:19 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgreSQL.org
id m11Zcq6-0003kLC; Fri, 8 Oct 99 18:25 MET DST
Message-Id: <m11Zcq6-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Features for next release
To: lockhart@alumni.caltech.edu (Thomas Lockhart)
Date: Fri, 8 Oct 1999 18:25:50 +0200 (MET DST)
Cc: hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37FE08B5.9BA2B3C1@alumni.caltech.edu> from "Thomas Lockhart" at
Oct 8, 99 03:07:33 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Thomas Lockhart wrote:

Hmm. I see a problem coming up for myself :(

I'm working on JOIN syntax and (hopefully) OUTER JOIN capabilities for
the next release. That will take a lot of time afaik. We also have
lots of great new features (almost certainly) coming up, such as WAL
and RI. Lots of stuff, and taken together it should lead to a v7.0
release.

What I actually see when starting/stopping the postmaster
lets me think that Vadim alread has the WAL target in sight.

And for RI I can say that we'll have at least FOREIGN KEY for
MATCH FULL without PENDANT in the next release. The key
features are in place and there's plenty of time left to do
all the stuff around.

However! I've been waiting for v7.0 to do internal remapping of the
datetime types (and possibly other types; I'm not remembering right
now) so that the 4-byte TIMESTAMP becomes, internally, what is
currently DATETIME and so that the current DATETIME becomes a synonym
for TIMESTAMP. If we are releasing v7.0 rather than v6.6, then I
should work on that now to ensure it is completed. If we might release
as v6.6, I should continue to work on OUTER JOIN, since the type
changes shouldn't go in yet.

Any opinions/comments on the right path to take? With code changes and
docs changes I would think that the datetime stuff is two or a few
weeks work with my off-work time, which I suppose wouldn't impace a
release schedule too much...

Break TIMESTAMP right now. IMHO it would be THE reason (a
functional incompatibility to v6.5) we where looking for to
be 100% sure the next release must be v7.0.

I clearly vote for v7.0 - even if I personally hoped we would
have a little chance to produce the ultimate devils
PostgreSQL-v6.6.6 someday.

Apropos devil: tomorrow Braunschweig Lions vs. Hamburg Blue
Devils here in Hamburg - German bowl! Go Devils go!

Jan

From bouncefilter Fri Oct 8 12:31:00 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA86265
for <pgsql-hackers@postgresql.org>; Fri, 8 Oct 1999 12:30:34 -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 MAA27953;
Fri, 8 Oct 1999 12:30:21 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910081630.MAA27953@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <2748.939390423@sss.pgh.pa.us> from Tom Lane at "Oct 8,
1999 09:47:03 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 8 Oct 1999 12:30:21 -0400 (EDT)
CC: luuk@wxs.nl, PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian <maillist@candle.pha.pa.us> writes:
*** src/backend/parser/scan.l	1999/09/28 03:41:36	1.57
--- src/backend/parser/scan.l	1999/10/08 04:58:23
***************
*** 167,173 ****
param \${integer}

! comment ("--"|"//").*\n
space			[ \t\n\f]
other			.
--- 167,173 ----
param \${integer}

! comment ("--"|"//").*

space [ \t\n\f]
other .
Ah, so the problem was that the perl interface didn't append a newline?
Good catch. I don't like this fix, however, since I fear it will
alter behavior for the case where there is an embedded newline in the
query buffer. For example
CREATE TABLE mytab -- comment \n (f1 int)

No problem. I just added test code to see if it works, and it does:

$result = $conn->exec(
"CREATE TABLE person (id int4, -- test\n name char(16)) -- test");

Tests embedded newline, and comment without newline.

I will commit this so it will always be tested by the perl test code.

can be sent to the backend as one string (though not via psql). With
the above change in scan.l I think the comment will be taken to include
everything from -- to the end of the buffer, which is wrong.

No, seems lex only goes the end-of-line unless you specifically say \n.

A better solution IMHO is to leave scan.l as it was and instead
always append a \n to the presented query string before we parse.

Problem here is that perl is not the only interface that would have this
problem. In fact, I am not sure why libpq doesn't have this problem.
Maybe it does. Anyway, changing all the interfaces would be a pain, and
non-portable to older releases.

BTW, might be a good idea to add \r to that list of "space" characters
so we don't mess up on DOS-style newlines (\r\n).

Interesting idea. I tried that, but the problem is things like this:

xqliteral [\\](.|\n)

If I change it to:

xqliteral [\\](.|\n|\r)

then \r\n is not going to work, and if I change it to:

xqliteral [\\](.|\n|\r)+

Then \n\n is going to be accepted when it shouldn't. Seems I will have
to leave it alone for now.

-- 
  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 Fri Oct 8 12:34:00 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA86678
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 12:33:52 -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 MAA28027;
Fri, 8 Oct 1999 12:33:36 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910081633.MAA28027@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Top N queries and disbursion
In-Reply-To: <2975.939392683@sss.pgh.pa.us> from Tom Lane at "Oct 8,
1999 10:24:43 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 8 Oct 1999 12:33:36 -0400 (EDT)
CC: Roberto Cornacchia <rcorna@tin.it>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I don't have a better idea right at the moment. I'm open to the idea
that VACUUM should compute more or different statistics, though ---
as long as it doesn't slow things down too much. (How much is too much
would probably depend on how much win the new stats would provide for
normal query-planning. For example, I'd resist making two passes over
the table during VACUUM ANALYZE, but I wouldn't rule it out completely;
you could sell me on it if the advantages were great enough.)

Hey, you guys are the researchers ... give us a better approach to
keeping table statistics ;-)

Yes, I am open to better ideas. The current code does 2-value columns,
and unique columns perfectly. The other distributions it gets only
approximate answers, but for a one-pass system, that's the best I could
do.

-- 
  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 Fri Oct 8 13:07:00 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA90483
for <hackers@postgreSQL.org>; Fri, 8 Oct 1999 13:06:42 -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 NAA28701;
Fri, 8 Oct 1999 13:06:10 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910081706.NAA28701@candle.pha.pa.us>
Subject: Re: [HACKERS] Features for next release
In-Reply-To: <37FE08B5.9BA2B3C1@alumni.caltech.edu> from Thomas Lockhart at
"Oct 8, 1999 03:07:33 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Fri, 8 Oct 1999 13:06:10 -0400 (EDT)
CC: Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hmm. I see a problem coming up for myself :(

I'm working on JOIN syntax and (hopefully) OUTER JOIN capabilities for
the next release. That will take a lot of time afaik. We also have
lots of great new features (almost certainly) coming up, such as WAL
and RI. Lots of stuff, and taken together it should lead to a v7.0
release.

However! I've been waiting for v7.0 to do internal remapping of the
datetime types (and possibly other types; I'm not remembering right
now) so that the 4-byte TIMESTAMP becomes, internally, what is
currently DATETIME and so that the current DATETIME becomes a synonym
for TIMESTAMP. If we are releasing v7.0 rather than v6.6, then I
should work on that now to ensure it is completed. If we might release
as v6.6, I should continue to work on OUTER JOIN, since the type
changes shouldn't go in yet.

Any opinions/comments on the right path to take? With code changes and
docs changes I would think that the datetime stuff is two or a few
weeks work with my off-work time, which I suppose wouldn't impace a
release schedule too much...

My guess is 7.0. With the minor releases still being made, Marc is in
no rush.

-- 
  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 Fri Oct 8 13:34:01 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 NAA93408
for <hackers@postgreSQL.org>; Fri, 8 Oct 1999 13:32:59 -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 NAA29185;
Fri, 8 Oct 1999 13:15:56 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910081715.NAA29185@candle.pha.pa.us>
Subject: Re: [HACKERS] Features for next release
In-Reply-To: <m11Zcq6-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 8, 1999 06:25:50 pm"
To: Jan Wieck <wieck@debis.com>
Date: Fri, 8 Oct 1999 13:15:56 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

Hmm. I see a problem coming up for myself :(

I'm working on JOIN syntax and (hopefully) OUTER JOIN capabilities for
the next release. That will take a lot of time afaik. We also have
lots of great new features (almost certainly) coming up, such as WAL
and RI. Lots of stuff, and taken together it should lead to a v7.0
release.

What I actually see when starting/stopping the postmaster
lets me think that Vadim alread has the WAL target in sight.

Yes, looks very impressive:

DEBUG: Data Base System is starting up at Fri Oct 8 01:38:04 1999
DEBUG: Data Base System was shutdowned at Fri Oct 8 01:37:42 1999
DEBUG: CheckPoint record at (0, 968)
DEBUG: Redo record at (0, 968); Undo record at (0, 0)
DEBUG: NextTransactionId: 20995; NextOid: 0
DEBUG: Invalid NextTransactionId/NextOid
DEBUG: Data Base System is in production state at Fri Oct 8 01:38:04 1999

-- 
  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 Fri Oct 8 13:30:06 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA92982
for <pgsql-hackers@postgresql.org>; Fri, 8 Oct 1999 13:29:09 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id NAA06576
for <pgsql-hackers@postgresql.org>; Fri, 8 Oct 1999 13:28:59 -0400
Message-ID: <37FE29D8.C778D2B3@wgcr.org>
Date: Fri, 08 Oct 1999 13:28:56 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Interesting Quote you might enjoy about PGSQL.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Found this quote by Philip Greenspun (who is unabashedly in love with
Oracle) in a LinuxWorld article:
"> The open source purist's only realistic choice for an RDBMS

is PostgreSQL (see Resources for the URL). In some ways,
PostgreSQL has more advanced features than any commercial
RDBMS. Most important, the loosely organized, unpaid
developers of PostgreSQL were able to convert to an
Oracle-style multiversion concurrency system (see below),
leaving all the rest of the commercial competition
deadlocked in the dust. If you've decided to accept John
Ousterhout as your personal savior, you'll be delighted
to learn that you can run Tcl procedures inside the
PostgreSQL database. And if your business can't live without
commercial support for your RDBMS, you can buy it
(see Resources for a link).

Cheers! (the full series of articles, which are about AOLserver, is
available at http://linuxworld.com)

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

From bouncefilter Fri Oct 8 14:32:01 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 OAA04642;
Fri, 8 Oct 1999 14:31:03 -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 OAA01200;
Fri, 8 Oct 1999 14:25:36 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910081825.OAA01200@candle.pha.pa.us>
Subject: Re: [HACKERS] Interesting Quote you might enjoy about PGSQL.]
In-Reply-To: <37FE29D8.C778D2B3@wgcr.org> from Lamar Owen at "Oct 8,
1999 01:28:56 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Fri, 8 Oct 1999 14:25:36 -0400 (EDT)
CC: pgsql-hackers@postgresql.org, webmaster@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Found this quote by Philip Greenspun (who is unabashedly in love with
Oracle) in a LinuxWorld article:
"> The open source purist's only realistic choice for an RDBMS

is PostgreSQL (see Resources for the URL). In some ways,
PostgreSQL has more advanced features than any commercial
RDBMS. Most important, the loosely organized, unpaid
developers of PostgreSQL were able to convert to an
Oracle-style multiversion concurrency system (see below),
leaving all the rest of the commercial competition
deadlocked in the dust. If you've decided to accept John

That is am amazing quotation. Vince, can we get a link to it on the
webpage?

Ousterhout as your personal savior, you'll be delighted
to learn that you can run Tcl procedures inside the
PostgreSQL database. And if your business can't live without
commercial support for your RDBMS, you can buy it
(see Resources for a link).

Cheers! (the full series of articles, which are about AOLserver, is
available at http://linuxworld.com)

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

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

-- 
  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 Fri Oct 8 15:13:01 1999
Received: from mout1.01019freenet.de (exim@mout1.01019freenet.de
[62.104.201.3]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA12190
for <hackers@postgresql.org>; Fri, 8 Oct 1999 15:12:41 -0400 (EDT)
(envelope-from michael@fam-meskes.de)
Received: from [62.104.201.2] (helo=mx1.01019freenet.de)
by mout1.01019freenet.de with esmtp (Exim 3.03 #1)
id 11ZfRX-00085I-00; Fri, 08 Oct 1999 21:12:39 +0200
Received: from [212.81.152.248] (helo=tanja.fam-meskes.de)
by mx1.01019freenet.de with esmtp (Exim 3.03 #1)
id 11ZfRW-0001mm-00; Fri, 08 Oct 1999 21:12:38 +0200
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian/GNU) id UAA00906;
Fri, 8 Oct 1999 20:57:43 +0200
Date: Fri, 8 Oct 1999 20:57:43 +0200
From: Michael Meskes <meskes@postgresql.org>
To: Jan Wieck <wieck@debis.com>
Cc: hackers@postgresql.org
Subject: Re: [HACKERS] Features for next release
Message-ID: <19991008205743.B890@fam-meskes.de>
Mail-Followup-To: Jan Wieck <wieck@debis.com>, hackers@postgresql.org
References: <37FE08B5.9BA2B3C1@alumni.caltech.edu>
<m11Zcq6-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0pre2i
In-Reply-To: <m11Zcq6-0003kLC@orion.SAPserv.Hamburg.dsh.de>

On Fri, Oct 08, 1999 at 06:25:50PM +0200, Jan Wieck wrote:

I clearly vote for v7.0 - even if I personally hoped we would

Me too. Although it means I have to check whether there is more stuff I have
to add to ECPG before 7.0 comes out.

have a little chance to produce the ultimate devils
PostgreSQL-v6.6.6 someday.

It seems we are too superstitous to allow this number. :-)

Apropos devil: tomorrow Braunschweig Lions vs. Hamburg Blue
Devils here in Hamburg - German bowl! Go Devils go!

Jan, now you surprise me. You are a football fan? I never expected another
German on this list to love football (american style that is). Maybe we are
able to meet at a football games. But then I cannot come to the German Bowl.

Do you go to NFLE games too?

Michael

P.S.: Sorry for being off-topic for this list in the last part of my mail.
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Fri Oct 8 16:10:02 1999
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net
[194.217.242.38]) by hub.org (8.9.3/8.9.3) with ESMTP id QAA18222
for <hackers@postgresql.org>; Fri, 8 Oct 1999 16:09:32 -0400 (EDT)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
id 11ZgJi-000GzW-0A
for hackers@postgreSQL.org; Fri, 8 Oct 1999 20:08:39 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id VAA07611; Fri, 8 Oct 1999 21:08:33 +0100 (BST)
Message-Id: <199910082008.VAA07611@mtcc.demon.co.uk>
Date: Fri, 8 Oct 1999 21:08:33 +0100 (BST)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: SPARC problem with WAL additions?
To: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: XelFOXq8IsvUM5KUaCSb3w==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

Hi All,

I'm seeing a funny with the new WAL aware postmaster.

After doing a "kill" on the postmaster process I get another
postmaster process which appears to be spinning on a spinlock.

I left it for almost an hour whilst I did something else.

I believe the spinlock code on my system, SPARCLinux, is OK
from running the s_lock_test, see below.

Any ideas what's happening?

Keith.

[postgres@sparclinux pgsql]$ ps -aux| grep post
postgres 19364 0.0 1.9 1936 760 p0 S Sep 26 0:00 login -p -h sparc2 -f
postgres 19365 0.0 2.2 1484 880 p0 S Sep 26 0:10 -bash
postgres 27333 0.0 2.4 4012 948 p0 S 22:24 0:00 postmaster -N 16 -B 3
postgres 27385 99.6 2.9 4076 1124 p0 R 19:19 51:49 postmaster -N 16 -B 3
postgres 27409 0.0 1.3 1116 512 p0 R 20:11 0:00 ps -aux
postgres 27410 0.0 1.1 1176 448 p0 R 20:11 0:00 grep post
[postgres@sparclinux pgsql]$ gdb /usr/local/pgsql/bin/postmaster 27385
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (sparc-unknown-linux), Copyright 1996 Free Software Foundation, Inc...

/usr/local/pgsql/27385: No such file or directory.
Attaching to program `/usr/local/pgsql/bin/postmaster', process 27385
Reading symbols from /lib/libdl.so.1.8.3...done.
Reading symbols from /lib/libm.so.5.0.6...done.
Reading symbols from /usr/lib/libreadline.so.2.0...done.
Reading symbols from /lib/libtermcap.so.2.0.8...done.
Reading symbols from /usr/lib/libncurses.so.3.0...done.
Reading symbols from /lib/libc.so.5.3.12...done.
Reading symbols from /lib/ld-linux.so.1...done.
CreateCheckPoint (shutdown=1 '\001') at ../../../include/storage/s_lock.h:151
151 __asm__("ldstub [%2], %0" \
(gdb) bt
#0 CreateCheckPoint (shutdown=1 '\001') at
../../../include/storage/s_lock.h:151
#1 0x55f1c in ShutdownXLOG () at xlog.c:1426
#2 0x587e4 in BootstrapMain (argc=5, argv=0xeffff5c8) at bootstrap.c:359
#3 0xb63bc in SSDataBase (startup=0 '\000') at postmaster.c:2026
#4 0xb53f0 in pmdie (postgres_signal_arg=1469440) at postmaster.c:1254
#5 0xeffff8f0 in ?? ()
#6 0xb48cc in ServerLoop () at postmaster.c:745
#7 0xb468c in PostmasterMain (argc=4620, argv=0x120c) at postmaster.c:640

[postgres@sparclinux buffer]$ make s_lock_test
gcc -I../../../include -I../../../backend -O2 -Wall -Wmissing-prototypes
-I../.. -DS_LOCK_TEST=1 s_lock.c -o
s_lock_test
./s_lock_test
S_LOCK_TEST: this will hang for a few minutes and then abort
with a 'stuck spinlock' message if S_LOCK()
and TAS() are working.

FATAL: s_lock(00020bf0) at s_lock.c:270, stuck spinlock. Aborting.

FATAL: s_lock(00020bf0) at s_lock.c:270, stuck spinlock. Aborting.
make: *** [s_lock_test] IOT trap/Abort (core dumped)
make: *** Deleting file `s_lock_test'

From bouncefilter Fri Oct 8 18:55:04 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 SAA66644
for <pgsql-hackers@postgresql.org>; Fri, 8 Oct 1999 18:54: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 SAA05072;
Fri, 8 Oct 1999 18:53:19 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: luuk@wxs.nl, PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-reply-to: Your message of Fri, 8 Oct 1999 12:30:21 -0400 (EDT)
<199910081630.MAA27953@candle.pha.pa.us>
Date: Fri, 08 Oct 1999 18:53:18 -0400
Message-ID: <5070.939423198@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Ah, so the problem was that the perl interface didn't append a newline?
Good catch. I don't like this fix, however, since I fear it will
alter behavior for the case where there is an embedded newline in the
query buffer.

I will commit this so it will always be tested by the perl test code.

But how often do we run that?

No, seems lex only goes the end-of-line unless you specifically say \n.

OK, I see in the flex manual that "." matches everything except newline,
so I guess it will work. At least with flex. But ".*" patterns with
no clearly defined terminator always make me itch --- it doesn't take
much change to get the wrong result.

A better solution IMHO is to leave scan.l as it was and instead
always append a \n to the presented query string before we parse.

Problem here is that perl is not the only interface that would have this
problem. In fact, I am not sure why libpq doesn't have this problem.

No, I wasn't suggesting patching the perl interface; I was suggesting
changing the backend, ie, adding the \n to the received query in
postgres.c just before we hand it off to the parser.

BTW, might be a good idea to add \r to that list of "space" characters
so we don't mess up on DOS-style newlines (\r\n).

Interesting idea. I tried that, but the problem is things like this:
xqliteral [\\](.|\n)

Hmm, didn't think about what to do with \r inside literals. I agree,
it's not worth trying to be smart about those, so I suppose ignoring
them outside literals would be inconsistent. Still, how many people
try to enter newlines within literals? Adding \r to the whitespace
set and nothing else might still be a useful compatibility gain.

regards, tom lane

From bouncefilter Fri Oct 8 19:16:04 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 TAA69161
for <hackers@postgreSQL.org>; Fri, 8 Oct 1999 19:15:32 -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 TAA05158;
Fri, 8 Oct 1999 19:14:24 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Features for next release
In-reply-to: Your message of Fri, 08 Oct 1999 15:07:33 +0000
<37FE08B5.9BA2B3C1@alumni.caltech.edu>
Date: Fri, 08 Oct 1999 19:14:24 -0400
Message-ID: <5156.939424464@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

It seems people are thinking winter or early spring (northern hemisphere
that is ;-)) for the next major release, and by then I think there will
be enough cool stuff done that we can call it 7.0. The only really big
to-do item that no one seems to be committed to doing in this cycle is
tuples bigger than a disk block, and maybe once the dust settles for
long queries someone will feel like tackling that...

I have another reason for calling it 7.0, which is that if we fix
the function-call interface the way I want to, we will break existing
user-written loadable modules that contain C-language functions.
Better to do that in a "7.0" than in a "6.6", no?

regards, tom lane

From bouncefilter Fri Oct 8 21:38:06 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA84430
for <pgsql-hackers@postgresql.org>; Fri, 8 Oct 1999 21:37:32 -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 VAA22009;
Fri, 8 Oct 1999 21:34:43 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910090134.VAA22009@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql
comparison
In-Reply-To: <5070.939423198@sss.pgh.pa.us> from Tom Lane at "Oct 8,
1999 06:53:18 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 8 Oct 1999 21:34:43 -0400 (EDT)
CC: luuk@wxs.nl, PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Ah, so the problem was that the perl interface didn't append a newline?
Good catch. I don't like this fix, however, since I fear it will
alter behavior for the case where there is an embedded newline in the
query buffer.

I will commit this so it will always be tested by the perl test code.

But how often do we run that?

Well, at least it is there now, and I will do --with-perl here, so it
will be run.

No, seems lex only goes the end-of-line unless you specifically say \n.

OK, I see in the flex manual that "." matches everything except newline,
so I guess it will work. At least with flex. But ".*" patterns with
no clearly defined terminator always make me itch --- it doesn't take
much change to get the wrong result.

True, but it fixes the problem.

A better solution IMHO is to leave scan.l as it was and instead
always append a \n to the presented query string before we parse.

Problem here is that perl is not the only interface that would have this
problem. In fact, I am not sure why libpq doesn't have this problem.

No, I wasn't suggesting patching the perl interface; I was suggesting
changing the backend, ie, adding the \n to the received query in
postgres.c just before we hand it off to the parser.

I try to avoid hacks like that if I can. Removing \n from the comment
termination is much clearer and more limited.

BTW, might be a good idea to add \r to that list of "space" characters
so we don't mess up on DOS-style newlines (\r\n).

Interesting idea. I tried that, but the problem is things like this:
xqliteral [\\](.|\n)

Hmm, didn't think about what to do with \r inside literals. I agree,
it's not worth trying to be smart about those, so I suppose ignoring
them outside literals would be inconsistent. Still, how many people
try to enter newlines within literals? Adding \r to the whitespace
set and nothing else might still be a useful compatibility gain.

Added \r to the {space} pattern.

-- 
  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 Fri Oct 8 22:06:52 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 WAA87291
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 22:06:06 -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 CAA30774;
Sat, 9 Oct 1999 02:05:55 GMT
Sender: lockhart@hub.org
Message-ID: <37FEA303.3D19D345@alumni.caltech.edu>
Date: Sat, 09 Oct 1999 02:05:55 +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: Lamar Owen <lamar.owen@wgcr.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Interesting Quote you might enjoy about PGSQL.
References: <37FE29D8.C778D2B3@wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lamar Owen wrote:

Found this quote by Philip Greenspun (who is unabashedly in love with
Oracle) in a LinuxWorld article:

It's nice to know he is a fan. btw, Philip was inquiring about the
feasibility of making PostgreSQL more compatible with Oracle to allow
him to port a large software project he built (in fact, you referred
us to his web site on some other topic recently). Until we have outer
joins it is a non-starter for him, but it was nice he asked :)

- Thomas

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

From bouncefilter Fri Oct 8 22:19:06 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 WAA88357
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 22:18:52 -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 CAA30796;
Sat, 9 Oct 1999 02:18:40 GMT
Sender: lockhart@hub.org
Message-ID: <37FEA5FF.19FA139D@alumni.caltech.edu>
Date: Sat, 09 Oct 1999 02:18:39 +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: Lamar Owen <lamar.owen@wgcr.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Interesting Quote you might enjoy about PGSQL.
References: <37FE29D8.C778D2B3@wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

... PostgreSQL has more advanced features than any commercial
RDBMS. Most important, the loosely organized, unpaid
developers of PostgreSQL were able to convert to an
Oracle-style multiversion concurrency system (see below),
leaving all the rest of the commercial competition
deadlocked in the dust.

There we go, riding Vadim's coattails to glory :))

- Thomas

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

From bouncefilter Fri Oct 8 22:48:06 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 WAA90942
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 22:47:59 -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 WAA24470;
Fri, 8 Oct 1999 22:46:43 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910090246.WAA24470@candle.pha.pa.us>
Subject: Re: [HACKERS] Interesting Quote you might enjoy about PGSQL.
In-Reply-To: <37FEA5FF.19FA139D@alumni.caltech.edu> from Thomas Lockhart at
"Oct 9, 1999 02:18:39 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Fri, 8 Oct 1999 22:46:43 -0400 (EDT)
CC: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org,
Jan Wieck <jwieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

... PostgreSQL has more advanced features than any commercial
RDBMS. Most important, the loosely organized, unpaid
developers of PostgreSQL were able to convert to an
Oracle-style multiversion concurrency system (see below),
leaving all the rest of the commercial competition
deadlocked in the dust.

There we go, riding Vadim's coattails to glory :))

Yep. The article makes it sound like we all did MVCC. No one told him
is was just one person.

I was mentioning to the MySQL folks that we have some brilliant
developers. Certainly most database companies have only a few really
good developers. Because we have the entire Internet to get people, we
draw the best database developers in the world.

Added to developers page:

We don't hire people to develop PostgreSQL. We have the entire Internet
to get people, so we draw the best database developers in the world.

[Jan, can we get a better image for the developers page?]

-- 
  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 Fri Oct 8 22:54:06 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA91549
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 22:53:54 -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 WAA24675;
Fri, 8 Oct 1999 22:53:35 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910090253.WAA24675@candle.pha.pa.us>
Subject: Re: [HACKERS] Interesting Quote you might enjoy about PGSQL.
In-Reply-To: <37FEA5FF.19FA139D@alumni.caltech.edu> from Thomas Lockhart at
"Oct 9, 1999 02:18:39 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Fri, 8 Oct 1999 22:53:35 -0400 (EDT)
CC: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

... PostgreSQL has more advanced features than any commercial
RDBMS. Most important, the loosely organized, unpaid
developers of PostgreSQL were able to convert to an
Oracle-style multiversion concurrency system (see below),
leaving all the rest of the commercial competition
deadlocked in the dust.

There we go, riding Vadim's coattails to glory :))

New text:

We don't hire developers. We reach across the Internet, drawing the
best database developers in the world to PostgreSQL.

-- 
  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 Fri Oct 8 22:56:06 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA92027
for <pgsql-hackers@postgreSQL.org>; Fri, 8 Oct 1999 22:55:23 -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 WAA24733;
Fri, 8 Oct 1999 22:55:08 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910090255.WAA24733@candle.pha.pa.us>
Subject: Re: [HACKERS] Interesting Quote you might enjoy about PGSQL.
In-Reply-To: <37FEA5FF.19FA139D@alumni.caltech.edu> from Thomas Lockhart at
"Oct 9, 1999 02:18:39 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Fri, 8 Oct 1999 22:55:08 -0400 (EDT)
CC: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org,
Jan Wieck <jwieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

... PostgreSQL has more advanced features than any commercial
RDBMS. Most important, the loosely organized, unpaid
developers of PostgreSQL were able to convert to an
Oracle-style multiversion concurrency system (see below),
leaving all the rest of the commercial competition
deadlocked in the dust.

There we go, riding Vadim's coattails to glory :))

Wow, that web page looks good now, with the quote at the bottom. Jan,
we need the nicer world image.

-- 
  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 Sat Oct 9 05:23:17 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id FAA31266
for <pgsql-hackers@postgreSQL.org>; Sat, 9 Oct 1999 05:22:53 -0400 (EDT)
(envelope-from a.joubert@albourne.com)
Received: from isadora.cy.albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.6X) with ESMTP
id MAA12968 for <pgsql-hackers@postgreSQL.org>;
Sat, 9 Oct 1999 12:25:41 +0300 (EET DST)
Received: from albourne.com (localhost [127.0.0.1])
by isadora.cy.albourne.com (8.9.3/8.9.3/Albourne/CYC/1.4) with ESMTP id
MAA13302 for <pgsql-hackers@postgreSQL.org>;
Sat, 9 Oct 1999 12:22:34 +0300 (EET DST)
Sender: a.joubert@albourne.com
Message-ID: <37FF095A.7DC0841B@albourne.com>
Date: Sat, 09 Oct 1999 12:22:34 +0300
From: Adriaan Joubert <a.joubert@albourne.com>
Organization: APL Financial Services (Overseas) Ltd
X-Mailer: Mozilla 4.61 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
References: <199909270044.UAA27257@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

OK, I've finally gotten round to coding most of the functions for bit
strings. I've got I/O, concatenation, substring and all bit operations
(and, or, xor, not, shift) working on the bitstring data structures. A
few (probably pretty daft) questions (if there is documentation on this
somewhere, please point me to it):

1. In the varchar file there are some functions which I believe are for
the conversion of char(n) to char(m). They take as argument a pointer to
a char() and a len which is the length of the total data structure. I
haven't figured out how conversions are implemented within postgres, but
I would need to transfer the equivalent of an atttypmod value, which
would contain the length of the bit string to do the conversions. Does
this fit in with the way the rest of the system works?

char * zpbit (char * arg, int32 bitlen)

2. there is a function _bpchar, which has something to do with arrays,
but I can't see how it fits in with everything else.

3. I need to write a hash function for bitstrings. I know nothing about
hash functions, except that they are hard to do well. I looked at the
function for text hashes and that is some weird code (i.e. it took me a
while to figure out what it did). Does anybody have any suggestions
off-hand for a decent hash function for bit strings? Could I just use
the text hash function? (Seems to me text should be different as it
usually draws from a more restricted range than a bit string).

4. Now that I've got the functionality, can somebody give me a rough
roadmap to what I need to change to turn this into a proper postgres
type? As far as I can see I need to assign oid's to it in pg_type.h and
I'll have to have a look at the parser to get it to recognise the types.
It would be a big help though if somebody could tell me what else needs
to change.

Thanks,

Adriaan

From bouncefilter Sat Oct 9 06:23:17 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 GAA36808
for <pgsql-hackers@postgreSQL.org>; Sat, 9 Oct 1999 06:22:52 -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 GAA05654;
Sat, 9 Oct 1999 06:20:59 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910091020.GAA05654@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
In-Reply-To: <37FF095A.7DC0841B@albourne.com> from Adriaan Joubert at "Oct 9,
1999 12:22:34 pm"
To: Adriaan Joubert <a.joubert@albourne.com>
Date: Sat, 9 Oct 1999 06:20:59 -0400 (EDT)
CC: Postgresql <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

4. Now that I've got the functionality, can somebody give me a rough
roadmap to what I need to change to turn this into a proper postgres
type? As far as I can see I need to assign oid's to it in pg_type.h and
I'll have to have a look at the parser to get it to recognise the types.
It would be a big help though if somebody could tell me what else needs
to change.

I can integrate the type for you into the include/catalog files if
everyone agrees they want it as a standard type and not an contrib type.

-- 
  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 Sat Oct 9 08:51:19 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA49199
for <hackers@postgreSQL.org>; Sat, 9 Oct 1999 08:50:46 -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 IAA10637;
Sat, 9 Oct 1999 08:50:21 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910091250.IAA10637@candle.pha.pa.us>
Subject: Re: [HACKERS] psql and comments
In-Reply-To: <Pine.LNX.4.10.9910072343450.848-100000@peter-e.yi.org> from
Peter
Eisentraut at "Oct 7, 1999 11:47:43 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Sat, 9 Oct 1999 08:50:20 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Oct 7, Bruce Momjian mentioned:

Things aren't a big problem the way they stand, but istm that a
completely blank line (after stripping single-line comments) may as
well be the same as an empty line,and that psql could figure that out.

I see your point in the above example. I will wait for the psql/libpq
cleaner-upper to finish, and take a look at it.

Oh, now I'm cleaning up libpq as well??? 8-}

Well anyway, by a vote of 1 1/2 to 1 psql will strip all comments before
sending a query, probably in a C pre-processor kind of way.

Looks like we are going for a 7.0 next, so feel free to remove very old
functions.

-- 
  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 Sat Oct 9 08:54:19 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA49450;
Sat, 9 Oct 1999 08:53:36 -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 IAA10670;
Sat, 9 Oct 1999 08:53:22 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910091253.IAA10670@candle.pha.pa.us>
Subject: Next release is 7.0(?)
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgreSQL.org>
Date: Sat, 9 Oct 1999 08:53:22 -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

Because the next release is going to probably be 7.0, if people have
backward compatability library code that they have been dying to remove,
this is the time for it.

I don't recommend removing backward compatability with 6.4 or 6.5
releases, but if you have some code that is hanging around just to be
compatible with 6.1 or earlier, I think it can be removed now.

-- 
  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 Sat Oct 9 09:03:19 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id JAA51005
for <pgsql-hackers@postgreSQL.org>; Sat, 9 Oct 1999 09:03:14 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 22980 invoked by uid 1001); 9 Oct 1999 13:03:09 -0000
Date: Sat, 9 Oct 1999 09:03:09 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Next release is 7.0(?)
In-Reply-To: <199910091253.IAA10670@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.05.9910090901230.22960-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 9 Oct 1999, Bruce Momjian wrote:

Because the next release is going to probably be 7.0, if people have
backward compatability library code that they have been dying to remove,
this is the time for it.

I don't recommend removing backward compatability with 6.4 or 6.5
releases, but if you have some code that is hanging around just to be
compatible with 6.1 or earlier, I think it can be removed now.

Then perhaps we can also overhaul the installation. I installed about
5 times this past week and have it down to 4 or 5 steps (not including
regression testing).

From bouncefilter Sat Oct 9 10:52:20 1999
Received: from osprey.astro.umass.edu (root@osprey.astro.umass.edu
[128.119.51.182]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA85917
for <pgsql-hackers@postgreSQL.org>; Sat, 9 Oct 1999 10:51:29 -0400 (EDT)
(envelope-from weinberg@osprey.astro.umass.edu)
Received: (from weinberg@localhost)
by osprey.astro.umass.edu (8.9.3/8.9.3/Debian/GNU) id KAA26361;
Sat, 9 Oct 1999 10:51:24 -0400
Date: Sat, 9 Oct 1999 10:51:24 -0400
Message-Id: <199910091451.KAA26361@osprey.astro.umass.edu>
From: Martin Weinberg <weinberg@osprey.astro.umass.edu>
To: pgsql-hackers@postgreSQL.org
Cc: weinberg@osprey.astro.umass.edu
Subject: memory problems in copying large table

Folks,

I've been struggling to copy a large table (200 million
records, 60GB) to tape using:

psql -qc "copy psc to STDOUT;" Winter99 | dd of=/dev/st0 bs=32k

After processing about 10 million records (this varies), I
get:

FATAL 1: Memory exhausted in AllocSetAlloc()

(The tape drive is a DLT 7000, and the tape is not filled at
this point).

There is no evidence that the backend has really exhausted
avail memory (I have 256MB but 1GB swap and the postgres
user and database user both have unlimited memory usage).

This is 6.5.1 on Linux 2.2.11 (w/Debian 2.1) on a dual
450Mhz Xeon box with a 128GB software Raid0 array. I've set
SHMEM to 128MB am using "-B 12288 -S 8192". I've been
trying to figure this out for a few weeks but can't seem to
get this table copied to tape. Can one of the developers
offer a suggestion?

BTW, this is a large astronomical database which will
eventually grow to about 500 million records. Besides this
tape problem, pgsql is now working nicely for our
application.

I've been following the mysql thread. You folks may want
to add "works with databases over 2GB" to your plus column.

With thoughtful indexing, one can retrieve queries of
<100000 records in 1 to 15 minutes which competes nicely
with our main data server, a bunch of Sun Enterprise 5000
and 6000s running Informix. Of course, many people using
this large system simultaneously, but our goal for this
project is to recommend an alternative hardware/software
solution to the astronomical community for <$10K.

--M

===========================================================================

Martin Weinberg Phone: (413) 545-3821
Dept. of Physics and Astronomy FAX: (413) 545-2117/0648
530 Graduate Research Tower weinberg@astro.umass.edu
University of Massachusetts http://www.astro.umass.edu/~weinberg/
Amherst, MA 01003-4525

From bouncefilter Sat Oct 9 12:06:21 1999
Received: from osprey.astro.umass.edu (root@osprey.astro.umass.edu
[128.119.51.182]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA94362
for <pgsql-hackers@postgreSQL.org>; Sat, 9 Oct 1999 12:06:02 -0400 (EDT)
(envelope-from weinberg@osprey.astro.umass.edu)
Received: from osprey.astro.umass.edu (weinberg@localhost [127.0.0.1])
by osprey.astro.umass.edu (8.9.3/8.9.3/Debian/GNU) with ESMTP id
MAA26655; Sat, 9 Oct 1999 12:02:27 -0400
Message-Id: <199910091602.MAA26655@osprey.astro.umass.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Martin Weinberg <weinberg@osprey.astro.umass.edu>,
pgsql-hackers@postgreSQL.org, weinberg@osprey.astro.umass.edu
Subject: Re: [HACKERS] memory problems in copying large table to STDOUT
In-reply-to: Your message of "Sat, 09 Oct 1999 11:54:34 EDT."
<11327.939484474@sss.pgh.pa.us>
Date: Sat, 09 Oct 1999 12:02:27 -0300
From: Martin Weinberg <weinberg@osprey.astro.umass.edu>

Tom Lane wrote on Sat, 09 Oct 1999 11:54:34 EDT

Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:

I've been struggling to copy a large table (200 million
records, 60GB) to tape using:
psql -qc "copy psc to STDOUT;" Winter99 | dd of=/dev/st0 bs=32k
After processing about 10 million records (this varies), I
get:
FATAL 1: Memory exhausted in AllocSetAlloc()

Hmm. What is the exact declaration of the table?

The only explanation I can think of offhand is that the output
conversion function for one of the column types is leaking memory...
copy.c itself looks to be pretty careful not to.

The table def is:

CREATE TABLE psc (
hemis text,
date date,
scan int2,
id int4,
ra float4,
dec float4,
glon float4,
glat float4,
err_maj float4,
err_min float4,
err_ang int2,
xscan float4,
cnf_flag text,
j_m float4,
h_m float4,
k_m float4,
j_msig float4,
h_msig float4,
k_msig float4,
j_m_psf float4,
h_m_psf float4,
k_m_psf float4,
j_psfchi float4,
h_psfchi float4,
k_psfchi float4,
j_skyval float4,
h_skyval float4,
k_skyval float4,
j_blend int2,
h_blend int2,
k_blend int2,
j_m_stdap float4,
h_m_stdap float4,
k_m_stdap float4,
j_msig_stdap float4,
h_msig_stdap float4,
k_msig_stdap float4,
j_prob_pers float4,
h_prob_pers float4,
k_prob_pers float4,
j_prg_flg text,
h_prg_flg text,
k_prg_flg text,
j_mrg_flg text,
h_mrg_flg text,
k_mrg_flg text,
j_pix_flg text,
h_pix_flg text,
k_pix_flg text,
j_cal float4,
h_cal float4,
k_cal float4,
gal_contam int2,
id_opt text,
dist_opt float4,
b_m_opt float4,
r_m_opt float4,
j_h float4,
h_k float4,
j_k float4,
dup_src int2,
use_src int2,
ext_key_1 int4
);

Thanks for taking a look,

--Martin

===========================================================================

From bouncefilter Sat Oct 9 11:04:20 1999
Received: from osprey.astro.umass.edu (root@osprey.astro.umass.edu
[128.119.51.182]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA88367
for <pgsql-hackers@postgreSQL.org>; Sat, 9 Oct 1999 11:04:19 -0400 (EDT)
(envelope-from weinberg@osprey.astro.umass.edu)
Received: (from weinberg@localhost)
by osprey.astro.umass.edu (8.9.3/8.9.3/Debian/GNU) id LAA26487;
Sat, 9 Oct 1999 11:04:14 -0400
Date: Sat, 9 Oct 1999 11:04:14 -0400
Message-Id: <199910091504.LAA26487@osprey.astro.umass.edu>
From: Martin Weinberg <weinberg@osprey.astro.umass.edu>
To: pgsql-hackers@postgreSQL.org
Subject: memory problems in copying large table to STDOUT

Folks,

I've been struggling to copy a large table (200 million
records, 60GB) to tape using:

psql -qc "copy psc to STDOUT;" Winter99 | dd of=/dev/st0 bs=32k

After processing about 10 million records (this varies), I
get:

FATAL 1: Memory exhausted in AllocSetAlloc()

(The tape drive is a DLT 7000, and the tape is not filled at
this point).

There is no evidence that the backend has really exhausted
avail memory (I have 256MB but 1GB swap and the postgres
user and database user both have unlimited memory usage).

BTW, this is a large astronomical database which will
eventually grow to about 500 million records. Besides this
tape problem, pgsql is now working nicely for our
application.

I've been following the mysql thread. You folks may want
to add "works with databases over 2GB" to your plus column.

--M

===========================================================================

From bouncefilter Sat Oct 9 11:51:21 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 LAA92299
for <pgsql-hackers@postgreSQL.org>; Sat, 9 Oct 1999 11:50:50 -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 LAA11307;
Sat, 9 Oct 1999 11:49:33 -0400 (EDT)
To: Adriaan Joubert <a.joubert@albourne.com>
cc: Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
In-reply-to: Your message of Sat, 09 Oct 1999 12:22:34 +0300
<37FF095A.7DC0841B@albourne.com>
Date: Sat, 09 Oct 1999 11:49:33 -0400
Message-ID: <11305.939484173@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Adriaan Joubert <a.joubert@albourne.com> writes:

1. In the varchar file there are some functions which I believe are for
the conversion of char(n) to char(m). They take as argument a pointer to
a char() and a len which is the length of the total data structure. I
haven't figured out how conversions are implemented within postgres, but
I would need to transfer the equivalent of an atttypmod value, which
would contain the length of the bit string to do the conversions.

bpchar(), for example, is actually a user-callable SQL function; it
takes a char(n) value and an atttypmod value and coerces the string
to the right length for that atttypmod. Although there are no *direct*
references to bpchar() anywhere except in pg_proc, the parser's
SizeTargetExpr routine nonetheless generates calls to it as part of
INSERT and UPDATE queries:

/*
* SizeTargetExpr()
*
* If the target column type possesses a function named for the type
* and having parameter signature (columntype, int4), we assume that
* the type requires coercion to its own length and that the said
* function should be invoked to do that.
*
* Currently, "bpchar" (ie, char(N)) is the only such type, but try
* to be more general than a hard-wired test...
*/

So, if you want to implement a fixed-length BIT(N) type, the only
real difference between that and an any-width bitstring is the existence
of a coercion function matching SizeTargetExpr's criteria.

BTW, the last line of that comment is in error --- "varchar" also has a
function matching SizeTargetExpr's criteria. Its function behaves
a little differently, since it only truncates and never pads, but
the interface to the system is the same.

2. there is a function _bpchar, which has something to do with arrays,
but I can't see how it fits in with everything else.

Looks like it is the equivalent of bpchar() for arrays of char(N).

3. I need to write a hash function for bitstrings. I know nothing about
hash functions, except that they are hard to do well. I looked at the
function for text hashes and that is some weird code (i.e. it took me a
while to figure out what it did).

If you're looking at the type-specific hash functions in hashfunc.c,
I think they are mostly junk. They could all be replaced by two
functions, one for pass-by-val types and one for pass-by-ref types, a la
the type-independent hashFunc() in nodeHash.c.

The only situation where you really need a type-specific hasher is with
datatypes that have garbage bits in them (such as padding between struct
elements that might contain uninitialized bits). If you're careful to
make sure that all unused bits are zeroes, so that logically equivalent
values of your type will always have the same bit contents, then you
should be able to just use hashtext().

Actually, unless you feel a compelling need to support hash indexes
on your datatype, you don't need a hash routine at all. Certainly
getting btree index support should be a higher-priority item.

regards, tom lane

From bouncefilter Sat Oct 9 11:56:21 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 LAA92891
for <pgsql-hackers@postgreSQL.org>; Sat, 9 Oct 1999 11:55:50 -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 LAA11329;
Sat, 9 Oct 1999 11:54:34 -0400 (EDT)
To: Martin Weinberg <weinberg@osprey.astro.umass.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] memory problems in copying large table to STDOUT
In-reply-to: Your message of Sat, 9 Oct 1999 11:04:14 -0400
<199910091504.LAA26487@osprey.astro.umass.edu>
Date: Sat, 09 Oct 1999 11:54:34 -0400
Message-ID: <11327.939484474@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:

I've been struggling to copy a large table (200 million
records, 60GB) to tape using:
psql -qc "copy psc to STDOUT;" Winter99 | dd of=/dev/st0 bs=32k
After processing about 10 million records (this varies), I
get:
FATAL 1: Memory exhausted in AllocSetAlloc()

Hmm. What is the exact declaration of the table?

The only explanation I can think of offhand is that the output
conversion function for one of the column types is leaking memory...
copy.c itself looks to be pretty careful not to.

regards, tom lane

From bouncefilter Sat Oct 9 14:44:23 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 OAA09279
for <pgsql-hackers@postgreSQL.org>; Sat, 9 Oct 1999 14:44:05 -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 OAA13341;
Sat, 9 Oct 1999 14:42:56 -0400 (EDT)
To: Martin Weinberg <weinberg@osprey.astro.umass.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] memory problems in copying large table to STDOUT
In-reply-to: Your message of Sat, 09 Oct 1999 12:02:27 -0300
<199910091602.MAA26655@osprey.astro.umass.edu>
Date: Sat, 09 Oct 1999 14:42:56 -0400
Message-ID: <13339.939494576@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:

Tom Lane wrote on Sat, 09 Oct 1999 11:54:34 EDT

FATAL 1: Memory exhausted in AllocSetAlloc()

Hmm. What is the exact declaration of the table?

The only explanation I can think of offhand is that the output
conversion function for one of the column types is leaking memory...
copy.c itself looks to be pretty careful not to.

The table def is:

CREATE TABLE psc (
hemis text,
date date,
scan int2,
id int4,
ra float4,
[ lots more fields of these same types ]

Hmm, nothing unusual there. I made up a dummy table containing these
column types, filled it with 16 meg of junk data, and copied in and
out without observing any process memory usage growth at all, under
both current sources and 6.5.2. I also used gdb to set a breakpoint
at AllocSetAlloc, and checked that the inner loop of the copy wasn't
allocating anything it didn't free. So there's no obvious memory
leakage bug here. (It'd be pretty surprising if there was, really,
for such commonly used data types.)

I'm now thinking that there must be either a problem specific to your
platform, or some heretofore unnoticed problem with copying from a
multi-segment (ie, multi-gigabyte) table. I don't have enough disk
space to check the latter theory here...

Can you prepare a debugger backtrace showing what the backend is doing
when it gets the error? If you're not familiar with gdb, it'd go
something like this:

1. Build & install postgres with debugging symbols enabled
("make CUSTOM_COPT=-g all").
2. Start gdb on the postgres executable, eg
"gdb /usr/local/pgsql/bin/postgres".
3. Fire up the copy-out operation as usual. (I assume this takes long
enough that you have plenty of time for the next two steps ;-))
4. Use ps or top to find out the process number of the backend handling
the session.
5. Attach to that process number in gdb:
(gdb) attach NNNN
6. Set a breakpoint at elog, and let the backend continue running:
(gdb) break elog
(gdb) continue
7. When the breakpoint is hit, get a backtrace:
Breakpoint 1, elog ...
(gdb) bt
After copying & pasting the resulting printout, you can "quit" to
get out of gdb.

regards, tom lane

From bouncefilter Sat Oct 9 17:01:24 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA32166
for <pgsql-hackers@postgreSQL.org>; Sat, 9 Oct 1999 17:00:55 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by trends.net (8.8.8/8.8.8) with ESMTP id RAA25282
for <pgsql-hackers@postgreSQL.org>; Sat, 9 Oct 1999 17:00:45 -0400 (EDT)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id QAA14345;
Sat, 9 Oct 1999 16:21:56 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910092021.QAA14345@candle.pha.pa.us>
Subject: Re: [HACKERS] Next release is 7.0(?)
In-Reply-To: <Pine.BSF.4.05.9910090901230.22960-100000@paprika.michvhf.com>
from Vince Vielhaber at "Oct 9, 1999 09:03:09 am"
To: Vince Vielhaber <vev@michvhf.com>
Date: Sat, 9 Oct 1999 16:21:56 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sat, 9 Oct 1999, Bruce Momjian wrote:

Because the next release is going to probably be 7.0, if people have
backward compatability library code that they have been dying to remove,
this is the time for it.

I don't recommend removing backward compatability with 6.4 or 6.5
releases, but if you have some code that is hanging around just to be
compatible with 6.1 or earlier, I think it can be removed now.

Then perhaps we can also overhaul the installation. I installed about
5 times this past week and have it down to 4 or 5 steps (not including
regression testing).

Great. That certainly needs a cleanup. My ideal would be to have a
list of short instructions, and then have footnotes people would go to
when they had a problem with a certain item. Not sure how to do that in
sgml.

If we did it in html, they could click on something when they had a
problem, but html instructions are hard if you don't have a browser.

-- 
  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 Sun Oct 10 08:35:35 1999
Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net
[194.159.73.21]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA36288;
Sun, 10 Oct 1999 08:35:04 -0400 (EDT)
(envelope-from jeroen@design.nl)
Received: from [212.238.131.55] (helo=manderijn)
by post.mail.nl.demon.net with smtp (Exim 2.12 #1)
id 11aICw-000BHn-00; Sun, 10 Oct 1999 12:36:11 +0000
Message-Id: <4.1.19991010143417.0092ba20@mail.design.nl>
X-Sender: morinel@pop3.demon.nl
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Sun, 10 Oct 1999 14:35:01 +0200
To: pgsql-hackers@postgresql.org, pgsql-general@postgresql.org,
pgsql-announce@postgresql.org
From: Jeroen van Vianen <jeroen@design.nl>
Subject: pgxml 1.0 released
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hi,

I'd like to announce the release of pgxml 1.0, a tool which outputs
PostgreSQL queries in XML format.

Here's a small example:

Run
pgxml -d books -c "select * from books" \
-t library,book -s books.css -o books.xml

The output might look like this

<?xml version="1.0"?>
<?xml-stylesheet href="books.css"type="text/css"?>

<!DOCTYPE library [
<!ELEMENT library (book)*>
<!ELEMENT book (id?, title?, author?)>
<!ELEMENT id (#PCDATA)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT author (#PCDATA)>
]>
<library>
<book>
<id>1</id>
<title>Hitchhiker's Guide to the Galaxy</title>
<author>Douglas Adams</author>
</book>

[...]

<book>
<id>4</id>
<title>The C Programming Language</title>
<author>Brian W. Kernighan and Dennis M. Ritchie</author>
</book>
</library>

Check it out at http://www.morinel.demon.nl/pgxml/ or download it from
http://www.morinel.demon.nl/pgxml/pgxml-1.0.tar.gz

As I make heavy use of stylesheets, my website is best viewed with Mozilla
or M$ IE 5 :-(

Cheers,

Jeroen

From bouncefilter Sun Oct 10 10:42:36 1999
Received: from osprey.astro.umass.edu (root@osprey.astro.umass.edu
[128.119.51.182]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA44950
for <pgsql-hackers@postgreSQL.org>;
Sun, 10 Oct 1999 10:42:18 -0400 (EDT)
(envelope-from weinberg@osprey.astro.umass.edu)
Received: from osprey.astro.umass.edu (weinberg@localhost [127.0.0.1])
by osprey.astro.umass.edu (8.9.3/8.9.3/Debian/GNU) with ESMTP id
KAA15476; Sun, 10 Oct 1999 10:38:43 -0400
Message-Id: <199910101438.KAA15476@osprey.astro.umass.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Martin Weinberg <weinberg@osprey.astro.umass.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] memory problems in copying large table to STDOUT
In-reply-to: Your message of "Sat, 09 Oct 1999 14:42:56 EDT."
<13339.939494576@sss.pgh.pa.us>
Date: Sun, 10 Oct 1999 10:38:43 -0300
From: Martin Weinberg <weinberg@osprey.astro.umass.edu>

Tom,

I am attaching the backtrace. This one simultaneously generated
this kernel message from the md driver:

raid0_map bug: hash->zone0==NULL for block 1132810879
Bad md_map in ll_rw_block

Definitely a problem but no longer sure if it's the same one . . .
sigh.

I inserted a pause() in the beginning of elog.c so that I
could attach remotely; I'm keeping the sleeping processing
around in case there's anything else you would like me to
check.

Guess, I'm (foolishly?) pushing the envelope here with a 100GB
database on software raid.

Thanks!!!

--Martin

P.S. After the fact, I realized that my source is Oliver Elphick's
Debian 6.5.1 source package rather than a pure vanilla source.
Hope this is not a problem . . .

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

(gdb) bt
#0 0x4012eb77 in pause ()
#1 0x81160e9 in elog (lev=-1, fmt=0x8146a4b "cannot read block %d of %s")
at elog.c:81
#2 0x80e76ef in smgrread (which=0, reln=0x822af60, blocknum=2638753,
buffer=0x44a85040 "h") at smgr.c:235
#3 0x80dd7a2 in ReadBufferWithBufferLock (reln=0x822af60, blockNum=2638753,
bufferLockHeld=0) at bufmgr.c:302
#4 0x80dd682 in ReadBuffer (reln=0x822af60, blockNum=2638753) at bufmgr.c:180
#5 0x80ddf1d in ReleaseAndReadBuffer (buffer=9175, relation=0x822af60,
blockNum=2638753) at bufmgr.c:954
#6 0x806ad13 in heapgettup (relation=0x822af60, tuple=0x8235374, dir=1,
buffer=0x8235398, snapshot=0x8232af0, nkeys=0, key=0x0) at heapam.c:469
#7 0x806b6bf in heap_getnext (scandesc=0x8235360, backw=0) at heapam.c:912
#8 0x8084eb3 in CopyTo (rel=0x822af60, binary=0 '\000', oids=0 '\000',
fp=0x0, delim=0x813c829 "\t") at copy.c:405
#9 0x8084ce4 in DoCopy (relname=0x82350c0 "psc", binary=0 '\000',
oids=0 '\000', from=0 '\000', pipe=1 '\001', filename=0x0,
delim=0x813c829 "\t") at copy.c:323
#10 0x80ea8c6 in ProcessUtility (parsetree=0x82350d8, dest=Remote)
at utility.c:227
#11 0x80e8a36 in pg_exec_query_dest (
query_string=0xbfffaef4 "copy psc to STDOUT;", dest=Remote, aclOverride=0)
at postgres.c:727
#12 0x80e8944 in pg_exec_query (query_string=0xbfffaef4 "copy psc to STDOUT;")
at postgres.c:656
#13 0x80e9b88 in PostgresMain (argc=11, argv=0xbffff46c, real_argc=12,
real_argv=0xbffff984) at postgres.c:1647
#14 0x80d1adc in DoBackend (port=0x81ef748) at postmaster.c:1628
#15 0x80d1613 in BackendStartup (port=0x81ef748) at postmaster.c:1373
#16 0x80d0ca6 in ServerLoop () at postmaster.c:823
#17 0x80d080c in PostmasterMain (argc=12, argv=0xbffff984) at postmaster.c:616
#18 0x80a4597 in main (argc=12, argv=0xbffff984) at main.c:93

Tom Lane wrote on Sat, 09 Oct 1999 14:42:56 EDT

Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:

Tom Lane wrote on Sat, 09 Oct 1999 11:54:34 EDT

FATAL 1: Memory exhausted in AllocSetAlloc()

Hmm. What is the exact declaration of the table?

The only explanation I can think of offhand is that the output
conversion function for one of the column types is leaking memory...
copy.c itself looks to be pretty careful not to.

The table def is:

CREATE TABLE psc (
hemis text,
date date,
scan int2,
id int4,
ra float4,
[ lots more fields of these same types ]

Hmm, nothing unusual there. I made up a dummy table containing these
column types, filled it with 16 meg of junk data, and copied in and
out without observing any process memory usage growth at all, under
both current sources and 6.5.2. I also used gdb to set a breakpoint
at AllocSetAlloc, and checked that the inner loop of the copy wasn't
allocating anything it didn't free. So there's no obvious memory
leakage bug here. (It'd be pretty surprising if there was, really,
for such commonly used data types.)

I'm now thinking that there must be either a problem specific to your
platform, or some heretofore unnoticed problem with copying from a
multi-segment (ie, multi-gigabyte) table. I don't have enough disk
space to check the latter theory here...

Can you prepare a debugger backtrace showing what the backend is doing
when it gets the error? If you're not familiar with gdb, it'd go
something like this:

1. Build & install postgres with debugging symbols enabled
("make CUSTOM_COPT=-g all").
2. Start gdb on the postgres executable, eg
"gdb /usr/local/pgsql/bin/postgres".
3. Fire up the copy-out operation as usual. (I assume this takes long
enough that you have plenty of time for the next two steps ;-))
4. Use ps or top to find out the process number of the backend handling
the session.
5. Attach to that process number in gdb:
(gdb) attach NNNN
6. Set a breakpoint at elog, and let the backend continue running:
(gdb) break elog
(gdb) continue
7. When the breakpoint is hit, get a backtrace:
Breakpoint 1, elog ...
(gdb) bt
After copying & pasting the resulting printout, you can "quit" to
get out of gdb.

regards, tom lane

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

From bouncefilter Sun Oct 10 12:01: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 MAA53514
for <pgsql-hackers@postgreSQL.org>;
Sun, 10 Oct 1999 12:00:59 -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 LAA02103;
Sun, 10 Oct 1999 11:59:53 -0400 (EDT)
To: Martin Weinberg <weinberg@osprey.astro.umass.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] memory problems in copying large table to STDOUT
In-reply-to: Your message of Sun, 10 Oct 1999 10:38:43 -0300
<199910101438.KAA15476@osprey.astro.umass.edu>
Date: Sun, 10 Oct 1999 11:59:53 -0400
Message-ID: <2101.939571193@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:

I am attaching the backtrace. This one simultaneously generated
this kernel message from the md driver:

raid0_map bug: hash->zone0==NULL for block 1132810879
Bad md_map in ll_rw_block

Definitely a problem but no longer sure if it's the same one . . .
sigh.

Looks like it is not the same. As you can see, the error message that
elog is about to report is "cannot read <block#> of <file>", which isn't
too surprising given the kernel notice:

#1 0x81160e9 in elog (lev=-1, fmt=0x8146a4b "cannot read block %d of %s")
at elog.c:81

If this read failure is reproducible then you will need to get that
taken care of before we can make any progress on the original problem.
But it might be a transient failure --- why don't you just start the
copy over again to see?

regards, tom lane

From bouncefilter Sun Oct 10 12:55:37 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA58155
for <pgsql-hackers@postgreSQL.org>;
Sun, 10 Oct 1999 12:55:30 -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 MAA08707
for pgsql-hackers@postgreSQL.org; Sun, 10 Oct 1999 12:55:11 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910101655.MAA08707@candle.pha.pa.us>
Subject: Mention of FAQ in shared memory/ipc errors
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Sun, 10 Oct 1999 12:55:11 -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

We are continuing to get ipc/shared memory error reports from people who
have not looked at the FAQ and platform-specific FAQ's.

This is easily fixed by mentioning the FAQ locations in the error
messages, and have added that.

-- 
  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 Sun Oct 10 13:59:38 1999
Received: from perio.unlp.edu.ar (IDENT:root@perio.unlp.edu.ar [163.10.16.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA63295;
Sun, 10 Oct 1999 13:59:21 -0400 (EDT)
(envelope-from ser@perio.unlp.edu.ar)
Received: from perio.unlp.edu.ar (modem76.way.com.ar [200.41.165.76])
by perio.unlp.edu.ar (8.9.3/8.8.7) with ESMTP id OAA16406;
Sun, 10 Oct 1999 14:59:14 GMT
Message-ID: <3800D45F.B8C280F2@perio.unlp.edu.ar>
Date: Sun, 10 Oct 1999 15:01:03 -0300
From: "Sergio A. Kessler" <ser@perio.unlp.edu.ar>
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
CC: PostgreSQL-interfaces <pgsql-interfaces@postgreSQL.org>
Subject: Re: [INTERFACES] Next release is 7.0(?)
References: <199910091253.IAA10670@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Because the next release is going to probably be 7.0, if people have
backward compatability library code that they have been dying to remove,
this is the time for it.

I don't recommend removing backward compatability with 6.4 or 6.5
releases, but if you have some code that is hanging around just to be
compatible with 6.1 or earlier, I think it can be removed now.

can the commands createuser and destroyuser be renamed to
pg_createuser and pg_destroyuser (as pg_dump) adding soft links to
preserve backwards compatibility (declaring previous commands
deprecated) ?

the same can be done for createdb and destroydb ...

I think is a much more nice namespace for Postgres wich is
important when you have thousands of commands in this times.

--
| Sergio A. Kessler http://sak.org.ar
-O_O- You can have it Soon, Cheap, and Working; choose *two*.

From bouncefilter Sun Oct 10 16:44:40 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 QAA78559;
Sun, 10 Oct 1999 16:43:48 -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 QAA11104;
Sun, 10 Oct 1999 16:39:55 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910102039.QAA11104@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
In-Reply-To: <3800D45F.B8C280F2@perio.unlp.edu.ar> from "Sergio A. Kessler" at
"Oct 10, 1999 03:01:03 pm"
To: "Sergio A. Kessler" <ser@perio.unlp.edu.ar>
Date: Sun, 10 Oct 1999 16:39:55 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yes, we have discussed this, and will add it to the TODO list.

Bruce Momjian wrote:

Because the next release is going to probably be 7.0, if people have
backward compatability library code that they have been dying to remove,
this is the time for it.

I don't recommend removing backward compatability with 6.4 or 6.5
releases, but if you have some code that is hanging around just to be
compatible with 6.1 or earlier, I think it can be removed now.

can the commands createuser and destroyuser be renamed to
pg_createuser and pg_destroyuser (as pg_dump) adding soft links to
preserve backwards compatibility (declaring previous commands
deprecated) ?

the same can be done for createdb and destroydb ...

I think is a much more nice namespace for Postgres wich is
important when you have thousands of commands in this times.

--
| Sergio A. Kessler http://sak.org.ar
-O_O- You can have it Soon, Cheap, and Working; choose *two*.

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

-- 
  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 Sun Oct 10 23:09:44 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id XAA12481
for pgsql-hackers@postgresql.org; Sun, 10 Oct 1999 23:08:53 -0400 (EDT)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
Message-ID: <38010C37.6C85816@vkci.com>
Date: Sun, 10 Oct 1999 17:59:19 -0400
From: Victor Kane <vk@vkci.com>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
X-Newsgroups: comp.databases.postgresql.hackers
Subject: Looking for pgsql programmer
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: 10 Oct 1999 17:56:38 -0400, nyc1-01-25.eclipse.net
Lines: 15
To: pgsql-hackers@postgresql.org

Gentlemen, pardon my non-hacker's intrusion, into this hacker zone.
I have two projects - one rather urgent - for a pgSQL programmer(s)
and thought this would be the right place to ask.
Both projects are for different types of retail businesses.
I have a dBase-3 code of a working application to be used as a prototype

for one of them.
My business is located in New York City, so, some proximity - I imagine
-
would be a convenience.
If anyone of you is interested - please contact me at my email
address.

Victor.

From bouncefilter Sun Oct 10 20:40:42 1999
Received: from osprey.astro.umass.edu (root@osprey.astro.umass.edu
[128.119.51.182]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA96537
for <pgsql-hackers@postgreSQL.org>;
Sun, 10 Oct 1999 20:40:38 -0400 (EDT)
(envelope-from weinberg@osprey.astro.umass.edu)
Received: from osprey.astro.umass.edu (weinberg@localhost [127.0.0.1])
by osprey.astro.umass.edu (8.9.3/8.9.3/Debian/GNU) with ESMTP id
UAA18086; Sun, 10 Oct 1999 20:37:04 -0400
Message-Id: <199910110037.UAA18086@osprey.astro.umass.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Martin Weinberg <weinberg@osprey.astro.umass.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] memory problems in copying large table to STDOUT
In-reply-to: Your message of "Sun, 10 Oct 1999 11:59:53 EDT."
<2101.939571193@sss.pgh.pa.us>
Date: Sun, 10 Oct 1999 20:37:04 -0300
From: Martin Weinberg <weinberg@osprey.astro.umass.edu>

Hi Tom,

I got the backtrace with ""Memory exhausted in
AllocSetAlloc()" this time. The process has a virtual image
size of 103840 which is consistent with SHMMAX + the text
and stack size (in case this fact is of any use) . . .

Again, I've saved the process in case checking any symbols
would be helpful.

--Martin

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

(gdb) bt
#0 0x4012eb77 in pause ()
#1 0x81160e9 in elog (lev=1,
fmt=0x814f05d "Memory exhausted in AllocSetAlloc()") at elog.c:81
#2 0x811949e in AllocSetAlloc (set=0x8232fb0, size=875628846) at aset.c:273
#3 0x8119a13 in PortalHeapMemoryAlloc (this=0x81efbd8, size=875628846)
at portalmem.c:264
#4 0x8119732 in MemoryContextAlloc (context=0x81efbd8, size=875628846)
at mcxt.c:230
#5 0x810ebf1 in textout (vlena=0x4106182c) at varlena.c:190
#6 0x808508c in CopyTo (rel=0x822af08, binary=0 '\000', oids=0 '\000',
fp=0x0, delim=0x813c829 "\t") at copy.c:421
#7 0x8084ce4 in DoCopy (relname=0x8235068 "psc", binary=0 '\000',
oids=0 '\000', from=0 '\000', pipe=1 '\001', filename=0x0,
delim=0x813c829 "\t") at copy.c:323
#8 0x80ea8c6 in ProcessUtility (parsetree=0x8235080, dest=Remote)
at utility.c:227
#9 0x80e8a36 in pg_exec_query_dest (
query_string=0xbfffb274 "copy psc to STDOUT;", dest=Remote, aclOverride=0)
at postgres.c:727
#10 0x80e8944 in pg_exec_query (query_string=0xbfffb274 "copy psc to STDOUT;")
at postgres.c:656
#11 0x80e9b88 in PostgresMain (argc=11, argv=0xbffff7ec, real_argc=12,
real_argv=0xbffffd04) at postgres.c:1647
#12 0x80d1adc in DoBackend (port=0x81ef748) at postmaster.c:1628
#13 0x80d1613 in BackendStartup (port=0x81ef748) at postmaster.c:1373
#14 0x80d0ca6 in ServerLoop () at postmaster.c:823
#15 0x80d080c in PostmasterMain (argc=12, argv=0xbffffd04) at postmaster.c:616
#16 0x80a4597 in main (argc=12, argv=0xbffffd04) at main.c:93
(gdb)

Tom Lane wrote on Sun, 10 Oct 1999 11:59:53 EDT

Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:

I am attaching the backtrace. This one simultaneously generated
this kernel message from the md driver:

raid0_map bug: hash->zone0==NULL for block 1132810879
Bad md_map in ll_rw_block

Definitely a problem but no longer sure if it's the same one . . .
sigh.

Looks like it is not the same. As you can see, the error message that
elog is about to report is "cannot read <block#> of <file>", which isn't
too surprising given the kernel notice:

#1 0x81160e9 in elog (lev=-1, fmt=0x8146a4b "cannot read block %d of %s")
at elog.c:81

If this read failure is reproducible then you will need to get that
taken care of before we can make any progress on the original problem.
But it might be a transient failure --- why don't you just start the
copy over again to see?

regards, tom lane

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

From bouncefilter Sun Oct 10 21:34:43 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 VAA01559
for <pgsql-hackers@postgreSQL.org>;
Sun, 10 Oct 1999 21:34:11 -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 VAA03582;
Sun, 10 Oct 1999 21:33:00 -0400 (EDT)
To: Martin Weinberg <weinberg@osprey.astro.umass.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] memory problems in copying large table to STDOUT
In-reply-to: Your message of Sun, 10 Oct 1999 20:37:04 -0300
<199910110037.UAA18086@osprey.astro.umass.edu>
Date: Sun, 10 Oct 1999 21:33:00 -0400
Message-ID: <3580.939605580@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:

I got the backtrace with ""Memory exhausted in
AllocSetAlloc()" this time.

#4 0x8119732 in MemoryContextAlloc (context=0x81efbd8, size=875628846)
at mcxt.c:230
#5 0x810ebf1 in textout (vlena=0x4106182c) at varlena.c:190
#6 0x808508c in CopyTo (rel=0x822af08, binary=0 '\000', oids=0 '\000',
fp=0x0, delim=0x813c829 "\t") at copy.c:421

OK, that shoots down the "memory leak" theory. It sure looks like
what you've got is corrupt data: textout is reading a length word of
875628846 (plus or minus a couple bytes) from what is supposed to be
a text datum. Obviously that's not right. Next question is how
it got that way.

I think it's pretty likely that the original cause is the kernel disk
driver or disk hardware flakiness that we already have evidence for.
However, I hate passing the buck like that, so I'm willing to continue
digging if you are.

Again, I've saved the process in case checking any symbols
would be helpful.

You should look at the source tuple location info in CopyTo ---
something like
(gdb) f 6 -- frame 6, ie, CopyTo
(gdb) p i -- get column number
(gdb) p *tuple -- print contents of HeapTupleData
(gdb) p *tuple->t_data -- print contents of HeapTupleHeaderData

The last is mainly to find out the tuple's OID for possible future
reference. What we want right now is the tuple location info,
tuple->t_self, which will give us a block number (bi_hi and bi_lo in
that struct are the high and low 16 bits of the block number). Then,
if you can use dd and od to get a hex dump of that block from the
relation's data files, we can see what's really on disk there.
(Remember that the "blocks" are 8K each; also, if you get an offset
beyond 1 gig, then it's going to be in one of the continuation files
"psc.1", "psc.2", etc --- one gig apiece.)

It would also be useful to look at the contents of the disk block as
sitting in memory in the backend, to see if they are the same as what
you read using dd; I would not be too surprised to find they are not.
The t_data pointer should be pointing into a disk buffer in Postgres'
shared memory block, but offhand I'm not sure what's the easiest way to
discover the starting address of that buffer using gdb. (Can any other
hackers lend a hand here?)

regards, tom lane

From bouncefilter Mon Oct 11 00:21:46 1999
Received: from osprey.astro.umass.edu (root@osprey.astro.umass.edu
[128.119.51.182]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA21092
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 00:20:51 -0400 (EDT)
(envelope-from weinberg@osprey.astro.umass.edu)
Received: from osprey.astro.umass.edu (weinberg@localhost [127.0.0.1])
by osprey.astro.umass.edu (8.9.3/8.9.3/Debian/GNU) with ESMTP id
AAA18542; Mon, 11 Oct 1999 00:17:21 -0400
Message-Id: <199910110417.AAA18542@osprey.astro.umass.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Martin Weinberg <weinberg@osprey.astro.umass.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] memory problems in copying large table to STDOUT
In-reply-to: Your message of "Sun, 10 Oct 1999 21:33:00 EDT."
<3580.939605580@sss.pgh.pa.us>
Date: Mon, 11 Oct 1999 00:17:21 -0300
From: Martin Weinberg <weinberg@osprey.astro.umass.edu>

Hi Tom,

Tom Lane wrote on Sun, 10 Oct 1999 21:33:00 EDT

I think it's pretty likely that the original cause is the kernel disk
driver or disk hardware flakiness that we already have evidence for.
However, I hate passing the buck like that, so I'm willing to continue
digging if you are.

Honestly, I'm inclined to agree but I'd like to know for sure before
go buy a hardware raid controller (or give up trying to build a
database this large with Linux altogether). The "coincidence" that's
haunting me here is that I used pgsql on a 12GB database of the same
sort with no trouble for about 6 months. All of this started when I
tried to load 60GB. And after loading the table, I index it and
exercise it and everything is fine. Twice now, this problem has
arisen when I've tried to backup the table with a "copy". The first
time, I wiped out the raid array, got the latest kernel with the
up-to-date raid patches and rebuilt (takes a while . . .). Same thing
again. Of course, this copy hits the disks pretty hard, so maybe it's
not so coincidental. Anyway, ruling out a pgsql problem would be
progress.

Again, I've saved the process in case checking any symbols
would be helpful.

You should look at the source tuple location info in CopyTo ---
something like
(gdb) f 6 -- frame 6, ie, CopyTo
(gdb) p i -- get column number
(gdb) p *tuple -- print contents of HeapTupleData
(gdb) p *tuple->t_data -- print contents of HeapTupleHeaderData

The last is mainly to find out the tuple's OID for possible future
reference. What we want right now is the tuple location info,
tuple->t_self, which will give us a block number (bi_hi and bi_lo in
that struct are the high and low 16 bits of the block number). Then,
if you can use dd and od to get a hex dump of that block from the
relation's data files, we can see what's really on disk there.
(Remember that the "blocks" are 8K each; also, if you get an offset
beyond 1 gig, then it's going to be in one of the continuation files
"psc.1", "psc.2", etc --- one gig apiece.)

Ok done. Here's what I find:

(gdb) p i
$1 = 48
(gdb) p *tuple
$2 = {t_len = 352, t_self = {ip_blkid = {bi_hi = 24, bi_lo = 26279},
ip_posid = 19}, t_data = 0x41061710}
(gdb) p *tuple->t_data
$3 = {t_oid = 37497689, t_cmin = 0, t_cmax = 0, t_xmin = 17943, t_xmax
= 0,
t_ctid = {ip_blkid = {bi_hi = 24, bi_lo = 26279}, ip_posid = 19},
t_natts = 63, t_infomask = 2307, t_hoff = 40 '(', t_bits = "<FF><FF><FF><FF>"}

Now, check me to make sure I've followed you correctly:

Since 1GB of blocks is 0x20000, this data in the 13th GB.
The offset into the 13th is 26279.

So I did:

dd if=psc.12 skip=26279 count=1 bs=8k | od -t x > ~/dump.hex

I'm not sure what I'm looking for in dump.hex. The first hand full
of lines are:

--Martin

===========================================================================

From bouncefilter Mon Oct 11 04:33:47 1999
Received: from server1.ppc.pims.org (ptr4.skynet.be [194.78.114.4] (may be
forged)) by hub.org (8.9.3/8.9.3) with ESMTP id EAA45918
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 04:33:05 -0400 (EDT)
(envelope-from huffmana@ppc.pims.org)
Received: from ppc.pims.org ([207.176.11.63]) by server1.ppc.pims.org
(Netscape Messaging Server 3.5) with ESMTP id AAA6666
for <pgsql-hackers@postgreSQL.org>; Mon, 11 Oct 1999 10:31:39 +0200
Message-ID: <3801A034.994FE487@ppc.pims.org>
Date: Mon, 11 Oct 1999 10:30:44 +0200
From: "Allan Huffman" <huffmana@ppc.pims.org>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: --with-mb-encoding?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To ./configure PostgreSQL 6.5.2 to run with JDBC 1.1.7 what encoding
should I use in the following:

"--with-mb-encoding enable multi-byte support" (from
www.postgresql.org/docs/admin/config.htm)

Many Thanks,

Allan

Allan@ppc.pims.org

PS I found this:

Unicode can now be used in operating systems from Microsoft, IBM, DEC,
Sun, and Apple. Microsoft Windows NT uses Unicode as the default
character encoding in the OS; Windows 95 has most of the Microsoft
Unicode API in the MFC foundation class libraries. IBM, DEC, and Sun
offer Unicode in varying degrees of implementation, ranging from a full
Unicode development library provided with IBM AIX, to UTF-8 multi-byte
and UCS-4 wide-character support in Solaris, following the POSIX model.

http://www.isoc.org/isoc/whatis/conferences/inet/97/proceedings/A8/A8_2.HTM

so should I specify Unicode? Guess that it is worth a try.... Guess
that I should check out the Sun site too.

From bouncefilter Mon Oct 11 05:33: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 FAA60927
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 05:33:14 -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 NAA26832
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 13:32:48 +0400 (MSD)
Date: Mon, 11 Oct 1999 13:32:47 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
Reply-To: Oleg Bartunov <oleg@sai.msu.su>
To: pgsql-hackers@postgreSQL.org
Subject: vaccum problem
Message-ID: <Pine.GSO.3.96.SK.991011131943.4801V-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

I have a cron job to vacuum table which updates rather frequently
and after month of work I'm getting NOTICE

NOTICE: Index hits_pkey: NUMBER OF INDEX' TUPLES (10003) IS NOT THE SAME AS
HEAP' (10006)

I use

psql -tq discovery < vacuum_hits.sql
where vacuum_hits.sql is:

vacuum analyze hits(msg_id);
begin work;
drop index hits_pkey;
create unique index hits_pkey on hits(msg_id);
end work;

I rebuild index hits_pkey to avoid infinite grow - well, after Vadim's
patch it still grows when table intensively updates.

I've dumped and restored this table but I still get NOTICE message.
The site I developed is in alpha stage, so sometimes I restart http
server. I use persistent connection with postgres database so
each http process has persistent connection with postgres database.
Could be the problem If I just kill http processes and restart them ?
Or I have to stop all postgres processes before ?
What's the best way to manage persistent connections in 24*7 regime
of http server ?

Regards,

Oleg

PS.
Forget to note: postgres 6.5.2, Linux 2.0.37, Apache 1.3.9,
modperl 1.21, ApacheDBI 0.87
_____________________________________________________________
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 11 06:09:48 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 GAA64712
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 06:09:13 -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 TAA02736; Mon, 11 Oct 1999 19:08:16 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>
Cc: "Thomas Lockhart" <lockhart@alumni.caltech.edu>,
"pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
Date: Mon, 11 Oct 1999 19:12:06 +0900
Message-ID: <000201bf13d1$1260f560$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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <199910071635.MAA01926@candle.pha.pa.us>

I'm planning to implement a new type of scan,scan by TID.
It's on TODO * Allow WHERE restriction on ctid.
First,I want to define an equal operator between TID.

[snip]

I would use OIDs for '=' operator between TIDs as follows.
387 for = (tid, tid)
1292 for tideq(tid, tid)

Unfortunately,TIDs are changed by UPDATE operations.
So we would need some functions in order to get the latest
TID of a specified tuple such as
currtid(relationid/name, tid) which returns tid.
I would provide functions for both relid and relname and
use 1293-1294 for OIDs of these functions.

Comments ?
If there's no objection,I would commit them to the current tree.

Sounds good.

I have committed them to the current tree.
Needs initdb.

Now we could enjoy WHERE restriction on ctid as follows.
Unfortunately,the scan is still sequential.

=> create table t1 (dt text);
CREATE
=> insert into t1 values ('data inserted');
INSERT 45833 1
=> select ctid,* from t1;
ctid |dt
-----+----------
(0,1)|data inserted
(1 row)

=> select * from t1 where ctid='(0,1)';
dt
----------
data inserted
(1 row)

=> update t1 set dt='data updated';
UPDATE 1
=> select * from t1 where ctid='(0,1)';
dt
--
(0 rows)

=> select ctid,* from t1 where ctid=currtid2('t1', '(0,1)');
ctid |dt
-----+------------
(0,2)|data updated
(1 row)

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Oct 11 06:47:50 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 GAA68421
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 06:47:48 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11acuN-0003kLC; Mon, 11 Oct 99 12:42 MET DST
Message-Id: <m11acuN-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Interesting Quote you might enjoy about PGSQL.
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Mon, 11 Oct 1999 12:42:23 +0200 (MET DST)
Cc: 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: <199910090255.WAA24733@candle.pha.pa.us> from "Bruce Momjian" at
Oct 8, 99 10:55:08 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

... PostgreSQL has more advanced features than any commercial
RDBMS. Most important, the loosely organized, unpaid
developers of PostgreSQL were able to convert to an
Oracle-style multiversion concurrency system (see below),
leaving all the rest of the commercial competition
deadlocked in the dust.

There we go, riding Vadim's coattails to glory :))

Wow, that web page looks good now, with the quote at the bottom. Jan,
we need the nicer world image.

You mean one with the mountains - no?

Well, I'll spend some time, polish up the Povray sources etc.
so Vince can easily maintain the map after - only that he
needs Povray 3.1 and maybe Tcl/Tk 8.0 to do it, but that
shouldn't be a problem since both are freely available and
easily to install.

Jan

From bouncefilter Mon Oct 11 07:40:49 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id HAA72993
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 07:40:19 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 1415 invoked by uid 1001); 11 Oct 1999 11:40:20 -0000
Date: Mon, 11 Oct 1999 07:40:20 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Jan Wieck <wieck@debis.com>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, lockhart@alumni.caltech.edu,
lamar.owen@wgcr.org, pgsql-hackers@postgreSQL.org, jwieck@debis.com
Subject: Re: [HACKERS] Interesting Quote you might enjoy about PGSQL.
In-Reply-To: <m11acuN-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.BSF.4.05.9910110739140.1131-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 11 Oct 1999, Jan Wieck wrote:

Bruce Momjian wrote:

... PostgreSQL has more advanced features than any commercial
RDBMS. Most important, the loosely organized, unpaid
developers of PostgreSQL were able to convert to an
Oracle-style multiversion concurrency system (see below),
leaving all the rest of the commercial competition
deadlocked in the dust.

There we go, riding Vadim's coattails to glory :))

Wow, that web page looks good now, with the quote at the bottom. Jan,
we need the nicer world image.

You mean one with the mountains - no?

Well, I'll spend some time, polish up the Povray sources etc.
so Vince can easily maintain the map after - only that he
needs Povray 3.1 and maybe Tcl/Tk 8.0 to do it, but that
shouldn't be a problem since both are freely available and
easily to install.

Not a problem. I may have some questions re Povray's setup (I've
never used it).

From bouncefilter Mon Oct 11 09:46:51 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA05194
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 09:46:02 -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 JAA26512;
Mon, 11 Oct 1999 09:45:28 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910111345.JAA26512@candle.pha.pa.us>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
In-Reply-To: <000201bf13d1$1260f560$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Oct 11, 1999 07:12:06 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 11 Oct 1999 09:45:28 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have committed them to the current tree.
Needs initdb.

TODO list updated. Seems the tid could be accessed directly, by
checking the page list, and if it is valid, just going to the tid. I
assume you are working on that issue, or do you need assistance?

-- 
  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 Mon Oct 11 09:46:53 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA05213
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 09:46:19 -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 JAA26545;
Mon, 11 Oct 1999 09:45:54 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910111345.JAA26545@candle.pha.pa.us>
Subject: Re: [HACKERS] Interesting Quote you might enjoy about PGSQL.
In-Reply-To: <m11acuN-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 11, 1999 12:42:23 pm"
To: Jan Wieck <wieck@debis.com>
Date: Mon, 11 Oct 1999 09:45:54 -0400 (EDT)
CC: lockhart@alumni.caltech.edu, lamar.owen@wgcr.org,
pgsql-hackers@postgreSQL.org, jwieck@debis.com
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Wow, that web page looks good now, with the quote at the bottom. Jan,
we need the nicer world image.

You mean one with the mountains - no?

Well, I'll spend some time, polish up the Povray sources etc.
so Vince can easily maintain the map after - only that he
needs Povray 3.1 and maybe Tcl/Tk 8.0 to do it, but that
shouldn't be a problem since both are freely available and
easily to install.

Yes. I would also like to see the sources.

-- 
  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 Mon Oct 11 09:47:06 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA05230
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 09:46:49 -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 JAA26559;
Mon, 11 Oct 1999 09:46:17 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910111346.JAA26559@candle.pha.pa.us>
Subject: Re: [HACKERS] Interesting Quote you might enjoy about PGSQL.
In-Reply-To: <Pine.BSF.4.05.9910110739140.1131-100000@paprika.michvhf.com>
from
Vince Vielhaber at "Oct 11, 1999 07:40:20 am"
To: Vince Vielhaber <vev@michvhf.com>
Date: Mon, 11 Oct 1999 09:46:17 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>, lockhart@alumni.caltech.edu,
lamar.owen@wgcr.org, pgsql-hackers@postgreSQL.org, jwieck@debis.com
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Wow, that web page looks good now, with the quote at the bottom. Jan,
we need the nicer world image.

You mean one with the mountains - no?

Well, I'll spend some time, polish up the Povray sources etc.
so Vince can easily maintain the map after - only that he
needs Povray 3.1 and maybe Tcl/Tk 8.0 to do it, but that
shouldn't be a problem since both are freely available and
easily to install.

I have tcl 8.0.5 and povray here too.

-- 
  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 Mon Oct 11 10:11:51 1999
Received: from ext16.sra.co.jp (IDENT:root@ykh28DS04.kng.mesh.ad.jp
[133.205.214.4]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA08753
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 10:11:02 -0400 (EDT)
(envelope-from t-ishii@ext16.sra.co.jp)
Received: from ext16.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext16.sra.co.jp (8.8.8/8.8.8) with ESMTP id XAA00901;
Mon, 11 Oct 1999 23:04:22 +0900
Message-Id: <199910111404.XAA00901@ext16.sra.co.jp>
To: "Allan Huffman" <huffmana@ppc.pims.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: PostgreSQL Help
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Mon, 11 Oct 1999 15:30:15 +0200.
<3801E667.82AD4B99@ppc.pims.org>
Date: Mon, 11 Oct 1999 23:04:22 +0900
Sender: t-ishii@ext16.sra.co.jp

Dear Tatsuo (did I get your name right this time),

Yes:-)

After installing PostgreSQL 6.5.2
--with-mb=UNICODE

I am still getting a truncation of some varchar columns. When accessing a table
in PostgreSQL I get this:
$(C(BERROR: Conversion between UNICODE and SQL_ASCII is not supported$(D(B

What kind of client program are you using? If it's psql or something
using libpq, you are likely setting an environment variable
PGCLIENTENCODING to SQL_ASCII. As the message said, Conversion between
UNICODE and SQL_ASCII is not currently supported. You should unset the
variable and use a client program that understands UNICODE (UTF-8).

If your client program is a Java using JDBC, I have no idea at all
since I am not involved into the PostgreSQL JDBC driver.
---
Tatsuo Ishii

From bouncefilter Mon Oct 11 11:59:53 1999
Received: from osprey.astro.umass.edu (root@osprey.astro.umass.edu
[128.119.51.182]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA23963
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 11:59:50 -0400 (EDT)
(envelope-from weinberg@osprey.astro.umass.edu)
Received: from osprey.astro.umass.edu (weinberg@localhost [127.0.0.1])
by osprey.astro.umass.edu (8.9.3/8.9.3/Debian/GNU) with ESMTP id
LAA20895; Mon, 11 Oct 1999 11:57:16 -0400
Message-Id: <199910111557.LAA20895@osprey.astro.umass.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: weinberg@osprey.astro.umass.edu, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] memory problems in copying large table to STDOUT
In-reply-to: Your message of "Mon, 11 Oct 1999 10:59:25 EDT."
<7793.939653965@sss.pgh.pa.us>
Date: Mon, 11 Oct 1999 11:57:16 -0300
From: Martin Weinberg <weinberg@osprey.astro.umass.edu>

Tom Lane wrote on Mon, 11 Oct 1999 10:59:25 EDT

Looks good. For fun you might try "select * from psc where oid = 37497689"
and see if it succeeds or not on a "retail" retrieval of the problem tuple.

Yes . . . the backend dies with status 11. Could this be that I
can't do this until "release" the other process since it seems to
have gobbled all the shared memory?

Could you send the whole dump? I can figure this stuff out by hand but
I'm not sure I can explain it to someone else. (The relevant data
structure declarations are in various files in src/include/storage/ and
src/include/access/ if you want to look for yourself.)

Here it is:

0000000 01840064 20002000 02c09ea0 02809d60
0000020 02c09c00 02989ab4 02c09954 02989808
0000040 028096c8 02809588 02c09428 02c092c8
0000060 02c09168 02c09008 02c08ea8 02988d5c
0000100 02c08bfc 02c08a9c 0280895c 02588830
0000120 02c086d0 02c08570 02588444 02c082e4
0000140 02c08184 00000000 00000000 00000000
0000160 00000000 00000000 00000000 00000000
*
0000600 00000000 023c2b5d 00000000 00000000
0000620 00004617 00000000 66a70018 003f0017
0000640 ff280903 ffffffff 000fffff 00000005
0000660 00000073 fffffd95 000000ac 00003d2b
0000700 4375bc7b c142851c 4024fe3b 41cb436f
0000720 3df5c28f 3df5c28f 0000002d c0e851ec
0000740 0000000a 31313131 00003131 416ec49c
0000760 41676873 41672b02 3cfdf3b6 3d1fbe77
0001000 3da7ef9e 416ec49c 41676873 41672b02
0001020 3fc8f5c3 3f866666 3f91eb85 438015c3
0001040 445407ae 44b6f429 00010001 00000001
0001060 416ecccd 41661893 416476c9 3d810625
0001100 3de147ae 3e48b439 00000000 00000000
0001120 00000000 00000007 00303030 00000007
0001140 00303030 00000007 00303030 0000000a
0001160 30303030 00003030 0000000a 30303030
0001200 00003030 0000000a 30303030 00003030
0001220 00000008 36363030 00000008 36363030
0001240 00000008 36333030 bd2c0831 bd1ba5e3
0001260 bced9168 00000000 00000011 35373055
0001300 36393030 35373237 00000032 3ee147ae
0001320 41873333 417e6666 3eeb851f 3c75c28f
0001340 3ef33333 023c2b5c 00000000 00000000
0001360 00004617 00000000 66a70018 003f0016
0001400 ff280903 ffffffff 000fffff 00000005
0001420 00000073 fffffd95 000000ac 00003d2c
0001440 4375b28f c14283ee 4023590c 41cb80be
0001460 3e851eb8 3e4ccccd 0000000b 43011eb8
0001500 0000000a 31313131 00003131 418226e9
0001520 417d4396 41764dd3 3db43958 3df9db23
0001540 3e3851ec 418226e9 417d4396 41764dd3
0001560 3fb47ae1 3f4ccccd 3f6147ae 437fbae1
0001600 445437ae 44b6e000 00010001 00000001
0001620 418047ae 4181126f 4178ed91 3e49ba5e
0001640 3e8ccccd 3e418937 00000000 00000000
0001660 00000000 00000007 00303030 00000007
0001700 00303030 00000007 00303030 0000000a
0001720 30303030 00003030 0000000a 30303030
0001740 00003030 0000000a 30303030 00003030
0001760 00000008 36323030 00000008 36303030
0002000 00000008 35303130 bd2c0831 bd1ba5e3
0002020 bced9168 00000000 00000011 35373055
0002040 36393030 37343037 00000034 3d8f5c29
0002060 41980000 418d999a 3ee147ae 3edeb852
0002100 3f600000 023c2b5b 00000000 00000000
0002120 00004617 00000000 66a70018 003f0015
0002140 ff280903 edbefbff 000e1fff 00000005
0002160 00000073 fffffd95 000000ac 00003d2e
0002200 4375af05 c1427b74 4022dec2 41cb9919
0002220 3e570a3d 3e428f5c 0000005d 4331c51f
0002240 0000000a 30313031 00003030 41871062
0002260 4181645a 4180f5c3 3e126e98 3e1db22d
0002300 41871062 4181645a 4185624e 3f7851ec
0002320 3fa8f5c3 437fc7ae 445463d7 40d4cccd
0002340 00010001 4188851f 417d1eb8 3e9a1cac
0002360 3e656042 00000000 00000000 00000000
0002400 00000007 00303030 00000007 00303030
0002420 00000007 006c6966 0000000a 30303030
0002440 00003030 0000000a 30303030 00003030
0002460 0000000a 30303030 00003030 00000008
0002500 36303030 00000008 36303030 00000005
0002520 00000030 bd2c0831 bd1ba5e3 bced9168
0002540 00000000 3f358106 3d5d2f1b 3f4353f8
0002560 023c2b5a 00000000 00000000 00004617
0002600 00000000 66a70018 003f0014 ff280903
0002620 ffffffff 000fffff 00000005 00000073
0002640 fffffd95 000000ac 00003d2f 4375c250
0002660 c14279bb 40261fbc 41cb231d 3df5c28f
0002700 3df5c28f 0000005a c2aee148 0000000a
0002720 31313131 00003131 415c6666 4154c083
0002740 41531aa0 3cc49ba6 3ccccccd 3d178d50
0002760 415c6666 4154c083 41531aa0 3f666666
0003000 3f933333 3f7851ec 43802000 4454299a
0003020 44b6bbd7 00010001 00000001 415c7efa
0003040 4154bc6a 41527ae1 3cbc6a7f 3d8d4fdf
0003060 3d7df3b6 00000000 00000000 00000000
0003100 00000007 00303030 00000007 00303030
0003120 00000007 00303030 0000000a 30303030
0003140 00003030 0000000a 30303030 00003030
0003160 0000000a 30303030 00003030 00000008
0003200 36363030 00000008 36363030 00000008
0003220 36363030 bd2c0831 bd1ba5e3 bced9168
0003240 00000000 00000011 35373055 36393030
0003260 30313437 00000037 3f0a3d71 4180cccd
0003300 41700000 3ef4bc6a 3dd2f1aa 3f14bc6a
0003320 023c2b59 00000000 00000000 00004617
0003340 00000000 66a70018 003f0013 ff280903
0003360 ffffffff 000fffff 00000005 00000073
0003400 fffffd95 000000ac 00003d31 4375c8ba
0003420 c1427477 402744d4 41cafd50 3e800000
0003440 3e428f5c 0000004f c32fa3d7 0000000a
0003460 31313131 00003131 41810c4a 417b4bc7
0003500 41769fbe 3d9db22d 3dd70a3d 3e395810
0003520 41810c4a 417b4bc7 41769fbe 3f666666
0003540 3f9c28f6 3f7851ec 437f8000 44541333
0003560 44b6e7ae 00010001 00000001 4180126f
0003600 41783958 41753f7d 3dc8b439 3e25e354
0003620 3e1ba5e3 00000000 00000000 00000000
0003640 00000007 00303030 00000007 00303030
0003660 00000007 00303030 0000000a 30303030
0003700 00003030 0000000a 30303030 00003030
0003720 0000000a 30303030 00003030 00000008
0003740 36313030 00000008 09310931 34310931
0003760 3237382e 2e343109 09393035 342e3431
0004000 00000000 00000011 35373055 36393030
0004020 35353537 00000035 3f4ccccd 4195999a
0004040 418c0000 3ed9999a 3e958106 3f378d50
0004060 023c2b58 00000000 00000000 00004617
0004100 00000000 66a70018 003f0012 ff280903
0004120 edbefbff 000e1fff 00000005 00000073
0004140 fffffd95 000000ac 00003d32 4375abb4
0004160 c1427133 40227432 41cbb0a2 3e570a3d
0004200 3e428f5c 000000a2 435f599a 0000000a
0004220 30313031 00003030 41860c4a 41820c4a
0004240 4174b852 3e116873 3e3851ec 41860c4a
0004260 41820c4a 4177ba5e 3f4f5c29 3fa00000
0004300 43800000 44544b85 40df0a3d 00010001
0004320 41861eb8 41818312 3e395810 3ebbe76d
0004340 00000000 00000000 00000000 00000007
0004360 00303030 00000007 00303030 00000007
0004400 006c6966 0000000a 30303030 00003030
0004420 0000000a 30303030 00003030 0000000a
0004440 30303030 00003030 00000008 36303030
0004460 00000008 36303030 00000005 00000030
0004500 bd2c0831 bd1ba5e3 bced9168 00000000
0004520 3f000000 3f760419 3fbb020c 023c2b57
0004540 00000000 00000000 00004617 00000000
0004560 66a70018 003f0011 ff280903 ffffffff
0004600 000e1fff 00000005 00000073 fffffd95
0004620 000000ac 00003d38 4375b2a2 c14260bd
0004640 4023d6b6 41cb8b2a 3df5c28f 3df5c28f
0004660 00000056 4300147b 0000000a 31313131
0004700 00003131 4177a5e3 416f53f8 4168dd2f
0004720 3d48b439 3d6d9168 3da9fbe7 4177a5e3
0004740 416f53f8 4168dd2f 3f7ae148 3f9851ec
0004760 3f70a3d7 437f547b 44543c29 44b6bd71
0005000 00010001 00000001 4178c49c 416f4fdf
0005020 41678d50 3d810625 3e2f1aa0 3dba5e35
0005040 00000000 00000000 00000000 00000007
0005060 00303030 00000007 00303030 00000007
0005100 00303030 0000000a 30303030 00003030
0005120 0000000a 30303030 00003030 0000000a
0005140 30303030 00003030 00000008 36363030
0005160 00000008 36333030 00000008 36303030
0005200 bd2c0831 bd1ba5e3 bced9168 00000000
0005220 3f051eb8 3eced917 3f6c8b44 023c2b56
0005240 00000000 00000000 00004617 00000000
0005260 66a70018 003f0010 ff280903 ffffffff
0005300 000fffff 00000005 00000073 fffffd95
0005320 000000ac 00003d3b 4375c079 c1425ae2
0005340 40263c43 41cb37f5 3df5c28f 3df5c28f
0005360 0000005a c278a3d7 0000000a 31313131
0005400 00003131 413e0c4a 4133eb85 4131e354
0005420 3cb43958 3cbc6a7f 3cd4fdf4 413e0c4a
0005440 4133eb85 4131e354 3f19999a 3f400000
0005460 3ee66666 4380ab85 445420a4 44b71614
0005500 00010001 00000001 413da9fc 41341062
0005520 41319db2 3c75c28f 3cf5c28f 3c9374bc
0005540 00000000 00000000 00000000 00000007
0005560 00303030 00000007 00303030 00000007
0005600 00303030 0000000a 30303030 00003030
0005620 0000000a 30303030 00003030 0000000a
0005640 30303030 00003030 00000008 35353130
0005660 00000008 36363030 00000008 35353130
0005700 bd2c0831 bd1ba5e3 bced9168 00000000
0005720 00000011 35373055 36393030 36363337
0005740 00000038 3f170a3d 41700000 41566666
0005760 3f220c4a 3e020c4a 3f428f5c 023c2b55
0006000 00000000 00000000 00004617 00000000
0006020 66a70018 003f000f ff280903 ffffffff
0006040 000fffff 00000005 00000073 fffffd95
0006060 000000ac 00003d3e 4375c67b c1425599
0006100 40275009 41cb14aa 3df5c28f 3df5c28f
0006120 0000002d c310c51f 0000000a 31313131
0006140 00003131 41732f1b 41660000 41636042
0006160 3d23d70a 3d178d50 3d89374c 41732f1b
0006200 41660000 41636042 3f8b851f 3f4a3d71
0006220 3f666666 437ff0a4 44541ccd 44b6f148
0006240 00010001 00000001 4172624e 41668b44
0006260 416147ae 3d03126f 3ddd2f1b 3ddf3b64
0006300 00000000 00000000 00000000 00000007
0006320 00303030 00000007 00303030 00000007
0006340 00303030 0000000a 30303030 00003030
0006360 0000000a 30303030 00003030 0000000a
0006400 30303030 00003030 00000008 36363030
0006420 00000008 35353130 00000008 36333030
0006440 bd2c0831 bd1ba5e3 bced9168 00000000
0006460 00000011 35373055 36393030 35303537
0006500 00000030 3faccccd 41973333 4189999a
0006520 3f52f1aa 3e27ef9e 3f7ced91 023c2b54
0006540 00000000 00000000 00004617 00000000
0006560 66a70018 003f000e ff280903 edbefbff
0006600 000fffff 00000005 00000073 fffffd95
0006620 000000ac 00003d45 4375bb2e c142481a
0006640 40259ad4 41cb5e49 3e19999a 3e19999a
0006660 0000002d 412947ae 0000000a 30313031
0006700 00003030 41826666 4179374c 4180872b
0006720 3db851ec 3db22d0e 41826666 4179374c
0006740 41850625 3f95c28f 3f9c28f6 437fb0a4
0006760 44540333 40d33333 00010001 418320c5
0007000 417ce560 3ea2d0e5 3ea8f5c3 00000000
0007020 00000000 00000000 00000007 00303030
0007040 00000007 00303030 00000007 006c6966
0007060 0000000a 30303030 00003030 0000000a
0007100 30303030 00003030 0000000a 30303030
0007120 00003030 00000008 36313030 00000008
0007140 36303030 00000005 00000030 bd2c0831
0007160 bd1ba5e3 bced9168 00000000 00000011
0007200 35373055 36393030 34343237 00000038
0007220 3f3851ec 419a6666 418b3333 3f395810
0007240 befae148 3e6f9db2 023c2b53 00000000
0007260 00000000 00004617 00000000 66a70018
0007300 003f000d ff280903 ffffffff 000fffff
0007320 00000005 00000073 fffffd95 000000ac
0007340 00003d48 4375c3cc c1424254 40272014
0007360 41cb2b20 3df5c28f 3df5c28f 0000002d
0007400 c2d7b852 0000000a 31313131 00003131
0007420 41681893 415f9db2 415d374c 3ced9168
0007440 3d03126f 3d3c6a7f 41681893 415f9db2
0007460 415d374c 3f733333 3fb33333 3f947ae1
0007500 437fae14 4453fb85 44b6f6b8 00010001
0007520 00000001 41674fdf 415f851f 415bced9
0007540 3c03126f 3d9374bc 3ddb22d1 00000000
0007560 00000000 00000000 00000007 00303030
0007600 00000007 00303030 00000007 00303030
0007620 0000000a 30303030 00003030 0000000a
0007640 30303030 00003030 0000000a 30303030
0007660 00003030 00000008 36363030 00000008
0007700 36363030 00000008 35343130 bd2c0831
0007720 bd1ba5e3 bced9168 00000000 00000011
0007740 35373055 36393030 35343437 00000031
0007760 3f6147ae 41873333 417ccccd 3f07ae14
0010000 3e19999a 3f2e147b 023c2b52 00000000
0010020 00000000 00004617 00000000 66a70018
0010040 003f000c ff280903 ffffffff 000fffff
0010060 00000005 00000073 fffffd95 000000ac
0010100 00003d4a 4375ad5e c14240f3 4023636f
0010120 41cbb55a 3df5c28f 3df5c28f 0000005a
0010140 43487ae1 0000000a 31313131 00003131
0010160 41609ba6 4158dd2f 4156353f 3cdd2f1b
0010200 3ce56042 3d23d70a 41609ba6 4158dd2f
0010220 4156353f 3f88f5c3 3f8b851f 3f828f5c
0010240 437fe666 44542852 44b6b5c3 00010001
0010260 00000001 4160a3d7 415778d5 4155c6a8
0010300 3cbc6a7f 3d872b02 3dc08312 00000000
0010320 00000000 00000000 00000007 00303030
0010340 00000007 00303030 00000007 00303030
0010360 0000000a 30303030 00003030 0000000a
0010400 30303030 00003030 0000000a 30303030
0010420 00003030 00000008 36363030 00000008
0010440 36363030 00000008 36363030 bd2c0831
0010460 bd1ba5e3 bced9168 00000000 00000011
0010500 35373055 36393030 38323936 00000036
0010520 3f2b851f 4185999a 41766666 3ef7ced9
0010540 3e29fbe7 3f266666 023c2b51 00000000
0010560 00000000 00004617 00000000 66a70018
0010600 003f000b ff280903 ffffffff 000fffff
0010620 00000005 00000073 fffffd95 000000ac
0010640 00003d4e 4375ab2d c142384d 40232374
0010660 41cbc580 3df5c28f 3df5c28f 0000005a
0010700 4366a148 0000000a 31313131 00003131
0010720 4173126f 416b0625 41666a7f 3d408312
0010740 3d5d2f1b 3da5e354 4173126f 416b0625
0010760 41666a7f 3fae147b 3faa3d71 3f95c28f
0011000 43800148 445438f6 44b6e3d7 00010001
0011020 00000001 41711eb8 4168f1aa 41659db2
0011040 3d591687 3df7ced9 3dba5e35 00000000
0011060 00000000 00000000 00000007 00303030
0011100 00000007 00303030 00000007 00303030
0011120 0000000a 30303030 00003030 0000000a
0011140 30303030 00003030 0000000a 30303030
0011160 00003030 00000008 36363030 00000008
0011200 36353030 00000008 36323030 bd2c0831
0011220 bd1ba5e3 bced9168 00000000 00000011
0011240 35373055 36393030 35373836 00000035
0011260 3f63d70a 418a6666 41833333 3f00c49c
0011300 3e9374bc 3f4a7efa 023c2b50 00000000
0011320 00000000 00004617 00000000 66a70018
0011340 003f000a ff280903 ffffffff 000fffff
0011360 00000005 00000073 fffffd95 000000ac
0011400 00003d4f 4375c0b4 c1423820 4026bf0a
0011420 41cb414c 3df5c28f 3df5c28f 0000005a
0011440 c282a3d7 0000000a 31313131 00003131
0011460 415ba1cb 415378d5 4153126f 3cc49ba6
0011500 3ccccccd 3d1374bc 415ba1cb 415378d5
0011520 4153126f 3f866666 3f570a3d 3f428f5c
0011540 43805c29 445417ae 44b6eeb8 00010001
0011560 00000001 415afdf4 4153f3b6 4154ac08
0011600 3cdd2f1b 3d5d2f1b 3d0b4396 00000000
0011620 00000000 00000000 00000007 00303030
0011640 00000007 00303030 00000007 00303030
0011660 0000000a 30303030 00003030 0000000a
0011700 30303030 00003030 0000000a 30303030
0011720 00003030 00000008 35353130 00000008
0011740 36363030 00000008 36363030 bd2c0831
0011760 bd1ba5e3 bced9168 00000000 00000011
0012000 35373055 36393030 33373337 00000034
0012020 3f88f5c3 417b3333 416ccccd 3f028f5c
0012040 3ccccccd 3f08f5c3 023c2b4f 00000000
0012060 00000000 00004617 00000000 66a70018
0012100 003f0009 ff280903 ffffffff 000fffff
0012120 00000005 00000073 fffffd95 000000ac
0012140 00003d51 4375bd58 c1423676 402634e3
0012160 41cb5674 3e051eb8 3e051eb8 0000002d
0012200 c1993333 0000000a 31313131 00003131
0012220 41780000 41706a7f 4172dd2f 3d48b439
0012240 3d50e560 3e16872b 41780000 41706a7f
0012260 4172dd2f 3f68f5c3 3fc28f5c 3f5c28f6
0012300 437ff0a4 44540a3d 44b70a8f 00010001
0012320 00000001 41770625 41779db2 416dbe77
0012340 3db43958 3ded9168 3df9db23 00000000
0012360 00000000 00000000 00000007 00303030
0012400 00000007 00303030 00000007 00303030
0012420 0000000a 30303030 00003030 0000000a
0012440 30303030 00003030 0000000a 30303030
0012460 00003030 00000008 36353030 00000008
0012500 36303030 00000008 36303030 bd2c0831
0012520 bd1ba5e3 bced9168 00000000 00000011
0012540 35373055 36393030 37393237 00000036
0012560 3f3851ec 418d999a 4184cccd 3ef2b021
0012600 be1cac08 3ea45a1d 023c2b4e 00000000
0012620 00000000 00004617 00000000 66a70018
0012640 003f0008 ff280903 ffffffff 000e1fff
0012660 00000005 00000073 fffffd95 000000ac
0012700 00003d52 4375c128 c1423492 4026dedb
0012720 41cb3f9a 3e8f5c29 3e851eb8 00000051
0012740 c28f23d7 0000000a 31313131 00003131
0012760 4182e76d 417a5604 41796042 3dba5e35
0013000 3dced917 3e560419 4182e76d 417a5604
0013020 41796042 3f9ae148 3f63d70a 3f428f5c
0013040 437fc51f 44542d71 44b6dae1 00010001
0013060 00000001 41839375 4178cccd 417a3d71
0013100 3edcac08 3df1a9fc 3e818937 00000000
0013120 00000000 00000000 00000007 00303030
0013140 00000007 00303030 00000007 00303030
0013160 0000000a 30303030 00003030 0000000a
0013200 30303030 00003030 0000000a 30303030
0013220 00003030 00000008 35313130 00000008
0013240 36303030 00000008 36303030 bd2c0831
0013260 bd1ba5e3 bced9168 00000000 3f378d50
0013300 3d75c28f 3f46e979 023c2b4d 00000000
0013320 00000000 00004617 00000000 66a70018
0013340 003f0007 ff280903 ffffffff 000e1fff
0013360 00000005 00000073 fffffd95 000000ac
0013400 00003d55 4375cc2c c1423065 4028c522
0013420 41cafd30 3df5c28f 3df5c28f 00000056
0013440 c35f028f 0000000a 31313131 00003131
0013460 417ec49c 41735c29 416e5a1d 3d9374bc
0013500 3d9374bc 3dced917 417ec49c 41735c29
0013520 416e5a1d 3f733333 3f75c28f 3f95c28f
0013540 43804148 4453feb8 44b6f0f6 00010001
0013560 00000001 417be354 4172c8b4 4170624e
0013600 3db43958 3e5c28f6 3e841893 00000000
0013620 00000000 00000000 00000007 00303030
0013640 00000007 00303030 00000007 00303030
0013660 0000000a 30303030 00003030 0000000a
0013700 30303030 00003030 0000000a 30303030
0013720 00003030 00000008 36333030 00000008
0013740 36323030 00000008 36303030 bd2c0831
0013760 bd1ba5e3 bced9168 00000000 3f36872b
0014000 3ea04189 3f8353f8 023c2b4c 00000000
0014020 00000000 00004617 00000000 66a70018
0014040 003f0006 ff280903 edbefbff 000fffff
0014060 00000005 00000073 fffffd95 000000ac
0014100 00003d56 4375c913 c1422f27 402844e1
0014120 41cb109b 3e3851ec 3e2e147b 00000078
0014140 c33470a4 0000000a 30313031 00003030
0014160 4183d4fe 418076c9 417cf9db 3dced917
0014200 3e116873 4183d4fe 418076c9 4182020c
0014220 3f99999a 3f7851ec 437f2e14 445410a4
0014240 40d9999a 00010001 4184c28f 4184c8b4
0014260 3e820c4a 3e947ae1 00000000 00000000
0014300 00000000 00000007 00303030 00000007
0014320 00303030 00000007 006c6966 0000000a
0014340 30303030 00003030 0000000a 30303030
0014360 00003030 0000000a 30303030 00003030
0014400 00000008 36313030 00000008 36303030
0014420 00000005 00000030 bd2c0831 bd1ba5e3
0014440 bced9168 00000000 00000011 35373055
0014460 36393030 33363537 00000036 3e8a3d71
0014500 4191999a 418f3333 3ed78d50 3e7ced91
0014520 3f2b020c 023c2b4b 00000000 00000000
0014540 00004617 00000000 66a70018 003f0005
0014560 ff280903 ffffffff 000fffff 00000005
0014600 00000073 fffffd95 000000ac 00003d58
0014620 4375b5f4 c1422d49 4025180d 41cb86b3
0014640 3df5c28f 3df5c28f 0000002d 42a4e666
0014660 0000000a 31313131 00003131 416c28f6
0014700 4164ac08 4164872b 3cf5c28f 3d1374bc
0014720 3d8d4fdf 416c28f6 4164ac08 4164872b
0014740 3f5eb852 3fa00000 3f47ae14 437fcf5c
0014760 44542f5c 44b6fa3d 00010001 00000001
0015000 416cf5c3 41643d71 416251ec 3cf5c28f
0015020 3d79db23 3df5c28f 00000000 00000000
0015040 00000000 00000007 00303030 00000007
0015060 00303030 00000007 00303030 0000000a
0015100 30303030 00003030 0000000a 30303030
0015120 00003030 0000000a 30303030 00003030
0015140 00000008 36363030 00000008 36363030
0015160 00000008 35333130 bd2c0831 bd1ba5e3
0015200 bced9168 00000000 00000011 35373055
0015220 36393030 34323137 00000034 3ef5c28f
0015240 41826666 417b3333 3eef9db2 3c1374bc
0015260 3ef43958 023c2b4a 00000000 00000000
0015300 00004617 00000000 66a70018 003f0004
0015320 ff280903 edbefbff 000fffff 00000005
0015340 00000073 fffffd95 000000ac 00003d5b
0015360 4375c246 c1422b6b 40272e84 41cb3b94
0015400 3e6147ae 3e4ccccd 00000049 c2add1ec
0015420 0000000a 30313031 00003030 418570a4
0015440 41812f1b 417e0419 3df7ced9 3e147ae1
0015460 418570a4 41812f1b 4182999a 3f51eb85
0015500 3f5eb852 438007ae 44540e14 40d051ec
0015520 00010001 41859ba6 41802d0e 3e25e354
0015540 3ec5a1cb 00000000 00000000 00000000
0015560 00000007 00303030 00000007 00303030
0015600 00000007 006c6966 0000000a 30303030
0015620 00003030 0000000a 30303030 00003030
0015640 0000000a 30303030 00003030 00000008
0015660 36303030 00000008 36303030 00000005
0015700 00000030 bd2c0831 bd1ba5e3 bced9168
0015720 00000000 00000011 35373055 36393030
0015740 39303437 00000039 3eb851ec 419b3333
0015760 41926666 3f083127 3e8b4396 3f4dd2f2
0016000 023c2b49 00000000 00000000 00004617
0016020 00000000 66a70018 003f0003 ff280903
0016040 ffffffff 000fffff 00000005 00000073
0016060 fffffd95 000000ac 00003d5f 4375c992
0016100 c14225e5 40287a31 41cb1070 3f028f5c
0016120 3f028f5c 0000005a c33b3852 0000000a
0016140 31313131 00003131 4187147b 41835c29
0016160 4180a3d7 3e189375 3e49ba5e 3e947ae1
0016200 4187147b 41835c29 4180a3d7 3f9ae148
0016220 3f451eb8 3f947ae1 437f75c3 44540ccd
0016240 44b6e948 00010001 00000001 418af5c3
0016260 418022d1 41a50000 3ea9fbe7 3e9a9fbe
0016300 410e353f 00000000 00000000 00000000
0016320 00000007 00303030 00000007 00303030
0016340 00000007 00303030 0000000a 30303030
0016360 00003030 0000000a 30303030 00003030
0016400 0000000a 30303030 00003030 00000008
0016420 36303030 00000008 36303030 00000008
0016440 36303030 bd2c0831 bd1ba5e3 bced9168
0016460 00000000 00000011 35373055 36393030
0016500 34373537 00000039 3f266666 4198cccd
0016520 418f3333 3eee147b 3eae147b 3f4e147b
0016540 023c2b48 00000000 00000000 00004617
0016560 00000000 66a70018 003f0002 ff280903
0016600 ffffffff 000e1fff 00000005 00000073
0016620 fffffd95 000000ac 00003d61 4375b6b0
0016640 c1422463 40255671 41cb84f3 3e6b851f
0016660 3e6147ae 00000047 4290bd71 0000000a
0016700 31313131 00003131 41847ae1 4179d2f2
0016720 4177a9fc 3de147ae 3dc28f5c 3e52f1aa
0016740 41847ae1 4179d2f2 4177a9fc 3f400000
0016760 3f91eb85 3f970a3d 437fbae1 44543852
0017000 44b6e052 00010001 00000001 41839ba6
0017020 41781062 41770625 3e52f1aa 3e818937
0017040 3ed6872b 00000000 00000000 00000000
0017060 00000007 00303030 00000007 00303030
0017100 00000007 00303030 0000000a 30303030
0017120 00003030 0000000a 30303030 00003030
0017140 0000000a 30303030 00003030 00000008
0017160 36303030 00000008 36313030 00000008
0017200 36303030 bd2c0831 bd1ba5e3 bced9168
0017220 00000000 3f722d0e 3e0a3d71 3f8a5e35
0017240 023c2b47 00000000 00000000 00004617
0017260 00000000 66a70018 003f0001 ff280903
0017300 ffffffff 000fffff 00000005 00000073
0017320 fffffd95 000000ac 00003d62 4375b331
0017340 c14221b7 4024c9cd 41cb9b43 3ea8f5c3
0017360 3e75c28f 0000004d 42f0e666 0000000a
0017400 31313131 00003131 4182b22d 417ced91
0017420 417bc28f 3dc8b439 3ddd2f1b 3e4ed917
0017440 4182b22d 417ced91 417bc28f 3f7ae148
0017460 3fa3d70a 3fa28f5c 437fc51f 44542c29
0017500 44b6fd71 00010001 00000001 41808937
0017520 4179f3b6 4173ef9e 3dcccccd 3e4ed917
0017540 3e872b02 00000000 00000000 00000000
0017560 00000007 00303030 00000007 00303030
0017600 00000007 00303030 0000000a 30303030
0017620 00003030 0000000a 30303030 00003030
0017640 0000000a 30303030 00003030 00000008
0017660 36303030 00000008 36313030 00000008
0017700 36303030 bd2c0831 bd1ba5e3 bced9168
0017720 00000000 00000011 35373055 36393030
0017740 32363037 00000035 3e8f5c29 41966666
0017760 418d999a 3f076c8b 3d958106 3f1a1cac
0020000

From bouncefilter Mon Oct 11 11:48:51 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 LAA22358
for <hackers@postgreSQL.org>; Mon, 11 Oct 1999 11:48:37 -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 OAA01866;
Mon, 11 Oct 1999 14:57:58 GMT
Sender: lockhart@hub.org
Message-ID: <3801FAF6.6CC3E6E0@alumni.caltech.edu>
Date: Mon, 11 Oct 1999 14:57:58 +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: Peter Eisentraut <peter_e@gmx.net>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <maillist@candle.pha.pa.us>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and comments
References: <Pine.LNX.4.10.9910072348440.848-100000@peter-e.yi.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Luckily, the regression tests don't make extensive use of the backslash
commands, the issue being that their output might change. I only found
three backslash commands in the whole regression tests. One occurence does
something like this:
some query;
*** comment
*** comment
\p
\r
more queries;
which should probably be changed anyway to something like
-- comment
-- comment

Actually, this is probably testing that the buffer reset actually
clears the lines, which wouldn't be as obvious if there were only
legal SQL preceeding it. Maybe leave it as-is??

- Thomas

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

From bouncefilter Mon Oct 11 11:00:52 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 LAA15011
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 11:00:29 -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 KAA07795;
Mon, 11 Oct 1999 10:59:25 -0400 (EDT)
To: Martin Weinberg <weinberg@osprey.astro.umass.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] memory problems in copying large table to STDOUT
In-reply-to: Your message of Mon, 11 Oct 1999 00:17:21 -0300
<199910110417.AAA18542@osprey.astro.umass.edu>
Date: Mon, 11 Oct 1999 10:59:25 -0400
Message-ID: <7793.939653965@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:

Ok done. Here's what I find:

(gdb) p i
$1 = 48
(gdb) p *tuple
$2 = {t_len = 352, t_self = {ip_blkid = {bi_hi = 24, bi_lo = 26279},
ip_posid = 19}, t_data = 0x41061710}
(gdb) p *tuple->t_data
$3 = {t_oid = 37497689, t_cmin = 0, t_cmax = 0, t_xmin = 17943, t_xmax
= 0,
t_ctid = {ip_blkid = {bi_hi = 24, bi_lo = 26279}, ip_posid = 19},
t_natts = 63, t_infomask = 2307, t_hoff = 40 '(', t_bits = "<FF><FF><FF><FF>"}

Looks good. For fun you might try "select * from psc where oid = 37497689"
and see if it succeeds or not on a "retail" retrieval of the problem tuple.

Now, check me to make sure I've followed you correctly:
Since 1GB of blocks is 0x20000, this data in the 13th GB.
The offset into the 13th is 26279.
So I did:
dd if=psc.12 skip=26279 count=1 bs=8k | od -t x > ~/dump.hex

Looks right to me.

I'm not sure what I'm looking for in dump.hex.

Could you send the whole dump? I can figure this stuff out by hand but
I'm not sure I can explain it to someone else. (The relevant data
structure declarations are in various files in src/include/storage/ and
src/include/access/ if you want to look for yourself.)

regards, tom lane

From bouncefilter Mon Oct 11 11:19:56 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 LAA17354;
Mon, 11 Oct 1999 11:18: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 PAA01927;
Mon, 11 Oct 1999 15:17:47 GMT
Sender: lockhart@hub.org
Message-ID: <3801FF9A.D88C446E@alumni.caltech.edu>
Date: Mon, 11 Oct 1999 15:17: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: Bruce Momjian <maillist@candle.pha.pa.us>
CC: "Sergio A. Kessler" <ser@perio.unlp.edu.ar>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgresql.org>
Subject: Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
References: <199910102039.QAA11104@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yes, we have discussed this, and will add it to the TODO list.

can the commands createuser and destroyuser be renamed to
pg_createuser and pg_destroyuser (as pg_dump) adding soft links to
preserve backwards compatibility (declaring previous commands
deprecated) ?
the same can be done for createdb and destroydb ...

I hope we don't have a consensus on this. Long commands with
underscores in them are certainly another sign of the coming
apocalypse ;)

- Thomas

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

From bouncefilter Mon Oct 11 11:25:52 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA18480
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 11:25:13 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id LAA09254;
Mon, 11 Oct 1999 11:24:43 -0400
Message-ID: <38020136.5948C081@wgcr.org>
Date: Mon, 11 Oct 1999 11:24:38 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Interesting Quote you might enjoy about PGSQL.
References: <37FE29D8.C778D2B3@wgcr.org>
<37FEA303.3D19D345@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

Lamar Owen wrote:

Found this quote by Philip Greenspun (who is unabashedly in love with
Oracle) in a LinuxWorld article:

It's nice to know he is a fan. btw, Philip was inquiring about the
feasibility of making PostgreSQL more compatible with Oracle to allow
him to port a large software project he built (in fact, you referred
us to his web site on some other topic recently). Until we have outer
joins it is a non-starter for him, but it was nice he asked :)

That would be the ArsDigita Community System -- ACS for short. This is
an absolutely wonderful community system for database-backed web sites
-- www.arsdigita.com for more info. Version 7 territory! I have played
with ACS against the free development-only Oracle 8i for Linux -- very
comprehensive. However, Oracle for a database-backed web site is priced
sky-high -- I saw one quote for $25,000 to back a website with Oracle 8i
on a 500MHz Pentium III (their license factors server speed into the
cost -- a 386-16 might only cost $1,000 on that scale...;-))
Compatibility with Oracle is IMHO a pretty good thing, as long as we
don't become an Oracle clone -- PostgreSQL has too many nice extras for
that.

Yeah, it was _because_ of AOLserver and Philip Greenspun that I got into
PostgreSQL in the first place.

BTW: RedHat 6.1 shipped, with the last RPM's I posted.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Mon Oct 11 11:33:51 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 LAA19696
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 11:32:56 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone (ppm228.noc.fukui.nsk.ne.jp [210.161.188.103])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id AAA02799; Tue, 12 Oct 1999 00:32:21 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
Date: Tue, 12 Oct 1999 00:30:54 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFOEACCAAA.Inoue@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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <199910111345.JAA26512@candle.pha.pa.us>

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: Monday, October 11, 1999 10:45 PM
To: Hiroshi Inoue
Cc: Thomas Lockhart; pgsql-hackers
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new
build-in operator)

I have committed them to the current tree.
Needs initdb.

TODO list updated. Seems the tid could be accessed directly, by
checking the page list, and if it is valid, just going to the tid. I
assume you are working on that issue, or do you need assistance?

Yes,I have done a part of my story.
I would add new type of path and scan by which we are able to access
tids directly.

I don't understand planner/executor stage well.
So I'm happy if someone could check my story.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Oct 11 12:02: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 MAA24729;
Mon, 11 Oct 1999 12:02:21 -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 LAA29508;
Mon, 11 Oct 1999 11:43:33 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910111543.LAA29508@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
In-Reply-To: <3801FF9A.D88C446E@alumni.caltech.edu> from Thomas Lockhart at
"Oct 11, 1999 03:17:46 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Mon, 11 Oct 1999 11:43:33 -0400 (EDT)
CC: "Sergio A. Kessler" <ser@perio.unlp.edu.ar>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yes, we have discussed this, and will add it to the TODO list.

can the commands createuser and destroyuser be renamed to
pg_createuser and pg_destroyuser (as pg_dump) adding soft links to
preserve backwards compatibility (declaring previous commands
deprecated) ?
the same can be done for createdb and destroydb ...

I hope we don't have a consensus on this. Long commands with
underscores in them are certainly another sign of the coming
apocalypse ;)

But if we keep symlinks to the existing names, is that OK?

-- 
  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 Mon Oct 11 12:57:54 1999
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA34365;
Mon, 11 Oct 1999 12:57:00 -0400 (EDT)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
KAA17620;
Mon, 11 Oct 1999 10:56:30 -0600 (MDT)
Date: Mon, 11 Oct 1999 10:56:30 -0600 (MDT)
Message-Id: <199910111656.KAA17620@biology.nmsu.edu>
X-Authentication-Warning: biology.nmsu.edu: brook set sender to
brook@biology.nmsu.edu using -f
From: Brook Milligan <brook@biology.nmsu.edu>
To: maillist@candle.pha.pa.us
CC: lockhart@alumni.caltech.edu, ser@perio.unlp.edu.ar,
pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
In-reply-to: <199910111543.LAA29508@candle.pha.pa.us> (message from Bruce
Momjian on Mon, 11 Oct 1999 11:43:33 -0400 (EDT))
Subject: Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
References: <199910111543.LAA29508@candle.pha.pa.us>

I hope we don't have a consensus on this. Long commands with
underscores in them are certainly another sign of the coming
apocalypse ;)

But if we keep symlinks to the existing names, is that OK?

Isn't the point to avoid naming conflicts. Symlinks won't help that,
surely.

I agree; underscores are a pain. If you must go this direction, I
suggest hyphens (-).

Cheers,
Brook

From bouncefilter Mon Oct 11 12:59:52 1999
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA34695
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 12:59:00 -0400 (EDT)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
KAA17623;
Mon, 11 Oct 1999 10:58:14 -0600 (MDT)
Date: Mon, 11 Oct 1999 10:58:14 -0600 (MDT)
Message-Id: <199910111658.KAA17623@biology.nmsu.edu>
X-Authentication-Warning: biology.nmsu.edu: brook set sender to
brook@biology.nmsu.edu using -f
From: Brook Milligan <brook@biology.nmsu.edu>
To: maillist@candle.pha.pa.us
CC: vev@michvhf.com, pgsql-hackers@postgreSQL.org
In-reply-to: <199910092021.QAA14345@candle.pha.pa.us> (message from Bruce
Momjian on Sat, 9 Oct 1999 16:21:56 -0400 (EDT))
Subject: Re: [HACKERS] Next release is 7.0(?)
References: <199910092021.QAA14345@candle.pha.pa.us>

Then perhaps we can also overhaul the installation. I installed about
5 times this past week and have it down to 4 or 5 steps (not including
regression testing).

Would this also be a relevant time to get a regression test to run on
a non-installed system? Couldn't this be done by starting up the
database on a different port from within the newly compiled source
tree for the purpose of testing?

Cheers,
Brook

From bouncefilter Mon Oct 11 13:05:54 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA36155;
Mon, 11 Oct 1999 13:05:43 -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 NAA05891;
Mon, 11 Oct 1999 13:04:56 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910111704.NAA05891@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
In-Reply-To: <199910111656.KAA17620@biology.nmsu.edu> from Brook Milligan at
"Oct 11, 1999 10:56:30 am"
To: Brook Milligan <brook@biology.nmsu.edu>
Date: Mon, 11 Oct 1999 13:04:56 -0400 (EDT)
CC: lockhart@alumni.caltech.edu, ser@perio.unlp.edu.ar,
pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I hope we don't have a consensus on this. Long commands with
underscores in them are certainly another sign of the coming
apocalypse ;)

But if we keep symlinks to the existing names, is that OK?

Isn't the point to avoid naming conflicts. Symlinks won't help that,
surely.

I agree; underscores are a pain. If you must go this direction, I
suggest hyphens (-).

You could make the actual command pg_createuser, and make a symlink of
createuser, but allow the symlink creation to fail. Best of both
worlds, I think. I vote for underscore. That's what I normally use.
Dashes look too much like command arguments.

-- 
  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 Mon Oct 11 13:06:52 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA36248
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 13:06:06 -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 NAA05903;
Mon, 11 Oct 1999 13:05:24 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910111705.NAA05903@candle.pha.pa.us>
Subject: Re: [HACKERS] Next release is 7.0(?)
In-Reply-To: <199910111658.KAA17623@biology.nmsu.edu> from Brook Milligan at
"Oct 11, 1999 10:58:14 am"
To: Brook Milligan <brook@biology.nmsu.edu>
Date: Mon, 11 Oct 1999 13:05:24 -0400 (EDT)
CC: vev@michvhf.com, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Then perhaps we can also overhaul the installation. I installed about
5 times this past week and have it down to 4 or 5 steps (not including
regression testing).

Would this also be a relevant time to get a regression test to run on
a non-installed system? Couldn't this be done by starting up the
database on a different port from within the newly compiled source
tree for the purpose of testing?

Gee, I never even though of that. What advantage would there be for
that?

-- 
  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 Mon Oct 11 14:06:54 1999
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA47033
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 14:06:06 -0400 (EDT)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
MAA18307;
Mon, 11 Oct 1999 12:05:42 -0600 (MDT)
Date: Mon, 11 Oct 1999 12:05:42 -0600 (MDT)
Message-Id: <199910111805.MAA18307@biology.nmsu.edu>
X-Authentication-Warning: biology.nmsu.edu: brook set sender to
brook@biology.nmsu.edu using -f
From: Brook Milligan <brook@biology.nmsu.edu>
To: maillist@candle.pha.pa.us
CC: vev@michvhf.com, pgsql-hackers@postgreSQL.org
In-reply-to: <199910111705.NAA05903@candle.pha.pa.us> (message from Bruce
Momjian on Mon, 11 Oct 1999 13:05:24 -0400 (EDT))
Subject: Re: [HACKERS] Next release is 7.0(?)
References: <199910111705.NAA05903@candle.pha.pa.us>

Would this also be a relevant time to get a regression test to run on
a non-installed system? Couldn't this be done by starting up the
database on a different port from within the newly compiled source
tree for the purpose of testing?

Gee, I never even though of that. What advantage would there be for
that?

Wouldn't that be useful for developing/debugging/testing a new version
on a machine that runs some other version in production mode?

One example would be someone who wants to update, but wishes to verify
the functioning of the new version prior to blowing away the old
one. So, one could build the new version, run regression tests,
resolve any issues, THEN deinstall the old version and install the new
already verified one.

Another example is that developers could use a production machine to
tweak new code without having to actually install the test versions.

I'm sure other applications of that flexibility are apparent also.

Cheers,
Brook

From bouncefilter Mon Oct 11 14:06:53 1999
Received: from noether.math.ksu.edu (noether.math.ksu.edu [129.130.6.19])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA47027
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 14:06:04 -0400 (EDT)
(envelope-from jamest@math.ksu.edu)
Received: from hobbes.math.ksu.edu (hobbes.math.ksu.edu [129.130.6.20])
by noether.math.ksu.edu (Postfix) with ESMTP
id 759481A422; Mon, 11 Oct 1999 13:06:02 -0500 (CDT)
Date: Mon, 11 Oct 1999 13:06:02 -0500 (CDT)
From: James Thompson <jamest@math.ksu.edu>
To: Brook Milligan <brook@biology.nmsu.edu>
Cc: maillist@candle.pha.pa.us, vev@michvhf.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Next release is 7.0(?)
In-Reply-To: <199910111658.KAA17623@biology.nmsu.edu>
Message-ID: <Pine.LNX.4.10.9910111302090.12458-100000@hobbes.math.ksu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 11 Oct 1999, Brook Milligan wrote:

Then perhaps we can also overhaul the installation. I installed about
5 times this past week and have it down to 4 or 5 steps (not including
regression testing).

One thing I thought would be nice would be a client only install. Say I'm
running a server on Solaris and want to make psql available on linux
stations which will access the Solaris server. Right now, unless I've
missed something, I'm stuck installing the whole package. No big problem
but if you're overhaulling the install..... :-)

Take Care,
James

->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561
Kansas State University Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

From bouncefilter Mon Oct 11 14:34:53 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA52031
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 14:34:33 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id OAA09646;
Mon, 11 Oct 1999 14:32:33 -0400
Message-ID: <38022D3A.712CB0A4@wgcr.org>
Date: Mon, 11 Oct 1999 14:32:26 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: James Thompson <jamest@math.ksu.edu>
CC: Brook Milligan <brook@biology.nmsu.edu>, maillist@candle.pha.pa.us,
vev@michvhf.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Next release is 7.0(?)
References: <Pine.LNX.4.10.9910111302090.12458-100000@hobbes.math.ksu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

James Thompson wrote:

One thing I thought would be nice would be a client only install. Say I'm
running a server on Solaris and want to make psql available on linux
stations which will access the Solaris server. Right now, unless I've
missed something, I'm stuck installing the whole package. No big problem
but if you're overhaulling the install..... :-)

You can do that now with the RPM installation under RedHat Linux --
however, it is an RPM feature, not part of the tarball.

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Mon Oct 11 14:59:55 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 OAA57335
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 14:59:13 -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 OAA08665;
Mon, 11 Oct 1999 14:57:25 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Brook Milligan <brook@biology.nmsu.edu>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Next release is 7.0(?)
In-reply-to: Your message of Mon, 11 Oct 1999 13:05:24 -0400 (EDT)
<199910111705.NAA05903@candle.pha.pa.us>
Date: Mon, 11 Oct 1999 14:57:25 -0400
Message-ID: <8663.939668245@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Would this also be a relevant time to get a regression test to run on
a non-installed system?

Gee, I never even though of that. What advantage would there be for
that?

It has been suggested before, and I think it's a good idea. The
advantage is you can smoke-test a new compilation *before* you blow
away your existing installation ;-)

It is, of course, possible to do that by installing into a nonstandard
location/port and then running the regress tests there. But you have
to know exactly what you're doing to do that. If we're going to
overhaul install, we should make it easier to run the regress tests
that way, or even better with not-installed-at-all binaries from the
source tree.

Another thing I'd like to see would be full support for building in
a separate object-directory tree, leaving the source tree pristine
rather than filled with configure and build output files.
This is a standard GNU practice and I think it's a good one.

regards, tom lane

From bouncefilter Mon Oct 11 15:09: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 PAA59712
for <pgsql-hackers@postgresql.org>;
Mon, 11 Oct 1999 15:09:13 -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 PAA08774;
Mon, 11 Oct 1999 15:07:46 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Bruce Momjian" <maillist@candle.pha.pa.us>,
"pgsql-hackers" <pgsql-hackers@postgresql.org>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
In-reply-to: Your message of Tue, 12 Oct 1999 00:30:54 +0900
<NDBBIJLOILGIKBGDINDFOEACCAAA.Inoue@tpf.co.jp>
Date: Mon, 11 Oct 1999 15:07:46 -0400
Message-ID: <8772.939668866@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Yes,I have done a part of my story.
I would add new type of path and scan by which we are able to access
tids directly.

Yes, new path type, new plan type, probably a new access method if
you want to keep things clean in the executor, cost-estimation routines
in the planner, etc. etc.

Looks like a lot of work, and a lot of added code bulk that will
have to be maintained. I haven't figured out why you think it's
worth it... tids are so transient that I don't see much need for
finding tuples by them...

regards, tom lane

From bouncefilter Mon Oct 11 15:12:00 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA60357
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 15:11:12 -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 PAA29986;
Mon, 11 Oct 1999 15:10:57 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910111910.PAA29986@candle.pha.pa.us>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)]
In-Reply-To: <NDBBIJLOILGIKBGDINDFOEACCAAA.Inoue@tpf.co.jp> from Hiroshi Inoue
at "Oct 12, 1999 00:30:54 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 11 Oct 1999 15:10:57 -0400 (EDT)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

TODO list updated. Seems the tid could be accessed directly, by
checking the page list, and if it is valid, just going to the tid. I
assume you are working on that issue, or do you need assistance?

Yes,I have done a part of my story.
I would add new type of path and scan by which we are able to access
tids directly.

I don't understand planner/executor stage well.
So I'm happy if someone could check my story.

My guess is that you are going to have to hard-code something into the
backend to handle non-scan lookup of this type specially.

Normally, either there is an index lookup, or a sequential scan. In
your case, you "know" the actual location of the row, or at least a
request for a possible valid location.

You could create a fake index that really doesn't exist, but returns a
tid that exactly matches the requested tid, or you could have the code
check for a specific TID type, and heap_fetch the desired row directly,
rather than performing a sequential scan. See the developers FAQ on how
to do a heap_fetch with a tid.

You can also use heap_fetch() to fetch rows by block
number/offset.

The block number/offset is the tid. Of course, you have to make sure
the tid is valid.

-- 
  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 Mon Oct 11 15:16:55 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA61866
for <pgsql-hackers@postgresql.org>;
Mon, 11 Oct 1999 15:16:49 -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 PAA00307;
Mon, 11 Oct 1999 15:14:16 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910111914.PAA00307@candle.pha.pa.us>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
In-Reply-To: <8772.939668866@sss.pgh.pa.us> from Tom Lane at "Oct 11,
1999 03:07:46 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 11 Oct 1999 15:14:16 -0400 (EDT)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Yes,I have done a part of my story.
I would add new type of path and scan by which we are able to access
tids directly.

Yes, new path type, new plan type, probably a new access method if
you want to keep things clean in the executor, cost-estimation routines
in the planner, etc. etc.

Looks like a lot of work, and a lot of added code bulk that will
have to be maintained. I haven't figured out why you think it's
worth it... tids are so transient that I don't see much need for
finding tuples by them...

That's why I just suggested a more short-circuited option of snatching
tid oids from expressions, and doing a heap_fetch directly at that point
to avoid the index scan. Seems it could be done in just one file.

-- 
  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 Mon Oct 11 15:18:55 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA62195
for <pgsql-hackers@postgresql.org>;
Mon, 11 Oct 1999 15:18:14 -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 PAA00329;
Mon, 11 Oct 1999 15:15:26 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910111915.PAA00329@candle.pha.pa.us>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
In-Reply-To: <8772.939668866@sss.pgh.pa.us> from Tom Lane at "Oct 11,
1999 03:07:46 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 11 Oct 1999 15:15:26 -0400 (EDT)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Yes,I have done a part of my story.
I would add new type of path and scan by which we are able to access
tids directly.

Yes, new path type, new plan type, probably a new access method if
you want to keep things clean in the executor, cost-estimation routines
in the planner, etc. etc.

Looks like a lot of work, and a lot of added code bulk that will
have to be maintained. I haven't figured out why you think it's
worth it... tids are so transient that I don't see much need for
finding tuples by them...

Ingres has access by tid, and it does come in handy for quick-and-dirty
uses where you just want to snag a bunch of rows and operate on them
without too much fuss. I believe if we had it, some things internally
may prove to be easier with them accessible in a query.

-- 
  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 Mon Oct 11 15:20:54 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA62986
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 15:20:51 -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 PAA00952
for pgsql-hackers@postgreSQL.org; Mon, 11 Oct 1999 15:20:45 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910111920.PAA00952@candle.pha.pa.us>
Subject: pginterface/pgeasy
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 11 Oct 1999 15:20:45 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM939669645-27189-0_
Content-Transfer-Encoding: 7bit

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

I have moved my easy C interface to pgsql into the main tree, and
renamed the old 'pginterface' to 'pgeasy'. Should compile/install
cleanly.

Thomas, can you convert the manual page to SGML and add it to the other
manuals? I have attached the troff manual page source. Should I try
the conversion myself?

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

--ELM939669645-27189-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/pg/interfaces/libpgeasy/libpgeasy.3"
Content-Transfer-Encoding: 7bit

.\" This is -*-nroff-*-
.\" XXX standard disclaimer belongs here....
.\" $Header: /usr/local/cvsroot/pgsql/src/interfaces/libpgeasy/pgeasy.3,v 1.1 1999/10/11 18:03:00 momjian Exp $
.TH PGEASY INTRO 08/08/98 PostgreSQL PostgreSQL
.SH DESCRIPTION
Pgeasy allows you to cleanly interface to the libpq library,
more like a 4gl SQL interface.
.PP
It consists of set of simplified C functions that encapsulate the
functionality of libpq.
The functions are:

.nf
PGresult *doquery(char *query);
PGconn *connectdb();
void disconnectdb();

int fetch(void *param,...);
int fetchwithnulls(void *param,...);
void reset_fetch();

void on_error_continue();
void on_error_stop();

PGresult *get_result();
void set_result(PGresult *newres);
void unset_result(PGresult *oldres);
.fi
.PP
Many functions return a structure or value, so you can do more work
with the result if required.
.PP
You basically connect to the database with
.BR connectdb ,
issue your query with
.BR doquery ,
fetch the results with
.BR fetch ,
and finish with
.BR disconnectdb .
.PP
For
.IR select
queries,
.BR fetch
allows you to pass pointers as parameters, and on return the variables
are filled with data from the binary cursor you opened. These binary
cursors can not be used if you are running the
.BR pgeasy
client on a system with a different architecture than the database
server. If you pass a NULL pointer parameter, the column is skipped.
.BR fetchwithnulls
allows you to retieve the
.IR null
status of the field by passing an
.IR int*
after each result pointer, which returns true or false if the field is null.
You can always use libpq functions on the PGresult pointer returned by
.BR doquery .
.BR reset_fetch
starts the fetch back at the beginning.
.PP
.BR get_result ,
.BR set_result ,
and
.BR unset_result
allow you to handle multiple result sets at the same time.
.PP
There are a variety of demonstration programs in the
.BR pgeasy
source directory.

--ELM939669645-27189-0_

--ELM939669645-27189-0_--

From bouncefilter Mon Oct 11 15:50:56 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA69775
for <pgsql-hackers@postgresql.org>;
Mon, 11 Oct 1999 15:50:52 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:1719 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s.Xy1137510>;
Mon, 11 Oct 1999 21:50:27 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2) id 11alLp-0000DV-00
for pgsql-hackers@postgresql.org; Mon, 11 Oct 1999 21:43:17 +0200
Date: Mon, 11 Oct 1999 21:43:16 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgreSQL.org
Subject: psql Week 2
Message-ID: <Pine.LNX.4.10.9910112123420.832-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

Here's the long-awaited next edition. For those who must get their hands
on some code I have a tarball at
http://www.pathwaynet.com/~peter/psql.tar.bz2
It includes a file RELEASENOTES which should help you get started.

CHANGELOG

* Sorted out -e and -E: -e toggles query echoing in non-interactive
mode (why would you want to echo queries in interactive mode?). -E
enables showing of queries sent behind your back and is independent
of -e.
* Sorted out usernames and passwords: Switch -U specifies username or
"?" for "prompt me". Switch -P is "prompt for password". Old -u is
equivalent to -U ? -P. Equivalent changes to \connect (e.g., \c - ?
= connect to current database and ask for new username (and prompting
for password iff -u or -P mode)).
* Command history is saved and loaded automatically. Also, history and
readline are separately enabled in the code. (like anyone needs that)
* Allow versioned startup files (like .psqlrc-6.6.0), at least during
development.
* psql now has internal variables. Use \set and \unset to
set/unset/display them. The amount of internal state got out of hand,
so this should help. Most of the settings will be moved to some
variable. (The implementation is currently quite naive, but
encapsulated well to change it later on.)
* -q switch is now equivalent to setting variable quiet. Audited what
messages should be quieted, what are errors, what is normal output,
what is query output.
* Copy-in now has customizable prompt as well.
* Wrote a better strtok, with quoting capabilities, which is now used
to parse the options of the slash commands. (This will break
backward compatibility if you use filenames with spaces and quotes
since they will now be interpreted differently. Too bad.)
* Cleaned up various \d<x> commands. The queries are now
human-readable in -E mode. (Also they now show up in -E mode, and
not in -e mode!)
* -E mode is now the variable echo_secret. If you set the variable to
'noexec' then the "backdoor" queries will only be displayed, not
executed. (Nice if you just want to study the queries.)
* If a connection goes bad during query execution, PQreset is
attempted. If it still is bad, then an _interactive_ session will be
in unconnected mode. (Changed prompt to reflect that.)
* Ctrl-C only sends cancel request if query in progress (otherwise
default action = terminate program). This removes a major annoyance
(I hope).
* Refined \c[onnect]'ion failures: Non-interactive scripts will
terminate, even recursively. However, if the underlying session was
an interactive one, it does not terminate. The database connection
will be lost, however.
* Password prompts are automatic (both startup and \connect). Can
still use -P switch, but that might prove unnecessary. [ Cheers to
Roland R.! ]
* Implemented \lo_import, \lo_export, \lo_unlink, \lo_list. (Still
needs some refinement, though.)
* Can now use \copy with oids and delimiters. No binary, yet.

TODO LIST

* generalized backslash command handling (struct, no ..else if...)
* new printing routines
* rewrite mainloop parser, strip comments
* single line mode doesn't take slash commands
* make scripts bomb out (optionally) on query error
* remove Rollback warnings in lo_ ops
* \default(s?) command
* allow several \ cmds on a line (add '\' to strtokx delims?, windows?)

SIDE NOTES

1. Since the new animal is now probably going to be 7.0, let's provide a
psql that's worthy of that name, er, number. I hope I can lay a
framework with this, but there are still a few months I think, so ideas
are welcome.

1.a) On a related note, since the core developers have more important
issues to worry about, I wouldn't mind maintaining/accompanying/taking
care of/keeping an eye on/whatever psql until release (and possibly
thereafter).

2. What about including an snprintf() into the source tree similar what is
done with strdup()? (No, don't look at me, it totally escapes me how to
do that and I don't want to cheat and look at the GNU sources for
obvious reasons.)

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Oct 11 15:50:56 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA69754;
Mon, 11 Oct 1999 15:50:36 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:1715 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s.Xxz114982>;
Mon, 11 Oct 1999 21:50:23 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11alUU-0000DZ-00; Mon, 11 Oct 1999 21:52:14 +0200
Date: Mon, 11 Oct 1999 21:52:14 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-docs@postgreSQL.org
cc: pgsql-hackers@postgreSQL.org
Subject: bison
Message-ID: <Pine.LNX.4.10.9910112143570.832-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

You might want to include into the installation instructions (or whereever
it will end up) that GNU bison 1.25 is required. (right after the flex
stuff)

I have encountered problems in particular with the ecpg interface where
the Solaris yacc generated syntactically messed-up C code and bison 1.24
couldn't even process one of the .y files. (In case the ecpg maintainer is
unaware of this, let me know and I'll try to get a full problem
description. This happened with the CVS sources of today.)

This is just in addition to other problems that pop up once in a while
with vendor-supplied yaccs on the actual backend parser, I think.

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Oct 11 16:30:55 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA75958
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 16:30:02 -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 QAA04083;
Mon, 11 Oct 1999 16:29:23 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910112029.QAA04083@candle.pha.pa.us>
Subject: Re: [HACKERS] psql Week 2
In-Reply-To: <Pine.LNX.4.10.9910112123420.832-100000@peter-e.yi.org> from
Peter
Eisentraut at "Oct 11, 1999 09:43:16 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 11 Oct 1999 16:29:22 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

* Ctrl-C only sends cancel request if query in progress (otherwise
default action = terminate program). This removes a major annoyance
(I hope).

Yes, I always wanted that fixed. You have hit a number of other TODO
items. Nice.

* Refined \c[onnect]'ion failures: Non-interactive scripts will
terminate, even recursively. However, if the underlying session was
an interactive one, it does not terminate. The database connection
will be lost, however.

Nice.

* Password prompts are automatic (both startup and \connect). Can
still use -P switch, but that might prove unnecessary. [ Cheers to
Roland R.! ]

Nice

* Implemented \lo_import, \lo_export, \lo_unlink, \lo_list. (Still
needs some refinement, though.)

Also nice.

* Can now use \copy with oids and delimiters. No binary, yet.

Yes, quite nice.

TODO LIST

* generalized backslash command handling (struct, no ..else if...)
* new printing routines

How about a backslash command to print the current date/time. Good for
performance debugging.

* rewrite mainloop parser, strip comments
* single line mode doesn't take slash commands
* make scripts bomb out (optionally) on query error
* remove Rollback warnings in lo_ ops
* \default(s?) command
* allow several \ cmds on a line (add '\' to strtokx delims?, windows?)

SIDE NOTES

1. Since the new animal is now probably going to be 7.0, let's provide a
psql that's worthy of that name, er, number. I hope I can lay a
framework with this, but there are still a few months I think, so ideas
are welcome.

1.a) On a related note, since the core developers have more important
issues to worry about, I wouldn't mind maintaining/accompanying/taking
care of/keeping an eye on/whatever psql until release (and possibly
thereafter).

Good. It needs it.

2. What about including an snprintf() into the source tree similar what is
done with strdup()? (No, don't look at me, it totally escapes me how to
do that and I don't want to cheat and look at the GNU sources for
obvious reasons.)

We can do that. I thought we already did.

-- 
  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 Mon Oct 11 16:34:56 1999
Received: from perio.unlp.edu.ar (IDENT:root@[163.10.16.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA76660;
Mon, 11 Oct 1999 16:34:16 -0400 (EDT)
(envelope-from ser@perio.unlp.edu.ar)
Received: from perio.unlp.edu.ar (modem92.way.com.ar [200.41.165.92])
by perio.unlp.edu.ar (8.9.3/8.8.7) with ESMTP id RAA19692;
Mon, 11 Oct 1999 17:31:40 GMT
Message-ID: <38024928.15ACDB91@perio.unlp.edu.ar>
Date: Mon, 11 Oct 1999 17:31:36 -0300
From: "Sergio A. Kessler" <ser@perio.unlp.edu.ar>
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Brook Milligan <brook@biology.nmsu.edu>
CC: maillist@candle.pha.pa.us, lockhart@alumni.caltech.edu,
pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
Subject: Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
References: <199910111543.LAA29508@candle.pha.pa.us>
<199910111656.KAA17620@biology.nmsu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Brook Milligan wrote:

I hope we don't have a consensus on this. Long commands with
underscores in them are certainly another sign of the coming
apocalypse ;)

But if we keep symlinks to the existing names, is that OK?

Isn't the point to avoid naming conflicts. Symlinks won't help that,
surely.

my suggestion was:
in 7.0: provide symlinks for backward compatibility and make big
warnings 'don't use createuser, etc. they are deprecated'
all over the place ...
in 7.1: remove the symlinks.

I agree; underscores are a pain. If you must go this direction, I
suggest hyphens (-).

yup, but maybe (-) can rise problems in some filesystems ...
(I certainly don't know)
and more importantly you have then to rename pg_dump and pg_dumpall
wich is the more heavily used command in scripts ...
my idea was to leave this commands untouched.

as for longnames that Thomas doesn't like (wich I don't agree because
my idea for upgrading scripts is just: 'prepend a pg_ to the commands')
what about pg_adduser, pg_deluser, pg_adddb, etc ? ;)

--
| Sergio A. Kessler http://sak.org.ar
-O_O- You can have it Soon, Cheap, and Working; choose *two*.

From bouncefilter Mon Oct 11 17:44:55 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA87615
for <hackers@postgresql.org>; Mon, 11 Oct 1999 17:44:37 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:4862 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s.Zco133412>;
Mon, 11 Oct 1999 23:44:20 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11am6h-0000Lc-00; Mon, 11 Oct 1999 22:31:43 +0200
Date: Mon, 11 Oct 1999 22:31:42 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <maillist@candle.pha.pa.us>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] psql and comments
In-Reply-To: <3801FAF6.6CC3E6E0@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.10.9910112225240.832-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 11, Thomas Lockhart mentioned:

some query;
*** comment
*** comment
\p
\r
more queries;
which should probably be changed anyway to something like
-- comment
-- comment

Actually, this is probably testing that the buffer reset actually
clears the lines, which wouldn't be as obvious if there were only
legal SQL preceeding it. Maybe leave it as-is??

I think I figured that out: the *** comments actually show up in the
output of the regression tests as an aid to a person glancing at the
results. If the regression tests wanted to test psql then they could
certainly do a lot more fun things than that.

I was planning on implementing an \echo command which could easily be
dropped in there as a more elegant solution.

Which makes me think. The server regression tests should certainly not
rely on some particular psql functionality, just as a matter of principle.
But if I'm ever really bored I could write a separate psql regression
test. No promise though.

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Oct 11 16:53:55 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA80013;
Mon, 11 Oct 1999 16:53:01 -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 QAA05209;
Mon, 11 Oct 1999 16:51:46 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910112051.QAA05209@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
In-Reply-To: <38024928.15ACDB91@perio.unlp.edu.ar> from "Sergio A. Kessler" at
"Oct 11, 1999 05:31:36 pm"
To: "Sergio A. Kessler" <ser@perio.unlp.edu.ar>
Date: Mon, 11 Oct 1999 16:51:46 -0400 (EDT)
CC: Brook Milligan <brook@biology.nmsu.edu>, lockhart@alumni.caltech.edu,
pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

my suggestion was:
in 7.0: provide symlinks for backward compatibility and make big
warnings 'don't use createuser, etc. they are deprecated'
all over the place ...
in 7.1: remove the symlinks.

I agree; underscores are a pain. If you must go this direction, I
suggest hyphens (-).

yup, but maybe (-) can rise problems in some filesystems ...
(I certainly don't know)
and more importantly you have then to rename pg_dump and pg_dumpall
wich is the more heavily used command in scripts ...
my idea was to leave this commands untouched.

as for longnames that Thomas doesn't like (wich I don't agree because
my idea for upgrading scripts is just: 'prepend a pg_ to the commands')
what about pg_adduser, pg_deluser, pg_adddb, etc ? ;)

That's a compromise. The destroy* entries are from the old quel days.
Of course, that would make pg_deluser into pg_dropuser, but adddb would
be createdb, and we are back were we started. :-)

-- 
  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 Mon Oct 11 17:43:57 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA87486;
Mon, 11 Oct 1999 17:43:26 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:4814 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s.Zbb137508>;
Mon, 11 Oct 1999 23:43:03 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11amVz-0000MC-00; Mon, 11 Oct 1999 22:57:51 +0200
Date: Mon, 11 Oct 1999 22:57:51 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
"Sergio A. Kessler" <ser@perio.unlp.edu.ar>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgresql.org>
Subject: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?))
In-Reply-To: <199910111543.LAA29508@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.9910112232220.832-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 11, Bruce Momjian mentioned:

Yes, we have discussed this, and will add it to the TODO list.

can the commands createuser and destroyuser be renamed to
pg_createuser and pg_destroyuser (as pg_dump) adding soft links to
preserve backwards compatibility (declaring previous commands
deprecated) ?
the same can be done for createdb and destroydb ...

I hope we don't have a consensus on this. Long commands with
underscores in them are certainly another sign of the coming
apocalypse ;)

But if we keep symlinks to the existing names, is that OK?

I think Thomas' primary problem was the underscore. (?)

I was going to say that I can take of that, since I was going to adjust
the scripts to play well with the new psql anyway. (In particular, I just
terminally removed the -a option, since it has gone unused for a while and
might be a very popular option switch in the future. Switches are becoming
scarce these days.)

I can offer the following plan (from my bin dir):

cleardbdir --> (Remove. It's been a while.)
createdb --> pgcreatedb
createlang --> (In my excessively undereducated opinion, this should
be removed. createdb and createuser I can see but
this?)
createuser --> pgcreateuser
destroydb --> pgdestroydb
destroylang --> (see above)
destroyuser --> pgdestroyuser
ecpg
initdb --> pginitdb
initlocation --> pginitlocation
ipcclean --> pg_ipcclean
(An underscore here to make it more complicated to type :)
. . .
vacuumdb --> pgvacuumdb

Alternatively, there could also be shorter commands, now that the
association with the PostgreSQL installation is clearer:
pgcrdb
pgcruser
pgdestdb
pgdestuser
pgvacuum

This might remove the mnemonic association with the related SQL commands
(which some might find desirable). Some might also go for a set like this:
pguseradd
pguserdel
pgmkdb
pgrmdb
in association to *nix commands. (Some might find that a bad idea).

Furthermore I was thinking about a configure switch along the following
lines:

--enable-scripts=old|new|both|none
(defaults to new)

since a while back there was some talk about removing the scripts
altogether (which also died after Thomas protested, I think).

While we're at it, perhaps the scripts can also be moved around in the
source tree, e.g., to bin/scripts or (if there will really be only 4 or 5)
even into the psql subtree.

Well, unless someone vetos, I would take a vote here and see what I can
do.

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Oct 11 17:43:56 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA87490
for <hackers@postgresql.org>; Mon, 11 Oct 1999 17:43:27 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:4825 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s.Zbm28964>;
Mon, 11 Oct 1999 23:43:14 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11amet-0000MK-00; Mon, 11 Oct 1999 23:07:03 +0200
Date: Mon, 11 Oct 1999 23:07:03 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Regression tests (was Re: [HACKERS] psql and comments)
In-Reply-To: <Pine.LNX.4.10.9910112225240.832-100000@peter-e.yi.org>
Message-ID: <Pine.LNX.4.10.9910112301080.832-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

Um, I hate to break this to you folks, but, barring an AI diff being
available, the regression tests might need to be adjusted anyway, since
they rely on a particular table output format which I cannot guarantee to
(or even want to) reproduce exactly.

But I hear the tests were going to be revised for 7.0 anyway, right? ;)

Since I got you into this mess I would certainly try to help to resolve
it, but that's a future issue.

-Peter

On Oct 11, Peter Eisentraut mentioned:

On Oct 11, Thomas Lockhart mentioned:

some query;
*** comment
*** comment
\p
\r
more queries;
which should probably be changed anyway to something like
-- comment
-- comment

Actually, this is probably testing that the buffer reset actually
clears the lines, which wouldn't be as obvious if there were only
legal SQL preceeding it. Maybe leave it as-is??

I think I figured that out: the *** comments actually show up in the
output of the regression tests as an aid to a person glancing at the
results. If the regression tests wanted to test psql then they could
certainly do a lot more fun things than that.

I was planning on implementing an \echo command which could easily be
dropped in there as a more elegant solution.

Which makes me think. The server regression tests should certainly not
rely on some particular psql functionality, just as a matter of principle.
But if I'm ever really bored I could write a separate psql regression
test. No promise though.

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Oct 11 18:31:58 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 SAA93939;
Mon, 11 Oct 1999 18:31:46 -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 SAA09670;
Mon, 11 Oct 1999 18:24:17 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910112224.SAA09670@candle.pha.pa.us>
Subject: Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is
7.0(?))
In-Reply-To: <Pine.LNX.4.10.9910112232220.832-100000@peter-e.yi.org> from
Peter
Eisentraut at "Oct 11, 1999 10:57:51 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 11 Oct 1999 18:24:17 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
"Sergio A. Kessler" <ser@perio.unlp.edu.ar>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I think Thomas' primary problem was the underscore. (?)

OK.

I was going to say that I can take of that, since I was going to adjust
the scripts to play well with the new psql anyway. (In particular, I just
terminally removed the -a option, since it has gone unused for a while and
might be a very popular option switch in the future. Switches are becoming
scarce these days.)

I can offer the following plan (from my bin dir):

cleardbdir --> (Remove. It's been a while.)

Good.

createdb --> pgcreatedb

Good.

createlang --> (In my excessively undereducated opinion, this should
be removed. createdb and createuser I can see but
this?)

Yes, remove. What is that doing there. Jan's plpgsql doesn't use it. :-)

createuser --> pgcreateuser
destroydb --> pgdestroydb

Can I recommend pgdropdb?

destroylang --> (see above)
destroyuser --> pgdestroyuser

pgdropuser?

ecpg
initdb --> pginitdb
initlocation --> pginitlocation
ipcclean --> pg_ipcclean
(An underscore here to make it more complicated to type :)
. . .

Not sure about that.

vacuumdb --> pgvacuumdb

OK.

Alternatively, there could also be shorter commands, now that the
association with the PostgreSQL installation is clearer:
pgcrdb
pgcruser
pgdestdb
pgdestuser
pgvacuum

Too cryptic for me.

This might remove the mnemonic association with the related SQL commands
(which some might find desirable). Some might also go for a set like this:
pguseradd
pguserdel
pgmkdb
pgrmdb
in association to *nix commands. (Some might find that a bad idea).

Doesn't grab me.

Furthermore I was thinking about a configure switch along the following
lines:

--enable-scripts=old|new|both|none
(defaults to new)

Too complicated. Issue a warning if invoked with old args and remove
old link in 8.x. You can test basename $0 and test to see how you were
invoked.

since a while back there was some talk about removing the scripts
altogether (which also died after Thomas protested, I think).

I like the scripts too.

-- 
  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 Mon Oct 11 18:31:56 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 SAA93915
for <hackers@postgresql.org>; Mon, 11 Oct 1999 18:31:22 -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 SAA09681;
Mon, 11 Oct 1999 18:25:06 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910112225.SAA09681@candle.pha.pa.us>
Subject: Re: Regression tests (was Re: [HACKERS] psql and comments)
In-Reply-To: <Pine.LNX.4.10.9910112301080.832-100000@peter-e.yi.org> from
Peter
Eisentraut at "Oct 11, 1999 11:07:03 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 11 Oct 1999 18:25:06 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Um, I hate to break this to you folks, but, barring an AI diff being
available, the regression tests might need to be adjusted anyway, since
they rely on a particular table output format which I cannot guarantee to
(or even want to) reproduce exactly.

But I hear the tests were going to be revised for 7.0 anyway, right? ;)

Yes, Thomas does it, but doesn't like to do it too often. He will
almost certainly do it for 7.0. :-)

-- 
  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 Mon Oct 11 19:00:57 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA98511;
Mon, 11 Oct 1999 19:00:23 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id SAA00664;
Mon, 11 Oct 1999 18:59:47 -0400
Message-ID: <38026BE1.2599C93C@wgcr.org>
Date: Mon, 11 Oct 1999 18:59:45 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Peter Eisentraut <peter_e@gmx.net>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
"Sergio A. Kessler" <ser@perio.unlp.edu.ar>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgresql.org>
Subject: Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is
7.0(?))
References: <199910112224.SAA09670@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

createlang --> (In my excessively undereducated opinion, this should
be removed. createdb and createuser I can see but
this?)

Yes, remove. What is that doing there. Jan's plpgsql doesn't use it. :-)

Used by regression test script. No reason the script can't inline the
createlang script's code, though.

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Mon Oct 11 20:21:57 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 UAA08302
for <pgsql-hackers@postgresql.org>;
Mon, 11 Oct 1999 20:21:11 -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 JAA02919; Tue, 12 Oct 1999 09:19:35 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Bruce Momjian" <maillist@candle.pha.pa.us>,
"pgsql-hackers" <pgsql-hackers@postgresql.org>
Subject: RE: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
Date: Tue, 12 Oct 1999 09:23:26 +0900
Message-ID: <000701bf1448$00979c40$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <8772.939668866@sss.pgh.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Tuesday, October 12, 1999 4:08 AM
To: Hiroshi Inoue
Cc: Bruce Momjian; pgsql-hackers
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)

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

Yes,I have done a part of my story.
I would add new type of path and scan by which we are able to access
tids directly.

Yes, new path type, new plan type, probably a new access method if
you want to keep things clean in the executor, cost-estimation routines
in the planner, etc. etc.

Looks like a lot of work, and a lot of added code bulk that will
have to be maintained.

You are right and It's the reason I have announced this issue
many times.

I haven't figured out why you think it's
worth it... tids are so transient that I don't see much need for
finding tuples by them...

As far as I know,many DBMSs have means to access tuples
directly.
I have been wondering why PostgreSQL doesn't support such
means.

PostgreSQL isn't perfect and this kind of means are necessary
to make up for the deficiency,I think.
For example how do we implement advanced features of ODBC
/JDBC drivers etc without this kind of support ?

OIDs are preferable for such means because they are
invariant. But unfortunately OIDs have no guarantee that
have indexes and even with indexes it isn't the fastest way.

TIDs are transient,so I have provided built-in functions
currtid() to follow update chain of links.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Oct 11 21:03:58 1999
Received: from ext16.sra.co.jp (ykh28DS11.kng.mesh.ad.jp [133.205.214.11])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA26661
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 21:03:04 -0400 (EDT)
(envelope-from t-ishii@ext16.sra.co.jp)
Received: from ext16.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext16.sra.co.jp (8.8.8/8.8.8) with ESMTP id JAA01440;
Tue, 12 Oct 1999 09:55:21 +0900
Message-Id: <199910120055.JAA01440@ext16.sra.co.jp>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql Week 2
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Mon, 11 Oct 1999 16:29:22 -0400.
<199910112029.QAA04083@candle.pha.pa.us>
Date: Tue, 12 Oct 1999 09:55:21 +0900
Sender: t-ishii@ext16.sra.co.jp

Will the new psql replace the old one in 7.0? If so, I need to work on
it to incomporate the multi-byte capability. Peter, can you tell me
when you will finish the work?
---
Tatsuo Ishii

From bouncefilter Mon Oct 11 21:06:58 1999
Received: from ext16.sra.co.jp (IDENT:root@ykh28DS15.kng.mesh.ad.jp
[133.205.214.15]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA32443
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 21:06:41 -0400 (EDT)
(envelope-from t-ishii@ext16.sra.co.jp)
Received: from ext16.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext16.sra.co.jp (8.8.8/8.8.8) with ESMTP id KAA01526
for <pgsql-hackers@postgreSQL.org>; Tue, 12 Oct 1999 10:00:09 +0900
Message-Id: <199910120100.KAA01526@ext16.sra.co.jp>
From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: pgsql-hackers@postgreSQL.org
Subject: Different BLKSZ
Date: Tue, 12 Oct 1999 10:00:09 +0900
Sender: t-ishii@ext16.sra.co.jp

While doing some tests, I have encountered too many problems with
incompatible BLKSZ (the backend comipled in different BLKSZ with the
one in database). I know this is my fault, but it would be nice if
there is better way to avoid this kind of disaster. For example:

(1) there is a file called PG_BLKSZ under $PGDATA.

(2) postmaster checks the contents of the file to see if it was
compiled in the same BLKSZ.

(3) If not, give some error messages and exit.

Comments?
---
Tatsuo Ishii

From bouncefilter Mon Oct 11 21:30:58 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 VAA35794
for <pgsql-hackers@postgreSQL.org>;
Mon, 11 Oct 1999 21:30:06 -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 VAA10301;
Mon, 11 Oct 1999 21:28:15 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql Week 2
In-reply-to: Your message of Mon, 11 Oct 1999 21:43:16 +0200 (CEST)
<Pine.LNX.4.10.9910112123420.832-100000@peter-e.yi.org>
Date: Mon, 11 Oct 1999 21:28:15 -0400
Message-ID: <10299.939691695@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

2. What about including an snprintf() into the source tree similar what is
done with strdup()?

There is one in the backend/port/ directory, along with some other
important library routines that are missing on certain platforms.
Up to now we haven't worried about including these into anything but
the backend, but I see no reason not to include them into psql if
you need 'em. (Probably would not be a good idea to put them into
libpq though, since that could cause conflicts with user apps that
supply their own versions.) See backend/port/Makefile.in for the
tests that determine whether individual routines need to be included.

regards, tom lane

From bouncefilter Mon Oct 11 22:15:58 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 WAA43002
for <pgsql-hackers@postgresql.org>;
Mon, 11 Oct 1999 22:15:35 -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 LAA02965; Tue, 12 Oct 1999 11:13:59 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>,
"Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Subject: RE: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
Date: Tue, 12 Oct 1999 11:17:50 +0900
Message-ID: <002401bf1457$fbcd28a0$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
In-reply-to: <199910111914.PAA00307@candle.pha.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: Tuesday, October 12, 1999 4:14 AM
To: Tom Lane
Cc: Hiroshi Inoue; pgsql-hackers
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)

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

Yes,I have done a part of my story.
I would add new type of path and scan by which we are able to access
tids directly.

Yes, new path type, new plan type, probably a new access method if
you want to keep things clean in the executor, cost-estimation routines
in the planner, etc. etc.

Looks like a lot of work, and a lot of added code bulk that will
have to be maintained. I haven't figured out why you think it's
worth it... tids are so transient that I don't see much need for
finding tuples by them...

That's why I just suggested a more short-circuited option of snatching
tid oids from expressions, and doing a heap_fetch directly at that point
to avoid the index scan. Seems it could be done in just one file.

I have thought the way as Tom says and I have a prospect to do it.
But it would take a lot of work.

Where to snatch and return to(or exit from) planner/executor
in your story ?

Hiroshi Inoue
Inoue@tpf.co.jp.

From bouncefilter Mon Oct 11 23:11:59 1999
Received: from perio.unlp.edu.ar (IDENT:root@perio.unlp.edu.ar [163.10.16.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA50514;
Mon, 11 Oct 1999 23:11:49 -0400 (EDT)
(envelope-from ser@perio.unlp.edu.ar)
Received: from perio.unlp.edu.ar (modem87.way.com.ar [200.41.165.87])
by perio.unlp.edu.ar (8.9.3/8.8.7) with ESMTP id AAA20938;
Tue, 12 Oct 1999 00:11:27 GMT
Message-ID: <3802A719.47016331@perio.unlp.edu.ar>
Date: Tue, 12 Oct 1999 00:12:25 -0300
From: "Sergio A. Kessler" <ser@perio.unlp.edu.ar>
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Peter Eisentraut <peter_e@gmx.net>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgreSQL.org>
Subject: Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is
7.0(?))
References: <199910112224.SAA09670@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

I think Thomas' primary problem was the underscore. (?)

OK.

hmmm, ok, not everyone can be totally happy ...
please, Thomas, let us use the underscore so there no need to
rename pg_dump and pg_dumpall

pg_dump -> pg_dump
pg_dumpall -> pg_dumpall

createdb -> pg_createdb
destroydb -> pg_dropdb

createuser -> pg_createuser
destroyuser -> pg_dropuser

and prepend a 'pg_' to the rest

I think it can't be more consistent that this...

Thomas ?, please ?

--
| Sergio A. Kessler http://sak.org.ar
-O_O- You can have it Soon, Cheap, and Working; choose *two*.

From bouncefilter Mon Oct 11 23:26:00 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA52890
for <pgsql-hackers@postgresql.org>;
Mon, 11 Oct 1999 23:25:09 -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 XAA18860;
Mon, 11 Oct 1999 23:22:24 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910120322.XAA18860@candle.pha.pa.us>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
In-Reply-To: <002401bf1457$fbcd28a0$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Oct 12, 1999 11:17:50 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 11 Oct 1999 23:22:23 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Looks like a lot of work, and a lot of added code bulk that will
have to be maintained. I haven't figured out why you think it's
worth it... tids are so transient that I don't see much need for
finding tuples by them...

That's why I just suggested a more short-circuited option of snatching
tid oids from expressions, and doing a heap_fetch directly at that point
to avoid the index scan. Seems it could be done in just one file.

I have thought the way as Tom says and I have a prospect to do it.
But it would take a lot of work.

Where to snatch and return to(or exit from) planner/executor
in your story ?

Basically, if I remember, in the executor, access to a table either
opens the table for sequential scan, does an index scan, or has the
value it needs already in a result of a previous join result.

If we put something in the executor so when a sequential/index scan is
requested on a table that has a restriction on tid, you could just do a
heap_fetch and return the single row, rather than putting the query
through the whole scan process for every row checking to see if it
matches the WHERE restriction.

Seems like a few lines in the executor could do the entire job of
fetching by tid by short-circuiting the sequential/index scan.

-- 
  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 12 00:04:01 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA60911
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 00:03:45 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id BAA88451;
Tue, 12 Oct 1999 01:02:50 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 12 Oct 1999 01:02:49 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Adriaan Joubert <a.joubert@albourne.com>,
Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
In-Reply-To: <199910091020.GAA05654@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910120102440.404-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Sounds great to me...

On Sat, 9 Oct 1999, Bruce Momjian wrote:

4. Now that I've got the functionality, can somebody give me a rough
roadmap to what I need to change to turn this into a proper postgres
type? As far as I can see I need to assign oid's to it in pg_type.h and
I'll have to have a look at the parser to get it to recognise the types.
It would be a big help though if somebody could tell me what else needs
to change.

I can integrate the type for you into the include/catalog files if
everyone agrees they want it as a standard type and not an contrib type.
-- 
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
************

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 12 00:11:00 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA62265
for <hackers@postgresql.org>; Tue, 12 Oct 1999 00:10:28 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id BAA88500;
Tue, 12 Oct 1999 01:07:57 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 12 Oct 1999 01:07:57 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Features for next release
In-Reply-To: <5156.939424464@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9910120106430.404-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 8 Oct 1999, Tom Lane wrote:

It seems people are thinking winter or early spring (northern hemisphere
that is ;-)) for the next major release, and by then I think there will
be enough cool stuff done that we can call it 7.0. The only really big
to-do item that no one seems to be committed to doing in this cycle is
tuples bigger than a disk block, and maybe once the dust settles for
long queries someone will feel like tackling that...

I have another reason for calling it 7.0, which is that if we fix
the function-call interface the way I want to, we will break existing
user-written loadable modules that contain C-language functions.
Better to do that in a "7.0" than in a "6.6", no?

Based on all the comments flyng around, v7.0 it is. to be released...some
day :)

Bruce, you asked for a v6.5.3 to be released...anything outstanding that
should prevent me from doing that tomorrow afternoon?

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 12 00:14:00 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 AAA62522
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 00:13: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 AAA15268
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 00:12:28 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: mdnblocks is an amazing time sink in huge relations
Date: Tue, 12 Oct 1999 00:12:28 -0400
Message-ID: <15265.939701548@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I have been doing some testing with multi-segment relations.
(Not having sixty gigabytes laying around, like some folk I've been
talking to recently, I rebuilt with a very small RELSEG_SIZE for
testing...) I have discovered that performance goes to zero as the
number of segments gets large --- in particular, if the number of
segments exceeds the number of kernel file descriptors that fd.c
thinks it can use, you can take a coffee break while inserting a
few tuples :-(. The main problem is mdnblocks() in md.c, which
is called for each tuple inserted; it insists on touching every
segment of the relation to verify its length via lseek(). That's an
unreasonable number of kernel calls in any case, and if you add a file
open and close to each touch because of file-descriptor thrashing,
it's coffee break time.

It seems to me that mdnblocks should assume that all segments
previously verified to be of length RELSEG_SIZE are still of that
length, and only do an _mdnblocks() call on the last element of the
segment chain. That way the number of kernel interactions needed
is a constant independent of the number of segments in the table.
(This doesn't make truncation of the relation by a different backend
any more or less dangerous; we're still hosed if we don't get a
notification before we try to do something with the relation.
I think that is fixed, and if it's not this doesn't make it worse.)

Any objections?

regards, tom lane

From bouncefilter Tue Oct 12 00:17:02 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA63176;
Tue, 12 Oct 1999 00:16:51 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id BAA88621;
Tue, 12 Oct 1999 01:16:27 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 12 Oct 1999 01:16:26 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
"Sergio A. Kessler" <ser@perio.unlp.edu.ar>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgreSQL.org>
Subject: Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
In-Reply-To: <3801FF9A.D88C446E@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.10.9910120115410.404-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 11 Oct 1999, Thomas Lockhart wrote:

Yes, we have discussed this, and will add it to the TODO list.

can the commands createuser and destroyuser be renamed to
pg_createuser and pg_destroyuser (as pg_dump) adding soft links to
preserve backwards compatibility (declaring previous commands
deprecated) ?
the same can be done for createdb and destroydb ...

I hope we don't have a consensus on this. Long commands with
underscores in them are certainly another sign of the coming
apocalypse ;)

You'll get my agreement on this...but, then again, I'm advocating getting
rid of them altoghther and forcing the DBA to be forced to learn teh
proper commands...*shrug*

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 12 00:18:02 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA63292;
Tue, 12 Oct 1999 00:17:30 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id BAA88625;
Tue, 12 Oct 1999 01:17:22 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 12 Oct 1999 01:17:22 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
"Sergio A. Kessler" <ser@perio.unlp.edu.ar>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgreSQL.org>
Subject: Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
In-Reply-To: <199910111543.LAA29508@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910120116350.404-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 11 Oct 1999, Bruce Momjian wrote:

Yes, we have discussed this, and will add it to the TODO list.

can the commands createuser and destroyuser be renamed to
pg_createuser and pg_destroyuser (as pg_dump) adding soft links to
preserve backwards compatibility (declaring previous commands
deprecated) ?
the same can be done for createdb and destroydb ...

I hope we don't have a consensus on this. Long commands with
underscores in them are certainly another sign of the coming
apocalypse ;)

But if we keep symlinks to the existing names, is that OK?

can we get rid of 'createdb/destroydb' and shorten them to:
'pg_adddb/pg_deldb' ... ? :)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 12 00:19:02 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA63398;
Tue, 12 Oct 1999 00:18:12 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id BAA88629;
Tue, 12 Oct 1999 01:18:04 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 12 Oct 1999 01:18:04 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
"Sergio A. Kessler" <ser@perio.unlp.edu.ar>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgreSQL.org>
Subject: Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
In-Reply-To: <199910111543.LAA29508@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910120117260.404-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 11 Oct 1999, Bruce Momjian wrote:

Yes, we have discussed this, and will add it to the TODO list.

can the commands createuser and destroyuser be renamed to
pg_createuser and pg_destroyuser (as pg_dump) adding soft links to
preserve backwards compatibility (declaring previous commands
deprecated) ?
the same can be done for createdb and destroydb ...

I hope we don't have a consensus on this. Long commands with
underscores in them are certainly another sign of the coming
apocalypse ;)

But if we keep symlinks to the existing names, is that OK?

Oh, and, IMHO...remove, don't create symlinks...its a major release, we
don't have to maintain backwards compatability...we aren't mIcrosoft, eh?
:)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 12 00:25:03 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA64385;
Tue, 12 Oct 1999 00:24:12 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id BAA88668;
Tue, 12 Oct 1999 01:22:36 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 12 Oct 1999 01:22:36 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
"Sergio A. Kessler" <ser@perio.unlp.edu.ar>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgresql.org>
Subject: Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is
7.0(?))
In-Reply-To: <199910112224.SAA09670@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910120121150.404-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Note: I still don't like the scripts...they create lazy, uneducated DBAs,
of which I was one, since I didn't even *know* there were internal
commands that did more then the external ones did, for the longest time...

Personally, those scripts should jsut become:

try 'create user' from psql interface

*grump look*

On Mon, 11 Oct 1999, Bruce Momjian wrote:

I think Thomas' primary problem was the underscore. (?)

OK.

I was going to say that I can take of that, since I was going to adjust
the scripts to play well with the new psql anyway. (In particular, I just
terminally removed the -a option, since it has gone unused for a while and
might be a very popular option switch in the future. Switches are becoming
scarce these days.)

I can offer the following plan (from my bin dir):

cleardbdir --> (Remove. It's been a while.)

Good.

createdb --> pgcreatedb

Good.

createlang --> (In my excessively undereducated opinion, this should
be removed. createdb and createuser I can see but
this?)

Yes, remove. What is that doing there. Jan's plpgsql doesn't use it. :-)

createuser --> pgcreateuser
destroydb --> pgdestroydb

Can I recommend pgdropdb?

destroylang --> (see above)
destroyuser --> pgdestroyuser

pgdropuser?

ecpg
initdb --> pginitdb
initlocation --> pginitlocation
ipcclean --> pg_ipcclean
(An underscore here to make it more complicated to type :)
. . .

Not sure about that.

vacuumdb --> pgvacuumdb

OK.

Alternatively, there could also be shorter commands, now that the
association with the PostgreSQL installation is clearer:
pgcrdb
pgcruser
pgdestdb
pgdestuser
pgvacuum

Too cryptic for me.

This might remove the mnemonic association with the related SQL commands
(which some might find desirable). Some might also go for a set like this:
pguseradd
pguserdel
pgmkdb
pgrmdb
in association to *nix commands. (Some might find that a bad idea).

Doesn't grab me.

Furthermore I was thinking about a configure switch along the following
lines:

--enable-scripts=old|new|both|none
(defaults to new)

Too complicated. Issue a warning if invoked with old args and remove
old link in 8.x. You can test basename $0 and test to see how you were
invoked.

since a while back there was some talk about removing the scripts
altogether (which also died after Thomas protested, I think).

I like the scripts too.
-- 
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
************

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 12 09:39:14 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 JAA57181;
Tue, 12 Oct 1999 09:39:02 -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 FAA03307;
Tue, 12 Oct 1999 05:43:03 GMT
Sender: lockhart@hub.org
Message-ID: <3802CA66.C08B5B05@alumni.caltech.edu>
Date: Tue, 12 Oct 1999 05:43:02 +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: Peter Eisentraut <peter_e@gmx.net>
CC: pgsql-docs@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] bison
References: <Pine.LNX.4.10.9910112143570.832-100000@peter-e.yi.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

You might want to include into the installation instructions (or whereever
it will end up) that GNU bison 1.25 is required. (right after the flex
stuff)

We haven't been careful about building and shipping the bison output
in the tarball distribution, as we have for the main parser. It just
needs someone to look at it, as well as look at Jan's backend
languages which suffer from the same symptom as I recall...

- Thomas

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

From bouncefilter Tue Oct 12 09:39:13 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 JAA57176
for <hackers@postgresql.org>; Tue, 12 Oct 1999 09:38:57 -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 GAA03334;
Tue, 12 Oct 1999 06:00:04 GMT
Sender: lockhart@hub.org
Message-ID: <3802CE64.92C41126@alumni.caltech.edu>
Date: Tue, 12 Oct 1999 06:00:04 +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: Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: Regression tests (was Re: [HACKERS] psql and comments)
References: <199910112225.SAA09681@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yes, Thomas does it, but doesn't like to do it too often. He will
almost certainly do it for 7.0. :-)

I can regenerate the tests (usually) pretty easily. I've got the
parser spread across the computer room floor at the moment, so it will
be a few weeks...

- Thomas

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

From bouncefilter Tue Oct 12 03:08:09 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 DAA89957
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 03:07: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 QAA03089; Tue, 12 Oct 1999 16:07:49 +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, 12 Oct 1999 16:11:42 +0900
Message-ID: <002801bf1481$0921a5c0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <15265.939701548@sss.pgh.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
Sent: Tuesday, October 12, 1999 1:12 PM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] mdnblocks is an amazing time sink in huge relations

I have been doing some testing with multi-segment relations.
(Not having sixty gigabytes laying around, like some folk I've been
talking to recently, I rebuilt with a very small RELSEG_SIZE for
testing...) I have discovered that performance goes to zero as the
number of segments gets large --- in particular, if the number of
segments exceeds the number of kernel file descriptors that fd.c
thinks it can use, you can take a coffee break while inserting a
few tuples :-(. The main problem is mdnblocks() in md.c, which
is called for each tuple inserted; it insists on touching every
segment of the relation to verify its length via lseek(). That's an
unreasonable number of kernel calls in any case, and if you add a file
open and close to each touch because of file-descriptor thrashing,
it's coffee break time.

It's me who removed the following code from mdnblocks().
The code caused a disaster in case of mdtruncate().

if (v->mdfd_lstbcnt == RELSEG_SIZE
|| ....

At that time I was anxious about the change of performance
but I've forgotten,sorry.

It seems to me that mdnblocks should assume that all segments
previously verified to be of length RELSEG_SIZE are still of that
length, and only do an _mdnblocks() call on the last element of the
segment chain. That way the number of kernel interactions needed
is a constant independent of the number of segments in the table.
(This doesn't make truncation of the relation by a different backend
any more or less dangerous; we're still hosed if we don't get a
notification before we try to do something with the relation.
I think that is fixed, and if it's not this doesn't make it worse.)

Currently only the first segment is opened when mdopen() etc is
called. Would you change to check all segments at first open ?

If there is a relation which has multi-segment of size 0,which would
be the last segment ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Oct 12 04:28:09 1999
Received: from wilk.lupus.pl (root@wilk.lupus.pl [195.116.206.178])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA99941
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 04:27:20 -0400 (EDT)
(envelope-from grzegorz_przezdziecki@lupus.waw.pl)
Received: from lupus.waw.pl ([195.116.206.134])
by wilk.lupus.pl with ESMTP id KAA14091
for <pgsql-hackers@postgreSQL.org>; Tue, 12 Oct 1999 10:09:16 +0200
Message-ID: <3802EF98.4D85654F@lupus.waw.pl>
Date: Tue, 12 Oct 1999 10:21:44 +0200
From: Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?=
<grzegorz_przezdziecki@lupus.waw..pl>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Backend proceses
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit

Welcome

May next question.
Sorry :|)

I have PostgreSQL on Linux and few users connetcing to databases from
Windows 95 where client application is Access 97.
When I shutdown Win by reset or the power broke I see that on my Linux
proceses which was created by connection from Win stay and waiting.
On Win sometime when main server lost connection with local computer
(users have his own Access file on it) i see only white forms without
any data and postgres don't ask me abou password when I restart Access.

Any idea what I have to do with this.

Best Regards

From bouncefilter Tue Oct 12 05:01:10 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 FAA04332
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 05:00:21 -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 RAA03207;
Tue, 12 Oct 1999 17:00:12 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <3802F89B.6EDADD90@krs.ru>
Date: Tue, 12 Oct 1999 17:00:11 +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: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Different BLKSZ
References: <199910120100.KAA01526@ext16.sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tatsuo Ishii wrote:

While doing some tests, I have encountered too many problems with
incompatible BLKSZ (the backend comipled in different BLKSZ with the
one in database). I know this is my fault, but it would be nice if
there is better way to avoid this kind of disaster. For example:

(1) there is a file called PG_BLKSZ under $PGDATA.

(2) postmaster checks the contents of the file to see if it was
compiled in the same BLKSZ.

(3) If not, give some error messages and exit.

There is special file pg_control for the WAL purposes - good
place for the BLCKSZ...

Vadim

From bouncefilter Tue Oct 12 05:12:11 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA06847
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 05:11:55 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id SAA16689;
Tue, 12 Oct 1999 18:11:53 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id SAA02979;
Tue, 12 Oct 1999 18:11:52 +0900 (JST)
Message-Id: <199910120911.SAA02979@srapc451.sra.co.jp>
To: Vadim Mikheev <vadim@krs.ru>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Different BLKSZ
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Tue, 12 Oct 1999 17:00:11 +0800.
<3802F89B.6EDADD90@krs.ru>
Date: Tue, 12 Oct 1999 18:11:52 +0900
Sender: t-ishii@srapc451.sra.co.jp

While doing some tests, I have encountered too many problems with
incompatible BLKSZ (the backend comipled in different BLKSZ with the
one in database). I know this is my fault, but it would be nice if
there is better way to avoid this kind of disaster. For example:

(1) there is a file called PG_BLKSZ under $PGDATA.

(2) postmaster checks the contents of the file to see if it was
compiled in the same BLKSZ.

(3) If not, give some error messages and exit.

There is special file pg_control for the WAL purposes - good
place for the BLCKSZ...

Nice. Do you have some functions to access the file? Seems it is a
binary file.
--
Tatsuo Ishii

From bouncefilter Tue Oct 12 05:19:10 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 FAA07723;
Tue, 12 Oct 1999 05:18:10 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-interfaces@postgreSQL.org
id m11axyd-0003kLC; Tue, 12 Oct 99 11:12 MET DST
Message-Id: <m11axyd-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is
To: scrappy@hub.org (The Hermit Hacker)
Date: Tue, 12 Oct 1999 11:12:11 +0200 (MET DST)
Cc: maillist@candle.pha.pa.us, peter_e@gmx.net, lockhart@alumni.caltech.edu,
ser@perio.unlp.edu.ar, pgsql-hackers@postgreSQL.org,
pgsql-interfaces@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <Pine.BSF.4.10.9910120121150.404-100000@thelab.hub.org> from "The
Hermit Hacker" at Oct 12, 99 01:22:36 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

in association to *nix commands. (Some might find that a bad idea).

Then it MUST be pgcreatuser!

Jan

From bouncefilter Tue Oct 12 05:20:10 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 FAA07865
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 05:19:28 -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 RAA03404;
Tue, 12 Oct 1999 17:19:21 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <3802FD18.4D6321F8@krs.ru>
Date: Tue, 12 Oct 1999 17:19:20 +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: t-ishii@sra.co.jp
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Different BLKSZ
References: <199910120911.SAA02979@srapc451.sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tatsuo Ishii wrote:

There is special file pg_control for the WAL purposes - good
place for the BLCKSZ...

Nice. Do you have some functions to access the file? Seems it is a
binary file.

access/transam/xlog.c:StartupXLOG() is called on every database
startup and read control file - just add BLCKSZ to
struct ControlFileData and check it on startup. Don't forget
to initialize this value in BootStrapXLOG() (while creating
control file).

Vadim

From bouncefilter Tue Oct 12 05:33:10 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA10414
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 05:32:17 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id SAA18655;
Tue, 12 Oct 1999 18:32:16 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id SAA03241;
Tue, 12 Oct 1999 18:32:15 +0900 (JST)
Message-Id: <199910120932.SAA03241@srapc451.sra.co.jp>
To: Vadim Mikheev <vadim@krs.ru>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Different BLKSZ
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Tue, 12 Oct 1999 17:19:20 +0800.
<3802FD18.4D6321F8@krs.ru>
Date: Tue, 12 Oct 1999 18:32:15 +0900
Sender: t-ishii@srapc451.sra.co.jp

There is special file pg_control for the WAL purposes - good
place for the BLCKSZ...

Nice. Do you have some functions to access the file? Seems it is a
binary file.

access/transam/xlog.c:StartupXLOG() is called on every database
startup and read control file - just add BLCKSZ to
struct ControlFileData and check it on startup. Don't forget
to initialize this value in BootStrapXLOG() (while creating
control file).

Thanks. I will work on this issue.
--
Tatsuo Ishii

From bouncefilter Tue Oct 12 05:53:10 1999
Received: from server1.ppc.pims.org ([194.78.114.4])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA13115;
Tue, 12 Oct 1999 05:52:59 -0400 (EDT)
(envelope-from huffmana@ppc.pims.org)
Received: from ppc.pims.org ([207.176.11.63]) by server1.ppc.pims.org
(Netscape Messaging Server 3.5) with ESMTP id AAA14D7;
Tue, 12 Oct 1999 11:51:36 +0200
Message-ID: <3803046A.CE172801@ppc.pims.org>
Date: Tue, 12 Oct 1999 11:50:35 +0200
From: "Allan Huffman" <huffmana@ppc.pims.org>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-interfaces@postgresql.org, pgsql-hackers@postgresql.org,
boulangj@ppc.pims.org, randolpf@ppc.pims.org
Subject: HELP - Accessing SQL_ASCII from Java
Content-Type: multipart/alternative;
boundary="------------BED33262DDBAC34C3B8B3F16"

--------------BED33262DDBAC34C3B8B3F16
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dear Fellow Developers and Hackers,

After installing PostgreSQL 6.5.2 (on my Sparc 7) and configured as
follows:
ï¿½--with-mb=UNICODEï¿½

I am getting a truncation of some varchar columns. When accessing a
PostgreSQL table1. I get this error in my postmaster window:

ï¿½ERROR: Conversion between UNICODE and SQL_ASCII is not supportedï¿½

And this error in my DOS window (which Visual Cafï¿½ Database Edition uses
to run applets from):

ï¿½The maximum width size for column 2 is: 17ï¿½

table1:
+------------------------------------------------+
!     Field     !     Type         !  Length     !
+------------------------------------------------+
! data_code     !     varchar()    !    15       !
! data_field    !     varchar()    !    43       !
+------------------------------------------------+

From my PC Java GUI, running in Visual Cafï¿½, I am able to enter a full

15 character string into data_code but I get the following error when I
try to enter a 43 (or greater than 17) character string into data_field:

ï¿½Invalid value for the column dataï¿½

and it truncates the data I enter to 17 characters.

From a psql prompt on the same Sun that is running the postmaster I can

change (select) the table without the truncation and no mention of
UNICODE!

+__________________________________________________________________________+

Without UNICODE configured I got the following errors:

From the Postmaster:

"ERROR: MultiByte strings (MB) must be enabled to use this function."

From Visual Cafï¿½:

"The maximum width size for column 2 is: 17"

+__________________________________________________________________________+

Any suggestion will be greatly appreciated, even a work around. What I
want to do is just access SQL_ASCII and leave UNICODE alone!

Sincerely,

Allan

--------------BED33262DDBAC34C3B8B3F16
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
 
 Dear Fellow Developers and Hackers,
After installing PostgreSQL 6.5.2 (on my Sparc 7) and configured as
follows:
 ï¿½--with-mb=UNICODEï¿½
I am getting a truncation of some varchar columns.  When accessing
a PostgreSQL  table1.  I get this error in my postmaster
window:
ï¿½ERROR: Conversion between UNICODE and SQL_ASCII is not supportedï¿½
And this error in my DOS window (which Visual Café Database Edition
uses to run applets from):
ï¿½The maximum width size for column 2 is: 17ï¿½
table1:
 <tt>+------------------------------------------------+</tt>
 <tt>!     Field     !    
Type         !  Length    
!</tt>
 <tt>+------------------------------------------------+</tt>
 <tt>! data_code     !    
varchar()    !    15      
!</tt>
 <tt>! data_field    !    
varchar()    !    43      
!</tt>
 <tt>+------------------------------------------------+</tt>
From my PC Java GUI, running in Visual Café, I am able to enter
a full 15 character string into data_code but I get the following
error when I try to enter a 43 (or greater than 17) character string into
data_field:
ï¿½Invalid value for the column dataï¿½
and it truncates the data I enter to 17 characters.
From a psql prompt on the same Sun that is running the postmaster I
can change (select) the table without the truncation and no mention of
UNICODE!
+__________________________________________________________________________+
Without UNICODE configured I got the following errors:
From the Postmaster:
"ERROR: MultiByte strings (MB) must be enabled to use this function."
From Visual Café:
"The maximum width size for column 2 is: 17"
+__________________________________________________________________________+
Any suggestion will be greatly appreciated, even a work around. 
What I want to do is just access SQL_ASCII and leave UNICODE alone!
Sincerely,
Allan
  
  </html>

--------------BED33262DDBAC34C3B8B3F16--

From bouncefilter Tue Oct 12 06:10:10 1999
Received: from gate.plzen-city.cz (gate.plzen-city.cz [194.212.191.10])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA15313
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 06:09:34 -0400 (EDT)
(envelope-from horak@mmp.plzen-city.cz)
Received: (from mail@localhost) by gate.plzen-city.cz (8.9.3/8.9.1) id
MAA08792
for <pgsql-hackers@postgreSQL.org>; Tue, 12 Oct 1999 12:09:19 +0200
Received: from EXCHANGE.mmp.plzen-city.cz(s5srvr1.mmp.plzen-city.cz
192.168.21.21) by gate.plzen-city.cz via smap (v1.3-ps12tp)
id sma008783; Tue Oct 12 12:09:06 1999
Received: by exchange.mmp.plzen-city.cz with Internet Mail Service
(5.5.2448.0)
id <4YAK8FQ5>; Tue, 12 Oct 1999 12:08:53 +0200
Message-ID:
<2E7F82FAC1FCD2118E1500A024B3BF907DEDAF@exchange.mmp.plzen-city.cz>
From: Horak Daniel <horak@mmp.plzen-city.cz>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: win32 port on newer Cygwin snapshots (990115)
Date: Tue, 12 Oct 1999 12:08:48 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01BF1499.C8F7A86E"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF1499.C8F7A86E
Content-Type: text/plain;
charset="iso-8859-2"

Hi,

I have created a small patch that makes possible to compile pgsql on newer
Cygwin snapshots (tested on 990115 which is recommended to use - it fixes
some errors in B20.1)

And I have another patch for including <sys/ipc.h> before <sys/sem.h> in
backend/storage/lmgr/proc.c - it is required due the design of cygipc
headers

Dan

PS: I think there are missing some files in the interfaces/libpgeasy
directory (snapshot via CVS a few hours old)

----------------------------------------------
Daniel Horak
network and system administrator
e-mail: horak@mmp.plzen-city.cz
privat e-mail: dan.horak@email.cz ICQ:36448176
----------------------------------------------

------_=_NextPart_000_01BF1499.C8F7A86E
Content-Type: application/octet-stream;
name="proc.c.diff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="proc.c.diff"

--- backend/storage/lmgr/proc.c.orig	Tue Oct 12 10:40:47 1999=0A=
+++ backend/storage/lmgr/proc.c	Tue Oct 12 10:40:26 1999=0A=
@@ -53,7 +53,7 @@=0A=
 #include <signal.h>=0A=
 #include <sys/types.h>=0A=
 =0A=
-#if defined(solaris_sparc)=0A=
+#if defined(solaris_sparc) || defined(__CYGWIN__)=0A=
 #include <sys/ipc.h>=0A=
 #include <sys/sem.h>=0A=
 #endif=0A=

------_=_NextPart_000_01BF1499.C8F7A86E
Content-Type: application/octet-stream;
name="win.h.diff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="win.h.diff"

--- include/port/win.h.orig	Sat Oct 09 14:16:42 1999=0A=
+++ include/port/win.h	Sat Oct 09 17:00:45 1999=0A=
@@ -9,3 +9,8 @@=0A=
 #define tzname _tzname			/* should be in time.h? */=0A=
 #define USE_POSIX_TIME=0A=
 #define HAVE_INT_TIMEZONE		/* has int _timezone */=0A=
+=0A=
+#include <cygwin/version.h>=0A=
+#if (CYGWIN_VERSION_API_MAJOR >=3D 0) && (CYGWIN_VERSION_API_MINOR =

=3D 8)=0A=

+#define sys_nerr _sys_nerr=0A=
+#endif=0A=

------_=_NextPart_000_01BF1499.C8F7A86E--

From bouncefilter Tue Oct 12 06:30:13 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA17793
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 06:29:23 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id TAA22161;
Tue, 12 Oct 1999 19:29:21 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id TAA03928;
Tue, 12 Oct 1999 19:29:21 +0900 (JST)
Message-Id: <199910121029.TAA03928@srapc451.sra.co.jp>
To: Vadim Mikheev <vadim@krs.ru>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Different BLKSZ
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Tue, 12 Oct 1999 18:32:15 JST.
<199910120932.SAA03241@srapc451.sra.co.jp>
Date: Tue, 12 Oct 1999 19:29:21 +0900
Sender: t-ishii@srapc451.sra.co.jp

access/transam/xlog.c:StartupXLOG() is called on every database
startup and read control file - just add BLCKSZ to
struct ControlFileData and check it on startup. Don't forget
to initialize this value in BootStrapXLOG() (while creating
control file).

Thanks. I will work on this issue.

I have committed changes to xlog.c. If the blcksz of database does not
match the one of the backend, you will get following error message and
postmaster won't start.

DEBUG: Data Base System is starting up at Tue Oct 12 19:11:03 1999
FATAL 2: database was initialized in BLCKSZ(0), but the backend was
compiled in BLCKSZ(8192)

This change requires initdb.
--
Tatsuo Ishii

From bouncefilter Tue Oct 12 06:39:11 1999
Received: from Radha.DoCS.UU.SE (root@Radha.DoCS.UU.SE [130.238.9.99])
by hub.org (8.9.3/8.9.3) with SMTP id GAA19083
for <pgsql-hackers@postgresql.org>;
Tue, 12 Oct 1999 06:38:46 -0400 (EDT)
(envelope-from e99re41@Emu.DoCS.UU.SE)
Received: from Emu.DoCS.UU.SE (e99re41@Emu.DoCS.UU.SE [130.238.9.176]) by
Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id MAA11292 for
<pgsql-hackers@postgresql.org>; Tue, 12 Oct 1999 12:38:43 +0200
Received: from localhost (e99re41@localhost) by Emu.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id MAA29508 for <pgsql-hackers@postgresql.org>;
Tue, 12 Oct 1999 12:38:41 +0200
X-Authentication-Warning: Emu.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 12 Oct 1999 12:38:41 +0200 (MET DST)
From: Peter Eisentraut <e99re41@Minsk.DoCS.UU.SE>
Reply-To: peter_e@gmx.net
To: pgsql-hackers@postgresql.org
Subject: It's PR time!
Message-ID: <Pine.GSO.4.02A.9910121233500.29495-100000@Emu.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

... on Slashdot of all places.

Some fellow wants to install a large database on Linux and is considering
Oracle vs. PostgreSQL. (Perhaps the poster with the 60GB astronomical db
from the other day could come forward?) I know you guys always wanted to
be on Slashdot, so here's your chance.

Not to start this all over again, but I especially liked this post:

"If you are looking for mission critical data, why not give a chance to
MySQL?"

Take a look.

-Peter

From bouncefilter Tue Oct 12 07:00:11 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id GAA21680
for <pgsql-hackers@postgresql.org>;
Tue, 12 Oct 1999 06:59:30 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11azeS-000PeR-0K; Tue, 12 Oct 1999 10:59:29 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id NAA28428;
Tue, 12 Oct 1999 13:03:28 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5KBN>; Tue, 12 Oct 1999 11:57:30 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E6C4@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'peter_e@gmx.net'" <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] It's PR time!
Date: Tue, 12 Oct 1999 11:57:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

I'll have to check /.

The 60Gb Astronomical DB is probably the TASS project (which I'm
associated with), but it's not 60Gb yet (about 18 at the moment), but
it's going to grow by about 200Mb a day when it really starts.

The best person (who I know is on atleast the interfaces list) is Chris
Robertson (I think I have his surname correct), but I only have his
email address at home.

You may find it on http://www.tass-survey.org

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Peter Eisentraut [mailto:e99re41@Minsk.DoCS.UU.SE]
Sent: 12 October 1999 11:39
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] It's PR time!

... on Slashdot of all places.

Some fellow wants to install a large database on Linux and is
considering
Oracle vs. PostgreSQL. (Perhaps the poster with the 60GB astronomical db
from the other day could come forward?) I know you guys always wanted to
be on Slashdot, so here's your chance.

Not to start this all over again, but I especially liked this post:

"If you are looking for mission critical data, why not give a chance to
MySQL?"

Take a look.

-Peter

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

From bouncefilter Tue Oct 12 09:43:13 1999
Received: from osprey.astro.umass.edu (root@osprey.astro.umass.edu
[128.119.51.182]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA57939
for <pgsql-hackers@postgresql.org>;
Tue, 12 Oct 1999 09:43:01 -0400 (EDT)
(envelope-from weinberg@osprey.astro.umass.edu)
Received: from osprey.astro.umass.edu (weinberg@localhost [127.0.0.1])
by osprey.astro.umass.edu (8.9.3/8.9.3/Debian/GNU) with ESMTP id
JAA25076; Tue, 12 Oct 1999 09:42:59 -0400
Message-Id: <199910121342.JAA25076@osprey.astro.umass.edu>
X-Mailer: exmh version 2.0.2 2/24/98 (debian)
To: peter_e@gmx.net
cc: pgsql-hackers@postgresql.org, weinberg@osprey.astro.umass.edu
Subject: Re: [HACKERS] It's PR time!
In-reply-to: Your message of "Tue, 12 Oct 1999 12:38:41 +0200."
<Pine.GSO.4.02A.9910121233500.29495-100000@Emu.DoCS.UU.SE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 12 Oct 1999 09:42:58 -0300
From: Martin Weinberg <weinberg@osprey.astro.umass.edu>

Peter Eisentraut wrote on Tue, 12 Oct 1999 12:38:41 +0200

(Perhaps the poster with the 60GB astronomical db
from the other day could come forward?)

That was me . . . I'm on the 2MASS (Two Micron All Sky Survey)
Science Team. This survey, now nearly 70% complete, has
amassed about 20TB of image data and from this we compile
catalogs of stellar and galaxian sources. The star catalog
will contain about 500 million sources and be about 100GB
on disk in condensed form.

Our goals for pgsql is to recommend a local data server system
for astronomers who want to spin and query all or parts of
this catalog.

The URLs for the project are:

http://pegasus.astro.umass.edu
http://www.ipac.caltech.edu/2mass

I am not the right person to head an "official" pgsql response,
but I'd be happy to help and "donote" additional info on our
applicaton.

--Martin

===========================================================================

From bouncefilter Tue Oct 12 10:02:14 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA61814
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 10:01:55 -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 JAA02293;
Tue, 12 Oct 1999 09:56:11 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121356.JAA02293@candle.pha.pa.us>
Subject: Re: [HACKERS] Features for next release
In-Reply-To: <Pine.BSF.4.10.9910120106430.404-100000@thelab.hub.org> from The
Hermit Hacker at "Oct 12, 1999 01:07:57 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 12 Oct 1999 09:56:10 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have another reason for calling it 7.0, which is that if we fix
the function-call interface the way I want to, we will break existing
user-written loadable modules that contain C-language functions.
Better to do that in a "7.0" than in a "6.6", no?

Based on all the comments flyng around, v7.0 it is. to be released...some
day :)

Bruce, you asked for a v6.5.3 to be released...anything outstanding that
should prevent me from doing that tomorrow afternoon?

Not that I know of. I was waiting to see if we could come up with other
patches, but I don't think that is going to happen anytime soon.

-- 
  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 12 10:02:18 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA61823
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 10:02:00 -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 JAA02356;
Tue, 12 Oct 1999 09:57:53 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121357.JAA02356@candle.pha.pa.us>
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
In-Reply-To: <15265.939701548@sss.pgh.pa.us> from Tom Lane at "Oct 12,
1999 00:12:28 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 12 Oct 1999 09:57:53 -0400 (EDT)
CC: pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

It seems to me that mdnblocks should assume that all segments
previously verified to be of length RELSEG_SIZE are still of that
length, and only do an _mdnblocks() call on the last element of the
segment chain. That way the number of kernel interactions needed
is a constant independent of the number of segments in the table.
(This doesn't make truncation of the relation by a different backend
any more or less dangerous; we're still hosed if we don't get a
notification before we try to do something with the relation.
I think that is fixed, and if it's not this doesn't make it worse.)

Any objections?

Sounds great. Now that the segments work properly, it is time for some
optimization. Vadim has complained about the lseek() from day-1.
Someday he wants a shared catalog cache to prevent that from being
needed.

-- 
  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 12 10:02:22 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA61715;
Tue, 12 Oct 1999 10:01:17 -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 JAA02367;
Tue, 12 Oct 1999 09:58:42 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121358.JAA02367@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
In-Reply-To: <Pine.BSF.4.10.9910120117260.404-100000@thelab.hub.org> from The
Hermit Hacker at "Oct 12, 1999 01:18:04 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 12 Oct 1999 09:58:42 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
"Sergio A. Kessler" <ser@perio.unlp.edu.ar>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I hope we don't have a consensus on this. Long commands with
underscores in them are certainly another sign of the coming
apocalypse ;)

But if we keep symlinks to the existing names, is that OK?

Oh, and, IMHO...remove, don't create symlinks...its a major release, we
don't have to maintain backwards compatability...we aren't mIcrosoft, eh?
:)

That is a good point. We could remove them. They don't get called very
often.

-- 
  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 12 10:02:13 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA61763
for <hackers@postgresql.org>; Tue, 12 Oct 1999 10:01:36 -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 KAA02565;
Tue, 12 Oct 1999 10:01:07 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121401.KAA02565@candle.pha.pa.us>
Subject: Re: Regression tests (was Re: [HACKERS] psql and comments)
In-Reply-To: <3802CE64.92C41126@alumni.caltech.edu> from Thomas Lockhart at
"Oct 12, 1999 06:00:04 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 12 Oct 1999 10:01:07 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yes, Thomas does it, but doesn't like to do it too often. He will
almost certainly do it for 7.0. :-)

I can regenerate the tests (usually) pretty easily. I've got the
parser spread across the computer room floor at the moment, so it will
be a few weeks...

Yes, Thomas has to check the current regression tests to see that he has
no errors, then change the backend display, and regenerate the
regression tests with the new output style. That way, he knows that the
old and new regression tests are the same.

-- 
  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 12 10:16:14 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 KAA64927
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 10:16:13 -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 KAA16265;
Tue, 12 Oct 1999 10:14:17 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Features for next release
In-reply-to: Your message of Tue, 12 Oct 1999 09:56:10 -0400 (EDT)
<199910121356.JAA02293@candle.pha.pa.us>
Date: Tue, 12 Oct 1999 10:14:17 -0400
Message-ID: <16263.939737657@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce, you asked for a v6.5.3 to be released...anything outstanding that
should prevent me from doing that tomorrow afternoon?

Not that I know of. I was waiting to see if we could come up with other
patches, but I don't think that is going to happen anytime soon.

On the other hand, is there a reason to be in a rush to put out 6.5.3?
I didn't think we had many important changes from 6.5.2 yet.

I imagine that we will acquire a few more fixes for 6.5.* as time goes
on, and it looks like 7.0 will be months away. Maybe a 6.5.* update
every month or two (if anything's been patched) would be the way to
proceed.

regards, tom lane

From bouncefilter Tue Oct 12 10:28:14 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 KAA67001
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 10:28: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 KAA16365;
Tue, 12 Oct 1999 10:27:30 -0400 (EDT)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Different BLKSZ
In-reply-to: Your message of Tue, 12 Oct 1999 10:00:09 +0900
<199910120100.KAA01526@ext16.sra.co.jp>
Date: Tue, 12 Oct 1999 10:27:30 -0400
Message-ID: <16363.939738450@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

While doing some tests, I have encountered too many problems with
incompatible BLKSZ (the backend comipled in different BLKSZ with the
one in database). I know this is my fault, but it would be nice if
there is better way to avoid this kind of disaster.

I think this is a fine idea, but BLKSZ is not the only critical
parameter that should be verified at startup. RELSEG_SIZE is
also critical and should be checked the same way. Are there any
other configuration variables that affect database layout? I can't
think of any offhand, but maybe someone else can.

Another thing I would like to see handled in the same way is some sort
of "database layout serial number" that is not the same as the official
version number. During development we frequently make initdb-forcing
changes to the contents of system tables, and sometimes not everyone
gets the word. (I recall Thomas wasted a few hours that way after a
recent change of mine, for example.) We ought to have an internal
version number in some central source file that can be incremented at
any time by anyone who's committing a change that requires initdb.
That would make sure that no one tries to run updated code against an
incompatible database, even if they haven't been paying close attention
to their hackers email. It could save a lot of wasted effort, I think.

regards, tom lane

From bouncefilter Tue Oct 12 10:38:16 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 KAA68614;
Tue, 12 Oct 1999 10:37:52 -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 KAA16415;
Tue, 12 Oct 1999 10:36:39 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-docs@postgresql.org,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] bison
In-reply-to: Your message of Tue, 12 Oct 1999 05:43:02 +0000
<3802CA66.C08B5B05@alumni.caltech.edu>
Date: Tue, 12 Oct 1999 10:36:39 -0400
Message-ID: <16413.939738999@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

You might want to include into the installation instructions (or whereever
it will end up) that GNU bison 1.25 is required. (right after the flex
stuff)

We haven't been careful about building and shipping the bison output
in the tarball distribution, as we have for the main parser.

Huh? src/tools/release_prep automatically builds both the main parser
and ecpg bison output files. Is there other stuff it should be
handling too?

regards, tom lane

From bouncefilter Tue Oct 12 10:42:18 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA69848
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 10:41:50 -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 KAA07612;
Tue, 12 Oct 1999 10:41:24 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121441.KAA07612@candle.pha.pa.us>
Subject: Re: [HACKERS] Features for next release
In-Reply-To: <16263.939737657@sss.pgh.pa.us> from Tom Lane at "Oct 12,
1999 10:14:17 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 12 Oct 1999 10:41:24 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce, you asked for a v6.5.3 to be released...anything outstanding that
should prevent me from doing that tomorrow afternoon?

Not that I know of. I was waiting to see if we could come up with other
patches, but I don't think that is going to happen anytime soon.

On the other hand, is there a reason to be in a rush to put out 6.5.3?
I didn't think we had many important changes from 6.5.2 yet.

I imagine that we will acquire a few more fixes for 6.5.* as time goes
on, and it looks like 7.0 will be months away. Maybe a 6.5.* update
every month or two (if anything's been patched) would be the way to
proceed.

Missing pgaccess source code.

-- 
  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 12 10:45:14 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA70256
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 10:44:43 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id LAA92144;
Tue, 12 Oct 1999 11:44:29 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 12 Oct 1999 11:44:29 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Features for next release
In-Reply-To: <16263.939737657@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9910121144000.30583-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 12 Oct 1999, Tom Lane wrote:

Bruce, you asked for a v6.5.3 to be released...anything outstanding that
should prevent me from doing that tomorrow afternoon?

Not that I know of. I was waiting to see if we could come up with other
patches, but I don't think that is going to happen anytime soon.

On the other hand, is there a reason to be in a rush to put out 6.5.3?
I didn't think we had many important changes from 6.5.2 yet.

v6.5.3, I believe, was because PgAccess somehow got removed in v6.5.2 :(

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 12 10:50:14 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 KAA71459
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 10:49:40 -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 KAA11000;
Tue, 12 Oct 1999 10:48:09 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121448.KAA11000@candle.pha.pa.us>
Subject: Re: [HACKERS] Features for next release
In-Reply-To: <Pine.BSF.4.10.9910121144000.30583-100000@thelab.hub.org> from
The
Hermit Hacker at "Oct 12, 1999 11:44:29 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 12 Oct 1999 10:48:09 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 12 Oct 1999, Tom Lane wrote:

Bruce, you asked for a v6.5.3 to be released...anything outstanding that
should prevent me from doing that tomorrow afternoon?

Not that I know of. I was waiting to see if we could come up with other
patches, but I don't think that is going to happen anytime soon.

On the other hand, is there a reason to be in a rush to put out 6.5.3?
I didn't think we had many important changes from 6.5.2 yet.

v6.5.3, I believe, was because PgAccess somehow got removed in v6.5.2 :(

OK, it was me, I didn't want to add it to 6.5.2 because it was not a
major bugfix, I got it 24 hours before release, it was a completely new
source tree layout, I asked the author to check my work, I didn't check
my work, and it was not committed properly. I feel better now. :-)

-- 
  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 12 10:53:15 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA72212;
Tue, 12 Oct 1999 10:52:43 -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 KAA14086;
Tue, 12 Oct 1999 10:52:32 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121452.KAA14086@candle.pha.pa.us>
Subject: Dead CVS directories
To: "Marc G. Fournier" <scrappy@postgreSQL.org>
Date: Tue, 12 Oct 1999 10:52:32 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Marc, I added a dead directory called interfaces/pgeasy that I have
removed via CVS, but I know the directory still exists in the CVS tree.
(Now called libpgeasy). In fact, I know there are many directories that
are empty in the tree.

Can you figure out a way to remove them from the CVSROOT tree?

-- 
  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 12 10:56:15 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA73055
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 10:55:49 -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 KAA14702;
Tue, 12 Oct 1999 10:55:12 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121455.KAA14702@candle.pha.pa.us>
Subject: Re: [HACKERS] win32 port on newer Cygwin snapshots (990115)
In-Reply-To:
<2E7F82FAC1FCD2118E1500A024B3BF907DEDAF@exchange.mmp.plzen-city.cz>
from Horak Daniel at "Oct 12, 1999 12:08:48 pm"
To: Horak Daniel <horak@mmp.plzen-city.cz>
Date: Tue, 12 Oct 1999 10:55:12 -0400 (EDT)
CC: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-2 unsupported, filtering to ASCII...]

Hi,

I have created a small patch that makes possible to compile pgsql on newer
Cygwin snapshots (tested on 990115 which is recommended to use - it fixes
some errors in B20.1)

And I have another patch for including <sys/ipc.h> before <sys/sem.h> in
backend/storage/lmgr/proc.c - it is required due the design of cygipc
headers

Thanks. Applied to both trees, so this will be in 6.5.3.

Marc, I need to version stamp 6.5.3. I will do it now.

Dan

PS: I think there are missing some files in the interfaces/libpgeasy
directory (snapshot via CVS a few hours old)

Yes, cleaning that up now. I don't know how I mess CVS up so often.

-- 
  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 12 11:02:14 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA74577
for <hackers@postgresql.org>; Tue, 12 Oct 1999 11:01:45 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11b3Om-0002hO-0K; Tue, 12 Oct 1999 14:59:32 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id RAA29230;
Tue, 12 Oct 1999 17:02:23 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5KDM>; Tue, 12 Oct 1999 15:56:20 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E6C8@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'The Hermit Hacker'" <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <maillist@candle.pha.pa.us>, Thomas Lockhart
<lockhart@alumni.caltech.edu>, Postgres Hackers List
<hackers@postgresql.org>
Subject: RE: [HACKERS] Features for next release
Date: Tue, 12 Oct 1999 15:56:19 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

I also have a slight feeling that 6.5.2 is missing bits of the current
JDBC source. I'm not certain (won't be able to check until tonight), but
I think this is the case.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: The Hermit Hacker [mailto:scrappy@hub.org]
Sent: 12 October 1999 15:44
To: Tom Lane
Cc: Bruce Momjian; Thomas Lockhart; Postgres Hackers List
Subject: Re: [HACKERS] Features for next release

On Tue, 12 Oct 1999, Tom Lane wrote:

Bruce, you asked for a v6.5.3 to be released...anything outstanding

that

should prevent me from doing that tomorrow afternoon?

Not that I know of. I was waiting to see if we could come up with

other

patches, but I don't think that is going to happen anytime soon.

On the other hand, is there a reason to be in a rush to put out 6.5.3?
I didn't think we had many important changes from 6.5.2 yet.

v6.5.3, I believe, was because PgAccess somehow got removed in v6.5.2 :(

Marc G. Fournier ICQ#7615664 IRC Nick:
Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary:
scrappy@{freebsd|postgresql}.org

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

From bouncefilter Tue Oct 12 10:59:14 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 KAA73524
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 10:58: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 KAA16559;
Tue, 12 Oct 1999 10:57:37 -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, 12 Oct 1999 16:11:42 +0900
<002801bf1481$0921a5c0$2801007e@cadzone.tpf.co.jp>
Date: Tue, 12 Oct 1999 10:57:37 -0400
Message-ID: <16557.939740257@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

It's me who removed the following code from mdnblocks().
The code caused a disaster in case of mdtruncate().

if (v->mdfd_lstbcnt == RELSEG_SIZE
|| ....

OK, but do you think there's still a risk, given that we've changed
the relcache-level interlocking?

Currently only the first segment is opened when mdopen() etc is
called. Would you change to check all segments at first open ?

No, I don't see a need to change that logic. I was thinking that
since mdnblocks adds another link to the chain whenever it sees that
the current segment is exactly RELSEG_SIZE, it could just assume that
if the next-segment link is not NULL then this segment must be of
size RELSEG_SIZE and it doesn't need to check that again. It'd only
need to do an actual check on the last chain element (plus any elements
it adds during the current call, of course). We'd rely on the
higher-level interlock to close and reopen the virtual file when a
truncate has happened.

If there is a relation which has multi-segment of size 0,which would
be the last segment ?

Only the last segment can have any size other than RELSEG_SIZE, I think.

regards, tom lane

From bouncefilter Tue Oct 12 11:03:14 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA74789;
Tue, 12 Oct 1999 11:02:51 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11b3QF-0002rh-0K; Tue, 12 Oct 1999 15:01:03 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id RAA29235;
Tue, 12 Oct 1999 17:03:53 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5KDN>; Tue, 12 Oct 1999 15:57:50 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E6C9@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Bruce Momjian'" <maillist@candle.pha.pa.us>, "Marc G. Fournier"
<scrappy@postgresql.org>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] Dead CVS directories
Date: Tue, 12 Oct 1999 15:57:45 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

rm?

Well it's a last resort I've used on one of my home cvs trees, but it
does loose the archived stuff under that directory.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: 12 October 1999 15:53
To: Marc G. Fournier
Cc: PostgreSQL-development
Subject: [HACKERS] Dead CVS directories

Can you figure out a way to remove them from the CVSROOT tree?

-- 
  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 12 11:04:14 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 LAA74913
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 11:03:21 -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 LAA16600;
Tue, 12 Oct 1999 11:02:09 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
In-reply-to: Your message of Mon, 11 Oct 1999 23:22:23 -0400 (EDT)
<199910120322.XAA18860@candle.pha.pa.us>
Date: Tue, 12 Oct 1999 11:02:09 -0400
Message-ID: <16598.939740529@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

If we put something in the executor so when a sequential/index scan is
requested on a table that has a restriction on tid, you could just do a
heap_fetch and return the single row, rather than putting the query
through the whole scan process for every row checking to see if it
matches the WHERE restriction.

Seems like a few lines in the executor could do the entire job of
fetching by tid by short-circuiting the sequential/index scan.

If I understand what you're proposing here, it would be a horrible
mangling of the system structure and doubtless a fruitful source
of bugs. I don't think we should be taking shortcuts with this issue.
If we think fast access by TID is worth supporting at all, we should
expend the work to do it properly.

regards, tom lane

From bouncefilter Tue Oct 12 11:09:15 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA76208;
Tue, 12 Oct 1999 11:08:58 -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 LAA20401;
Tue, 12 Oct 1999 11:08:43 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121508.LAA20401@candle.pha.pa.us>
Subject: Re: [HACKERS] Dead CVS directories
In-Reply-To:
<1B3D5E532D18D311861A00600865478C25E6C9@exchange1.nt.maidstone.gov.uk>
from Peter Mount at "Oct 12, 1999 03:57:45 pm"
To: Peter Mount <petermount@it.maidstone.gov.uk>
Date: Tue, 12 Oct 1999 11:08:43 -0400 (EDT)
CC: "Marc G. Fournier" <scrappy@postgresql.org>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

rm?

Well it's a last resort I've used on one of my home cvs trees, but it
does loose the archived stuff under that directory.

Peter

Yes, but in most cases we don't care. That stuff is very old. I don't
know of any directory that has no valid files that needs to be saved.

-- 
  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 12 11:11:14 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA76783
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 11:10:44 -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 LAA20419;
Tue, 12 Oct 1999 11:10:21 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121510.LAA20419@candle.pha.pa.us>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
In-Reply-To: <16598.939740529@sss.pgh.pa.us> from Tom Lane at "Oct 12,
1999 11:02:09 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 12 Oct 1999 11:10:21 -0400 (EDT)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

If we put something in the executor so when a sequential/index scan is
requested on a table that has a restriction on tid, you could just do a
heap_fetch and return the single row, rather than putting the query
through the whole scan process for every row checking to see if it
matches the WHERE restriction.

Seems like a few lines in the executor could do the entire job of
fetching by tid by short-circuiting the sequential/index scan.

If I understand what you're proposing here, it would be a horrible
mangling of the system structure and doubtless a fruitful source
of bugs. I don't think we should be taking shortcuts with this issue.
If we think fast access by TID is worth supporting at all, we should
expend the work to do it properly.

But to do that whole thing properly, you are adding tons of complexity
in access methods and stuff just to support one type that by definition
is very internal to the backend.

Just my ideas. I understand you concern. I just thought a few
well-placed lines could do the trick without adding tons of other stuff.

-- 
  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 12 11:29:15 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 LAA79905
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 11:28:21 -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 LAA16732;
Tue, 12 Oct 1999 11:24:22 -0400 (EDT)
To: The Hermit Hacker <scrappy@hub.org>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Features for next release
In-reply-to: Your message of Tue, 12 Oct 1999 11:44:29 -0300 (ADT)
<Pine.BSF.4.10.9910121144000.30583-100000@thelab.hub.org>
Date: Tue, 12 Oct 1999 11:24:22 -0400
Message-ID: <16730.939741862@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

The Hermit Hacker <scrappy@hub.org> writes:

On the other hand, is there a reason to be in a rush to put out 6.5.3?
I didn't think we had many important changes from 6.5.2 yet.

v6.5.3, I believe, was because PgAccess somehow got removed in v6.5.2 :(

Ah, right, I'd forgotten that. OK, we need a 6.5.3.

It sounds like Peter wants another day to check JDBC though...

regards, tom lane

From bouncefilter Tue Oct 12 11:30:16 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 LAA80370;
Tue, 12 Oct 1999 11:29:42 -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 LAA16756;
Tue, 12 Oct 1999 11:28:36 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: "Marc G. Fournier" <scrappy@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Dead CVS directories
In-reply-to: Your message of Tue, 12 Oct 1999 10:52:32 -0400 (EDT)
<199910121452.KAA14086@candle.pha.pa.us>
Date: Tue, 12 Oct 1999 11:28:36 -0400
Message-ID: <16754.939742116@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Marc, I added a dead directory called interfaces/pgeasy that I have
removed via CVS, but I know the directory still exists in the CVS tree.
(Now called libpgeasy). In fact, I know there are many directories that
are empty in the tree.

Can you figure out a way to remove them from the CVSROOT tree?

AFAIK, a directory in the CVS repository is forever, because there are
always going to be files in it --- maybe files that are dead as far as
the current version is concerned, but CVS wants to be able to give you
back any past state of the tree, so there are still ,v files in there.

Normally you should be running checkouts and updates with -p (prune)
switch, which removes directories from *your checked out copy* if they
contain no live files as of the version you are checking out. But
they have to stay there in the CVS repository.

regards, tom lane

From bouncefilter Tue Oct 12 11:31:19 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA81085;
Tue, 12 Oct 1999 11:31:01 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA92633;
Tue, 12 Oct 1999 12:30:46 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 12 Oct 1999 12:30:46 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Peter Mount <petermount@it.maidstone.gov.uk>,
"Marc G. Fournier" <scrappy@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Dead CVS directories
In-Reply-To: <199910121508.LAA20401@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910121229530.30583-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 12 Oct 1999, Bruce Momjian wrote:

rm?

Well it's a last resort I've used on one of my home cvs trees, but it
does loose the archived stuff under that directory.

Peter

Yes, but in most cases we don't care. That stuff is very old. I don't
know of any directory that has no valid files that needs to be saved.

Why would we want to remove it in the first place? If its been 'deleted',
it won't show up unless you want it to (cvs update -APd removed old
files/directories)...

Oops, careful in the above, it also removed any 'sticky/branch' tags...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 12 11:33:14 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA81505
for <hackers@postgresql.org>; Tue, 12 Oct 1999 11:32:23 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA92637;
Tue, 12 Oct 1999 12:32:01 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 12 Oct 1999 12:32:01 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Peter Mount <petermount@it.maidstone.gov.uk>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <maillist@candle.pha.pa.us>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgresql.org>
Subject: RE: [HACKERS] Features for next release
In-Reply-To:
<1B3D5E532D18D311861A00600865478C25E6C8@exchange1.nt.maidstone.gov.uk>
Message-ID: <Pine.BSF.4.10.9910121231440.30583-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 12 Oct 1999, Peter Mount wrote:

I also have a slight feeling that 6.5.2 is missing bits of the current
JDBC source. I'm not certain (won't be able to check until tonight), but
I think this is the case.

Done, let me know when you are finished/ready ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 12 11:41:16 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA83357
for <hackers@postgresql.org>; Tue, 12 Oct 1999 11:40:21 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11b3yo-0006Nz-0K; Tue, 12 Oct 1999 15:36:46 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id RAA29439;
Tue, 12 Oct 1999 17:39:14 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5K1F>; Tue, 12 Oct 1999 16:33:11 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E6CA@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>
Cc: Bruce Momjian <maillist@candle.pha.pa.us>, Thomas Lockhart
<lockhart@alumni.caltech.edu>, Postgres Hackers List
<hackers@postgresql.org>
Subject: RE: [HACKERS] Features for next release
Date: Tue, 12 Oct 1999 16:33:10 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

I'll check it tonight, so you should know in about 3 hours.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 12 October 1999 16:24
To: The Hermit Hacker
Cc: Bruce Momjian; Thomas Lockhart; Postgres Hackers List
Subject: Re: [HACKERS] Features for next release

The Hermit Hacker <scrappy@hub.org> writes:

On the other hand, is there a reason to be in a rush to put out

6.5.3?

I didn't think we had many important changes from 6.5.2 yet.

v6.5.3, I believe, was because PgAccess somehow got removed in v6.5.2

Ah, right, I'd forgotten that. OK, we need a 6.5.3.

It sounds like Peter wants another day to check JDBC though...

regards, tom lane

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

From bouncefilter Tue Oct 12 11:36:15 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA82523;
Tue, 12 Oct 1999 11:35:24 -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 LAA21501;
Tue, 12 Oct 1999 11:35:07 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121535.LAA21501@candle.pha.pa.us>
Subject: Re: [HACKERS] Dead CVS directoriesh
In-Reply-To: <Pine.BSF.4.10.9910121229530.30583-100000@thelab.hub.org> from
The
Hermit Hacker at "Oct 12, 1999 12:30:46 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 12 Oct 1999 11:35:07 -0400 (EDT)
CC: Peter Mount <petermount@it.maidstone.gov.uk>,
"Marc G. Fournier" <scrappy@postgresql.org>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 12 Oct 1999, Bruce Momjian wrote:

rm?

Well it's a last resort I've used on one of my home cvs trees, but it
does loose the archived stuff under that directory.

Peter

Yes, but in most cases we don't care. That stuff is very old. I don't
know of any directory that has no valid files that needs to be saved.

Why would we want to remove it in the first place? If its been 'deleted',
it won't show up unless you want it to (cvs update -APd removed old
files/directories)...

Oops, careful in the above, it also removed any 'sticky/branch' tags...

I just thought we could fiddle with CVS to remove the stuff totally. No
real need to, though. I just thought it would be confusing for people
who didn't do -P, or people managing CVSROOT directly.

-- 
  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 12 11:42:16 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA83032
for <hackers@postgresql.org>; Tue, 12 Oct 1999 11:39:53 -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 LAA21543;
Tue, 12 Oct 1999 11:36:28 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121536.LAA21543@candle.pha.pa.us>
Subject: Re: [HACKERS] Features for next release
In-Reply-To: <Pine.BSF.4.10.9910121231440.30583-100000@thelab.hub.org> from
The
Hermit Hacker at "Oct 12, 1999 12:32:01 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 12 Oct 1999 11:36:28 -0400 (EDT)
CC: Peter Mount <petermount@it.maidstone.gov.uk>,
Tom Lane <tgl@sss.pgh.pa.us>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM939742588-2735-0_
Content-Transfer-Encoding: 7bit

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

On Tue, 12 Oct 1999, Peter Mount wrote:

I also have a slight feeling that 6.5.2 is missing bits of the current
JDBC source. I'm not certain (won't be able to check until tonight), but
I think this is the case.

Done, let me know when you are finished/ready ...

I am ready. Thomas, please check out my new INSTALL file. I did it
with sgmltools and Netscape. Seems to be OK.

I am not sure if you have the 6.5.* branch, so I am attaching the file
for everyone's review.

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

--ELM939742588-2735-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/pgtoprel/INSTALL"
Content-Transfer-Encoding: 7bit

Chapter 0. Installation

Table of Contents
Requirements to Run Postgres
Installation Procedure
Playing with Postgres
The Next Step
Porting Notes

Complete installation instructions for Postgres v6.5.3.

Before installing Postgres, you may wish to visit www.postgresql.org for up
to date information, patches, etc.

These installation instructions assume:

* Commands are Unix-compatible. See note below.

* Defaults are used except where noted.

* User postgres is the Postgres superuser.

* The source path is /usr/src/pgsql (other paths are possible).

* The runtime path is /usr/local/pgsql (other paths are possible).

Commands were tested on RedHat Linux version 5.2 using the tcsh shell.
Except where noted, they will probably work on most systems. Commands like
ps and tar may vary wildly between platforms on what options you should use.
Use common sense before typing in these commands.

Our Makefiles require GNU make (called "gmake" in this document). They will
not work with non-GNU make programs. If you have GNU make installed under
the name "make" instead of "gmake", then you will use the command make
instead. That's OK, but you need to have the GNU form of make to succeed
with an installation.

Requirements to Run Postgres

Up to date information on supported platforms is at
http://www.postgresql.org/docs/admin/install.htm. In general, most
Unix-compatible platforms with modern libraries should be able to run
Postgres.

Although the minimum required memory for running Postgres is as little as
8MB, there are noticable improvements in runtimes for the regression tests
when expanding memory up to 96MB on a relatively fast dual-processor system
running X-Windows. The rule is you can never have too much memory.

Check that you have sufficient disk space. You will need about 30 Mbytes for
/usr/src/pgsql, about 5 Mbytes for /usr/local/pgsql (excluding your
database) and 1 Mbyte for an empty database. The database will temporarily
grow to about 20 Mbytes during the regression tests. You will also need
about 3 Mbytes for the distribution tar file.

We therefore recommend that during installation and testing you have well
over 20 Mbytes free under /usr/local and another 25 Mbytes free on the disk
partition containing your database. Once you delete the source files, tar
file and regression database, you will need 2 Mbytes for /usr/local/pgsql, 1
Mbyte for the empty database, plus about five times the space you would
require to store your database data in a flat file.

To check for disk space, use

$ df -k

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

Installation Procedure

Postgres Installation

For a fresh install or upgrading from previous releases of Postgres:

1. Read any last minute information and platform specific porting notes.
There are some platform specific notes at the end of this file for
Ultrix4.x, Linux, BSD/OS and NeXT. There are other files in directory
/usr/src/pgsql/doc, including files FAQ-Irix and FAQ-Linux. Also look
in directory ftp://ftp.postgresql.org/pub. If there is a file called
INSTALL in this directory then this file will contain the latest
installation information.

Please note that a "tested" platform in the list given earlier simply
means that someone went to the effort at some point of making sure that
a Postgres distribution would compile and run on this platform without
modifying the code. Since the current developers will not have access
to all of these platforms, some of them may not compile cleanly and
pass the regression tests in the current release due to minor problems.
Any such known problems and their solutions will be posted in
ftp://ftp.postgresql.org/pub/INSTALL.

2. Create the Postgres superuser account (postgres is commonly used) if it
does not already exist.

The owner of the Postgres files can be any unprivileged user account.
It must not be root, bin, or any other account with special access
rights, as that would create a security risk.

3. Log in to the Postgres superuser account. Most of the remaining steps
in the installation will happen in this account.

4. Ftp file ftp://ftp.postgresql.org/pub/postgresql-v6.5.3.tar.gz from the
Internet. Store it in your home directory.

5. Some platforms use flex. If your system uses flex then make sure you
have a good version. To check, type

$ flex --version

If the flex command is not found then you probably do not need it. If
the version is 2.5.2 or 2.5.4 or greater then you are okay. If it is
2.5.3 or before 2.5.2 then you will have to upgrade flex. You may get
it at ftp://prep.ai.mit.edu/pub/gnu/flex-2.5.4.tar.gz.

If you need flex and don't have it or have the wrong version, then you
will be told so when you attempt to compile the program. Feel free to
skip this step if you aren't sure you need it. If you do need it then
you will be told to install/upgrade flex when you try to compile
Postgres.

You may want to do the entire flex installation from the root account,
though that is not absolutely necessary. Assuming that you want the
installation to place files in the usual default areas, type the
following:

$ su -
$ cd /usr/local/src
ftp prep.ai.mit.edu
ftp> cd /pub/gnu/
ftp> binary
ftp> get flex-2.5.4.tar.gz
ftp> quit
$ gunzip -c flex-2.5.4.tar.gz | tar xvf -
$ cd flex-2.5.4
$ configure --prefix=/usr
$ gmake
$ gmake check
# You must be root when typing the next line:
$ gmake install
$ cd /usr/local/src
$ rm -rf flex-2.5.4

This will update files /usr/man/man1/flex.1, /usr/bin/flex,
/usr/lib/libfl.a, /usr/include/FlexLexer.h and will add a link
/usr/bin/flex++ which points to flex.

6. If you are not upgrading an existing system then skip to . If you are
upgrading from 6.5, you do not need to dump/reload or initdb. Simply
compile the source code, stop the postmaster, do a "make install", and
restart the postmaster. If you are upgrading from 6.4.* or earlier,
back up your database. For alpha- and beta-level releases, the database
format is liable to change, often every few weeks, with no notice
besides a quick comment in the HACKERS mailing list. Full releases
always require a dump/reload from previous releases. It is therefore a
bad idea to skip this step.

Tip: Do not use the pg_dumpall script from v6.0 or everything
will be owned by the Postgres super user.

To dump your fairly recent post-v6.0 database installation, type

$ pg_dumpall > db.out

To use the latest pg_dumpall script on your existing older database
before upgrading Postgres, pull the most recent version of pg_dumpall
from the new distribution:

$ cd
$ gunzip -c postgresql-v6.5.3.tar.gz \
| tar xvf - src/bin/pg_dump/pg_dumpall
$ chmod a+x src/bin/pg_dump/pg_dumpall
$ src/bin/pg_dump/pg_dumpall > db.out
$ rm -rf src

If you wish to preserve object id's (oids), then use the -o option when
running pg_dumpall. However, unless you have a special reason for doing
this (such as using OIDs as keys in tables), don't do it.

If the pg_dumpall command seems to take a long time and you think it
might have died, then, from another terminal, type

$ ls -l db.out

several times to see if the size of the file is growing.

Please note that if you are upgrading from a version prior to
Postgres95 v1.09 then you must back up your database, install
Postgres95 v1.09, restore your database, then back it up again. You
should also read the release notes which should cover any
release-specific issues.

Caution
You must make sure that your database is not updated in the middle of your
backup. If necessary, bring down postmaster, edit the permissions in file
/usr/local/pgsql/data/pg_hba.conf to allow only you on, then bring
postmaster back up.
7. If you are upgrading an existing system then kill the postmaster. Type

$ ps -ax | grep postmaster

This should list the process numbers for a number of processes. Type
the following line, with pid replaced by the process id for process
postmaster. (Do not use the id for process "grep postmaster".) Type

$ kill pid

to actually stop the process.

Tip: On systems which have Postgres started at boot time,
there is probably a startup file which will accomplish the
same thing. For example, on my Linux system I can type

$ /etc/rc.d/init.d/postgres.init stop

to halt Postgres.

8. If you are upgrading an existing system then move the old directories
out of the way. If you are short of disk space then you may have to
back up and delete the directories instead. If you do this, save the
old database in the /usr/local/pgsql/data directory tree. At a minimum,
save file /usr/local/pgsql/data/pg_hba.conf.

Type the following:

$ su -
$ cd /usr/src
$ mv pgsql pgsql_6_0
$ cd /usr/local
$ mv pgsql pgsql_6_0
$ exit

If you are not using /usr/local/pgsql/data as your data directory
(check to see if environment variable PGDATA is set to something else)
then you will also want to move this directory in the same manner.

9. Make new source and install directories. The actual paths can be
different for your installation but you must be consistent throughout
this procedure.

Note: There are two places in this installation procedure
where you will have an opportunity to specify installation
locations for programs, libraries, documentation, and other
files. Usually it is sufficient to specify these at the gmake
install stage of installation.

Type

$ su
$ cd /usr/src
$ mkdir pgsql
$ chown postgres:postgres pgsql
$ cd /usr/local
$ mkdir pgsql
$ chown postgres:postgres pgsql
$ exit

10. Unzip and untar the new source file. Type

$ cd /usr/src/pgsql
$ gunzip -c ~/postgresql-v6.5.3.tar.gz | tar xvf -

11. Configure the source code for your system. It is this step at which you
can specify your actual installation path for the build process (see
the --prefix option below). Type

$ cd /usr/src/pgsql/src
$ ./configure [ options ]

a. Among other chores, the configure script selects a system-specific
"template" file from the files provided in the template
subdirectory. If it cannot guess which one to use for your system,
it will say so and exit. In that case you'll need to figure out
which one to use and run configure again, this time giving the
--with-template=TEMPLATE option to make the right file be chosen.

Please Report Problems: If your system is not
automatically recognized by configure and you have to do
this, please send email to scrappy@hub.org with the
output of the program ./config.guess. Indicate what the
template file should be.

b. Choose configuration options. Check for details. However, for a
plain-vanilla first installation with no extra options like
multi-byte character support or locale collation support it may be
adequate to have chosen the installation areas and to run
configure without extra options specified. The configure script
accepts many additional options that you can use if you don't like
the default configuration. To see them all, type

./configure --help

Some of the more commonly used ones are:

--prefix=BASEDIR Selects a different base directory for the
installation of the Postgres configuration.
The default is /usr/local/pgsql.
--with-template=TEMPLATE
Use template file TEMPLATE - the template
files are assumed to be in the directory
src/template, so look there for proper values.
--with-tcl Build interface libraries and programs requiring
Tcl/Tk, including libpgtcl, pgtclsh, and pgtksh.
--with-perl Build the Perl interface library.
--with-odbc Build the ODBC driver package.
--enable-hba Enables Host Based Authentication (DEFAULT)
--disable-hba Disables Host Based Authentication
--enable-locale Enables USE_LOCALE
--enable-cassert Enables ASSERT_CHECKING
--with-CC=compiler
Use a specific C compiler that the configure
script cannot find.
--with-CXX=compiler
--without-CXX
Use a specific C++ compiler that the configure
script cannot find, or exclude C++ compilation
altogether. (This only affects libpq++ at
present.)

c. Here is the configure script used on a Sparc Solaris 2.5 system
with /opt/postgres specified as the installation base directory:

$ ./configure --prefix=/opt/postgres \
--with-template=sparc_solaris-gcc --with-pgport=5432 \
--enable-hba --disable-locale

Tip: Of course, you may type these three lines all on
the same line.

12. Install the man and HTML documentation. Type

$ cd /usr/src/pgsql/doc
$ gmake install

The documentation is also available in Postscript format. Look for
files ending with .ps.gz in the same directory.

13. Compile the program. Type

$ cd /usr/src/pgsql/src
$ gmake all > make.log 2>&1 &
$ tail -f make.log

The last line displayed will hopefully be

All of PostgreSQL is successfully made. Ready to install.

Remember, "gmake" may be called "make" on your system. At this point,
or earlier if you wish, type control-C to get out of tail. (If you have
problems later on you may wish to examine file make.log for warning and
error messages.)

Note: You will probably find a number of warning messages in
make.log. Unless you have problems later on, these messages
may be safely ignored.

If the compiler fails with a message stating that the flex command
cannot be found then install flex as described earlier. Next, change
directory back to this directory, type

$ gmake clean

then recompile again.

Compiler options, such as optimization and debugging, may be specified
on the command line using the COPT variable. For example, typing

$ gmake COPT="-g" all > make.log 2>&1 &

would invoke your compiler's -g option in all steps of the build. See
src/Makefile.global.in for further details.

14. Install the program. Type

$ cd /usr/src/pgsql/src
$ gmake install > make.install.log 2>&1 &
$ tail -f make.install.log

The last line displayed will be

gmake[1]: Leaving directory `/usr/src/pgsql/src/man'

At this point, or earlier if you wish, type control-C to get out of
tail. Remember, "gmake" may be called "make" on your system.

15. If necessary, tell your system how to find the new shared libraries.
You can do one of the following, preferably the first:

a. As root, edit file /etc/ld.so.conf. Add a line

/usr/local/pgsql/lib

to the file. Then run command /sbin/ldconfig.

b. In a bash shell, type

export LD_LIBRARY_PATH=/usr/local/pgsql/lib

c. In a csh shell, type

setenv LD_LIBRARY_PATH /usr/local/pgsql/lib

Please note that the above commands may vary wildly for different
operating systems. Check the platform specific notes, such as those for
Ultrix4.x or and for non-ELF Linux.

If, when you create the database, you get the message

pg_id: can't load library 'libpq.so'

then the above step was necessary. Simply do this step, then try to
create the database again.

16. If you used the --with-perl option to configure, check the install log
to see whether the Perl module was actually installed. If you've
followed our advice to make the Postgres files be owned by an
unprivileged userid, then the Perl module won't have been installed,
for lack of write privileges on the Perl library directories. You can
complete its installation, either now or later, by becoming the user
that does own the Perl library (often root) (via su) and doing

$ cd /usr/src/pgsql/src/interfaces/perl5
$ gmake install

17. If it has not already been done, then prepare account postgres for
using Postgres. Any account that will use Postgres must be similarly
prepared.

There are several ways to influence the runtime environment of the
Postgres server. Refer to the Administrator's Guide for more
information.

Note: The following instructions are for a bash/sh shell.
Adapt accordingly for other shells.

a. Add the following lines to your login environment: shell,
~/.bash_profile:

PATH=$PATH:/usr/local/pgsql/bin
MANPATH=$MANPATH:/usr/local/pgsql/man
PGLIB=/usr/local/pgsql/lib
PGDATA=/usr/local/pgsql/data
export PATH MANPATH PGLIB PGDATA

b. Several regression tests could fail if the user's locale collation
scheme is different from that of the standard C locale.

If you configure and compile Postgres with --enable-locale then
you should set the locale environment to "C" (or unset all "LC_*"
variables) by putting these additional lines to your login
environment before starting postmaster:

LC_COLLATE=C
LC_CTYPE=C
export LC_COLLATE LC_CTYPE

c. Make sure that you have defined these variables before continuing
with the remaining steps. The easiest way to do this is to type:

$ source ~/.bash_profile

18. Create the database installation from your Postgres superuser account
(typically account postgres). Do not do the following as root! This
would be a major security hole. Type

$ initdb

19. Set up permissions to access the database system. Do this by editing
file /usr/local/pgsql/data/pg_hba.conf. The instructions are included
in the file. (If your database is not located in the default location,
i.e. if PGDATA is set to point elsewhere, then the location of this
file will change accordingly.) This file should be made read only again
once you are finished. If you are upgrading from v6.0 or later you can
copy file pg_hba.conf from your old database on top of the one in your
new database, rather than redoing the file from scratch.

20. Briefly test that the backend will start and run by running it from the
command line.

a. Start the postmaster daemon running in the background by typing

$ cd
$ nohup postmaster -i > pgserver.log 2>&1 &

b. Create a database by typing

$ createdb

c. Connect to the new database:

$ psql

d. And run a sample query:

postgres=> SELECT datetime 'now';

e. Exit psql:

postgres=> \q

f. Remove the test database (unless you will want to use it later for
other tests):

$ destroydb

21. Run postmaster in the background from your Postgres superuser account
(typically account postgres). Do not run postmaster from the root
account!

Usually, you will want to modify your computer so that it will
automatically start postmaster whenever it boots. It is not required;
the Postgres server can be run successfully from non-privileged
accounts without root intervention.

Here are some suggestions on how to do this, contributed by various
users.

Whatever you do, postmaster must be run by the Postgres superuser
(postgres?) and not by root. This is why all of the examples below
start by switching user (su) to postgres. These commands also take into
account the fact that environment variables like PATH and PGDATA may
not be set properly. The examples are as follows. Use them with extreme
caution.

o If you are installing from a non-privileged account and have no
root access, then start the postmaster and send it to the
background:

$ cd
$ nohup postmaster > regress.log 2>&1 &

o Edit file rc.local on NetBSD or file rc2.d on SPARC Solaris 2.5.1
to contain the following single line:

su postgres -c "/usr/local/pgsql/bin/postmaster -S -D /usr/local/pgsql/data"

o In FreeBSD 2.2-RELEASE edit /usr/local/etc/rc.d/pgsql.sh to
contain the following lines and make it chmod 755 and chown
root:bin.

#!/bin/sh
[ -x /usr/local/pgsql/bin/postmaster ] && {
su -l pgsql -c 'exec /usr/local/pgsql/bin/postmaster
-D/usr/local/pgsql/data
-S -o -F > /usr/local/pgsql/errlog' &
echo -n ' pgsql'
}

You may put the line breaks as shown above. The shell is smart
enough to keep parsing beyond end-of-line if there is an
expression unfinished. The exec saves one layer of shell under the
postmaster process so the parent is init.

o In RedHat Linux add a file /etc/rc.d/init.d/postgres.init which is
based on the example in contrib/linux/. Then make a softlink to
this file from /etc/rc.d/rc5.d/S98postgres.init.

o In RedHat Linux edit file /etc/inittab to add the following as a
single line:

pg:2345:respawn:/bin/su - postgres -c
"/usr/local/pgsql/bin/postmaster -D/usr/local/pgsql/data
/usr/local/pgsql/server.log 2&1 /dev/null"

(The author of this example says this example will revive the
postmaster if it dies, but he doesn't know if there are other side
effects.)

22. Run the regression tests. The file
/usr/src/pgsql/src/test/regress/README has detailed instructions for
running and interpreting the regression tests. A short version follows
here:

a. Type

$ cd /usr/src/pgsql/src/test/regress
$ gmake clean
$ gmake all runtest

You do not need to type gmake clean if this is the first time you
are running the tests.

You should get on the screen (and also written to file
./regress.out) a series of statements stating which tests passed
and which tests failed. Please note that it can be normal for some
tests to "fail" on some platforms. The script says a test has
failed if there is any difference at all between the actual output
of the test and the expected output. Thus, tests may "fail" due to
minor differences in wording of error messages, small differences
in floating-point roundoff, etc, between your system and the
regression test reference platform. "Failures" of this type do not
indicate a problem with Postgres. The file ./regression.diffs
contains the textual differences between the actual test output on
your machine and the "expected" output (which is simply what the
reference system produced). You should carefully examine each
difference listed to see whether it appears to be a significant
issue.

For example,

+ For a i686/Linux-ELF platform, no tests failed since this is
the v6.5.3 regression testing reference platform.

Even if a test result clearly indicates a real failure, it may be
a localized problem that will not affect you. An example is that
the int8 test will fail, producing obviously incorrect output, if
your machine and C compiler do not provide a 64-bit integer data
type (or if they do but configure didn't discover it). This is not
something to worry about unless you need to store 64-bit integers.

Conclusion? If you do see failures, try to understand the nature
of the differences and then decide if those differences will
affect your intended use of Postgres. The regression tests are a
helpful tool, but they may require some study to be useful.

After running the regression tests, type

$ destroydb regression
$ cd /usr/src/pgsql/src/test/regress
$ gmake clean

to recover the disk space used for the tests. (You may want to
save the regression.diffs file in another place before doing
this.)

23. If you haven't already done so, this would be a good time to modify
your computer to do regular maintainence. The following should be done
at regular intervals:

Minimal Backup Procedure

1. Run the SQL command VACUUM. This will clean up your database.

2. Back up your system. (You should probably keep the last few
backups on hand.) Preferably, no one else should be using the
system at the time.

Ideally, the above tasks should be done by a shell script that is run
nightly or weekly by cron. Look at the man page for crontab for a
starting point on how to do this. (If you do it, please e-mail us a
copy of your shell script. We would like to set up our own systems to
do this too.)

24. If you are upgrading an existing system then reinstall your old
database. Type

$ cd
$ psql -e template1 < db.out

If your pre-v6.2 database uses either path or polygon geometric data
types, then you will need to upgrade any columns containing those
types. To do so, type (from within psql)

UPDATE FirstTable SET PathCol = UpgradePath(PathCol);
UPDATE SecondTable SET PathCol = UpgradePath(PathCol);
...
VACUUM;

UpgradePath() checks to see that a path value is consistant with the
old syntax, and will not update a column which fails that examination.
UpgradePoly() cannot verify that a polygon is in fact from an old
syntax, but RevertPoly() is provided to reverse the effects of a
mis-applied upgrade.

25. If you are a new user, you may wish to play with Postgres as described
below.

26. Clean up after yourself. Type

$ rm -rf /usr/src/pgsql_6_5
$ rm -rf /usr/local/pgsql_6_5
# Also delete old database directory tree if it is not in
# /usr/local/pgsql_6_5/data
$ rm ~/postgresql-v6.5.3.tar.gz

27. You will probably want to print out the documentation. If you have a
Postscript printer, or have your machine already set up to accept
Postscript files using a print filter, then to print the User's Guide
simply type

$ cd /usr/local/pgsql/doc
$ gunzip user.ps.tz | lpr

Here is how you might do it if you have Ghostscript on your system and
are writing to a laserjet printer.

$ alias gshp='gs -sDEVICE=laserjet -r300 -dNOPAUSE'
$ export GS_LIB=/usr/share/ghostscript:/usr/share/ghostscript/fonts
$ gunzip user.ps.gz
$ gshp -sOUTPUTFILE=user.hp user.ps
$ gzip user.ps
$ lpr -l -s -r manpage.hp

28. The Postgres team wants to keep Postgres working on all of the
supported platforms. We therefore ask you to let us know if you did or
did not get Postgres to work on you system. Please send a mail message
to pgsql-ports@postgresql.org telling us the following:

o The version of Postgres (v6.5.3, 6.5, beta 990318, etc.).

o Your operating system (i.e. RedHat v5.1 Linux v2.0.34).

o Your hardware (SPARC, i486, etc.).

o Did you compile, install and run the regression tests cleanly? If
not, what source code did you change (i.e. patches you applied,
changes you made, etc.), what tests failed, etc. It is normal to
get many warning when you compile. You do not need to report
these.

29. Now create, access and manipulate databases as desired. Write client
programs to access the database server. In other words, enjoy!

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

Playing with Postgres

After Postgres is installed, a database system is created, a postmaster
daemon is running, and the regression tests have passed, you'll want to see
Postgres do something. That's easy. Invoke the interactive interface to
Postgres, psql:

% psql template1

(psql has to open a particular database, but at this point the only one that
exists is the template1 database, which always exists. We will connect to it
only long enough to create another one and switch to it.)

The response from psql is:

Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL

type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: template1

template1=>

Create the database foo:

template1=> create database foo;
CREATEDB

(Get in the habit of including those SQL semicolons. Psql won't execute
anything until it sees the semicolon or a "\g" and the semicolon is required
to delimit multiple statements.)

Now connect to the new database:

template1=> \c foo
connecting to new database: foo

("slash" commands aren't SQL, so no semicolon. Use \? to see all the slash
commands.)

And create a table:

foo=> create table bar (i int4, c char(16));
CREATE

Then inspect the new table:

foo=> \d bar

Table    = bar
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                | Length|
+----------------------------------+----------------------------------+-------+
| i                                | int4                             |     4 |
| c                                | (bp)char                         |    16 |
+----------------------------------+----------------------------------+-------+

And so on. You get the idea.

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

The Next Step

Questions? Bugs? Feedback? First, read the files in directory
/usr/src/pgsql/doc/. The FAQ in this directory may be particularly useful.

If Postgres failed to compile on your computer then fill out the form in
file /usr/src/pgsql/doc/bug.template and mail it to the location indicated
at the top of the form.

Check on the web site at http://www.postgresql.org For more information on
the various support mailing lists.

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

Porting Notes

Check for any platform-specific FAQs in the doc/ directory of the source
distribution.

--ELM939742588-2735-0_

--ELM939742588-2735-0_--

From bouncefilter Tue Oct 12 12:29:18 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA94075
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 12:29:10 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <4YCB0R6R>; Tue, 12 Oct 1999 18:28:43 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C13E@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Dead CVS directories
Date: Tue, 12 Oct 1999 18:01:16 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

And besides, they will be backed up before removal, right?

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: Tuesday, October 12, 1999 5:09 PM
To: Peter Mount
Cc: Marc G. Fournier; PostgreSQL-development
Subject: Re: [HACKERS] Dead CVS directories

rm?

Well it's a last resort I've used on one of my home cvs

trees, but it

does loose the archived stuff under that directory.

Peter

Yes, but in most cases we don't care. That stuff is very
old. I don't
know of any directory that has no valid files that needs to be saved.
-- 
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 12 12:04:16 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 MAA88583
for <hackers@postgresql.org>; Tue, 12 Oct 1999 12:03:57 -0400 (EDT)
(envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max01-044.enterprise.net
[194.72.195.44])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id RAA16682;
Tue, 12 Oct 1999 17:03:54 +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/GNU) with ESMTP id RAA16784;
Tue, 12 Oct 1999 17:03:46 +0100
Message-Id: <199910121603.RAA16784@linda.lfix.co.uk>
X-Mailer: exmh version 2.0.2 2/24/98 (debian)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Features for next release
In-Reply-To: Message from Bruce Momjian <maillist@candle.pha.pa.us> of "Tue,
12 Oct 1999 09:56:10 EDT." <199910121356.JAA02293@candle.pha.pa.us>
References: <199910121356.JAA02293@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 12 Oct 1999 17:03:46 +0100
From: "Oliver Elphick" <olly@lfix.co.uk>

Bruce Momjian wrote:

Bruce, you asked for a v6.5.3 to be released...anything outstanding that
should prevent me from doing that tomorrow afternoon?

Not that I know of. I was waiting to see if we could come up with other
patches, but I don't think that is going to happen anytime soon.

Will this include a patch to let NUMERIC fields be indexed?

--
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
========================================
"Blessed is the man who makes the LORD his trust,
who does not look to the proud, to those who turn
aside to false gods." Psalms 40:4

From bouncefilter Tue Oct 12 12:05:30 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA88771
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 12:04:52 -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 MAA23497
for pgsql-hackers@postgreSQL.org; Tue, 12 Oct 1999 12:04:27 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121604.MAA23497@candle.pha.pa.us>
Subject: New HISTORY file
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: Tue, 12 Oct 1999 12:04:27 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM939744267-23429-0_
Content-Transfer-Encoding: 7bit

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

Here is a new HISTORY file for 6.5.3.

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

--ELM939744267-23429-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/pgtop/HISTORY"
Content-Transfer-Encoding: 7bit

Chapter 0. Release Notes

Table of Contents
Release 6.5.3
Release 6.5.2
Release 6.5.1
Release 6.5
Release 6.4.2
Release 6.4.1
Release 6.4
Release 6.3.2
Release 6.3.1
Release 6.3
Release 6.2.1
Release 6.2
Release 6.1.1
Release 6.1
Release v6.0
Release v1.09
Release v1.02
Release v1.01
Release v1.0
Postgres95 Beta 0.03
Postgres95 Beta 0.02
Postgres95 Beta 0.01
Timing Results

Release 6.5.3

This is basically a cleanup release for 6.5.2. We have added a new pgaccess
that was missing in 6.5.2, and installed an NT-specific fix.

Migration to v6.5.3

A dump/restore is not required for those running 6.5.*.

Detailed Change List

Updated version of pgaccess 0.98
NT-specific patch

------------------------------------------------------------------------
Release 6.5.2
Release Notes
------------------------------------------------------------------------

Release 6.5.2

This is basically a cleanup release for 6.5.1. We have fixed a variety of
problems reported by 6.5.1 users.

Migration to v6.5.2

A dump/restore is not required for those running 6.5.*.

Detailed Change List

subselect+CASE fixes(Tom)
Add SHLIB_LINK setting for solaris_i386 and solaris_sparc ports(Daren Sefcik)
Fixes for CASE in WHERE join clauses(Tom)
Fix BTScan abort(Tom)
Repair the check for redundant UNIQUE and PRIMARY KEY indices(Thomas)
Improve it so that it checks for multi-column constraints(Thomas)
Fix for Win32 making problem with MB enabled(Hiroki Kataoka)
Allow BSD yacc and bison to compile pl code(Bruce)
Fix SET NAMES working
int8 fixes(Thomas)
Fix vacuum's memory consumption(Hiroshi,Tatsuo)
Reduce the total memory consumption of vacuum(Tom)
Fix for timestamp(datetime)
Rule deparsing bugfixes(Tom)
Fix quoting problems in mkMakefile.tcldefs.sh.in and mkMakefile.tkdefs.sh.in(Tom)
This is to re-use space on index pages freed by vacuum(Vadim)
document -x for pg_dump(Bruce)
Fix for unary operators in rule deparser(Tom)
Comment out FileUnlink of excess segments during mdtruncate()(Tom)
Irix linking fix from Yu Cao yucao@falcon.kla-tencor.com
Repair logic error in LIKE: should not return LIKE_ABORT
when reach end of pattern before end of text(Tom)
Repair incorrect cleanup of heap memory allocation during transaction abort(Tom)
Updated version of pgaccess 0.98

------------------------------------------------------------------------
Release Notes Release 6.5.1
Release Notes
------------------------------------------------------------------------

Release 6.5.1

This is basically a cleanup release for 6.5. We have fixed a variety of
problems reported by 6.5 users.

Migration to v6.5.1

A dump/restore is not required for those running 6.5.

Detailed Change List

Add NT README file
Portability fixes for linux_ppc, Irix, linux_alpha, OpenBSD, alpha
Remove QUERY_LIMIT, use SELECT...LIMIT
Fix for EXPLAIN on inheritance(Tom)
Patch to allow vacuum on multi-segment tables(Hiroshi)
R-Tree optimizer selectivity fix(Tom)
ACL file descriptor leak fix(Atsushi Ogawa)
New expresssion subtree code(Tom)
Avoid disk writes for read-only transactions(Vadim)
Fix for removal of temp tables if last transaction was aborted(Bruce)
Fix to prevent too large tuple from being created(Bruce)
plpgsql fixes
Allow port numbers 32k - 64k(Bruce)
Add ^ precidence(Bruce)
Rename sort files called pg_temp to pg_sorttemp(Bruce)
Fix for microseconds in time values(Tom)
Tutorial source cleanup
New linux_m68k port
Fix for sorting of NULL's in some cases(Tom)
Shared library dependencies fixed (Tom)
Fixed glitches affecting GROUP BY in subselects(Tom)
Fix some compiler warnings (Tomoaki Nishiyama)
Add Win1250 (Czech) support (Pavel Behal)

------------------------------------------------------------------------
Release 6.5.2 Release 6.5
Release Notes
------------------------------------------------------------------------

Release 6.5

This release marks a major step in the development team's mastery of the
source code we inherited from Berkeley. You will see we are now easily
adding major features, thanks to the increasing size and experience of our
world-wide development team.

Here is a brief summary of the more notable changes:

Multi-version concurrency control(MVCC)

This removes our old table-level locking, and replaces it with a
locking system that is superior to most commercial database systems. In
a traditional system, each row that is modified is locked until
committed, preventing reads by other users. MVCC uses the natural
multi-version nature of PostgreSQL to allow readers to continue reading
consistent data during writer activity. Writers continue to use the
compact pg_log transaction system. This is all performed without having
to allocate a lock for every row like traditional database systems. So,
basically, we no longer are restricted by simple table-level locking;
we have something better than row-level locking.

Hot backups from pg_dump

pg_dump takes advantage of the new MVCC features to give a consistant
database dump/backup while the database stays online and available for
queries.

Numeric data type

We now have a true numeric data type, with user-specified precision.

Temporary tables

Temporary tables are guaranteed to have unique names within a database
session, and are destroyed on session exit.

New SQL features

We now have CASE, INTERSECT, and EXCEPT statement support. We have new
LIMIT/OFFSET, SET TRANSACTION ISOLATION LEVEL, SELECT ... FOR UPDATE,
and an improved LOCK TABLE command.

Speedups

We continue to speed up PostgreSQL, thanks to the variety of talents
within our team. We have sped up memory allocation, optimization, table
joins, and row transfer routines.

Ports

We continue to expand our port list, this time including WinNT/ix86 and
NetBSD/arm32.

Interfaces

Most interfaces have new versions, and existing functionality has been
improved.

Documentation

New and updated material is present throughout the documentation. New
FAQs have been contributed for SGI and AIX platforms. The Tutorial has
introductory information on SQL from Stefan Simkovics. For the User's
Guide, there are reference pages covering the postmaster and more
utility programs, and a new appendix contains details on date/time
behavior. The Administrator's Guide has a new chapter on
troubleshooting from Tom Lane. And the Programmer's Guide has a
description of query processing, also from Stefan, and details on
obtaining the Postgres source tree via anonymous CVS and CVSup.

Migration to v6.5

A dump/restore using pg_dump is required for those wishing to migrate data
from any previous release of Postgres. pg_upgrade can not be used to upgrade
to this release because the on-disk structure of the tables has changed
compared to previous releases.

The new Multi-Version Concurrency Control (MVCC) features can give somewhat
different behaviors in multi-user environments. Read and understand the
following section to ensure that your existing applications will give you
the behavior you need.

Multi-Version Concurrency Control

Because readers in 6.5 don't lock data, regardless of transaction isolation
level, data read by one transaction can be overwritten by another. In other
words, if a row is returned by SELECT it doesn't mean that this row really
exists at the time it is returned (i.e. sometime after the statement or
transaction began) nor that the row is protected from being deleted or
updated by concurrent transactions before the current transaction does a
commit or rollback.

To ensure the actual existence of a row and protect it against concurrent
updates one must use SELECT FOR UPDATE or an appropriate LOCK TABLE
statement. This should be taken into account when porting applications from
previous releases of Postgres and other environments.

Keep the above in mind if you are using contrib/refint.* triggers for
referential integrity. Additional technics are required now. One way is to
use LOCK parent_table IN SHARE ROW EXCLUSIVE MODE command if a transaction
is going to update/delete a primary key and use LOCK parent_table IN SHARE
MODE command if a transaction is going to update/insert a foreign key.

Note: Note that if you run a transaction in SERIALIZABLE mode then
you must execute the LOCK commands above before execution of any
DML statement (SELECT/INSERT/DELETE/UPDATE/FETCH/COPY_TO) in the
transaction.

These inconveniences will disappear in the future when the ability to read
dirty (uncommitted) data (regardless of isolation level) and true
referential integrity will be implemented.

Detailed Change List

Bug Fixes
---------
Fix text<->float8 and text<->float4 conversion functions(Thomas)
Fix for creating tables with mixed-case constraints(Billy)
Change exp()/pow() behavior to generate error on underflow/overflow(Jan)
Fix bug in pg_dump -z
Memory overrun cleanups(Tatsuo)
Fix for lo_import crash(Tatsuo)
Adjust handling of data type names to suppress double quotes(Thomas)
Use type coersion for matching columns and DEFAULT(Thomas)
Fix deadlock so it only checks once after one second of sleep(Bruce)
Fixes for aggregates and PL/pgsql(Hiroshi)
Fix for subquery crash(Vadim)
Fix for libpq function PQfnumber and case-insensitive names(Bahman Rafatjoo)
Fix for large object write-in-middle, no extra block, memory consumption(Tatsuo)
Fix for pg_dump -d or -D and quote special characters in INSERT
Repair serious problems with dynahash(Tom)
Fix INET/CIDR portability problems
Fix problem with selectivity error in ALTER TABLE ADD COLUMN(Bruce)
Fix executor so mergejoin of different column types works(Tom)
Fix for Alpha OR selectivity bug
Fix OR index selectivity problem(Bruce)
Fix so \d shows proper length for char()/varchar()(Ryan)
Fix tutorial code(Clark)
Improve destroyuser checking(Oliver)
Fix for Kerberos(Rodney McDuff)
Fix for dropping database while dirty buffers(Bruce)
Fix so sequence nextval() can be case-sensitive(Bruce)
Fix !!= operator
Drop buffers before destroying database files(Bruce)
Fix case where executor evaluates functions twice(Tatsuo)
Allow sequence nextval actions to be case-sensitive(Bruce)
Fix optimizer indexing not working for negative numbers(Bruce)
Fix for memory leak in executor with fjIsNull
Fix for aggregate memory leaks(Erik Riedel)
Allow username containing a dash GRANT permissions
Cleanup of NULL in inet types
Clean up system table bugs(Tom)
Fix problems of PAGER and \? command(Masaaki Sakaida)
Reduce default multi-segment file size limit to 1GB(Peter)
Fix for dumping of CREATE OPERATOR(Tom)
Fix for backward scanning of cursors(Hiroshi Inoue)
Fix for COPY FROM STDIN when using \i(Tom)
Fix for subselect is compared inside an expression(Jan)
Fix handling of error reporting while returning rows(Tom)
Fix problems with reference to array types(Tom,Jan)
Prevent UPDATE SET oid(Jan)
Fix pg_dump so -t option can handle case-sensitive tablenames
Fixes for GROUP BY in special cases(Tom, Jan)
Fix for memory leak in failed queries(Tom)
DEFAULT now supports mixed-case identifiers(Tom)
Fix for multi-segment uses of DROP/RENAME table, indexes(Ole Gjerde)
Disable use of pg_dump with both -o and -d options(Bruce)
Allow pg_dump to properly dump GROUP permissions(Bruce)
Fix GROUP BY in INSERT INTO table SELECT * FROM table2(Jan)
Fix for computations in views(Jan)
Fix for aggregates on array indexes(Tom)
Fix for DEFAULT handles single quotes in value requiring too many quotes
Fix security problem with non-super users importing/exporting large objects(Tom)
Rollback of transaction that creates table cleaned up properly(Tom)
Fix to allow long table and column names to generate proper serial names(Tom)

Enhancements
------------
Add "vacuumdb" utility
Speed up libpq by allocating memory better(Tom)
EXPLAIN all indices used(Tom)
Implement CASE, COALESCE, NULLIF expression(Thomas)
New pg_dump table output format(Constantin)
Add string min()/max() functions(Thomas)
Extend new type coersion techniques to aggregates(Thomas)
New moddatetime contrib(Terry)
Update to pgaccess 0.96(Constantin)
Add routines for single-byte "char" type(Thomas)
Improved substr() function(Thomas)
Improved multi-byte handling(Tatsuo)
Multi-version concurrency control/MVCC(Vadim)
New Serialized mode(Vadim)
Fix for tables over 2gigs(Peter)
New SET TRANSACTION ISOLATION LEVEL(Vadim)
New LOCK TABLE IN ... MODE(Vadim)
Update ODBC driver(Byron)
New NUMERIC data type(Jan)
New SELECT FOR UPDATE(Vadim)
Handle "NaN" and "Infinity" for input values(Jan)
Improved date/year handling(Thomas)
Improved handling of backend connections(Magnus)
New options ELOG_TIMESTAMPS and USE_SYSLOG options for log files(Massimo)
New TCL_ARRAYS option(Massimo)
New INTERSECT and EXCEPT(Stefan)
New pg_index.indisprimary for primary key tracking(D'Arcy)
New pg_dump option to allow dropping of tables before creation(Brook)
Speedup of row output routines(Tom)
New READ COMMITTED isolation level(Vadim)
New TEMP tables/indexes(Bruce)
Prevent sorting if result is already sorted(Jan)
New memory allocation optimization(Jan)
Allow psql to do \p\g(Bruce)
Allow multiple rule actions(Jan)
Added LIMIT/OFFSET functionality(Jan)
Improve optimizer when joining a large number of tables(Bruce)
New intro to SQL from S. Simkovics' Master's Thesis (Stefan, Thomas)
New intro to backend processing from S. Simkovics' Master's Thesis (Stefan)
Improved int8 support(Ryan Bradetich, Thomas, Tom)
New routines to convert between int8 and text/varchar types(Thomas)
New bushy plans, where meta-tables are joined(Bruce)
Enable right-hand queries by default(Bruce)
Allow reliable maximum number of backends to be set at configure time
(--with-maxbackends and postmaster switch (-N backends))(Tom)
GEQO default now 10 tables because of optimizer speedups(Tom)
Allow NULL=Var for MS-SQL portability(Michael, Bruce)
Modify contrib check_primary_key() so either "automatic" or "dependent"(Anand)
Allow psql \d on a view show query(Ryan)
Speedup for LIKE(Bruce)
Ecpg fixes/features, see src/interfaces/ecpg/ChangeLog file(Michael)
JDBC fixes/features, see src/interfaces/jdbc/CHANGELOG(Peter)
Make % operator have precedence like /(Bruce)
Add new postgres -O option to allow system table structure changes(Bruce)
Update contrib/pginterface/findoidjoins script(Tom)
Major speedup in vacuum of deleted rows with indexes(Vadim)
Allow non-SQL functions to run different versions based on arguments(Tom)
Add -E option that shows actual queries sent by \dt and friends(Masaaki Sakaida)
Add version number in startup banners for psql(Masaaki Sakaida)
New contrib/vacuumlo removes large objects not referenced(Peter)
New initialization for table sizes so non-vacuumed tables perform better(Tom)
Improve error messages when a connection is rejected(Tom)
Support for arrays of char() and varchar() fields(Massimo)
Overhaul of hash code to increase reliability and performance(Tom)
Update to PyGreSQL 2.4(D'Arcy)
Changed debug options so -d4 and -d5 produce different node displays(Jan)
New pg_options: pretty_plan, pretty_parse, pretty_rewritten(Jan)
Better optimization statistics for system table access(Tom)
Better handling of non-default block sizes(Massimo)
Improve GEQO optimizer memory consumption(Tom)
UNION now suppports ORDER BY of columns not in target list(Jan)
Major libpq++ improvements(Vince Vielhaber)
pg_dump now uses -z(ACL's) as default(Bruce)
backend cache, memory speedups(Tom)
have pg_dump do everything in one snapshot transaction(Vadim)
fix for large object memory leakage, fix for pg_dumping(Tom)
INET type now respects netmask for comparisons
Make VACUUM ANALYZE only use a readlock(Vadim)
Allow VIEWs on UNIONS(Jan)
pg_dump now can generate consistent snapshots on active databases(Vadim)

Source Tree Changes
-------------------
Improve port matching(Tom)
Portability fixes for SunOS
Add NT/Win32 backend port and enable dynamic loading(Magnus and Daniel Horak)
New port to Cobalt Qube(Mips) running Linux(Tatsuo)
Port to NetBSD/m68k(Mr. Mutsuki Nakajima)
Port to NetBSD/sun3(Mr. Mutsuki Nakajima)
Port to NetBSD/macppc(Toshimi Aoki)
Fix for tcl/tk configuration(Vince)
Removed CURRENT keyword for rule queries(Jan)
NT dynamic loading now works(Daniel Horak)
Add ARM32 support(Andrew McMurry)
Better support for HPUX 11 and Unixware
Improve file handling to be more uniform, prevent file descriptor leak(Tom)
New install commands for plpgsql(Jan)

------------------------------------------------------------------------
Release 6.5.1 Release 6.4.2
Release Notes
------------------------------------------------------------------------

Release 6.4.2

The 6.4.1 release was improperly packaged. This also has one additional bug
fix.

Migration to v6.4.2

A dump/restore is not required for those running 6.4.*.

Detailed Change List

Fix for datetime constant problem on some platforms(Thomas)

------------------------------------------------------------------------
Release 6.5 Release 6.4.1
Release Notes
------------------------------------------------------------------------

Release 6.4.1

This is basically a cleanup release for 6.4. We have fixed a variety of
problems reported by 6.4 users.

Migration to v6.4.1

A dump/restore is not required for those running 6.4.

Detailed Change List

Add pg_dump -N flag to force double quotes around identifiers. This is
the default(Thomas)
Fix for NOT in where clause causing crash(Bruce)
EXPLAIN VERBOSE coredump fix(Vadim)
Fix shared-library problems on Linux
Fix test for table existance to allow mixed-case and whitespace in
the table name(Thomas)
Fix a couple of pg_dump bugs
Configure matches template/.similar entries better(Tom)
Change builtin function names from SPI_* to spi_*
OR WHERE clause fix(Vadim)
Fixes for mixed-case table names(Billy)
contrib/linux/postgres.init.csh/sh fix(Thomas)
libpq memory overrun fix
SunOS fixes(Tom)
Change exp() behavior to generate error on underflow(Thomas)
pg_dump fixes for memory leak, inheritance constraints, layout change
update pgaccess to 0.93
Fix prototype for 64-bit platforms
Multi-byte fixes(Tatsuo)
New ecpg man page
Fix memory overruns(Tatsuo)
Fix for lo_import() crash(Bruce)
Better search for install program(Tom)
Timezone fixes(Tom)
HPUX fixes(Tom)
Use implicit type coersion for matching DEFAULT values(Thomas)
Add routines to help with single-byte (internal) character type(Thomas)
Compilation of libpq for Win32 fixes(Magnus)
Upgrade to PyGreSQL 2.2(D'Arcy)

------------------------------------------------------------------------
Release 6.4.2 Release 6.4
Release Notes
------------------------------------------------------------------------

Release 6.4

There are many new features and improvements in this release. Thanks to our
developers and maintainers, nearly every aspect of the system has received
some attention since the previous release. Here is a brief, incomplete
summary:

* Views and rules are now functional thanks to extensive new code in the
rewrite rules system from Jan Wieck. He also wrote a chapter on it for
the Programmer's Guide.

* Jan also contributed a second procedural language, PL/pgSQL, to go with
the original PL/pgTCL procedural language he contributed last release.

* We have optional multiple-byte character set support from Tatsuo Iishi
to complement our existing locale support.

* Client/server communications has been cleaned up, with better support
for asynchronous messages and interrupts thanks to Tom Lane.

* The parser will now perform automatic type coersion to match arguments
to available operators and functions, and to match columns and
expressions with target columns. This uses a generic mechanism which
supports the type extensibility features of Postgres. There is a new
chapter in the User's Guide which covers this topic.

* Three new data types have been added. Two types, inet and cidr, support
various forms of IP network, subnet, and machine addressing. There is
now an 8-byte integer type available on some platforms. See the chapter
on data types in the User's Guide for details. A fourth type, serial,
is now supported by the parser as an amalgam of the int4 type, a
sequence, and a unique index.

* Several more SQL92-compatible syntax features have been added,
including INSERT DEFAULT VALUES

* The automatic configuration and installation system has received some
attention, and should be more robust for more platforms than it has
ever been.

Migration to v6.4

A dump/restore using pg_dump or pg_dumpall is required for those wishing to
migrate data from any previous release of Postgres.

Detailed Change List

Bug Fixes
---------
Fix for a tiny memory leak in PQsetdb/PQfinish(Bryan)
Remove char2-16 data types, use char/varchar(Darren)
Pqfn not handles a NOTICE message(Anders)
Reduced busywaiting overhead for spinlocks with many backends (dg)
Stuck spinlock detection (dg)
Fix up "ISO-style" timespan decoding and encoding(Thomas)
Fix problem with table drop after rollback of transaction(Vadim)
Change error message and remove non-functional update message(Vadim)
Fix for COPY array checking
Fix for SELECT 1 UNION SELECT NULL
Fix for buffer leaks in large object calls(Pascal)
Change owner from oid to int4 type(Bruce)
Fix a bug in the oracle compatibility functions btrim() ltrim() and rtrim()
Fix for shared invalidation cache overflow(Massimo)
Prevent file descriptor leaks in failed COPY's(Bruce)
Fix memory leak in libpgtcl's pg_select(Constantin)
Fix problems with username/passwords over 8 characters(Tom)
Fix problems with handling of asynchronous NOTIFY in backend(Tom)
Fix of many bad system table entries(Tom)

Enhancements
------------
Upgrade ecpg and ecpglib,see src/interfaces/ecpc/ChangeLog(Michael)
Show the index used in an EXPLAIN(Zeugswetter)
EXPLAIN invokes rule system and shows plan(s) for rewritten queries(Jan)
Multi-byte awareness of many data types and functions, via configure(Tatsuo)
New configure --with-mb option(Tatsuo)
New initdb --pgencoding option(Tatsuo)
New createdb -E multibyte option(Tatsuo)
Select version(); now returns PostgreSQL version(Jeroen)
Libpq now allows asynchronous clients(Tom)
Allow cancel from client of backend query(Tom)
Psql now cancels query with Control-C(Tom)
Libpq users need not issue dummy queries to get NOTIFY messages(Tom)
NOTIFY now sends sender's PID, so you can tell whether it was your own(Tom)
PGresult struct now includes associated error message, if any(Tom)
Define "tz_hour" and "tz_minute" arguments to date_part()(Thomas)
Add routines to convert between varchar and bpchar(Thomas)
Add routines to allow sizing of varchar and bpchar into target columns(Thomas)
Add bit flags to support timezonehour and minute in data retrieval(Thomas)
Allow more variations on valid floating point numbers (e.g. ".1", "1e6")(Thomas)
Fixes for unary minus parsing with leading spaces(Thomas)
Implement TIMEZONE_HOUR, TIMEZONE_MINUTE per SQL92 specs(Thomas)
Check for and properly ignore FOREIGN KEY column constraints(Thomas)
Define USER as synonym for CURRENT_USER per SQL92 specs(Thomas)
Enable HAVING clause but no fixes elsewhere yet.
Make "char" type a synonym for "char(1)" (actually implemented as bpchar)(Thomas)
Save string type if specified for DEFAULT clause handling(Thomas)
Coerce operations involving different data types(Thomas)
Allow some index use for columns of different types(Thomas)
Add capabilities for automatic type conversion(Thomas)
Cleanups for large objects, so file is truncated on open(Peter)
Readline cleanups(Tom)
Allow psql \f \ to make spaces as delimiter(Bruce)
Pass pg_attribute.atttypmod to the frontend for column field lengths(Tom,Bruce)
Msql compatibility library in /contrib(Aldrin)
Remove the requirement that ORDER/GROUP BY clause identifiers be
included in the target list(David)
Convert columns to match columns in UNION clauses(Thomas)
Remove fork()/exec() and only do fork()(Bruce)
Jdbc cleanups(Peter)
Show backend status on ps command line(only works on some platforms)(Bruce)
Pg_hba.conf now has a sameuser option in the database field
Make lo_unlink take oid param, not int4
New DISABLE_COMPLEX_MACRO for compilers that can't handle our macros(Bruce)
Libpgtcl now handles NOTIFY as a Tcl event, need not send dummy queries(Tom)
libpgtcl cleanups(Tom)
Add -error option to libpgtcl's pg_result command(Tom)
New locale patch, see docs/README/locale(Oleg)
Fix for pg_dump so CONSTRAINT and CHECK syntax is correct(ccb)
New contrib/lo code for large object orphan removal(Peter)
New psql command "SET CLIENT_ENCODING TO 'encoding'" for multi-bytes
feature, see /doc/README.mb(Tatsuo)
/contrib/noupdate code to revoke update permission on a column
Libpq can now be compiled on win32(Magnus)
Add PQsetdbLogin() in libpq
New 8-byte integer type, checked by configure for OS support(Thomas)
Better support for quoted table/column names(Thomas)
Surround table and column names with double-quotes in pg_dump(Thomas)
PQreset() now works with passwords(Tom)
Handle case of GROUP BY target list column number out of range(David)
Allow UNION in subselects
Add auto-size to screen to \d? commands(Bruce)
Use UNION to show all \d? results in one query(Bruce)
Add \d? field search feature(Bruce)
Pg_dump issues fewer \connect requests(Tom)
Make pg_dump -z flag work better, document it in manual page(Tom)
Add HAVING clause with full support for subselects and unions(Stephan)
Full text indexing routines in contrib/fulltextindex(Maarten)
Transaction ids now stored in shared memory(Vadim)
New PGCLIENTENCODING when issuing COPY command(Tatsuo)
Support for SQL92 syntax "SET NAMES"(Tatsuo)
Support for LATIN2-5(Tatsuo)
Add UNICODE regression test case(Tatsuo)
Lock manager cleanup, new locking modes for LLL(Vadim)
Allow index use with OR clauses(Bruce)
Allows "SELECT NULL ORDER BY 1;"
Explain VERBOSE prints the plan, and now pretty-prints the plan to
the postmaster log file(Bruce)
Add Indices display to \d command(Bruce)
Allow GROUP BY on functions(David)
New pg_class.relkind for large objects(Bruce)
New way to send libpq NOTICE messages to a different location(Tom)
New \w write command to psql(Bruce)
New /contrib/findoidjoins scans oid columns to find join relationships(Bruce)
Allow binary-compatible indices to be considered when checking for valid
indices for restriction clauses containing a constant(Thomas)
New ISBN/ISSN code in /contrib/isbn_issn
Allow NOT LIKE, IN, NOT IN, BETWEEN, and NOT BETWEEN constraint(Thomas)
New rewrite system fixes many problems with rules and views(Jan)
* Rules on relations work
* Event qualifications on insert/update/delete work
* New OLD variable to reference CURRENT, CURRENT will be remove in future
* Update rules can reference NEW and OLD in rule qualifications/actions
* Insert/update/delete rules on views work
* Multiple rule actions are now supported, surrounded by parentheses
* Regular users can create views/rules on tables they have RULE permits
* Rules and views inherit the permissions on the creator
* No rules at the column level
* No UPDATE NEW/OLD rules
* New pg_tables, pg_indexes, pg_rules and pg_views system views
* Only a single action on SELECT rules
* Total rewrite overhaul, perhaps for 6.5
* handle subselects
* handle aggregates on views
* handle insert into select from view works
System indexes are now multi-key(Bruce)
Oidint2, oidint4, and oidname types are removed(Bruce)
Use system cache for more system table lookups(Bruce)
New backend programming language PL/pgSQL in backend/pl(Jan)
New SERIAL data type, auto-creates sequence/index(Thomas)
Enable assert checking without a recompile(Massimo)
User lock enhancements(Massimo)
New setval() command to set sequence value(Massimo)
Auto-remove unix socket file on startup if no postmaster running(Massimo)
Conditional trace package(Massimo)
New UNLISTEN command(Massimo)
Psql and libpq now compile under win32 using win32.mak(Magnus)
Lo_read no longer stores trailing NULL(Bruce)
Identifiers are now truncated to 31 characters internally(Bruce)
Createuser options now availble on the command line
Code for 64-bit integer supported added, configure tested, int8 type(Thomas)
Prevent file descriptor leaf from failed COPY(Bruce)
New pg_upgrade command(Bruce)
Updated /contrib directories(Massimo)
New CREATE TABLE DEFAULT VALUES statement available(Thomas)
New INSERT INTO TABLE DEFAULT VALUES statement available(Thomas)
New DECLARE and FETCH feature(Thomas)
libpq's internal structures now not exported(Tom)
Allow up to 8 key indexes(Bruce)
Remove ARCHIVE keyword, that is no longer used(Thomas)
pg_dump -n flag to supress quotes around indentifiers
disable system columns for views(Jan)
new INET and CIDR types for network addresses(TomH, Paul)
no more double quotes in psql output
pg_dump now dumps views(Terry)
new SET QUERY_LIMIT(Tatsuo,Jan)

Source Tree Changes
-------------------
/contrib cleanup(Jun)
Inline some small functions called for every row(Bruce)
Alpha/linux fixes
Hp/UX cleanups(Tom)
Multi-byte regression tests(Soonmyung.)
Remove --disabled options from configure
Define PGDOC to use POSTGRESDIR by default
Make regression optional
Remove extra braces code to pgindent(Bruce)
Add bsdi shared library support(Bruce)
New --without-CXX support configure option(Brook)
New FAQ_CVS
Update backend flowchart in tools/backend(Bruce)
Change atttypmod from int16 to int32(Bruce, Tom)
Getrusage() fix for platforms that do not have it(Tom)
Add PQconnectdb, PGUSER, PGPASSWORD to libpq man page
NS32K platform fixes(Phil Nelson, John Buller)
Sco 7/UnixWare 2.x fixes(Billy,others)
Sparc/Solaris 2.5 fixes(Ryan)
Pgbuiltin.3 is obsolete, move to doc files(Thomas)
Even more documention(Thomas)
Nextstep support(Jacek)
Aix support(David)
pginterface manual page(Bruce)
shared libraries all have version numbers
merged all OS-specific shared library defines into one file
smarter TCL/TK configuration checking(Billy)
smarter perl configuration(Brook)
configure uses supplied install-sh if no install script found(Tom)
new Makefile.shlib for shared library configuration(Tom)

------------------------------------------------------------------------
Release 6.4.1 Release 6.3.2
Release Notes
------------------------------------------------------------------------

Release 6.3.2

This is a bugfix release for 6.3.x. Refer to the release notes for v6.3 for
a more complete summary of new features.

Summary:

* Repairs automatic configuration support for some platforms, including
Linux, from breakage inadvertently introduced in v6.3.1.

* Correctly handles function calls on the left side of BETWEEN and LIKE
clauses.

A dump/restore is NOT required for those running 6.3 or 6.3.1. A 'make
distclean', 'make', and 'make install' is all that is required. This last
step should be performed while the postmaster is not running. You should
re-link any custom applications that use Postgres libraries.

For upgrades from pre-v6.3 installations, refer to the installation and
migration instructions for v6.3.

Detailed Change List

Changes
-------
Configure detection improvements for tcl/tk(Brook Milligan, Alvin)
Manual page improvements(Bruce)
BETWEEN and LIKE fix(Thomas)
fix for psql \connect used by pg_dump(Oliver Elphick)
New odbc driver
pgaccess, version 0.86
qsort removed, now uses libc version, cleanups(Jeroen)
fix for buffer over-runs detected(Maurice Gittens)
fix for buffer overrun in libpgtcl(Randy Kunkee)
fix for UNION with DISTINCT or ORDER BY(Bruce)
gettimeofday configure check(Doug Winterburn)
Fix "indexes not used" bug(Vadim)
docs additions(Thomas)
Fix for backend memory leak(Bruce)
libreadline cleanup(Erwan MAS)
Remove DISTDIR(Bruce)
Makefile dependency cleanup(Jeroen van Vianen)
ASSERT fixes(Bruce)

------------------------------------------------------------------------
Release 6.4 Release 6.3.1
Release Notes
------------------------------------------------------------------------

Release 6.3.1

Summary:

* Additional support for multi-byte character sets.

* Repair byte ordering for mixed-endian clients and servers.

* Minor updates to allowed SQL syntax.

* Improvements to the configuration autodetection for installation.

A dump/restore is NOT required for those running 6.3. A 'make distclean',
'make', and 'make install' is all that is required. This last step should be
performed while the postmaster is not running. You should re-link any custom
applications that use Postgres libraries.

For upgrades from pre-v6.3 installations, refer to the installation and
migration instructions for v6.3.

Detailed Change List

Changes
-------
ecpg cleanup/fixes, now version 1.1(Michael Meskes)
pg_user cleanup(Bruce)
large object fix for pg_dump and tclsh (alvin)
LIKE fix for multiple adjacent underscores
fix for redefining builtin functions(Thomas)
ultrix4 cleanup
upgrade to pg_access 0.83
updated CLUSTER manual page
multi-byte character set support, see doc/README.mb(Tatsuo)
configure --with-pgport fix
pg_ident fix
big-endian fix for backend communications(Kataoka)
SUBSTR() and substring() fix(Jan)
several jdbc fixes(Peter)
libpgtcl improvements, see libptcl/README(Randy Kunkee)
Fix for "Datasize = 0" error(Vadim)
Prevent \do from wrapping(Bruce)
Remove duplicate Russian character set entries
Sunos4 cleanup
Allow optional TABLE keyword in LOCK and SELECT INTO(Thomas)
CREATE SEQUENCE options to allow a negative integer(Thomas)
Add "PASSWORD" as an allowed column identifier(Thomas)
Add checks for UNION target fields(Bruce)
Fix Alpha port(Dwayne Bailey)
Fix for text arrays containing quotes(Doug Gibson)
Solaris compile fix(Albert Chin-A-Young)
Better identify tcl and tk libs and includes(Bruce)

------------------------------------------------------------------------
Release 6.3.2 Release 6.3
Release Notes
------------------------------------------------------------------------

Release 6.3

There are many new features and improvements in this release. Here is a
brief, incomplete summary:

* Many new SQL features, including full SQL92 subselect capability
(everything is here but target-list subselects).

* Support for client-side environment variables to specify time zone and
date style.

* Socket interface for client/server connection. This is the default now
so you may need to start postmaster with the "-i" flag.

* Better password authorization mechanisms. Default table permissions
have changed.

* Old-style "time travel" has been removed. Performance has been
improved.

Note: Bruce Momjian wrote the following notes to introduce the new
release.

There are some general 6.3 issues that I want to mention. These are only the
big items that can not be described in one sentence. A review of the
detailed changes list is still needed.

First, we now have subselects. Now that we have them, I would like to
mention that without subselects, SQL is a very limited language. Subselects
are a major feature, and you should review your code for places where
subselects provide a better solution for your queries. I think you will find
that there are more uses for subselects than you may think. Vadim has put us
on the big SQL map with subselects, and fully functional ones too. The only
thing you can't do with subselects is to use them in the target list.

Second, 6.3 uses unix domain sockets rather than TCP/IP by default. To
enable connections from other machines, you have to use the new postmaster
-i option, and of course edit pg_hba.conf. Also, for this reason, the format
of pg_hba.conf has changed.

Third, char() fields will now allow faster access than varchar() or text.
Specifically, the text and varchar() have a penalty for access to any
columns after the first column of this type. char() used to also have this
access penalty, but it no longer does. This may suggest that you redesign
some of your tables, especially if you have short character columns that you
have defined as varchar() or text. This and other changes make 6.3 even
faster than earlier releases.

We now have passwords definable independent of any Unix file. There are new
SQL USER commands. See the pg_hba.conf manual page for more information.
There is a new table, pg_shadow, which is used to store user information and
user passwords, and it by default only SELECT-able by the postgres
super-user. pg_user is now a view of pg_shadow, and is SELECT-able by
PUBLIC. You should keep using pg_user in your application without changes.

User-created tables now no longer have SELECT permission to PUBLIC by
default. This was done because the ANSI standard requires it. You can of
course GRANT any permissions you want after the table is created. System
tables continue to be SELECT-able by PUBLIC.

We also have real deadlock detection code. No more sixty-second timeouts.
And the new locking code implements a FIFO better, so there should be less
resource starvation during heavy use.

Many complaints have been made about inadequate documenation in previous
releases. Thomas has put much effort into many new manuals for this release.
Check out the doc/ directory.

For performance reasons, time travel is gone, but can be implemented using
triggers (see pgsql/contrib/spi/README). Please check out the new \d command
for types, operators, etc. Also, views have their own permissions now, not
based on the underlying tables, so permissions on them have to be set
separately. Check /pgsql/interfaces for some new ways to talk to Postgres.

This is the first release that really required an explanation for existing
users. In many ways, this was necessary because the new release removes many
limitations, and the work-arounds people were using are no longer needed.

Migration to v6.3

A dump/restore using pg_dump or pg_dumpall is required for those wishing to
migrate data from any previous release of Postgres.

Detailed Change List

Bug Fixes
---------
Fix binary cursors broken by MOVE implementation(Vadim)
Fix for tcl library crash(Jan)
Fix for array handling, from Gerhard Hintermayer
Fix acl error, and remove duplicate pqtrace(Bruce)
Fix psql \e for empty file(Bruce)
Fix for textcat on varchar() fields(Bruce)
Fix for DBT Sendproc (Zeugswetter Andres)
Fix vacuum analyze syntax problem(Bruce)
Fix for international identifiers(Tatsuo)
Fix aggregates on inherited tables(Bruce)
Fix substr() for out-of-bounds data
Fix for select 1=1 or 2=2, select 1=1 and 2=2, and select sum(2+2)(Bruce)
Fix notty output to show status result. -q option still turns it off(Bruce)
Fix for count(*), aggs with views and multiple tables and sum(3)(Bruce)
Fix cluster(Bruce)
Fix for PQtrace start/stop several times(Bruce)
Fix a variety of locking problems like newer lock waiters getting
lock before older waiters, and having readlock people not share
locks if a writer is waiting for a lock, and waiting writers not
getting priority over waiting readers(Bruce)
Fix crashes in psql when executing queries from external files(James)
Fix problem with multiple order by columns, with the first one having
NULL values(Jeroen)
Use correct hash table support functions for float8 and int4(Thomas)
Re-enable JOIN= option in CREATE OPERATOR statement (Thomas)
Change precedence for boolean operators to match expected behavior(Thomas)
Generate elog(ERROR) on over-large integer(Bruce)
Allow multiple-argument functions in constraint clauses(Thomas)
Check boolean input literals for 'true','false','yes','no','1','0'
and throw elog(ERROR) if unrecognized(Thomas)
Major large objects fix
Fix for GROUP BY showing duplicates(Vadim)
Fix for index scans in MergeJion(Vadim)

Enhancements
------------
Subselects with EXISTS, IN, ALL, ANY keywords (Vadim, Bruce, Thomas)
New User Manual(Thomas, others)
Speedup by inlining some frequently-called functions
Real deadlock detection, no more timeouts(Bruce)
Add SQL92 "constants" CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP,
CURRENT_USER(Thomas)
Modify constraint syntax to be SQL92-compliant(Thomas)
Implement SQL92 PRIMARY KEY and UNIQUE clauses using indices(Thomas)
Recognize SQL92 syntax for FOREIGN KEY. Throw elog notice(Thomas)
Allow NOT NULL UNIQUE constraint clause (each allowed separately before)(Thomas)
Allow Postgres-style casting ("::") of non-constants(Thomas)
Add support for SQL3 TRUE and FALSE boolean constants(Thomas)
Support SQL92 syntax for IS TRUE/IS FALSE/IS NOT TRUE/IS NOT FALSE(Thomas)
Allow shorter strings for boolean literals (e.g. "t", "tr", "tru")(Thomas)
Allow SQL92 delimited identifiers(Thomas)
Implement SQL92 binary and hexadecimal string decoding (b'10' and x'1F')(Thomas)
Support SQL92 syntax for type coercion of literal strings
(e.g. "DATETIME 'now'")(Thomas)
Add conversions for int2, int4, and OID types to and from text(Thomas)
Use shared lock when building indices(Vadim)
Free memory allocated for an user query inside transaction block after
this query is done, was turned off in <= 6.2.1(Vadim)
New SQL statement CREATE PROCEDURAL LANGUAGE(Jan)
New Postgres Procedural Language (PL) backend interface(Jan)
Rename pg_dump -H option to -h(Bruce)
Add Java support for passwords, European dates(Peter)
Use indices for LIKE and ~, !~ operations(Bruce)
Add hash functions for datetime and timespan(Thomas)
Time Travel removed(Vadim, Bruce)
Add paging for \d and \z, and fix \i(Bruce)
Add Unix domain socket support to backend and to frontend library(Goran)
Implement CREATE DATABASE/WITH LOCATION and initlocation utility(Thomas)
Allow more SQL92 and/or Postgres reserved words as column identifiers(Thomas)
Augment support for SQL92 SET TIME ZONE...(Thomas)
SET/SHOW/RESET TIME ZONE uses TZ backend environment variable(Thomas)
Implement SET keyword = DEFAULT and SET TIME ZONE DEFAULT(Thomas)
Enable SET TIME ZONE using TZ environment variable(Thomas)
Add PGDATESTYLE environment variable to frontend and backend initialization(Thomas)
Add PGTZ, PGCOSTHEAP, PGCOSTINDEX, PGRPLANS, PGGEQO
frontend library initialization environment variables(Thomas)
Regression tests time zone automatically set with "setenv PGTZ PST8PDT"(Thomas)
Add pg_description table for info on tables, columns, operators, types, and
aggregates(Bruce)
Increase 16 char limit on system table/index names to 32 characters(Bruce)
Rename system indices(Bruce)
Add 'GERMAN' option to SET DATESTYLE(Thomas)
Define an "ISO-style" timespan output format with "hh:mm:ss" fields(Thomas)
Allow fractional values for delta times (e.g. '2.5 days')(Thomas)
Validate numeric input more carefully for delta times(Thomas)
Implement day of year as possible input to date_part()(Thomas)
Define timespan_finite() and text_timespan() functions(Thomas)
Remove archive stuff(Bruce)
Allow for a pg_password authentication database that is separate from
the system password file(Todd)
Dump ACLs, GRANT, REVOKE permissions(Matt)
Define text, varchar, and bpchar string length functions(Thomas)
Fix Query handling for inheritance, and cost computations(Bruce)
Implement CREATE TABLE/AS SELECT (alternative to SELECT/INTO)(Thomas)
Allow NOT, IS NULL, IS NOT NULL in constraints(Thomas)
Implement UNIONs for SELECT(Bruce)
Add UNION, GROUP, DISTINCT to INSERT(Bruce)
varchar() stores only necessary bytes on disk(Bruce)
Fix for BLOBs(Peter)
Mega-Patch for JDBC...see README_6.3 for list of changes(Peter)
Remove unused "option" from PQconnectdb()
New LOCK command and lock manual page describing deadlocks(Bruce)
Add new psql \da, \dd, \df, \do, \dS, and \dT commands(Bruce)
Enhance psql \z to show sequences(Bruce)
Show NOT NULL and DEFAULT in psql \d table(Bruce)
New psql .psqlrc file startup(Andrew)
Modify sample startup script in contrib/linux to show syslog(Thomas)
New types for IP and MAC addresses in contrib/ip_and_mac(TomH)
Unix system time conversions with date/time types in contrib/unixdate(Thomas)
Update of contrib stuff(Massimo)
Add Unix socket support to DBD::Pg(Goran)
New python interface (PyGreSQL 2.0)(D'Arcy)
New frontend/backend protocol has a version number, network byte order(Phil)
Security features in pg_hba.conf enhanced and documented, many cleanups(Phil)
CHAR() now faster access than VARCHAR() or TEXT
ecpg embedded SQL preprocessor
Reduce system column overhead(Vadmin)
Remove pg_time table(Vadim)
Add pg_type attribute to identify types that need length (bpchar, varchar)
Add report of offending line when COPY command fails
Allow VIEW permissions to be set separately from the underlying tables.
For security, use GRANT/REVOKE on views as appropriate(Jan)
Tables now have no default GRANT SELECT TO PUBLIC. You must
explicitly grant such permissions.
Clean up tutorial examples(Darren)

Source Tree Changes
-------------------
Add new html development tools, and flow chart in /tools/backend
Fix for SCO compiles
Stratus computer port Robert Gillies
Added support for shlib for BSD44_derived & i386_solaris
Make configure more automated(Brook)
Add script to check regression test results
Break parser functions into smaller files, group together(Bruce)
Rename heap_create to heap_create_and_catalog, rename heap_creatr
to heap_create()(Bruce)
Sparc/Linux patch for locking(TomS)
Remove PORTNAME and reorganize port-specific stuff(Marc)
Add optimizer README file(Bruce)
Remove some recursion in optimizer and clean up some code there(Bruce)
Fix for NetBSD locking(Henry)
Fix for libptcl make(Tatsuo)
AIX patch(Darren)
Change IS TRUE, IS FALSE, ... to expressions using "=" rather than
function calls to istrue() or isfalse() to allow optimization(Thomas)
Various fixes NetBSD/Sparc related(TomH)
Alpha linux locking(Travis,Ryan)
Change elog(WARN) to elog(ERROR)(Bruce)
FAQ for FreeBSD(Marc)
Bring in the PostODBC source tree as part of our standard distribution(Marc)
A minor patch for HP/UX 10 vs 9(Stan)
New pg_attribute.atttypmod for type-specific info like varchar length(Bruce)
Unixware patches(Billy)
New i386 'lock' for spin lock asm(Billy)
Support for multiplexed backends is removed
Start an OpenBSD port
Start an AUX port
Start a Cygnus port
Add string functions to regression suite(Thomas)
Expand a few function names formerly truncated to 16 characters(Thomas)
Remove un-needed malloc() calls and replace with palloc()(Bruce)

------------------------------------------------------------------------
Release 6.3.1 Release 6.2.1
Release Notes
------------------------------------------------------------------------

Release 6.2.1

v6.2.1 is a bug-fix and usability release on v6.2.

Summary:

* Allow strings to span lines, per SQL92.

* Include example trigger function for inserting user names on table
updates.

This is a minor bug-fix release on v6.2. For upgrades from pre-v6.2 systems,
a full dump/reload is required. Refer to the v6.2 release notes for
instructions.

Migration from v6.2 to v6.2.1

This is a minor bug-fix release. A dump/reload is not required from v6.2,
but is required from any release prior to v6.2.

In upgrading from v6.2, if you choose to dump/reload you will find that
avg(money) is now calculated correctly. All other bug fixes take effect upon
updating the executables.

Another way to avoid dump/reload is to use the following SQL command from
psql to update the existing system table:

update pg_aggregate set aggfinalfn = 'cash_div_flt8'
where aggname = 'avg' and aggbasetype = 790;

This will need to be done to every existing database, including template1.

Detailed Change List

Changes in this release
-----------------------
Allow TIME and TYPE column names(Thomas)
Allow larger range of true/false as boolean values(Thomas)
Support output of "now" and "current"(Thomas)
Handle DEFAULT with INSERT of NULL properly(Vadim)
Fix for relation reference counts problem in buffer manager(Vadim)
Allow strings to span lines, like ANSI(Thomas)
Fix for backward cursor with ORDER BY(Vadim)
Fix avg(cash) computation(Thomas)
Fix for specifying a column twice in ORDER/GROUP BY(Vadim)
Documented new libpq function to return affected rows, PQcmdTuples(Bruce)
Trigger function for inserting user names for INSERT/UPDATE(Brook Milligan)

------------------------------------------------------------------------
Release 6.3 Release 6.2
Release Notes
------------------------------------------------------------------------

Release 6.2

A dump/restore is required for those wishing to migrate data from previous
releases of Postgres.

Migration from v6.1 to v6.2

This migration requires a complete dump of the 6.1 database and a restore of
the database in 6.2.

Note that the pg_dump and pg_dumpall utility from 6.2 should be used to dump
the 6.1 database.

Migration from v1.x to v6.2

Those migrating from earlier 1.* releases should first upgrade to 1.09
because the COPY output format was improved from the 1.02 release.

Detailed Change List

Bug Fixes
---------
Fix problems with pg_dump for inheritance, sequences, archive tables(Bruce)
Fix compile errors on overflow due to shifts, unsigned, and bad prototypes
from Solaris(Diab Jerius)
Fix bugs in geometric line arithmetic (bad intersection calculations)(Thomas)
Check for geometric intersections at endpoints to avoid rounding ugliness(Thomas)
Catch non-functional delete attempts(Vadim)
Change time function names to be more consistent(Michael Reifenberg)
Check for zero divides(Michael Reifenberg)
Fix very old bug which made tuples changed/inserted by a commnd
visible to the command itself (so we had multiple update of
updated tuples, etc)(Vadim)
Fix for SELECT null, 'fail' FROM pg_am (Patrick)
SELECT NULL as EMPTY_FIELD now allowed(Patrick)
Remove un-needed signal stuff from contrib/pginterface
Fix OR (where x != 1 or x isnull didn't return tuples with x NULL) (Vadim)
Fix time_cmp function (Vadim)
Fix handling of functions with non-attribute first argument in
WHERE clauses (Vadim)
Fix GROUP BY when order of entries is different from order
in target list (Vadim)
Fix pg_dump for aggregates without sfunc1 (Vadim)

Enhancements
------------
Default genetic optimizer GEQO parameter is now 8(Bruce)
Allow use parameters in target list having aggregates in functions(Vadim)
Added JDBC driver as an interface(Adrian & Peter)
pg_password utility
Return number of tuples inserted/affected by INSERT/UPDATE/DELETE etc.(Vadim)
Triggers implemented with CREATE TRIGGER (SQL3)(Vadim)
SPI (Server Programming Interface) allows execution of queries inside
C-functions (Vadim)
NOT NULL implemented (SQL92)(Robson Paniago de Miranda)
Include reserved words for string handling, outer joins, and unions(Thomas)
Implement extended comments ("/* ... */") using exclusive states(Thomas)
Add "//" single-line comments(Bruce)
Remove some restrictions on characters in operator names(Thomas)
DEFAULT and CONSTRAINT for tables implemented (SQL92)(Vadim & Thomas)
Add text concatenation operator and function (SQL92)(Thomas)
Support WITH TIME ZONE syntax (SQL92)(Thomas)
Support INTERVAL unit TO unit syntax (SQL92)(Thomas)
Define types DOUBLE PRECISION, INTERVAL, CHARACTER,
and CHARACTER VARYING (SQL92)(Thomas)
Define type FLOAT(p) and rudimentary DECIMAL(p,s), NUMERIC(p,s) (SQL92)(Thomas)
Define EXTRACT(), POSITION(), SUBSTRING(), and TRIM() (SQL92)(Thomas)
Define CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP (SQL92)(Thomas)
Add syntax and warnings for UNION, HAVING, INNER and OUTER JOIN (SQL92)(Thomas)
Add more reserved words, mostly for SQL92 compliance(Thomas)
Allow hh:mm:ss time entry for timespan/reltime types(Thomas)
Add center() routines for lseg, path, polygon(Thomas)
Add distance() routines for circle-polygon, polygon-polygon(Thomas)
Check explicitly for points and polygons contained within polygons
using an axis-crossing algorithm(Thomas)
Add routine to convert circle-box(Thomas)
Merge conflicting operators for different geometric data types(Thomas)
Replace distance operator "<===>" with "<->"(Thomas)
Replace "above" operator "!^" with ">^" and "below" operator "!|" with "<^"(Thomas)
Add routines for text trimming on both ends, substring, and string position(Thomas)
Added conversion routines circle(box) and poly(circle)(Thomas)
Allow internal sorts to be stored in memory rather than in files(Bruce & Vadim)
Allow functions and operators on internally-identical types to succeed(Bruce)
Speed up backend startup after profiling analysis(Bruce)
Inline frequently called functions for performance(Bruce)
Reduce open() calls(Bruce)
psql: Add PAGER for \h and \?,\C fix
Fix for psql pager when no tty(Bruce)
New entab utility(Bruce)
General trigger functions for referential integrity (Vadim)
General trigger functions for time travel (Vadim)
General trigger functions for AUTOINCREMENT/IDENTITY feature (Vadim)
MOVE implementation (Vadim)

Source Tree Changes
-------------------
HPUX 10 patches (Vladimir Turin)
Added SCO support, (Daniel Harris)
mkLinux patches (Tatsuo Ishii)
Change geometric box terminology from "length" to "width"(Thomas)
Deprecate temporary unstored slope fields in geometric code(Thomas)
Remove restart instructions from INSTALL(Bruce)
Look in /usr/ucb first for install(Bruce)
Fix c++ copy example code(Thomas)
Add -o to psql manual page(Bruce)
Prevent relname unallocated string length from being copied into database(Bruce)
Cleanup for NAMEDATALEN use(Bruce)
Fix pg_proc names over 15 chars in output(Bruce)
Add strNcpy() function(Bruce)
remove some (void) casts that are unnecessary(Bruce)
new interfaces directory(Marc)
Replace fopen() calls with calls to fd.c functions(Bruce)
Make functions static where possible(Bruce)
enclose unused functions in #ifdef NOT_USED(Bruce)
Remove call to difftime() in timestamp support to fix SunOS(Bruce & Thomas)
Changes for Digital Unix
Portability fix for pg_dumpall(Bruce)
Rename pg_attribute.attnvals to attdisbursion(Bruce)
"intro/unix" manual page now "pgintro"(Bruce)
"built-in" manual page now "pgbuiltin"(Bruce)
"drop" manual page now "drop_table"(Bruce)
Add "create_trigger", "drop_trigger" manual pages(Thomas)
Add constraints regression test(Vadim & Thomas)
Add comments syntax regression test(Thomas)
Add PGINDENT and support program(Bruce)
Massive commit to run PGINDENT on all *.c and *.h files(Bruce)
Files moved to /src/tools directory(Bruce)
SPI and Trigger programming guides (Vadim & D'Arcy)

------------------------------------------------------------------------
Release 6.2.1 Release 6.1.1
Release Notes
------------------------------------------------------------------------

Release 6.1.1

Migration from v6.1 to v6.1.1

This is a minor bug-fix release. A dump/reload is not required from v6.1,
but is required from any release prior to v6.1. Refer to the release notes
for v6.1 for more details.

Detailed Change List

Changes in this release
-----------------------
fix for SET with options (Thomas)
allow pg_dump/pg_dumpall to preserve ownership of all tables/objects(Bruce)
new psql \connect option allows changing usernames without changing databases
fix for initdb --debug option(Yoshihiko Ichikawa))
lextest cleanup(Bruce)
hash fixes(Vadim)
fix date/time month boundary arithmetic(Thomas)
fix timezone daylight handling for some ports(Thomas, Bruce, Tatsuo)
timestamp overhauled to use standard functions(Thomas)
other code cleanup in date/time routines(Thomas)
psql's \d now case-insensitive(Bruce)
psql's backslash commands can now have trailing semicolon(Bruce)
fix memory leak in psql when using \g(Bruce)
major fix for endian handling of communication to server(Thomas, Tatsuo)
Fix for Solaris assembler and include files(Yoshihiko Ichikawa)
allow underscores in usernames(Bruce)
pg_dumpall now returns proper status, portability fix(Bruce)

------------------------------------------------------------------------
Release 6.2 Release 6.1
Release Notes
------------------------------------------------------------------------

Release 6.1

The regression tests have been adapted and extensively modified for the v6.1
release of Postgres.

Three new data types (datetime, timespan, and circle) have been added to the
native set of Postgres types. Points, boxes, paths, and polygons have had
their output formats made consistant across the data types. The polygon
output in misc.out has only been spot-checked for correctness relative to
the original regression output.

Postgres v6.1 introduces a new, alternate optimizer which uses genetic
algorithms. These algorithms introduce a random behavior in the ordering of
query results when the query contains multiple qualifiers or multiple tables
(giving the optimizer a choice on order of evaluation). Several regression
tests have been modified to explicitly order the results, and hence are
insensitive to optimizer choices. A few regression tests are for data types
which are inherently unordered (e.g. points and time intervals) and tests
involving those types are explicitly bracketed with set geqo to 'off' and
reset geqo.

The interpretation of array specifiers (the curly braces around atomic
values) appears to have changed sometime after the original regression tests
were generated. The current ./expected/*.out files reflect this new
interpretation, which may not be correct!

The float8 regression test fails on at least some platforms. This is due to
differences in implementations of pow() and exp() and the signaling
mechanisms used for overflow and underflow conditions.

The "random" results in the random test should cause the "random" test to be
"failed", since the regression tests are evaluated using a simple diff.
However, "random" does not seem to produce random results on my test machine
(Linux/gcc/i686).

Migration to v6.1

This migration requires a complete dump of the 6.0 database and a restore of
the database in 6.1.

Those migrating from earlier 1.* releases should first upgrade to 1.09
because the COPY output format was improved from the 1.02 release.

Detailed Change List

Bug Fixes
---------
packet length checking in library routines
lock manager priority patch
check for under/over flow of float8(Bruce)
multi-table join fix(Vadim)
SIGPIPE crash fix(Darren)
large object fixes(Sven)
allow btree indexes to handle NULLs(Vadim)
timezone fixes(D'Arcy)
select SUM(x) can return NULL on no rows(Thomas)
internal optimizer, executor bug fixes(Vadim)
fix problem where inner loop in < or <= has no rows(Vadim)
prevent re-commuting join index clauses(Vadim)
fix join clauses for multiple tables(Vadim)
fix hash, hashjoin for arrays(Vadim)
fix btree for abstime type(Vadim)
large object fixes(Raymond)
fix buffer leak in hash indices (Vadim)
fix rtree for use in inner scan (Vadim)
fix gist for use in inner scan, cleanups (Vadim, Andrea)
avoid unnecessary local buffers allocation (Vadim, Massimo)
fix local buffers leak in transaction aborts (Vadim)
fix file manager memmory leaks, cleanups (Vadim, Massimo)
fix storage manager memmory leaks (Vadim)
fix btree duplicates handling (Vadim)
fix deleted tuples re-incarnation caused by vacuum (Vadim)
fix SELECT varchar()/char() INTO TABLE made zero-length fields(Bruce)
many psql, pg_dump, and libpq memory leaks fixed using Purify (Igor)

Enhancements
------------
attribute optimization statistics(Bruce)
much faster new btree bulk load code(Paul)
BTREE UNIQUE added to bulk load code(Vadim)
new lock debug code(Massimo)
massive changes to libpg++(Leo)
new GEQO optimizer speeds table multi-table optimization(Martin)
new WARN message for non-unique insert into unique key(Marc)
update x=-3, no spaces, now valid(Bruce)
remove case-sensitive identifier handling(Bruce,Thomas,Dan)
debug backend now pretty-prints tree(Darren)
new Oracle character functions(Edmund)
new plaintext password functions(Dan)
no such class or insufficient privilege changed to distinct messages(Dan)
new ANSI timestamp function(Dan)
new ANSI Time and Date types (Thomas)
move large chunks of data in backend(Martin)
multi-column btree indexes(Vadim)
new SET var TO value command(Martin)
update transaction status on reads(Dan)
new locale settings for character types(Oleg)
new SEQUENCE serial number generator(Vadim)
GROUP BY function now possible(Vadim)
re-organize regression test(Thomas,Marc)
new optimizer operation weights(Vadim)
new psql \z grant/permit option(Marc)
new MONEY data type(D'Arcy,Thomas)
tcp socket communication speed improved(Vadim)
new VACUUM option for attribute statistics, and for certain columns (Vadim)
many geometric type improvements(Thomas,Keith)
additional regression tests(Thomas)
new datestyle variable(Thomas,Vadim,Martin)
more comparison operators for sorting types(Thomas)
new conversion functions(Thomas)
new more compact btree format(Vadim)
allow pg_dumpall to preserve database ownership(Bruce)
new SET GEQO=# and R_PLANS variable(Vadim)
old (!GEQO) optimizer can use right-sided plans (Vadim)
typechecking improvement in SQL parser(Bruce)
new SET, SHOW, RESET commands(Thomas,Vadim)
new \connect database USER option
new destroydb -i option (Igor)
new \dt and \di psql commands (Darren)
SELECT "\n" now escapes newline (A. Duursma)
new geometry conversion functions from old format (Thomas)

Source tree changes
-------------------
new configuration script(Marc)
readline configuration option added(Marc)
OS-specific configuration options removed(Marc)
new OS-specific template files(Marc)
no more need to edit Makefile.global(Marc)
re-arrange include files(Marc)
nextstep patches (Gregor Hoffleit)
removed WIN32-specific code(Bruce)
removed postmaster -e option, now only postgres -e option (Bruce)
merge duplicate library code in front/backends(Martin)
now works with eBones, international Kerberos(Jun)
more shared library support
c++ include file cleanup(Bruce)
warn about buggy flex(Bruce)
DG-UX, Ultrix, Irix, AIX portability fixes

------------------------------------------------------------------------
Release 6.1.1 Release v6.0
Release Notes
------------------------------------------------------------------------

Release v6.0

A dump/restore is required for those wishing to migrate data from previous
releases of Postgres.

Migration from v1.09 to v6.0

This migration requires a complete dump of the 1.09 database and a restore
of the database in 6.0.

Migration from pre-v1.09 to v6.0

Those migrating from earlier 1.* releases should first upgrade to 1.09
because the COPY output format was improved from the 1.02 release.

Detailed Change List

Bug Fixes
---------
ALTER TABLE bug - running postgress process needs to re-read table definition
Allow vacuum to be run on one table or entire database(Bruce)
Array fixes
Fix array over-runs of memory writes(Kurt)
Fix elusive btree range/non-range bug(Dan)
Fix for hash indexes on some types like time and date
Fix for pg_log size explosion
Fix permissions on lo_export()(Bruce)
Fix unitialized reads of memory(Kurt)
Fixed ALTER TABLE ... char(3) bug(Bruce)
Fixed a few small memory leaks
Fixed EXPLAIN handling of options and changed full_path option name
Fixed output of group acl permissions
Memory leaks (hunt and destroy with tools like Purify(Kurt)
Minor improvements to rules system
NOTIFY fixes
New asserts for run-checking
Overhauled parser/analyze code to properly report errors and increase speed
Pg_dump -d now handles NULL's properly(Bruce)
Prevent SELECT NULL from crashing server (Bruce)
Properly report errors when INSERT ... SELECT columns did not match
Properly report errors when insert column names were not correct
Psql \g filename now works(Bruce)
Psql fixed problem with multiple statements on one line with multiple outputs
Removed duplicate system oid's
SELECT * INTO TABLE . GROUP/ORDER BY gives unlink error if table exists(Bruce)
Several fixes for queries that crashed the backend
Starting quote in insert string errors(Bruce)
Submitting an empty query now returns empty status, not just " " query(Bruce)

Enhancements
------------
Add EXPLAIN manual page(Bruce)
Add UNIQUE index capability(Dan)
Add hostname/user level access control rather than just hostname and user
Add synonym of != for (Bruce)
Allow "select oid,* from table"
Allow BY,ORDER BY to specify columns by number, or by non-alias table.column(Bruce)
Allow COPY from the frontend(Bryan)
Allow GROUP BY to use alias column name(Bruce)
Allow actual compression, not just reuse on the same page(Vadim)
Allow installation-configuration option to auto-add all local users(Bryan)
Allow libpq to distinguish between text value '' and null(Bruce)
Allow non-postgres users with createdb privs to destroydb's
Allow restriction on who can create C functions(Bryan)
Allow restriction on who can do backend COPY(Bryan)
Can shrink tables, pg_time and pg_log(Vadim & Erich)
Change debug level 2 to print queries only, changed debug heading layout(Bruce)
Change default decimal constant representation from float4 to float8(Bruce)
European date format now set when postmaster is started
Execute lowercase function names if not found with exact case
Fixes for aggregate/GROUP processing, allow 'select sum(func(x),sum(x+y) from z'
Gist now included in the distrubution(Marc)
Idend authentication of local users(Bryan)
Implement BETWEEN qualifier(Bruce)
Implement IN qualifier(Bruce)
Libpq has PQgetisnull()(Bruce)
Libpq++ improvements
New options to initdb(Bryan)
Pg_dump allow dump of oid's(Bruce)
Pg_dump create indexes after tables are loaded for speed(Bruce)
Pg_dumpall dumps all databases, and the user table
Pginterface additions for NULL values(Bruce)
Prevent postmaster from being run as root
Psql \h and \? is now readable(Bruce)
Psql allow backslashed, semicolons anywhere on the line(Bruce)
Psql changed command prompt for lines in query or in quotes(Bruce)
Psql char(3) now displays as (bp)char in \d output(Bruce)
Psql return code now more accurate(Bryan?)
Psql updated help syntax(Bruce)
Re-visit and fix vacuum(Vadim)
Reduce size of regression diffs, remove timezone name difference(Bruce)
Remove compile-time parameters to enable binary distributions(Bryan)
Reverse meaning of HBA masks(Bryan)
Secure Authentication of local users(Bryan)
Speed up vacuum(Vadim)
Vacuum now had VERBOSE option(Bruce)

Source tree changes
-------------------
All functions now have prototypes that are compared against the calls
Allow asserts to be disabled easly from Makefile.global(Bruce)
Change oid constants used in code to #define names
Decoupled sparc and solaris defines(Kurt)
Gcc -Wall compiles cleanly with warnings only from unfixable constructs
Major include file reorganization/reduction(Marc)
Make now stops on compile failure(Bryan)
Makefile restructuring(Bryan, Marc)
Merge bsdi_2_1 to bsdi(Bruce)
Monitor program removed
Name change from Postgres95 to PostgreSQL
New config.h file(Marc, Bryan)
PG_VERSION now set to 6.0 and used by postmaster
Portability additions, including Ultrix, DG/UX, AIX, and Solaris
Reduced the number of #define's, centeralized #define's
Remove duplicate OIDS in system tables(Dan)
Remove duplicate system catalog info or report mismatches(Dan)
Removed many os-specific #define's
Restructured object file generation/location(Bryan, Marc)
Restructured port-specific file locations(Bryan, Marc)
Unused/uninialized variables corrected

------------------------------------------------------------------------
Release 6.1 Release v1.09
Release Notes
------------------------------------------------------------------------

Release v1.09

Sorry, we stopped keeping track of changes from 1.02 to 1.09. Some of the
changes listed in 6.0 were actually included in the 1.02.1 to 1.09 releases.

------------------------------------------------------------------------
Release v6.0 Release v1.02
Release Notes
------------------------------------------------------------------------

Release v1.02

Migration from v1.02 to v1.02.1

Here is a new migration file for 1.02.1. It includes the 'copy' change and a
script to convert old ascii files.

Note: The following notes are for the benefit of users who want to
migrate databases from postgres95 1.01 and 1.02 to postgres95
1.02.1.

If you are starting afresh with postgres95 1.02.1 and do not need
to migrate old databases, you do not need to read any further.

In order to upgrade older postgres95 version 1.01 or 1.02 databases to
version 1.02.1, the following steps are required:

1. Start up a new 1.02.1 postmaster

2. Add the new built-in functions and operators of 1.02.1 to 1.01 or 1.02
databases. This is done by running the new 1.02.1 server against your
own 1.01 or 1.02 database and applying the queries attached at the end
of thie file. This can be done easily through psql. If your 1.01 or
1.02 database is named "testdb" and you have cut the commands from the
end of this file and saved them in addfunc.sql:

% psql testdb -f addfunc.sql

Those upgrading 1.02 databases will get a warning when executing the
last two statements in the file because they are already present in
1.02. This is not a cause for concern.

Dump/Reload Procedure

If you are trying to reload a pg_dump or text-mode 'copy tablename to
stdout' generated with a previous version, you will need to run the attached
sed script on the ASCII file before loading it into the database. The old
format used '.' as end-of-data, while '\.' is now the end-of-data marker.
Also, empty strings are now loaded in as '' rather than NULL. See the copy
manual page for full details.

sed 's/^\.$/\\./g' in_file out_file

If you are loading an older binary copy or non-stdout copy, there is no
end-of-data character, and hence no conversion necessary.

-- following lines added by agc to reflect the case-insensitive
-- regexp searching for varchar (in 1.02), and bpchar (in 1.02.1)
create operator ~* (leftarg = bpchar, rightarg = text, procedure = texticregexeq);
create operator !~* (leftarg = bpchar, rightarg = text, procedure = texticregexne);
create operator ~* (leftarg = varchar, rightarg = text, procedure = texticregexeq);
create operator !~* (leftarg = varchar, rightarg = text, procedure = texticregexne);

Detailed Change List

Source code maintenance and development
* worldwide team of volunteers
* the source tree now in CVS at ftp.ki.net

Enhancements
* psql (and underlying libpq library) now has many more options for
formatting output, including HTML
* pg_dump now output the schema and/or the data, with many fixes to
enhance completeness.
* psql used in place of monitor in administration shell scripts.
monitor to be depreciated in next release.
* date/time functions enhanced
* NULL insert/update/comparison fixed/enhanced
* TCL/TK lib and shell fixed to work with both tck7.4/tk4.0 and tcl7.5/tk4.1

Bug Fixes (almost too numerous to mention)
* indexes
* storage management
* check for NULL pointer before dereferencing
* Makefile fixes

New Ports
* added SolarisX86 port
* added BSDI 2.1 port
* added DGUX port

------------------------------------------------------------------------
Release v1.09 Release v1.01
Release Notes
------------------------------------------------------------------------

Release v1.01

Migration from v1.0 to v1.01

The following notes are for the benefit of users who want to migrate
databases from postgres95 1.0 to postgres95 1.01.

If you are starting afresh with postgres95 1.01 and do not need to migrate
old databases, you do not need to read any further.

In order to postgres95 version 1.01 with databases created with postgres95
version 1.0, the following steps are required:

1. Set the definition of NAMEDATALEN in src/Makefile.global to 16 and
OIDNAMELEN to 20.

2. Decide whether you want to use Host based authentication.

a. If you do, you must create a file name "pg_hba" in your top-level
data directory (typically the value of your $PGDATA).
src/libpq/pg_hba shows an example syntax.

b. If you do not want host-based authentication, you can comment out
the line

HBA = 1

in src/Makefile.global

Note that host-based authentication is turned on by default, and
if you do not take steps A or B above, the out-of-the-box 1.01
will not allow you to connect to 1.0 databases.

3. Compile and install 1.01, but DO NOT do the initdb step.

4. Before doing anything else, terminate your 1.0 postmaster, and backup
your existing $PGDATA directory.

5. Set your PGDATA environment variable to your 1.0 databases, but set up
path up so that 1.01 binaries are being used.

6. Modify the file $PGDATA/PG_VERSION from 5.0 to 5.1

7. Start up a new 1.01 postmaster

8. Add the new built-in functions and operators of 1.01 to 1.0 databases.
This is done by running the new 1.01 server against your own 1.0
database and applying the queries attached and saving in the file
1.0_to_1.01.sql. This can be done easily through psql. If your 1.0
database is name "testdb":

% psql testdb -f 1.0_to_1.01.sql

and then execute the following commands (cut and paste from here):

-- add builtin functions that are new to 1.01

create function int4eqoid (int4, oid) returns bool as 'foo'
language 'internal';
create function oideqint4 (oid, int4) returns bool as 'foo'
language 'internal';
create function char2icregexeq (char2, text) returns bool as 'foo'
language 'internal';
create function char2icregexne (char2, text) returns bool as 'foo'
language 'internal';
create function char4icregexeq (char4, text) returns bool as 'foo'
language 'internal';
create function char4icregexne (char4, text) returns bool as 'foo'
language 'internal';
create function char8icregexeq (char8, text) returns bool as 'foo'
language 'internal';
create function char8icregexne (char8, text) returns bool as 'foo'
language 'internal';
create function char16icregexeq (char16, text) returns bool as 'foo'
language 'internal';
create function char16icregexne (char16, text) returns bool as 'foo'
language 'internal';
create function texticregexeq (text, text) returns bool as 'foo'
language 'internal';
create function texticregexne (text, text) returns bool as 'foo'
language 'internal';

-- add builtin functions that are new to 1.01

create operator = (leftarg = int4, rightarg = oid, procedure = int4eqoid);
create operator = (leftarg = oid, rightarg = int4, procedure = oideqint4);
create operator ~* (leftarg = char2, rightarg = text, procedure = char2icregexeq);
create operator !~* (leftarg = char2, rightarg = text, procedure = char2icregexne);
create operator ~* (leftarg = char4, rightarg = text, procedure = char4icregexeq);
create operator !~* (leftarg = char4, rightarg = text, procedure = char4icregexne);
create operator ~* (leftarg = char8, rightarg = text, procedure = char8icregexeq);
create operator !~* (leftarg = char8, rightarg = text, procedure = char8icregexne);
create operator ~* (leftarg = char16, rightarg = text, procedure = char16icregexeq);
create operator !~* (leftarg = char16, rightarg = text, procedure = char16icregexne);
create operator ~* (leftarg = text, rightarg = text, procedure = texticregexeq);
create operator !~* (leftarg = text, rightarg = text, procedure = texticregexne);

Detailed Change List

Incompatibilities:
* 1.01 is backwards compatible with 1.0 database provided the user
follow the steps outlined in the MIGRATION_from_1.0_to_1.01 file.
If those steps are not taken, 1.01 is not compatible with 1.0 database.

Enhancements:
* added PQdisplayTuples() to libpq and changed monitor and psql to use it
* added NeXT port (requires SysVIPC implementation)
* added CAST .. AS ... syntax
* added ASC and DESC keywords
* added 'internal' as a possible language for CREATE FUNCTION
internal functions are C functions which have been statically linked
into the postgres backend.
* a new type "name" has been added for system identifiers (table names,
attribute names, etc.) This replaces the old char16 type. The
of name is set by the NAMEDATALEN #define in src/Makefile.global
* a readable reference manual that describes the query language.
* added host-based access control. A configuration file ($PGDATA/pg_hba)
is used to hold the configuration data. If host-based access control
is not desired, comment out HBA=1 in src/Makefile.global.
* changed regex handling to be uniform use of Henry Spencer's regex code
regardless of platform. The regex code is included in the distribution
* added functions and operators for case-insensitive regular expressions.
The operators are ~* and !~*.
* pg_dump uses COPY instead of SELECT loop for better performance

Bug fixes:
* fixed an optimizer bug that was causing core dumps when
functions calls were used in comparisons in the WHERE clause
* changed all uses of getuid to geteuid so that effective uids are used
* psql now returns non-zero status on errors when using -c
* applied public patches 1-14

------------------------------------------------------------------------
Release v1.02 Release v1.0
Release Notes
------------------------------------------------------------------------

Release v1.0

Detailed Change List

Copyright change:
* The copyright of Postgres 1.0 has been loosened to be freely modifiable
and modifiable for any purpose. Please read the COPYRIGHT file.
Thanks to Professor Michael Stonebraker for making this possible.

Incompatibilities:
* date formats have to be MM-DD-YYYY (or DD-MM-YYYY if you're using
EUROPEAN STYLE). This follows SQL-92 specs.
* "delimiters" is now a keyword

Enhancements:
* sql LIKE syntax has been added
* copy command now takes an optional USING DELIMITER specification.
delimiters can be any single-character string.
* IRIX 5.3 port has been added.
Thanks to Paul Walmsley and others.
* updated pg_dump to work with new libpq
* \d has been added psql
Thanks to Keith Parks
* regexp performance for architectures that use POSIX regex has been
improved due to caching of precompiled patterns.
Thanks to Alistair Crooks
* a new version of libpq++
Thanks to William Wanders

Bug fixes:
* arbitrary userids can be specified in the createuser script
* \c to connect to other databases in psql now works.
* bad pg_proc entry for float4inc() is fixed
* users with usecreatedb field set can now create databases without
having to be usesuper
* remove access control entries when the entry no longer has any
permissions
* fixed non-portable datetimes implementation
* added kerberos flags to the src/backend/Makefile
* libpq now works with kerberos
* typographic errors in the user manual have been corrected.
* btrees with multiple index never worked, now we tell you they don't
work when you try to use them

------------------------------------------------------------------------
Release v1.01 Postgres95 Beta 0.03
Release Notes
------------------------------------------------------------------------

Postgres95 Beta 0.03

Detailed Change List

Incompatible changes:
* BETA-0.3 IS INCOMPATIBLE WITH DATABASES CREATED WITH PREVIOUS VERSIONS
(due to system catalog changes and indexing structure changes).
* double-quote (") is deprecated as a quoting character for string literals;
you need to convert them to single quotes (').
* name of aggregates (eg. int4sum) are renamed in accordance with the
SQL standard (eg. sum).
* CHANGE ACL syntax is replaced by GRANT/REVOKE syntax.
* float literals (eg. 3.14) are now of type float4 (instead of float8 in
previous releases); you might have to do typecasting if you depend on it
being of type float8. If you neglect to do the typecasting and you assign
a float literal to a field of type float8, you may get incorrect values
stored!
* LIBPQ has been totally revamped so that frontend applications
can connect to multiple backends
* the usesysid field in pg_user has been changed from int2 to int4 to
allow wider range of Unix user ids.
* the netbsd/freebsd/bsd o/s ports have been consolidated into a
single BSD44_derived port. (thanks to Alistair Crooks)

SQL standard-compliance (the following details changes that makes postgres95
more compliant to the SQL-92 standard):
* the following SQL types are now built-in: smallint, int(eger), float, real,
char(N), varchar(N), date and time.

The following are aliases to existing postgres types:
smallint -> int2
integer, int -> int4
float, real -> float4
char(N) and varchar(N) are implemented as truncated text types. In
addition, char(N) does blank-padding.
* single-quote (') is used for quoting string literals; '' (in addition to
\') is supported as means of inserting a single quote in a string
* SQL standard aggregate names (MAX, MIN, AVG, SUM, COUNT) are used
(Also, aggregates can now be overloaded, i.e. you can define your
own MAX aggregate to take in a user-defined type.)
* CHANGE ACL removed. GRANT/REVOKE syntax added.
- Privileges can be given to a group using the "GROUP" keyword.
For example:
GRANT SELECT ON foobar TO GROUP my_group;
The keyword 'PUBLIC' is also supported to mean all users.

Privileges can only be granted or revoked to one user or group
at a time.

"WITH GRANT OPTION" is not supported. Only class owners can change
access control
- The default access control is to to grant users readonly access.
You must explicitly grant insert/update access to users. To change
this, modify the line in
src/backend/utils/acl.h
that defines ACL_WORLD_DEFAULT

Bug fixes:
* the bug where aggregates of empty tables were not run has been fixed. Now,
aggregates run on empty tables will return the initial conditions of the
aggregates. Thus, COUNT of an empty table will now properly return 0.
MAX/MIN of an empty table will return a tuple of value NULL.
* allow the use of \; inside the monitor
* the LISTEN/NOTIFY asynchronous notification mechanism now work
* NOTIFY in rule action bodies now work
* hash indices work, and access methods in general should perform better.
creation of large btree indices should be much faster. (thanks to Paul
Aoki)

Other changes and enhancements:
* addition of an EXPLAIN statement used for explaining the query execution
plan (eg. "EXPLAIN SELECT * FROM EMP" prints out the execution plan for
the query).
* WARN and NOTICE messages no longer have timestamps on them. To turn on
timestamps of error messages, uncomment the line in
src/backend/utils/elog.h:
/* define ELOG_TIMESTAMPS */
* On an access control violation, the message
"Either no such class or insufficient privilege"
will be given. This is the same message that is returned when
a class is not found. This dissuades non-privileged users from
guessing the existence of privileged classes.
* some additional system catalog changes have been made that are not
visible to the user.

libpgtcl changes:
* The -oid option has been added to the "pg_result" tcl command.
pg_result -oid returns oid of the last tuple inserted. If the
last command was not an INSERT, then pg_result -oid returns "".
* the large object interface is available as pg_lo* tcl commands:
pg_lo_open, pg_lo_close, pg_lo_creat, etc.

Portability enhancements and New Ports:
* flex/lex problems have been cleared up. Now, you should be able to use
flex instead of lex on any platforms. We no longer make assumptions of
what lexer you use based on the platform you use.
* The Linux-ELF port is now supported. Various configuration have been
tested: The following configuration is known to work:
kernel 1.2.10, gcc 2.6.3, libc 4.7.2, flex 2.5.2, bison 1.24
with everything in ELF format,

New utilities:
* ipcclean added to the distribution
ipcclean usually does not need to be run, but if your backend crashes
and leaves shared memory segments hanging around, ipcclean will
clean them up for you.

New documentation:
* the user manual has been revised and libpq documentation added.

------------------------------------------------------------------------
Release v1.0 Postgres95 Beta 0.02
Release Notes
------------------------------------------------------------------------

Postgres95 Beta 0.02

Detailed Change List

Incompatible changes:
* The SQL statement for creating a database is 'CREATE DATABASE' instead
of 'CREATEDB'. Similarly, dropping a database is 'DROP DATABASE' instead
of 'DESTROYDB'. However, the names of the executables 'createdb' and
'destroydb' remain the same.

New tools:
* pgperl - a Perl (4.036) interface to Postgres95
* pg_dump - a utility for dumping out a postgres database into a
script file containing query commands. The script files are in a ASCII
format and can be used to reconstruct the database, even on other
machines and other architectures. (Also good for converting
a Postgres 4.2 database to Postgres95 database.)

The following ports have been incorporated into postgres95-beta-0.02:
* the NetBSD port by Alistair Crooks
* the AIX port by Mike Tung
* the Windows NT port by Jon Forrest (more stuff but not done yet)
* the Linux ELF port by Brian Gallew

The following bugs have been fixed in postgres95-beta-0.02:
* new lines not escaped in COPY OUT and problem with COPY OUT when first
attribute is a '.'
* cannot type return to use the default user id in createuser
* SELECT DISTINCT on big tables crashes
* Linux installation problems
* monitor doesn't allow use of 'localhost' as PGHOST
* psql core dumps when doing \c or \l
* the "pgtclsh" target missing from src/bin/pgtclsh/Makefile
* libpgtcl has a hard-wired default port number
* SELECT DISTINCT INTO TABLE hangs
* CREATE TYPE doesn't accept 'variable' as the internallength
* wrong result using more than 1 aggregate in a SELECT

------------------------------------------------------------------------
Postgres95 Beta 0.03 Postgres95 Beta 0.01
Release Notes
------------------------------------------------------------------------

Postgres95 Beta 0.01

Initial release.

------------------------------------------------------------------------
Postgres95 Beta 0.02 Timing Results
Release Notes
Prev
------------------------------------------------------------------------

Timing Results

These timing results are from running the regression test with the commands

% cd src/test/regress
% make all
% time make runtest

Timing under Linux 2.0.27 seems to have a roughly 5% variation from run to
run, presumably due to the scheduling vagaries of multitasking systems.

v6.5

As has been the case for previous releases, timing between releases is not
directly comparable since new regression tests have been added. In general,
v6.5 is faster than previous releases.

Timing with fsync() disabled:

Time System
02:00 Dual Pentium Pro 180, 224MB, UW-SCSI, Linux 2.0.36, gcc 2.7.2.3 -O2 -m486
04:38 Sparc Ultra 1 143MHz, 64MB, Solaris 2.6

Timing with fsync() enabled:

Time System
04:21 Dual Pentium Pro 180, 224MB, UW-SCSI, Linux 2.0.36, gcc 2.7.2.3 -O2 -m486

For the linux system above, using UW-SCSI disks rather than (older) IDE
disks leads to a 50% improvement in speed on the regression test.

v6.4beta

The times for this release are not directly comparable to those for previous
releases since some additional regression tests have been included. In
general, however, v6.4 should be slightly faster than the previous release
(thanks, Bruce!).

Time System
02:26 Dual Pentium Pro 180, 96MB, UW-SCSI, Linux 2.0.30, gcc 2.7.2.1 -O2 -m486

v6.3

The times for this release are not directly comparable to those for previous
releases since some additional regression tests have been included and some
obsolete tests involving time travel have been removed. In general, however,
v6.3 is substantially faster than previous releases (thanks, Bruce!).

Time System
02:30 Dual Pentium Pro 180, 96MB, UW-SCSI, Linux 2.0.30, gcc 2.7.2.1 -O2 -m486
04:12 Dual Pentium Pro 180, 96MB, EIDE, Linux 2.0.30, gcc 2.7.2.1 -O2 -m486

v6.1

Time System
06:12 Pentium Pro 180, 32MB, EIDE, Linux 2.0.30, gcc 2.7.2 -O2 -m486
12:06 P-100, 48MB, Linux 2.0.29, gcc
39:58 Sparc IPC 32MB, Solaris 2.5, gcc 2.7.2.1 -O -g

------------------------------------------------------------------------
Prev Home
Postgres95 Beta 0.01

--ELM939744267-23429-0_

--ELM939744267-23429-0_--

From bouncefilter Tue Oct 12 12:09:30 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA89625
for <hackers@postgresql.org>; Tue, 12 Oct 1999 12:08:37 -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 MAA25343;
Tue, 12 Oct 1999 12:08:12 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121608.MAA25343@candle.pha.pa.us>
Subject: Re: [HACKERS] Features for next release
In-Reply-To: <199910121603.RAA16784@linda.lfix.co.uk> from Oliver Elphick at
"Oct 12, 1999 05:03:46 pm"
To: Oliver Elphick <olly@lfix.co.uk>
Date: Tue, 12 Oct 1999 12:08:12 -0400 (EDT)
CC: Postgres Hackers List <hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Bruce, you asked for a v6.5.3 to be released...anything outstanding that
should prevent me from doing that tomorrow afternoon?

Not that I know of. I was waiting to see if we could come up with other
patches, but I don't think that is going to happen anytime soon.

Will this include a patch to let NUMERIC fields be indexed?

Not sure.

-- 
  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 12 12:26:19 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 MAA93399
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 12:25:49 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11b4ew-0003kLC; Tue, 12 Oct 99 18:20 MET DST
Message-Id: <m11b4ew-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: New developer globe (was: Re: [HACKERS] Interesting Quote you might
enjoy about PGSQL.)
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Tue, 12 Oct 1999 18:20:18 +0200 (MET DST)
Cc: vev@michvhf.com, wieck@debis.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: <199910111346.JAA26559@candle.pha.pa.us> from "Bruce Momjian" at
Oct 11, 99 09:46:17 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Wow, that web page looks good now, with the quote at the bottom. Jan,
we need the nicer world image.

You mean one with the mountains - no?

Well, I'll spend some time, polish up the Povray sources etc.
so Vince can easily maintain the map after - only that he
needs Povray 3.1 and maybe Tcl/Tk 8.0 to do it, but that
shouldn't be a problem since both are freely available and
easily to install.

I have tcl 8.0.5 and povray here too.

I've setup an example for the new developers page at

<http://www.PostgreSQL.ORG/~wieck>

The image size is adjusted for the page width.

To maintain the hotspots I made a little, slightly
overspecialized, Tcl/Tk application that creates the imagemap
so it can easily be pasted into the page.

I'll contact you and Vince via private mail after packing it
up.

Jan

From bouncefilter Tue Oct 12 12:33:24 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 MAA95142
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 12:33:03 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgreSQL.org
id m11b4mB-0003kLC; Tue, 12 Oct 99 18:27 MET DST
Message-Id: <m11b4mB-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Features for next release
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Tue, 12 Oct 1999 18:27:47 +0200 (MET DST)
Cc: olly@lfix.co.uk, hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199910121608.MAA25343@candle.pha.pa.us> from "Bruce Momjian" at
Oct 12, 99 12:08:12 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

Bruce, you asked for a v6.5.3 to be released...anything outstanding that
should prevent me from doing that tomorrow afternoon?

Not that I know of. I was waiting to see if we could come up with other
patches, but I don't think that is going to happen anytime soon.

Will this include a patch to let NUMERIC fields be indexed?

Not sure.

Not FOR sure. Adding the default operator class etc. is
adding catalog entries. Thus it requires "initdb" and that's
a NONO for bugfix releases according to our release policy.

It's done in the v7.0 tree.

Jan

From bouncefilter Tue Oct 12 12:37:17 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA96198
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 12:36:17 -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 MAA26945;
Tue, 12 Oct 1999 12:34:25 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121634.MAA26945@candle.pha.pa.us>
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might enjoy about PGSQL.)u
In-Reply-To: <m11b4ew-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 12, 1999 06:20:18 pm"
To: Jan Wieck <wieck@debis.com>
Date: Tue, 12 Oct 1999 12:34:25 -0400 (EDT)
CC: vev@michvhf.com, lockhart@alumni.caltech.edu, lamar.owen@wgcr.org,
pgsql-hackers@postgreSQL.org, jwieck@debis.com
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Wow, that web page looks good now, with the quote at the bottom. Jan,
we need the nicer world image.

You mean one with the mountains - no?

Well, I'll spend some time, polish up the Povray sources etc.
so Vince can easily maintain the map after - only that he
needs Povray 3.1 and maybe Tcl/Tk 8.0 to do it, but that
shouldn't be a problem since both are freely available and
easily to install.

I have tcl 8.0.5 and povray here too.

I've setup an example for the new developers page at

<http://www.PostgreSQL.ORG/~wieck>

The image size is adjusted for the page width.

To maintain the hotspots I made a little, slightly
overspecialized, Tcl/Tk application that creates the imagemap
so it can easily be pasted into the page.

I'll contact you and Vince via private mail after packing it
up.

Yikes, that's amazingly good looking.

-- 
  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 12 12:38:16 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA96493
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 12:37:23 -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 MAA26990;
Tue, 12 Oct 1999 12:35:28 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121635.MAA26990@candle.pha.pa.us>
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might enjoy about PGSQL.)
In-Reply-To: <m11b4ew-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 12, 1999 06:20:18 pm"
To: Jan Wieck <wieck@debis.com>
Date: Tue, 12 Oct 1999 12:35:28 -0400 (EDT)
CC: vev@michvhf.com, lockhart@alumni.caltech.edu, lamar.owen@wgcr.org,
pgsql-hackers@postgreSQL.org, jwieck@debis.com
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have tcl 8.0.5 and povray here too.

I've setup an example for the new developers page at

<http://www.PostgreSQL.ORG/~wieck>

The image size is adjusted for the page width.

To maintain the hotspots I made a little, slightly
overspecialized, Tcl/Tk application that creates the imagemap
so it can easily be pasted into the page.

I'll contact you and Vince via private mail after packing it
up.

I just realized I can put my mouse over a pin, and the name appears.
That is great.

-- 
  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 12 12:48:37 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA99081
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 12:47:50 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by trends.net (8.8.8/8.8.8) with ESMTP id MAA15902
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 12:43:20 -0400 (EDT)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA27247;
Tue, 12 Oct 1999 12:42:52 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121642.MAA27247@candle.pha.pa.us>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
In-Reply-To: <38036A0D.363234BC@pop.dn.net> from Bernard Frankpitt at "Oct 12,
1999 05:04:13 pm"
To: Bernard Frankpitt <frankpit@pop.dn.net>
Date: Tue, 12 Oct 1999 12:42:52 -0400 (EDT)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Interesting. I see what you mean. We have a pyrotechnic API already
installed.

Bruce,
I think that an index interface would be simpler than you think.
The index does not need any disk storage which takes out virtually all
the complexity in implementation. All that you really need to implement
is the scan interface, and the only state that the scan needs is a
single flag that indicates when getnext has already been called once.
All that getnext need do is return the ctid, and flip the flag so that
it knows to return null on the next call. You also need to ensure that
the access method functions used by the optimizer return appropriate
values to ensure that the cost of an index search is always zero. I
have some suitable functions for that.

With all due respect to people who I am sure know a lot more about this
than I do, it seems to me that extensive use of TIDs in user code might
place an unwelcome restraint on the internal database design. If you
follow the arguments of the reiserfs people, the whole idea of a
buffered cache with fix size blocks is a necessary hack to cope with a
less than optimal underlying filesystem. In the ideal world that
reiserfs promises (:-)) disk access efficiency would be independent of
file-size, and it would be feasible to construct the buffered cache from
raw tuples of variable size. The files on disk would be identified by
OID. reiserfs uses a B-tree varient to cope with very large name
spaces.

Similar considerations would seem to apply if the storage layer of the
database is separated from the rest of the backend by a high-speed
qnetwork interface on something like a hard-disk farm. ( See for
example some of the Mariposa work ).

Until things like that actually happen (Version 10.* perhaps) I can see
that TIDs are a useful addition, but you might want to fasten them in
with a pyrotechnic interface so that you can blow them away if need be.

I have a URL for the reiserfs stuff at home, if anyone is interested
email me and I will dig it up and post it.

Bernie Frankpitt

-- 
  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 12 12:41:48 1999
Received: from postal.dn.net (postal.dn.net [207.226.170.20])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA97368
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 12:40:36 -0400 (EDT)
(envelope-from frankpit@pop.dn.net)
Received: from pop.dn.net (pm-50.ppp.wdc.dn.net [207.226.188.50])
by postal.dn.net (8.9.3/postal) with ESMTP id MAA07338;
Tue, 12 Oct 1999 12:39:44 -0400 (EDT)
Sender: matuser@postal.dn.net
Message-ID: <38036A0D.363234BC@pop.dn.net>
Date: Tue, 12 Oct 1999 17:04:13 +0000
From: Bernard Frankpitt <frankpit@pop.dn.net>
Organization: AIMS
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.32 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
References: <199910121510.LAA20419@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce,
I think that an index interface would be simpler than you think.
The index does not need any disk storage which takes out virtually all
the complexity in implementation. All that you really need to implement
is the scan interface, and the only state that the scan needs is a
single flag that indicates when getnext has already been called once.
All that getnext need do is return the ctid, and flip the flag so that
it knows to return null on the next call. You also need to ensure that
the access method functions used by the optimizer return appropriate
values to ensure that the cost of an index search is always zero. I
have some suitable functions for that.

With all due respect to people who I am sure know a lot more about this
than I do, it seems to me that extensive use of TIDs in user code might
place an unwelcome restraint on the internal database design. If you
follow the arguments of the reiserfs people, the whole idea of a
buffered cache with fix size blocks is a necessary hack to cope with a
less than optimal underlying filesystem. In the ideal world that
reiserfs promises (:-)) disk access efficiency would be independent of
file-size, and it would be feasible to construct the buffered cache from
raw tuples of variable size. The files on disk would be identified by
OID. reiserfs uses a B-tree varient to cope with very large name
spaces.

Similar considerations would seem to apply if the storage layer of the
database is separated from the rest of the backend by a high-speed
qnetwork interface on something like a hard-disk farm. ( See for
example some of the Mariposa work ).

Until things like that actually happen (Version 10.* perhaps) I can see
that TIDs are a useful addition, but you might want to fasten them in
with a pyrotechnic interface so that you can blow them away if need be.

I have a URL for the reiserfs stuff at home, if anyone is interested
email me and I will dig it up and post it.

Bernie Frankpitt

From bouncefilter Tue Oct 12 13:10:34 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA04199;
Tue, 12 Oct 1999 13:09:16 -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 NAA28963;
Tue, 12 Oct 1999 13:09:05 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121709.NAA28963@candle.pha.pa.us>
Subject: PostgreSQL book proposal
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
Date: Tue, 12 Oct 1999 13:09:05 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM939748145-27176-0_
Content-Transfer-Encoding: 7bit

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

Here is my proposal for an outline for a PostgreSQL book. Many of us
have been asked by publishers about writing a book. Here is what I
think would be a good outline for the book.

I am interested in whether this is a good outline for a PostgreSQL book,
how our existing documentation matches this outline, where our existing
documentation can be managed into a published book, etc.

Any comments would be welcome.

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

The attached document is in both web page and text formats.
View the one which looks best. Also in PDF format.

--ELM939748145-27176-0_
Content-Type: text/html
Content-Disposition: inline; filename="/tmp/book.html"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<HTML>
<HEAD>
<TITLE>PostgreSQL Book Proposal</TITLE>
<META NAME="description" CONTENT="PostgreSQL Book Proposal">
<META NAME="keywords" CONTENT="28822">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<LINK REL="STYLESHEET" HREF="28822.css">
</HEAD>
<BODY >

<H1 ALIGN="CENTER">PostgreSQL Book Proposal</H1>
Bruce Momjian

<DL COMPACT>
<DT>1.
<DD>Introduction
<DT>2.
<DD>Installation

<DL COMPACT>
<DT>(a)
<DD>Getting POSTGRESQL
<DT>(b)
<DD>Compiling
<DT>(c)
<DD>Initialization
<DT>(d)
<DD>Starting the server
<DT>(e)
<DD>Creating a database
<DT>(f)
<DD>Issuing database commands
</DL><DT>3.
<DD>Introduction to SQL

<DL COMPACT>
<DT>(a)
<DD>Why a database?
<DT>(b)
<DD>Creating tables
<DT>(c)
<DD>Adding data with INSERT
<DT>(d)
<DD>Viewing data with SELECT
<DT>(e)
<DD>Removing data with DELETE
<DT>(f)
<DD>Modifying data with UPDATE
<DT>(g)
<DD>Restriction with WHERE
<DT>(h)
<DD>Sorting data with ORDER BY
<DT>(i)
<DD>Usage of NULL values
</DL><DT>4.
<DD>Advanced SQL Commands

<DL COMPACT>
<DT>(a)
<DD>Inserting data from a SELECT
<DT>(b)
<DD>Aggregates: COUNT, SUM, etc.
<DT>(c)
<DD>GROUP BY with aggregates
<DT>(d)
<DD>HAVING with aggregates
<DT>(e)
<DD>Joining tables
<DT>(f)
<DD>Using table aliases
<DT>(g)
<DD>UNION clause
<DT>(h)
<DD>Subqueries
<DT>(i)
<DD>Transactions
<DT>(j)
<DD>Cursors
<DT>(k)
<DD>Indexing
<DT>(l)
<DD>Table defaults
<DT>(m)
<DD>Primary/Foreign keys
<DT>(n)
<DD>AND/OR usage
<DT>(o)
<DD>LIKE clause usage
<DT>(p)
<DD>Temporary tables
<DT>(q)
<DD>Importing data
</DL><DT>5.
<DD>POSTGRESQL'S Unique Features

<DL COMPACT>
<DT>(a)
<DD>Object ID'S (OID)
<DT>(b)
<DD>Multi-version Concurrency Control (MVCC)
<DT>(c)
<DD>Locking and Deadlocks
<DT>(d)
<DD>Vacuum
<DT>(e)
<DD>Views
<DT>(f)
<DD>Rules
<DT>(g)
<DD>Sequences
<DT>(h)
<DD>Triggers
<DT>(i)
<DD>Large Objects(BLOBS)
<DT>(j)
<DD>Adding User-defined Functions
<DT>(k)
<DD>Adding User-defined Operators
<DT>(l)
<DD>Adding User-defined Types
<DT>(m)
<DD>Exotic Preinstalled Types
<DT>(n)
<DD>Arrays
<DT>(o)
<DD>Inheritance
</DL><DT>6.
<DD>Interfacing to the POSTGRESQL Database

<DL COMPACT>
<DT>(a)
<DD>C Language API
<DT>(b)
<DD>Embedded C
<DT>(c)
<DD>C++
<DT>(d)
<DD>JAVA
<DT>(e)
<DD>ODBC
<DT>(f)
<DD>PERL
<DT>(g)
<DD>TCL/TK
<DT>(h)
<DD>PYTHON
<DT>(i)
<DD>Web access (PHP)
<DT>(j)
<DD>Server-side programming (PLPGSQL and SPI)
</DL><DT>7.
<DD>POSTGRESQL Adminstration

<DL COMPACT>
<DT>(a)
<DD>Creating users and databases
<DT>(b)
<DD>Backup and restore
<DT>(c)
<DD>Performance tuning
<DT>(d)
<DD>Troubleshooting
<DT>(e)
<DD>Customization options
<DT>(f)
<DD>Setting access permissions
</DL><DT>8.
<DD>Additional Resources

<DL COMPACT>
<DT>(a)
<DD>Frequently Asked Questions (FAQ'S)
<DT>(b)
<DD>Mailing list support
<DT>(c)
<DD>Supplied documentation
<DT>(d)
<DD>Commercial support
<DT>(e)
<DD>Modifying the source code
</DL></DL>

</BODY>
</HTML>

--ELM939748145-27176-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/tmp/book.txt"
Content-Transfer-Encoding: 7bit

PostgreSQL Book Proposal

Bruce Momjian

1.
Introduction
2.
Installation
(a)
Getting POSTGRESQL
(b)
Compiling
(c)
Initialization
(d)
Starting the server
(e)
Creating a database
(f)
Issuing database commands
3.
Introduction to SQL
(a)
Why a database?
(b)
Creating tables
(c)
Adding data with INSERT
(d)
Viewing data with SELECT
(e)
Removing data with DELETE
(f)
Modifying data with UPDATE
(g)
Restriction with WHERE
(h)
Sorting data with ORDER BY
(i)
Usage of NULL values
4.
Advanced SQL Commands
(a)
Inserting data from a SELECT
(b)
Aggregates: COUNT, SUM, etc.
(c)
GROUP BY with aggregates
(d)
HAVING with aggregates
(e)
Joining tables
(f)
Using table aliases
(g)
UNION clause
(h)
Subqueries
(i)
Transactions
(j)
Cursors
(k)
Indexing
(l)
Table defaults
(m)
Primary/Foreign keys
(n)
AND/OR usage
(o)
LIKE clause usage
(p)
Temporary tables
(q)
Importing data
5.
POSTGRESQL'S Unique Features
(a)
Object ID'S (OID)
(b)
Multi-version Concurrency Control (MVCC)
(c)
Locking and Deadlocks
(d)
Vacuum
(e)
Views
(f)
Rules
(g)
Sequences
(h)
Triggers
(i)
Large Objects(BLOBS)
(j)
Adding User-defined Functions
(k)
Adding User-defined Operators
(l)
Adding User-defined Types
(m)
Exotic Preinstalled Types
(n)
Arrays
(o)
Inheritance
6.
Interfacing to the POSTGRESQL Database
(a)
C Language API
(b)
Embedded C
(c)
C++
(d)
JAVA
(e)
ODBC
(f)
PERL
(g)
TCL/TK
(h)
PYTHON
(i)
Web access (PHP)
(j)
Server-side programming (PLPGSQL and SPI)
7.
POSTGRESQL Adminstration
(a)
Creating users and databases
(b)
Backup and restore
(c)
Performance tuning
(d)
Troubleshooting
(e)
Customization options
(f)
Setting access permissions
8.
Additional Resources
(a)
Frequently Asked Questions (FAQ'S)
(b)
Mailing list support
(c)
Supplied documentation
(d)
Commercial support
(e)
Modifying the source code

--ELM939748145-27176-0_
Content-Type: application/pdf
Content-Disposition: inline; filename="/root/book.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjIKJcfsj6IKNCAwIG9iago8PC9MZW5ndGggNSAwIFIvRmlsdGVyIC9GbGF0ZURlY29k
ZT4+CnN0cmVhbQp4nI1b+5+fRXWuVDFd+9ne09pEukuLQJJ9d27vXDahcdeNQYiBxEgCXQK6NBq6
SyAqGkRabG0t1gpWrbfe7MXWv7LPucy8826+i374ge8zO+/MmXObM+ecmMGuGPpP/7+7v/TKkhnc
ys0lZ31eiTmaIYSV/QqzG5xdcdb6wQXg4obkV5wpYfC+4d0lZ4IdchvYmwZyGUKRgTwYNxsZx6Gk
NuJMNAT8kMYK0jjEwOsTTJgIMvYaNEPEzDHiN38TEpNFYKKJ0F6HHKMSaZu7ocwtZsjdpxmflrpJ
yrL1GBvIA5ahHQlmlwdhQRkHT+dzkaA1YGaeoHPCQ0Dltgcf/MpMErtLn8NUS6uMcYieRcMw+CGD
HGvSYEg03nVy8UKOMJbhXqXO+yHkCeZAMmBq7VAsjUQVoTWZtqgjum+yQ8wrM5qEyOD4tCkRkTdO
LDnnaTkbSIT7Ffo0WGgUFh9G0obRy9rEXwWg3MY0ON/9OdBufoSq6m9rh2R5KkHVDHwXhkzqEMsw
EgbpY24Y0zG/HxGqEs5O/Osp5kNBFhgwcciJj0AwZRwhYTI4T0eAVsheUBqfGybSkhtM6mZEUrFS
huwUZJuHMMqJCXpsDUuwyQyFuAOFFu6MrICK6RgGcpsmCJ0O+jauzIiWU/hIf+hE4w0dBNpiMp2L
YXaWddqNBGwknVbgM+kRbTsGPmMOI1upi1AaIhzGzbAMNldI82HNoq3yd4jJjKLpmVgId2GjmIxl
laUR1jlXtdDBisziEVEOHrGDnRQI2BDDgcFHOhJE5l3DtA8UzM6WGN1QOo1zgf4cAp1HgStEGn3M
0GAir00HhqnU3wk6Z0VI4kMy+RIA0CROhM7qXApMs2KmSbinI0wUGC/ebchkNWAjnAK2gJslGAZH
SxSQItoNr0Dz4c5GdpRM6kEoqs9QaajGEFirEmzcpW474Mo2JXFaIs2W2ONTD76zQdE15UKveKyb
3hTaq9dN2LB1wkcYCqknLoqQ2whwYjLhliEy50MZom0YZPrAQuxmWHHTvgGwzASZy4JmH+ihzmYB
HFlFZGb/GyKFxyAIC2G7SHwaHgliwlA0UnUP4xyLuEyIFJ4GmF0o/CmL31vHNyZ0VC65OqDEuDj/
naDk0U+QtibmePEdiXwIH1d5IZg2goozD+oMXDWRRQBSSWBzAYiY4qhXaxVTYGWGgoID+xViRawM
NYL7ZoeDkwe47awAuwcHpgkC6cGMqmJJo4JgILPcRpwvVhWkYsOMSxQo8A3QZsDKM7EW6pWIfvIl
xHp4XI4RMF7YgAPiGXbVhfkXwDLvBIJ24jPcqw0V4KYurCsKM/EdIIh24HwIbIANOW/IyPBcKO04
CqQ9oLNOL3no/oRxbfJOpNN6r0dhVJuB9WP/BX9eV888F7e60b/RZvCVcj+zluO8WZVNnFuA0XXO
ruNhneGT0krXkQDILbMTEIglyCX5zJwCto35YuOJuELTYXc2ijjImXqJmQJfIALg3tK0dNUin1VP
oxou5MveELpYdGkJqdJYCYVu0OawIRJJw4j9jJwzebrcY4IQKWDwdJeQ7hAI8OJOfrOiFlmc/8Tq
DZtuv0Xz2TigP3KVp8KmwBDRgQdJwQWOZMAPkoNjFSHATM8SQRTWUuIiFLOUClyieJAnhunSZHUm
DLfHwkQoFV3Du5346wwmyMtd2BMr1AvHvDpbgQjTCuk02ER6lTx9CZdlrYDdznTpbyQrvorwIcu1
YpDg5Qx1ZAyiKFCLTFvByQaSFdSD4yMK4USpVRwY8KPYqaN7DiOIKnQki+uPjr2qEC9/nh1MTkr+
PPdObIRXjl6tjkOhaaSQgQGbLlBwIwQ0zixnhKtw3YyAy1YM2Q5sqWxoXlSqMzqiHiwIeTaCs8ru
gYJpHhkldMFy/G4IdDmL3yhi7ClqTEYzAFOL2CqQzdPkNfcqhDmQMEKsEeJIrq7RkRIFBLtL3QAH
JiNE48cFkKbzQBo4sE5RfGWRbyeO0G3s7MQUqKwX/w/+sSfyVlQQRsJu1XPowfyWWJiOSwKA/vMx
g7zJRisvT18lxq+ziukD5zl2rhOqxMkzx5WDOsGaM5IviL3mRCPOifyeaE40fLFlPPOUK4WjNnZ8
FJePuLmc+j4KjEZye6lhomxk859mBF2QZCRAeBY1YKdt5DcEnoLsYbowdkQQNn9ajYE5Pc2QZxk2
tBVYo1cQw5TZzvFhkgeexnVjlOfh9LYaJfJtMyLxpkwrHOCZcDY79nRse3JC1nv5jVMV4hwF591z
Z4z6AmjvoRGKZm03g5fFuyfU3/R80FddhLqmWcwZi176eIztV4jNyY1EdpiiDAroDcwMEohbyNPf
yOL5vVzozy6CatcgzYZjKv0EEM3HQJhqGRd5/FBgxi4QsuDXaoZ9kj2DDgJOaGGAe8gWmcswCdEC
Ro41AAbPOGjQiy00suWRvW4EShuTjOhX3YhnF01ZniC6V+nDiQrTJ4mTTNYd6URJbFMw7QwXwf6s
zoCusA+kJzjxgDxRanvQF7jcOe5CZEHug9jKKi10ge2JXFrF9AXdWrabYflCkHi9dBj3AWtPG4CS
jCwIuE/O3AR6tlbY3i3TCDgiVCcNqeWlH8mQfZ8LiPBOuZvg5KWVOdcAaOk+5meJF2k6zSbA/ZEb
jHBjJWtkSpCf9xyGRT2DjsD9GfY/keOyOZyeaTS/jO8yApzEGyVWEuDCGTw6g0mVyKBunrI6dIwZ
9JohYcxc8Jxk0qcHbSpG0lEBDfazJ2ZVokYXWWfjfGe5YtwIjzj6b8adq4eLHJ4JhPOCJmT47DLp
uEtR9bXpUsItMcZuBntXOADTgKxMcxmKRFyiUC6L0tAzKOEKSVFEHmTlUQIi2BD+j4e0JFnpqUwX
XaLXt+ujY+Iav7XxhqTUA8XYHEIhFhjpNE7f0oLxxTQykkXs3TUC7IWshp2wjzI8vAS0gsN3uTcc
KRS/FgPnJlyuabDRaNyWwComHO6Hckj0LmNjifx/RweO/bk4V+UnToiERKYz6bGAwWAacBT07ldI
sSjxsPD/+TEMPYM85bJTzFyP8tarM+idSmeYAOTi5SAMyfWSOHyeefe69OTeKc2SpwlCGFy+W5nR
LIfAgfJMSwupA+syX5L7NGLF8RmvxlIQmrCKUD4LllBs1lc59ivQZWPbO5ucXYztoZ0pF+l0Ki4Y
5XZsoFSVSXzDORLmXoUwNgoLc9J0XpaHBWWP+dbN9enBhw9tZK8baaUBygHnRQPTNzAFzmNPI6Nt
tQLemV9AWSIjAa1WwFAPtNeg5ecqp1ui+DR613EYXRrebcTowF434EQEUdMRBD9HUiqSUK6S9CbL
q5PU2lM8MY3APyJo84YuvSRvMlxl3sCg+aqFVliSHmYgRMkShEBdvUmjvEmgmQpwefHDRiE9r0Za
KgxhKs14U9WqlWpKFhuZ+N9GWmmmUC7bz0eyZB9kxBu+YCEAhMwKqgAEkgAC8ahCR1cpLTNavVPi
SttIcUeejuz1I7Kcr1UegdGI80jEJmU0WTczdi4KMj1wiPMchd6p+xVC4Zh58tjDxYJtAuXTGNCZ
KBQYBdKuHC6IcBqstRTAor4ikknyx26qpGBtw1kHxbR8iBoW6QymChwNcWVGsRwhOr396fLcnwYo
ZRdIQ6ApUnlIkwqIY2ibi2MQ0qmexWWpejDWS4K4HjhDP43Ai3FwCe/Ez3LhmmsjE3W2rBwgVaiv
RZlmMZY1uFaKFEqlyFsodFcp8tb3z29vcR11lSJviqbkXP1dK0UCtVLkubg1ZamxrJlXirBx7keE
Kq0UzSjmQ1mWUa0UCdRKEYDtK0XYK8wrRThF7CtFoI6DQa4UCWiVIoVyIeLD0FeKvHVlXinyNuSu
UqR0SqVoRrScgiLkvlLkHb+9m2gEqmioPtCLxnUZROzscCn3orF5bKKR3000DKtonDx4G+OdCwdE
Q8WaXjROkmoimp5iPpQbbS8ahlU0DmFOLxrn8gHRUKWyF42T7KaIhsEkGtfFgwB5JhoHU5qLxtHl
001gOlU0PdFyihQOiMbTA5wp4/LMfj8y0sgejdT7rY2QWrP1U6IAMPJ9wR4zEfZyQVKQxgzwlAEL
8hjirJv3FBvyYztS9o0XtdIgMDKz2qp55Kexp/IBOzzBtCptonCvwcC/XTn4WzbxIvUGA+eYOMsJ
jnnSLOZ3pqu+w0zlbv8F16xoDaNFWE46KCxCEcIpvoEFIviWrFDmi5lHMgfC6uRpBBcA+/AkuSxP
9U7po4BXXyG4UnsqFNDThi9xhpQoSfXL9kqSnSTMIwk0WuiKVE1qI7aK2SZ9Bt09wubEI0Gyp9MI
AuHUBoQfrBm+AqFw927WqXD0XdbJh94zXDTjOVFUmC2EhauHmIHdpQqVeOg/5fJnyVvoHMmjdqwo
VO5SarXrWPEhlnnHig82zqLQNlBDHh9gsLOOFU+Foq5jBVgjL9I/AS0IYtg6ViqkjhX8llQBfmkT
iHSsVBKk7WRCHGJQ3nfqWOmgzIWB5e5T2F/tWPGSB5eOlQq0Y0Vg7VjBoqbrWAFMXceKDyW1jhXl
tnSszCTBziqw46sdKwqlYwWica1jZZKLF3Ji6DpWlLrasaKwRVmUtJ51rGBp33es6L7SsTKjiYkc
bZp3rMA12nk5oBvhcoDnPON0pVF6dVYOwIjpywGeU5dTOcCPcjxWEfldk/+AYV4O8FR8mJUDMGJn
5QAMpFk5AP7bdeUAwKmBowLZnPWulgMUSjkAi7q+HNDoqOWAboDlNMbQlQM6KOUADPi+HCAH13KA
gloOUKbUcgDzrysHAIe+HMD87ssBGIh9OQA4deUACDDMywEYKV05YJK4lAMO6oRoTh7n5QAfU9/r
pFDDpDjOep1wJfcJeR/NrNcJi7deJ/3dwqQxT71O+G7W64RlD/Q6YeNZ4CRU1TCpp5gPFetDScKk
OE69Tp5yrH2YFP2BXicf7azXCdRNvU4CpjBJoIZJ0c56nXCMA71O2LzvdVI6NUzqiZZTpAO9Tj6x
uMHDkX2RQM+5bU9V3NBZK5Uvc+ylk9zYG6VPlA4rog4jY9OWo+kMmwEnEzXuqSOUIQ+lqROPWG2a
MuTOeCQNQVS6sDuPxYpTkSnAWg8mChRUChgm/E22Y4TILbD8tZ/Hc1+Lp8QqSxH+v8jHbWSkO59O
gEuQ+blghL+SEVqUmyiEA3VHAfBNnOhTmLhMQt8RL1k/OVLDOtpCGOlTMvgigD4dNQnAf0vanmIq
UPmyCqRRU8KcIBRIcQsiCU9ZS0myGtrCSCLSCHFYr9Q/2dZgqr+LJxqbiB0Hmd0hmko5vm5YVqJS
VmtXpqoUGVPoZjC9XGee0S6H0ZrQpM+ZV2+uRqC6mqx2WrU1u5ky08K9q0nykGdXI7+bq2FYXY02
dzRHQknjuauhvFrvapiq6mp6ivlQeCb0roZhdTV01/Wuhrog5q6GMuy9q8mc11RXw2ByNQLV1XCa
t3M1lOueuxo2uW4C06mupidaTpH8AVdTONdc2yoFalulz7yTtFUqqG2VPmvrqLZVAqeurdIXPKT7
tkpfbOnaKj2lhbu2SuA8b6vkkVlbpafkslk80nxVAeu7tkpPuc+urRLYz9sqQamftVV6ei51TQ/g
WVqpbZUKalulQmmrxNrcVERtlfK7tVUqlIZCsCL2bZXAZt5W2bjX2io9VxKntkpPIeXUVukpcz5r
q/TU1te3VQqpB2EtWPECXU8k46mtctqutlVOJLYl2jGmEbjUrq1Sda1yoVM81s0CTZq1VQbjkpRC
altloNyetGJQRQrQSmo2s8MKxkpdtWUCMOKFSbBnAvKclMhN/yitDnWullL2Kgyc/PUFtlpSp1dZ
PO/kqAodspuAQCZFWcDlDnsvTVjTiOPCLHBibpHxEoxi106KWsD0Y/qrtNmSKjJ9FU/LtxG2sL2J
QrXYkqJSmPRITqPG6lpKqa3QOqPoJUExsAAJcXkuv7qCZpfb4uI9eHcvHJRWDRzXrdSKmYApoBao
qQNihKi+pBYKgvA4FWRpOpX0u+QDZehN7FSt5KoylVKtWAZjjPZV8KfANZmmi0MNRm3u1BlVKWXx
g0oqqiwbcjmHnCq1EfqV2lTiqTqQtMIjJ8oSKNRuYIzov+aoMyS/xWViBYVrnCxovn8LOQAsnSVt
T0nWUqVEvlfusUC58DAzspRbMWK/hyMbAd4eMU8wRu3MHXFyToyAwuAbyJIrEyh5qEDlDk4NKvTj
PC0VqDxi9FXsI48EveZqXirQv8VhhZI5jLvsyYQTv5B3l9qIeuG9bgS+cUz0TdDSPp1GEgOa1yAq
p1NPD0XiYO3grCx8ZcXyv1Cq/9vdX9m6srS+uWJXrtxYqv9wac1wEwQFLpFrNlf2H/qVe97z3l+9
931H3r/z0q/9+geWd27/5m/89m/97u8c/b2Hr7y4tEb/vANHvfLCQ79PmKqZBN535A8++IHlPzz2
/uPvue9DR/9odeX+Dx3941X8xx/ZQrmkzDP/5MMPHHtw5+Gdh5ZPnDo5rJl1Z1f9e0+MIa6ZnYdo
ullxxtDU1KbmcuLUxpnT8XTcOHPiVHikTrWJ/gnNSJP/lDAFjgQ2zpzd/MhHt7ZPnKKFdx46fu78
xz7+6P2PXXj84ieOPXH8ycuXlj+5eUUOVFYofU8r7Dz8KRqighfhs5tPXV0z1+57ejVgY1pm+Rx/
gk3tePem/pmzmw+ewmYh0q5Eb4h/dmbjcn+4NShd3a//eN2d3bx05MS4cebkzk4l+tkT4/XjW/fk
srWN0eeex/94DUdrxLvW2Nomkk8OW9vMJSb42Y2PrjuCG3w0BCZrPJdPSpkYZtdlbMEr44ZuS5/6
NA2RWxRuPHgKxlLsqtD2mfWLWHbkZSOC4UXLnsGyu/4ZMPGFay9snMFn6y7zPiUY+uc4NOvP31Uh
Nk+Ma89eOvLJG1cmed/NPZL3Zz93/fjNF2fHjRDuYcfd/guRpfdNmAvkf4CZuu6I+3zBuqfj1rYc
L+FBtUjKpCJ7N9bdulMBK7Ev7W+S0ly/9WB5+epjH3zSPLH9+KQtd6saacsrxwL22z8/F8dLNHDi
1PXbl9yT5vPmSfOFI49POnM3RaQzXzy2tX3tvjXz3LIc87xSdY9SdfvVW7zWBx+/+KTa86FK8qUv
kwQDb4F3nnCJ54DRDG7eEYpfxC4wjbbLfa/d/srR149/9WLdJYSwUM3P3RGS4RRGmEWI/pmqLW9U
Pn72r/7yKri4LCvBYc0WUkquHyebWzMnL5BPEZoOcPHN208sv34MK33ma+6vhaqFS4V4dvO1G7ls
nDl3Z+veNfoT6KrHX/2bza/TEGk8j3zefP6e557fuHz6EbtadaZY/sdv9Oe/hUmQmjy3zEbjn9na
Xn+DjeA2u6QXrt23cRmSWr+YJ6u4m1FkFeyQ1IGIW1mGrkwmkpoqf7r/lAzx2t9tfOPS6lyLMsvk
EHPZu3Huzrk7Jy9sbZ+7QxuQiP7++aeefZQ3ykY3YlYktZmX33r8yDfNJeZO05evf/wf+Fyjcveb
R+HKR3/0AdE+b/Jh1nXrI288sfyoaF+Z7Rdlzle+BUHeUjXZhLieB8UDUwxlrLIIYzzM7m794+ZX
P/zt3bffefnqJ25jnUegJrTOwZP/IqP7zqk1w4agNqeudMTO7+paqFX2MOMjDVQR63JhdLPllAun
H9m6F9oXwyPiC2XpEaHwIQZ367XbL199+51H73/5n/wzuIUv29V6ZbyrcVkWLN5ZSsSd77JgEZQw
Ju0nE36kkuBjPtS+vnfk5AVWe5jZ5cnmjyurJ5/0z98XJ61seeOpq3b15IVcYOk7OzzbeYR2awHx
qmryD+aaLPfRutva/uHR7uKPbiFxp4m4oxti4eEQ8d2D1WTGQoPbOGNXT8PlqJDNYv27dt/ZzY+t
MsfoQsWPm2/96OiP75AP29oO8dwdiTJK4/gPejK2tm/ekQ0sPSQXyRpnPXtrD8J+/eqPluH9niVB
b1yGVxP5mDldyoE1c/bWlZ+8Pf7LxSdfYv04w/rxEn98pn2cF3789OrZ8987SlfQ06ssIjnYi9VD
+V9gEbkLh3Ye/u5dkmzr1rDqM3rziN7EFon86/EHftKFicsIE48jTPzwv/37Y/e/dgOc4WvNGlMd
+3d7gqDL9/z4eQ4XRtK3Rh71y0EtFnjn82+KRlTP+Kn/+L64yiouaPlbb4+vvwUK+NOx7iwr6Skf
vf/td15/66xEHs50zDjgoL/0ZVYysOGnp55bhuldIH/BYRbdKzihfy+RTsQzuPmsjktodpqXg+Jo
CPaOuGnKmBL+9tUvuC8cFzpcWhy5wEefv+LWjOeT57hITdUjSsB469VvEE/X3emoX1E76YKvVLFt
sguNFK77/CsXyXHYVbt6TYhcrM1wz+c1utrMU8BTb7250z3/xWPE1HaLm0NjlktHxAG0oPSg+mzr
Xa+u8KCt6VLXl8UVkrWfe56FKN77UMd5Bep+coAVXn1TApP4LvomHsjGSuSflv9kjxJr5MK3q3XV
i/FfR6Xtsf86W93LJP7//n5/9cwD4BfpyqIz/PQUedv/WcUggp3NH9+xq8yNA14+94I44LR/mXXf
vPE0XTkXyP6n6+DdHPsvs+r3jty88/QUyLlDfffP3A+Prhk6k9+FHx/IZ8+et1jt1ny1xTEwuWmQ
hgPQWapXP9w7642G1+Q2aQ5tJ8qmdhDrs+p/jz9wP8eMFAydlFXiojCeLKm9UtfwMrq+vPWtBd5z
56VXv9W8rfU5H/pSFM2J9E+8Fgez55/6P1Jlcg5QD76U7t278bHVB4VR5vDI9GfumpieW7Q7mO5I
nuu3n9IgJBzqu566+vPVn4u9mcP8zBvf2XkYMaL56i9yMm/eePUbX3O86bkrK5eWLi39P7mPeDtl
bmRzdHJlYW0KZW5kb2JqCjUgMCBvYmoKNjY1NwplbmRvYmoKMyAwIG9iago8PAovVHlwZSAvUGFn
ZQovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUGFyZW50IDIgMCBSCi9SZXNvdXJjZXMgPDwgL1By
b2NTZXQgWy9QREYgL0ltYWdlQiAvVGV4dF0KL0ZvbnQgPDwKL0EgNyAwIFIKPj4KPj4KL0NvbnRl
bnRzIDQgMCBSCj4+CmVuZG9iagoxODAgMCBvYmoKPDwvTGVuZ3RoIDE4MSAwIFIvRmlsdGVyIC9G
bGF0ZURlY29kZT4+CnN0cmVhbQp4nHVUW08TQRhNCCFNH/roSzdklwRStt3uzOzs7KVdm25a5FIK
LVWgLhiE1GhERDRAiJDos4kPokYxivFNvPxE55vZQpGSTWZ3vp453+WcKcpjFcETv9c3k9vJbRWL
WPe1vqmGraRZVrHa6iS7UAM+PDfvqg5meaq2NjM3c2vjrUdJ5qiW2trIlLYmpubRnLIDQcP1VGw7
EL8Je4tKUHW/tHV88pzsjH1KHZ98EVCLcSi7gFoSuqpwRu21MlM/Wp+ceiqg9DJpjKSsVH7wM4QQ
sXmpIngbti6SCL9pta12WHE9V6A8O0ZJHk+iDhJHiwenJZGJedZ5VR/eQ8ju9nnYSISVbO1eiq/5
79G469HArIcny1q2ZqDqfrbmN5eGlzYoizKpKhzFhJL+CXfQwY3Z9PTp2cjOgF+MMoopsmPsEZUv
AJo+PUi8DWRVFm+PEAThX2OjJxMjk1PT+Zn6bHpOmW82lIVbrejJ445J4uSup+egGt2mzEBRRtTi
uCrB9hVl/GKpfGcxmw8rflHPydpXsOZ6vMsoctOyumdmnf9s+4IJu1bvsG27ywSHXNkIcZxzzaJx
KUrcfan8ivhFSwjCJyKZPvYyYW35UObdytZAPd02EC9RzsIhl30TN2K1S+UJjVctiB0aE6/1YjhL
FC0N+03epTUYDuk21ngaGvClGk+6v4FNUiofJ7J5A2EZ9vqNoMCg2lXFQAaC4XeNYFBi96UNKzB9
GDe0yOUL7jaFDgHoVjbQstbdKPFkvfPu/7uHZfCnbsu8SvVRj/nTy5qQExLwrSdtETMSRrgzhOd+
j42mwUdmnQZgBkCl/GYBvUgDD29ey+YF54WlrioBlvq8H+t1ocQ7MSnWlTiscG49Vwge3n/cEXyU
OP3cEFbMrYUOHABf9w6DofP7/OMPBJyY/eWbs79fv0235e3BtkWuN+Punl+krMCkCVb4B+N5xlyP
u5A/3DI1XdDwbq/zXSMhwYWAMijXrBvIamNtaSPuEi7PxV00bNyXCkx2Z5H7YBgO8kkP0oBPP3G1
FtKfAOy0u2cgk1ARdtClWxD/bz7cjx2i51ZT4UCsa43rOmQNwmEhHGaEs1qIwhEHItWW2kg2kv8A
29J6X2VuZHN0cmVhbQplbmRvYmoKMTgxIDAgb2JqCjgzOQplbmRvYmoKMTc5IDAgb2JqCjw8Ci9U
eXBlIC9QYWdlCi9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9QYXJlbnQgMiAwIFIKL1Jlc291cmNl
cyA8PCAvUHJvY1NldCBbL1BERiAvSW1hZ2VCIC9UZXh0XQovRm9udCA8PAovQSA3IDAgUgo+Pgo+
PgovQ29udGVudHMgMTgwIDAgUgo+PgplbmRvYmoKNyAwIG9iago8PC9UeXBlL0ZvbnQvTmFtZS9B
L1N1YnR5cGUvVHlwZTMvRW5jb2RpbmcgNiAwIFIvRmlyc3RDaGFyIDAvTGFzdENoYXIgMTc2L0No
YXJQcm9jczw8L2ExNzUKMTg2IDAgUi9hMTc0CjE4NSAwIFIvYTE3MwoxODQgMCBSL2ExNzIKMTgz
IDAgUi9hMTcwCjE3OCAwIFIvYTE2OAoxNzYgMCBSL2ExNjcKMTc1IDAgUi9hMTY2CjE3NCAwIFIv
YTE2MwoxNzEgMCBSL2ExNjIKMTcwIDAgUi9hMTU5CjE2NyAwIFIvYTE1OAoxNjYgMCBSL2ExNTcK
MTY1IDAgUi9hMTU1CjE2MyAwIFIvYTE1NAoxNjIgMCBSL2ExNTMKMTYxIDAgUi9hMTUyCjE2MCAw
IFIvYTE1MAoxNTggMCBSL2ExNDkKMTU3IDAgUi9hMTQ4CjE1NiAwIFIvYTE0NgoxNTQgMCBSL2Ex
NDQKMTUyIDAgUi9hMTQzCjE1MSAwIFIvYTE0MgoxNTAgMCBSL2ExNDAKMTQ4IDAgUi9hMTM5CjE0
NyAwIFIvYTEzNwoxNDUgMCBSL2ExMzQKMTQyIDAgUi9hMTMzCjE0MSAwIFIvYTEzMgoxNDAgMCBS
L2ExMzEKMTM5IDAgUi9hMTMwCjEzOCAwIFIvYTEyOQoxMzcgMCBSL2ExMjcKMTM1IDAgUi9hMTI1
CjEzMyAwIFIvYTEyNAoxMzIgMCBSL2ExMjMKMTMxIDAgUi9hMTIyCjEzMCAwIFIvYTExOQoxMjcg
MCBSL2ExMTgKMTI2IDAgUi9hMTE3CjEyNSAwIFIvYTExNgoxMjQgMCBSL2ExMTUKMTIzIDAgUi9h
MTEzCjEyMSAwIFIvYTExMgoxMjAgMCBSL2ExMDkKMTE3IDAgUi9hMTA4CjExNiAwIFIvYTEwNwox
MTUgMCBSL2ExMDUKMTEzIDAgUi9hMTAzCjExMSAwIFIvYTEwMQoxMDkgMCBSL2E5NwoxMDUgMCBS
L2E5NQoxMDMgMCBSL2E5NAoxMDIgMCBSL2E5MQo5OSAwIFIvYTg5Cjk3IDAgUi9hODgKOTYgMCBS
L2E4Ngo5NCAwIFIvYTg1CjkzIDAgUi9hODQKOTIgMCBSL2E4Mwo5MSAwIFIvYTgxCjg5IDAgUi9h
ODAKODggMCBSL2E3OQo4NyAwIFIvYTc3Cjg1IDAgUi9hNzUKODMgMCBSL2E3NAo4MiAwIFIvYTcy
CjgwIDAgUi9hNzAKNzggMCBSL2E2OQo3NyAwIFIvYTY2Cjc0IDAgUi9hNjQKNzIgMCBSL2E2Mwo3
MSAwIFIvYTYyCjcwIDAgUi9hNTkKNjcgMCBSL2E1OAo2NiAwIFIvYTU2CjY0IDAgUi9hNTUKNjMg
MCBSL2E1Mgo2MCAwIFIvYTUxCjU5IDAgUi9hNDkKNTcgMCBSL2E0Nwo1NSAwIFIvYTQ1CjUzIDAg
Ui9hNDMKNTEgMCBSL2E0Mgo1MCAwIFIvYTQwCjQ4IDAgUi9hMzkKNDcgMCBSL2EzNwo0NSAwIFIv
YTM2CjQ0IDAgUi9hMzUKNDMgMCBSL2EzMgo0MCAwIFIvYTMxCjM5IDAgUi9hMjkKMzcgMCBSL2Ey
NgozNCAwIFIvYTI0CjMyIDAgUi9hMjMKMzEgMCBSL2EyMQoyOSAwIFIvYTE5CjI3IDAgUi9hMTcK
MjUgMCBSL2ExNQoyMyAwIFIvYTEzCjIxIDAgUi9hMTEKMTkgMCBSL2E5CjE3IDAgUi9hNwoxNSAw
IFIvYTUKMTMgMCBSL2EzCjExIDAgUi9hMQo5IDAgUi9hMAo4IDAgUi9hMTY1CjE3MyAwIFIvYTE1
MQoxNTkgMCBSL2E2MQo2OSAwIFIvYTU0CjYyIDAgUi9hMTQ1CjE1MyAwIFIvYTUzCjYxIDAgUi9h
NDQKNTIgMCBSL2E0MQo0OSAwIFIvYTE2MAoxNjggMCBSL2ExOAoyNiAwIFIvYTQ2CjU0IDAgUi9h
NzYKODQgMCBSL2E5MgoxMDAgMCBSL2ExNjQKMTcyIDAgUi9hNTcKNjUgMCBSL2EyMAoyOCAwIFIv
YTkwCjk4IDAgUi9hNAoxMiAwIFIvYTI1CjMzIDAgUi9hMTYxCjE2OSAwIFIvYTY4Cjc2IDAgUi9h
NjAKNjggMCBSL2E4Mgo5MCAwIFIvYTIyCjMwIDAgUi9hOAoxNiAwIFIvYTQ4CjU2IDAgUi9hMTIx
CjEyOSAwIFIvYTk2CjEwNCAwIFIvYTE0CjIyIDAgUi9hMjgKMzYgMCBSL2EzOAo0NiAwIFIvYTMz
CjQxIDAgUi9hNTAKNTggMCBSL2E3OAo4NiAwIFIvYTEzOAoxNDYgMCBSL2ExNzYKMTg3IDAgUi9h
MjcKMzUgMCBSL2EzNAo0MiAwIFIvYTczCjgxIDAgUi9hMTU2CjE2NCAwIFIvYTk5CjEwNyAwIFIv
YTg3Cjk1IDAgUi9hNgoxNCAwIFIvYTIKMTAgMCBSL2ExMTAKMTE4IDAgUi9hNjcKNzUgMCBSL2Ex
NDEKMTQ5IDAgUi9hMTM2CjE0NCAwIFIvYTEwMgoxMTAgMCBSL2E5MwoxMDEgMCBSL2ExMDYKMTE0
IDAgUi9hOTgKMTA2IDAgUi9hNzEKNzkgMCBSL2E2NQo3MyAwIFIvYTEyNgoxMzQgMCBSL2ExMTEK
MTE5IDAgUi9hMTE0CjEyMiAwIFIvYTMwCjM4IDAgUi9hMTAwCjEwOCAwIFIvYTEwCjE4IDAgUi9h
MTcxCjE4MiAwIFIvYTE0NwoxNTUgMCBSL2ExMjAKMTI4IDAgUi9hMTY5CjE3NyAwIFIvYTE2CjI0
IDAgUi9hMTA0CjExMiAwIFIvYTEyOAoxMzYgMCBSL2ExMzUKMTQzIDAgUi9hMTIKMjAgMCBSPj4v
Rm9udEJCb3hbMCAtNjggMTE1IDExN10vRm9udE1hdHJpeFsxIDAgMCAxIDAgMF0vV2lkdGhzWwow
IDAgNzMgMCA0NSAwIDcyIDAgNTMgMCA4OSAwIDEyMSAwIDU3IDAKOTcgMCAzNiAwIDQzIDAgNTIg
MCAwIDQ2IDAgNjYgNTggMCA4NyAwCjAgNjAgNjcgMCAwIDAgNTkgMCAwIDM0IDAgMCAzMyAwIDM4
IDAKNTQgMCA2MSAwIDAgMzIgMjkgMCAwIDQyIDAgMCA1MCAyOCAwIDAKMCA4MyAwIDc1IDQ4IDAg
MCA4MiAwIDY4IDAgMCAzOSAwIDYyIDAKMCAwIDUxIDAgMCAwIDAgNzEgMCAwIDQ0IDAgNDAgNzkg
MCAwCjU2IDAgODEgNzAgODggMCA3OCAwIDk5IDAgODAgMCAwIDAgNzQgODUKMCAwIDg2IDAgMCAw
IDAgMCA5NSA1NSAwIDAgMCAwIDg0IDAKMTA4IDAgMCAwIDAgMCAwIDExMiA3NyAwIDYzIDAgMCA3
NiAwIDAKMCAzMSAwIDkyIDAgMCAwIDI2IDAgMCAwIDAgNjkgMCAwIDAKMzUgNDcgMCAwIDQxIDI1
IDAgMCAwIDk2IDAgOTAgMCAwIDAgMAo2NF0+PgplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFn
ZXMgL0tpZHMgWwozIDAgUgoxNzkgMCBSCl0gL0NvdW50IDIKPj4KZW5kb2JqCjEgMCBvYmoKPDwg
L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDIgMCBSCj4+CmVuZG9iagoxODggMCBvYmoKPDwgL0NyZWF0
aW9uRGF0ZSAoRDoxOTk5MTAxMjEzMDQyMykKL1Byb2R1Y2VyIChBbGFkZGluIEdob3N0c2NyaXB0
IDUuNTApCj4+CmVuZG9iago2IDAgb2JqCjw8L1R5cGUvRW5jb2RpbmcvRGlmZmVyZW5jZXNbMAov
YTAvYTEvYTIvYTMvYTQvYTUvYTYvYTcvYTgvYTkvYTEwL2ExMS9hMTIvYTEzL2ExNC9hMTUKL2Ex
Ni9hMTcvYTE4L2ExOS9hMjAvYTIxL2EyMi9hMjMvYTI0L2EyNS9hMjYvYTI3L2EyOC9hMjkvYTMw
L2EzMQovYTMyL2EzMy9hMzQvYTM1L2EzNi9hMzcvYTM4L2EzOS9hNDAvYTQxL2E0Mi9hNDMvYTQ0
L2E0NS9hNDYvYTQ3Ci9hNDgvYTQ5L2E1MC9hNTEvYTUyL2E1My9hNTQvYTU1L2E1Ni9hNTcvYTU4
L2E1OS9hNjAvYTYxL2E2Mi9hNjMKL2E2NC9hNjUvYTY2L2E2Ny9hNjgvYTY5L2E3MC9hNzEvYTcy
L2E3My9hNzQvYTc1L2E3Ni9hNzcvYTc4L2E3OQovYTgwL2E4MS9hODIvYTgzL2E4NC9hODUvYTg2
L2E4Ny9hODgvYTg5L2E5MC9hOTEvYTkyL2E5My9hOTQvYTk1Ci9hOTYvYTk3L2E5OC9hOTkvYTEw
MC9hMTAxL2ExMDIvYTEwMy9hMTA0L2ExMDUvYTEwNi9hMTA3L2ExMDgvYTEwOS9hMTEwL2ExMTEK
L2ExMTIvYTExMy9hMTE0L2ExMTUvYTExNi9hMTE3L2ExMTgvYTExOS9hMTIwL2ExMjEvYTEyMi9h
MTIzL2ExMjQvYTEyNS9hMTI2L2ExMjcKL2ExMjgvYTEyOS9hMTMwL2ExMzEvYTEzMi9hMTMzL2Ex
MzQvYTEzNS9hMTM2L2ExMzcvYTEzOC9hMTM5L2ExNDAvYTE0MS9hMTQyL2ExNDMKL2ExNDQvYTE0
NS9hMTQ2L2ExNDcvYTE0OC9hMTQ5L2ExNTAvYTE1MS9hMTUyL2ExNTMvYTE1NC9hMTU1L2ExNTYv
YTE1Ny9hMTU4L2ExNTkKL2ExNjAvYTE2MS9hMTYyL2ExNjMvYTE2NC9hMTY1L2ExNjYvYTE2Ny9h
MTY4L2ExNjkvYTE3MC9hMTcxL2ExNzIvYTE3My9hMTc0L2ExNzUKL2ExNzYvYTE3Ny9hMTc4L2Ex
NzkvYTE4MC9hMTgxL2ExODIvYTE4My9hMTg0L2ExODUvYTE4Ni9hMTg3L2ExODgvYTE4OS9hMTkw
L2ExOTEKL2ExOTIvYTE5My9hMTk0L2ExOTUvYTE5Ni9hMTk3L2ExOTgvYTE5OS9hMjAwL2EyMDEv
YTIwMi9hMjAzL2EyMDQvYTIwNS9hMjA2L2EyMDcKL2EyMDgvYTIwOS9hMjEwL2EyMTEvYTIxMi9h
MjEzL2EyMTQvYTIxNS9hMjE2L2EyMTcvYTIxOC9hMjE5L2EyMjAvYTIyMS9hMjIyL2EyMjMKL2Ey
MjQvYTIyNS9hMjI2L2EyMjcvYTIyOC9hMjI5L2EyMzAvYTIzMS9hMjMyL2EyMzMvYTIzNC9hMjM1
L2EyMzYvYTIzNy9hMjM4L2EyMzkKL2EyNDAvYTI0MS9hMjQyL2EyNDMvYTI0NC9hMjQ1L2EyNDYv
YTI0Ny9hMjQ4L2EyNDkvYTI1MC9hMjUxL2EyNTIvYTI1My9hMjU0L2EyNTUKXSA+PgplbmRvYmoK
OCAwIG9iago8PC9MZW5ndGggMjI5ID4+CnN0cmVhbQowIDAgMCAwIDczIDgzIGQxCjczIDAgMCA4
MyAwIDAgY20KQkkKL0lNIHRydWUvVyA3My9IIDgzL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29s
dW1ucyA3MwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoyWg3ypAxIOCbB7NYOHsoBu/Bvdvw37ft/+3
7/f/v9//////6//69f/S9fr0vS9Lwl6XhLmsKFxBcFwfD5OGd+Dfhv2/b9/v3+//f/7///////9f
r/1+vX69fS9LVLwl4S0DCWhCwgsjBeSsC4AIAIAKRUkKZW5kc3RyZWFtCmVuZG9iago5IDAgb2Jq
Cjw8L0xlbmd0aCAxNzkgPj4Kc3RyZWFtCjAgMCAwIDI3IDQ5IDgzIGQxCjQ5IDAgMCA1NiAwIDI3
IGNtCkJJCi9JTSB0cnVlL1cgNDkvSCA1Ni9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMg
NDkKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqMgYf5DjMMLra/r////////////////////v+/7IJfB
FQE/0/bXW06sMLIxjH+HeHawd8O1g7WHDCgAgAgKRUkKZW5kc3RyZWFtCmVuZG9iagoxMCAwIG9i
ago8PC9MZW5ndGggMTY+PgpzdHJlYW0KNzMgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoK
MTEgMCBvYmoKPDwvTGVuZ3RoIDE5OCA+PgpzdHJlYW0KMCAwIDAgMjcgNzQgODQgZDEKNzQgMCAw
IDU3IDAgMjcgY20KQkkKL0lNIHRydWUvVyA3NC9IIDU3L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQov
Q29sdW1ucyA3NAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoZRIDB4MQQcPQcHhBwenD7g9Bw6OoRzp
LhBuh0g3XQb+mK99X6D////////////////////////////////////+uq6rhQuSEEGC/8AEAEAK
RUkKZW5kc3RyZWFtCmVuZG9iagoxMiAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KNDUgMCAw
IDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKPDwvTGVuZ3RoIDE5NyA+PgpzdHJl
YW0KMCAwIDAgMjcgNTMgODUgZDEKNTMgMCAwIDU4IDAgMjcgY20KQkkKL0lNIHRydWUvVyA1My9I
IDU4L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1MwovQmxhY2tJczEgdHJ1ZQo+PgpJ
RCAmoFyGC8IHhPCD09PT09PXmsK9BA/Tek/Tek/Tfvpft6++uvw9f//1//+//+5DMjwQe2n/6e37
/1trt/1trsOttLDDCC2KwwsMLBk4LgAgAgpFSQplbmRzdHJlYW0KZW5kb2JqCjE0IDAgb2JqCjw8
L0xlbmd0aCAxNj4+CnN0cmVhbQo3MiAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxNSAw
IG9iago8PC9MZW5ndGggMjAxID4+CnN0cmVhbQowIDAgMCAyNyA1OCA4NSBkMQo1OCAwIDAgNTgg
MCAyNyBjbQpCSQovSU0gdHJ1ZS9XIDU4L0ggNTgvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1
bW5zIDU4Ci9CbGFja0lzMSB0cnVlCj4+CklEICahlkMCJBQMwg8IPT0Hp6enroiAR6BBvhBvSfpv
QT/9N6T9ft66g9f1//1//+/KmG/98+GX9b/+2l/v91trult1tpbaWw0tgwlhisMLDCwYKACACApF
SQplbmRzdHJlYW0KZW5kb2JqCjE2IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo1MyAwIDAg
MCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxNyAwIG9iago8PC9MZW5ndGggMjczID4+CnN0cmVh
bQowIDAgMCAxIDExNSA4NSBkMQoxMTUgMCAwIDg0IDAgMSBjbQpCSQovSU0gdHJ1ZS9XIDExNS9I
IDg0L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAxMTUKL0JsYWNrSXMxIHRydWUKPj4K
SUQgJqRAw0GA0f8hRCkDBPIYIshmJ9pWtq2v33Trr/Tf/9P//T//0//9P//khP9X/q/1f+r/V/6/
1b/r/W/6f9b/p/+/0n/7/V/6v9X/q/1f+r/V/6v9X/q///Sb//9Jv//1f+r/V/6v9X/q/1f+r/V/
6v/f9K///Sb//9W/6/1b/r+Nj6/fr9+vV+r99L1vCt5Goh6sqA31gAgAgApFSQplbmRzdHJlYW0K
ZW5kb2JqCjE4IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo4OSAwIDAgMCAwIDAgZDEKZW5k
c3RyZWFtCmVuZG9iagoxOSAwIG9iago8PC9MZW5ndGggMjAzID4+CnN0cmVhbQowIDAgMCAyNyA1
OCA4NSBkMQo1OCAwIDAgNTggMCAyNyBjbQpCSQovSU0gdHJ1ZS9XIDU4L0ggNTgvQlBDIDEvRi9D
Q0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU4Ci9CbGFja0lzMSB0cnVlCj4+CklEICahoOoKIQPBA9B4
RDCvQQYegg3pN6Terelek3/pX7el/el+3r/9X/H/2v//15NV/+vXf+u13/S39tL63XbS20vrbCWG
0thoLYYJYYhYYWGFkFBEAEAECkVJCmVuZHN0cmVhbQplbmRvYmoKMjAgMCBvYmoKPDwvTGVuZ3Ro
IDE3Pj4Kc3RyZWFtCjEyMSAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoyMSAwIG9iago8
PC9MZW5ndGggMjM0ID4+CnN0cmVhbQowIDAgMCAyNyAxMDggODMgZDEKMTA4IDAgMCA1NiAwIDI3
IGNtCkJJCi9JTSB0cnVlL1cgMTA4L0ggNTYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5z
IDEwOAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmpEDIgZf8hRhBgQQXEYaDCDC6aa2q+na3////////
//////////////////////////////////////7TXuHXDRDT+UJ7a6sNWH6sNJhpZKFDDCsMLxsU
xWHaawdprDhprB2g1g4YQYWHBhBhQAQAQApFSQplbmRzdHJlYW0KZW5kb2JqCjIyIDAgb2JqCjw8
L0xlbmd0aCAxNj4+CnN0cmVhbQo1NyAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoyMyAw
IG9iago8PC9MZW5ndGggMTkyID4+CnN0cmVhbQowIDAgMCAwIDMyIDExNyBkMQozMiAwIDAgMTE3
IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDMyL0ggMTE3L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29s
dW1ucyAzMgovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoUzBIQPT4eiifT+31fT7317V4/9///3/////
///////////////////////XyBGl7w94eHh4P/////kC+aen/db//W/W1ABABApFSQplbmRzdHJl
YW0KZW5kb2JqCjI0IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo5NyAwIDAgMCAwIDAgZDEK
ZW5kc3RyZWFtCmVuZG9iagoyNSAwIG9iago8PC9MZW5ndGggMTc1ID4+CnN0cmVhbQowIDAgMCAw
IDM3IDgzIGQxCjM3IDAgMCA4MyAwIDAgY20KQkkKL0lNIHRydWUvVyAzNy9IIDgzL0JQQyAxL0Yv
Q0NGL0RQPDwvSyAtMQovQ29sdW1ucyAzNwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmo/kOM2Ftftf/
///////////////////////r+RuvHvg+D4Ph8Hx/////IMfhPQeun//v+11tYYUAEAEKRUkKZW5k
c3RyZWFtCmVuZG9iagoyNiAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KMzYgMCAwIDAgMCAw
IGQxCmVuZHN0cmVhbQplbmRvYmoKMjcgMCBvYmoKPDwvTGVuZ3RoIDIxMyA+PgpzdHJlYW0KMCAw
IDAgMjcgNTMgODQgZDEKNTMgMCAwIDU3IDAgMjcgY20KQkkKL0lNIHRydWUvVyA1My9IIDU3L0JQ
QyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1MwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmopQD
BmJCDQeg08INPTh9roO+dBXIc4oG6D0GN6adB3f6/k1X//3+/f2/b9v2/Yfhh+GH4Yfhh+GD8GD8
MeD4Pg/5fevp//f///67/pb/aWw0thhLDFYawwWQX1gAgAgKRUkKZW5kc3RyZWFtCmVuZG9iagoy
OCAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KNDMgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQpl
bmRvYmoKMjkgMCBvYmoKPDwvTGVuZ3RoIDE5NiA+PgpzdHJlYW0KMCAwIDAgMjcgNzMgODMgZDEK
NzMgMCAwIDU2IDAgMjcgY20KQkkKL0lNIHRydWUvVyA3My9IIDU2L0JQQyAxL0YvQ0NGL0RQPDwv
SyAtMQovQ29sdW1ucyA3MwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmpkDH7yEGENCfDCYW01/tNf//
///////////////////////////////9r3912vKEH6tr7DSybqGDC8bFYdrDtYOGsHDWDhhYcMKA
CACACkVJCmVuZHN0cmVhbQplbmRvYmoKMzAgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjUy
IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjMxIDAgb2JqCjw8L0xlbmd0aCAyNTEgPj4K
c3RyZWFtCjAgMCAwIDAgOTYgODcgZDEKOTYgMCAwIDg3IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDk2
L0ggODcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDk2Ci9CbGFja0lzMSB0cnVlCj4+
CklEICag2lOGrIapPBA8IHhHQMB4QIGHhBBh6CDeEEw9JvSDekw9JvSvVvSb69W9Jv70n1v70n+9
J/v/X6b/1/v/369f7//////////vXr3//71/67df712v1v7aX+6Xdbrt1ul2lt1ultpbaWG0ttLY
YS20FhhhLDDCCwwZBNMMQsMLBgsgqVQAQAQKRUkKZW5kc3RyZWFtCmVuZG9iagozMiAwIG9iago8
PC9MZW5ndGggMTc3ID4+CnN0cmVhbQowIDAgMCA5IDQyIDg0IGQxCjQyIDAgMCA3NSAwIDkgY20K
QkkKL0lNIHRydWUvVyA0Mi9IIDc1L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0Mgov
QmxhY2tJczEgdHJ1ZQo+PgpJRCAmoKCcSEHoPT09e+Qyek/TfB9P////////////////////////
//5GJf++GawxD77777777/vv+/7/8AEAEApFSQplbmRzdHJlYW0KZW5kb2JqCjMzIDAgb2JqCjw8
L0xlbmd0aCAxNj4+CnN0cmVhbQo0NiAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagozNCAw
IG9iago8PC9MZW5ndGggMjI3ID4+CnN0cmVhbQowIDAgMCAtNCA2NSA4NCBkMQo2NSAwIDAgODgg
MCAtNCBjbQpCSQovSU0gdHJ1ZS9XIDY1L0ggODgvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1
bW5zIDY1Ci9CbGFja0lzMSB0cnVlCj4+CklEICahlHUC8g3B4IHgg8I1hXhAgw9JvhBvpvhX7ft/
ft+/3/7f/3/7f///3/////1///+l//6/Xr9drw17S7S5Qg19sJfBhL2K9rw17XteGF4YXgzMNHH/
///////////X80BdDwfD4Pg+HweACACACkVJCmVuZHN0cmVhbQplbmRvYmoKMzUgMCBvYmoKPDwv
TGVuZ3RoIDE2Pj4Kc3RyZWFtCjY2IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjM2IDAg
b2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo1OCAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9i
agozNyAwIG9iago8PC9MZW5ndGggMTc2ID4+CnN0cmVhbQowIDAgMCAwIDQ2IDgxIGQxCjQ2IDAg
MCA4MSAwIDAgY20KQkkKL0lNIHRydWUvVyA0Ni9IIDgxL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQov
Q29sdW1ucyA0NgovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmp/IITBLBghw11v1/////////////////
///////////////////////r+uXy8eD4Pg+HwfB8HweACACACkVJCmVuZHN0cmVhbQplbmRvYmoK
MzggMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjg3IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0K
ZW5kb2JqCjM5IDAgb2JqCjw8L0xlbmd0aCAyMTQgPj4Kc3RyZWFtCjAgMCAwIDAgNjAgODMgZDEK
NjAgMCAwIDgzIDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDYwL0ggODMvQlBDIDEvRi9DQ0YvRFA8PC9L
IC0xCi9Db2x1bW5zIDYwCi9CbGFja0lzMSB0cnVlCj4+CklEICakVI/+3h99vfb2cBo7YPtt7Yfb
fbbtg7e3t7e3t7e3t7e3t7e33t7e/e3t977fe3+33+33+3/9//f/+RXX/v/7X/bS7+1217rtdhhL
YaXBguxW1tbWwtrDBYYWDKALgAgAgApFSQplbmRzdHJlYW0KZW5kb2JqCjQwIDAgb2JqCjw8L0xl
bmd0aCAxNTkgPj4Kc3RyZWFtCjAgMCAwIDY4IDMwIDEwMSBkMQozMCAwIDAgMzMgMCA2OCBjbQpC
SQovSU0gdHJ1ZS9XIDMwL0ggMzMvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDMwCi9C
bGFja0lzMSB0cnVlCj4+CklEICakbDRg8MPBg8MPDew8N7e33t797/3/ISawh1rr/662trrDCwwU
AEAECkVJCmVuZHN0cmVhbQplbmRvYmoKNDEgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjYw
IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjQyIDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0
cmVhbQo2NyAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago0MyAwIG9iago8PC9MZW5ndGgg
MjM2ID4+CnN0cmVhbQowIDAgMCAwIDU5IDg1IGQxCjU5IDAgMCA4NSAwIDAgY20KQkkKL0lNIHRy
dWUvVyA1OS9IIDg1L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1OQovQmxhY2tJczEg
dHJ1ZQo+PgpJRCAmopIDXzUGnIMUwweDDw3sPDD29vDew9vb729vfb72/29v9vv9v98gXpeQ0V+E
G3hB+g/QZSNGoQeggfQQN6T6Qfr1+r/S/66v/X//9f/X/+/6/X+/9eu3X+6X+2l/tpbpd1trtpba
W2EFsGEsMVsLBhYM0BQACACACkVJCmVuZHN0cmVhbQplbmRvYmoKNDQgMCBvYmoKPDwvTGVuZ3Ro
IDE2NSA+PgpzdHJlYW0KMCAwIDAgMCA0MyA2NyBkMQo0MyAwIDAgNjcgMCAwIGNtCkJJCi9JTSB0
cnVlL1cgNDMvSCA2Ny9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNDMKL0JsYWNrSXMx
IHRydWUKPj4KSUQgJqJ8gRVtdbX/////////////////////////////////r+uR+uGPB8HwfB8H
weACACAKRUkKZW5kc3RyZWFtCmVuZG9iago0NSAwIG9iago8PC9MZW5ndGggMTMyID4+CnN0cmVh
bQowIDAgMCA1OCAxMiA3MCBkMQoxMiAwIDAgMTIgMCA1OCBjbQpCSQovSU0gdHJ1ZS9XIDEyL0gg
MTIvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDEyCi9CbGFja0lzMSB0cnVlCj4+CklE
ICaxxwg+478mqW1tQAQAQApFSQplbmRzdHJlYW0KZW5kb2JqCjQ2IDAgb2JqCjw8L0xlbmd0aCAx
Nj4+CnN0cmVhbQo1OSAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago0NyAwIG9iago8PC9M
ZW5ndGggMTYxID4+CnN0cmVhbQowIDAgMCAwIDMzIDY5IGQxCjMzIDAgMCA2OSAwIDAgY20KQkkK
L0lNIHRydWUvVyAzMy9IIDY5L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAzMwovQmxh
Y2tJczEgdHJ1ZQo+PgpJRCAmt8iV4YW1+1/////////////////////////////////////6f6eE
HmA+ACACCkVJCmVuZHN0cmVhbQplbmRvYmoKNDggMCBvYmoKPDwvTGVuZ3RoIDE4NSA+PgpzdHJl
YW0KMCAwIDAgMjIgNTggNjkgZDEKNTggMCAwIDQ3IDAgMjIgY20KQkkKL0lNIHRydWUvVyA1OC9I
IDQ3L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1OAovQmxhY2tJczEgdHJ1ZQo+PgpJ
RCAmuVZeQheR6hnQ7Ca3a6r/////////////////////////////hr3XBFQvsP1bSzurBheNisO+
DhrB2sOGFg4MFABABApFSQplbmRzdHJlYW0KZW5kb2JqCjQ5IDAgb2JqCjw8L0xlbmd0aCAxNj4+
CnN0cmVhbQozNCAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago1MCAwIG9iago8PC9MZW5n
dGggMTY5ID4+CnN0cmVhbQowIDAgMCA3IDMzIDcwIGQxCjMzIDAgMCA2MyAwIDcgY20KQkkKL0lN
IHRydWUvVyAzMy9IIDYzL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAzMwovQmxhY2tJ
czEgdHJ1ZQo+PgpJRCAmoMGYsIPT09Pvk5vSD+3oH//////////////////////8xj8PhkMEvvvv
vvvv+/7/v8AEAEAKRUkKZW5kc3RyZWFtCmVuZG9iago1MSAwIG9iago8PC9MZW5ndGggMTcyID4+
CnN0cmVhbQowIDAgMCAyMiAzOCA2OSBkMQozOCAwIDAgNDcgMCAyMiBjbQpCSQovSU0gdHJ1ZS9X
IDM4L0ggNDcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDM4Ci9CbGFja0lzMSB0cnVl
Cj4+CklEICaxVhIMLDOgL2tr+v////////////////77/shL4Ip0/tPtrWGFmqY7vDvDvB2sO1g4
YUAEAEAKRUkKZW5kc3RyZWFtCmVuZG9iago1MiAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0K
MzMgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKNTMgMCBvYmoKPDwvTGVuZ3RoIDE5NCA+
PgpzdHJlYW0KMCAwIDAgMjIgNTIgNzEgZDEKNTIgMCAwIDQ5IDAgMjIgY20KQkkKL0lNIHRydWUv
VyA1Mi9IIDQ5L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1MgovQmxhY2tJczEgdHJ1
ZQo+PgpJRCAmoNycNEEawXhB4RQMPQQMPQTek3pN6V6t6X7elf+lfvr9X/r//ev////1v/9eu/3W
6/W/tpelt+6W2ltoLDDCWwwlhiFhgsgXpABABApFSQplbmRzdHJlYW0KZW5kb2JqCjU0IDAgb2Jq
Cjw8L0xlbmd0aCAxNj4+CnN0cmVhbQozOCAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago1
NSAwIG9iago8PC9MZW5ndGggMjE2ID4+CnN0cmVhbQowIDAgMCAtNCA1OSA3MCBkMQo1OSAwIDAg
NzQgMCAtNCBjbQpCSQovSU0gdHJ1ZS9XIDU5L0ggNzQvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9D
b2x1bW5zIDU5Ci9CbGFja0lzMSB0cnVlCj4+CklEICahsJwhwEggcPCcHhBwenB6cOjqK5Qa0EDG
Ok1oJ+g+v19ev1/6/X///1/////7///+3/7/+3+u37/a7a7a7a4Ya7DCPrhivDC8GC8f////////
/1/XINaffB8Pg+HweACACApFSQplbmRzdHJlYW0KZW5kb2JqCjU2IDAgb2JqCjw8L0xlbmd0aCAx
Nj4+CnN0cmVhbQo1NCAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago1NyAwIG9iago8PC9M
ZW5ndGggMTg2ID4+CnN0cmVhbQowIDAgMCAyMiA1OSA3MCBkMQo1OSAwIDAgNDggMCAyMiBjbQpC
SQovSU0gdHJ1ZS9XIDU5L0ggNDgvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU5Ci9C
bGFja0lzMSB0cnVlCj4+CklEICahnJwQ2CQg4PCDg9Bw9OD7h0SBXKLQQMOgeg3+xXT6h+n/////
/////////////////////////1X1woXNUQxX/ABABApFSQplbmRzdHJlYW0KZW5kb2JqCjU4IDAg
b2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo2MSAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9i
ago1OSAwIG9iago8PC9MZW5ndGggMTg2ID4+CnN0cmVhbQowIDAgMCAyMiA0MiA3MSBkMQo0MiAw
IDAgNDkgMCAyMiBjbQpCSQovSU0gdHJ1ZS9XIDQyL0ggNDkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0x
Ci9Db2x1bW5zIDQyCi9CbGFja0lzMSB0cnVlCj4+CklEICahnNAeCB4T0Hp6enro6jfCBvQT9BvS
f70n6f70/6+g///1//+//5Bve6D7XdP/b/rbXf2620thpbDS2IWGFgzMHABABApFSQplbmRzdHJl
YW0KZW5kb2JqCjYwIDAgb2JqCjw8L0xlbmd0aCAxNjcgPj4Kc3RyZWFtCjAgMCAwIDAgMjggNjkg
ZDEKMjggMCAwIDY5IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDI4L0ggNjkvQlBDIDEvRi9DQ0YvRFA8
PC9LIC0xCi9Db2x1bW5zIDI4Ci9CbGFja0lzMSB0cnVlCj4+CklEICa2Rl4Z0O11v///////////
/////////r+YdePD4Ph8HwfH////IWeE9e//9+trDCgAgAgKRUkKZW5kc3RyZWFtCmVuZG9iago2
MSAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KMzIgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQpl
bmRvYmoKNjIgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjI5IDAgMCAwIDAgMCBkMQplbmRz
dHJlYW0KZW5kb2JqCjYzIDAgb2JqCjw8L0xlbmd0aCAxOTcgPj4Kc3RyZWFtCjAgMCAwIDAgNDgg
NjkgZDEKNDggMCAwIDY5IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDQ4L0ggNjkvQlBDIDEvRi9DQ0Yv
RFA8PC9LIC0xCi9Db2x1bW5zIDQ4Ci9CbGFja0lzMSB0cnVlCj4+CklEICaxKT3++G999vZsDHbB
vbfbfbbtg7e3t7e3t7e3t7fe3t7e3+3t9797f7ff979//9/+W/69/+2v/aXa7fwwlsNeDCWxW1tb
W1hhbCwZOGgAEAEKRUkKZW5kc3RyZWFtCmVuZG9iago2NCAwIG9iago8PC9MZW5ndGggMTk2ID4+
CnN0cmVhbQowIDAgMCAyMiA0MCA3MSBkMQo0MCAwIDAgNDkgMCAyMiBjbQpCSQovSU0gdHJ1ZS9X
IDQwL0ggNDkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQwCi9CbGFja0lzMSB0cnVl
Cj4+CklEICasuEKATE6iYffJAV8EGH0/Cb6vr/6vS/69YrWEsLhLBLCWEsJYQWgtAtBaBcLhaC6I
Zx+EvX/0v+6/7a+u2uwwuwZYex4ZTrgzMJgAgAgKRUkKZW5kc3RyZWFtCmVuZG9iago2NSAwIG9i
ago8PC9MZW5ndGggMTY+PgpzdHJlYW0KNDIgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoK
NjYgMCBvYmoKPDwvTGVuZ3RoIDIwMCA+PgpzdHJlYW0KMCAwIDAgMjIgNDggNzAgZDEKNDggMCAw
IDQ4IDAgMjIgY20KQkkKL0lNIHRydWUvVyA0OC9IIDQ4L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQov
Q29sdW1ucyA0OAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoczBzwsEGgeg08J3w09O+SBuT3QQYw3o
NP3eg//X/v/7/fv7ft+w/DfsPwwfhh+GD8GPB8Hw++R96/f////6712u3W2F2GEFhisMLIEIgAgA
gApFSQplbmRzdHJlYW0KZW5kb2JqCjY3IDAgb2JqCjw8L0xlbmd0aCAxNjYgPj4Kc3RyZWFtCjAg
MCAwIC00IDI4IDY5IGQxCjI4IDAgMCA3MyAwIC00IGNtCkJJCi9JTSB0cnVlL1cgMjgvSCA3My9C
UEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgMjgKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrfI
uu1tdb/////////////////////////////////////+v65q98Hw+D4fDwAQAQpFSQplbmRzdHJl
YW0KZW5kb2JqCjY4IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo1MCAwIDAgMCAwIDAgZDEK
ZW5kc3RyZWFtCmVuZG9iago2OSAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KMjggMCAwIDAg
MCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKNzAgMCBvYmoKPDwvTGVuZ3RoIDE4NyA+PgpzdHJlYW0K
MCAwIDAgMCAzMSA5MyBkMQozMSAwIDAgOTMgMCAwIGNtCkJJCi9JTSB0cnVlL1cgMzEvSCA5My9C
UEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgMzEKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqGb
pYS0tLXS0tLS1610utdL9etf61/S//1/r9f//1///////////f///37/9//b/f+9/2/32/29vfvb
329vb28N7e2ACACACkVJCmVuZHN0cmVhbQplbmRvYmoKNzEgMCBvYmoKPDwvTGVuZ3RoIDE4OCA+
PgpzdHJlYW0KMCAwIDAgLTMgMjggOTAgZDEKMjggMCAwIDkzIDAgLTMgY20KQkkKL0lNIHRydWUv
VyAyOC9IIDkzL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAyOAovQmxhY2tJczEgdHJ1
ZQo+PgpJRCAmrLg3t7D29vYe3t797e33v3v33v3+/f97//f/+3///9////////6///+v1/r/0v/S
/rXrXr9LS/S60tetLS0FpaWgoAIAIApFSQplbmRzdHJlYW0KZW5kb2JqCjcyIDAgb2JqCjw8L0xl
bmd0aCAyMzQgPj4Kc3RyZWFtCjAgMCAwIC0yIDc0IDcxIGQxCjc0IDAgMCA3MyAwIC0yIGNtCkJJ
Ci9JTSB0cnVlL1cgNzQvSCA3My9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNzQKL0Js
YWNrSXMxIHRydWUKPj4KSUQgJqGmdAMSDQryGUN4RDCg8IoAgPCCBh4QQb0vCXoL0vX0vS+vX0vr
19L//0v/X6//9f/r//9P/0/BPyDSY/yBWa/f+/3/9v/2yCsP67/a7+2v+2lt+69rt+2uGwu2uw12
GFwwwXDIYyG+GJoJwYKshpT4AIAICkVJCmVuZHN0cmVhbQplbmRvYmoKNzMgMCBvYmoKPDwvTGVu
Z3RoIDE2Pj4Kc3RyZWFtCjgzIDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjc0IDAgb2Jq
Cjw8L0xlbmd0aCAxOTEgPj4Kc3RyZWFtCjAgMCAwIDIyIDQ2IDcxIGQxCjQ2IDAgMCA0OSAwIDIy
IGNtCkJJCi9JTSB0cnVlL1cgNDYvSCA0OS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMg
NDYKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqGw0BeCB4IPTwg9PT0+ahHoEH0EG+m9J+n0m+v36uk/
D/X//X/+/JUG/9nAUfX+/2u9d+6W2lt1tpbDCWwwlhiFhhZBvSACACAKRUkKZW5kc3RyZWFtCmVu
ZG9iago3NSAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KNzUgMCAwIDAgMCAwIGQxCmVuZHN0
cmVhbQplbmRvYmoKNzYgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjQ4IDAgMCAwIDAgMCBk
MQplbmRzdHJlYW0KZW5kb2JqCjc3IDAgb2JqCjw8L0xlbmd0aCAyMzcgPj4Kc3RyZWFtCjAgMCAw
IDIyIDU1IDk3IGQxCjU1IDAgMCA3NSAwIDIyIGNtCkJJCi9JTSB0cnVlL1cgNTUvSCA3NS9CUEMg
MS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTUKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqGchgok
HCYQPBA9B6eg9FOC75DDKegQN9N7Qb6f73ff+7fftrdbYLbIo1YrXCWl1oLguawzc0DVtdb/t77e
3sM6NiD4eEUEHoIN6CDek3rfTev03/r/fX/////6W//9ba/W6Kdb907a20thhGgYhiFhhYMFABAB
CkVJCmVuZHN0cmVhbQplbmRvYmoKNzggMCBvYmoKPDwvTGVuZ3RoIDE5MSA+PgpzdHJlYW0KMCAw
IDAgMCA1OSA2OSBkMQo1OSAwIDAgNjkgMCAwIGNtCkJJCi9JTSB0cnVlL1cgNTkvSCA2OS9CUEMg
MS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTkKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrEbAv8h
E+GFtftf///////////////+T04lOHw+QwgfBBvw37ft+37/fv9/+/3/////1/69fr/0vS9L0tUv
QWjWNaEFggswrABABApFSQplbmRzdHJlYW0KZW5kb2JqCjc5IDAgb2JqCjw8L0xlbmd0aCAxNj4+
CnN0cmVhbQo4MiAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago4MCAwIG9iago8PC9MZW5n
dGggMjEwID4+CnN0cmVhbQowIDAgMCAxMiA1OSA3MSBkMQo1OSAwIDAgNTkgMCAxMiBjbQpCSQov
SU0gdHJ1ZS9XIDU5L0ggNTkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU5Ci9CbGFj
a0lzMSB0cnVlCj4+CklEICahlHAzJDRXhA8ESGHo0BA8IIMPQQb0mHhJvSb6b1b0vSb+9J/vX6b/
1v/3647/////Jqtdr//vX+2l/vXa712lv7aW2lultpbaWw0sNhBYYMEFhiFhhZAuRABABApFSQpl
bmRzdHJlYW0KZW5kb2JqCjgxIDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo2OCAwIDAgMCAw
IDAgZDEKZW5kc3RyZWFtCmVuZG9iago4MiAwIG9iago8PC9MZW5ndGggMjA5ID4+CnN0cmVhbQow
IDAgMCAxMiAzOCA3MSBkMQozOCAwIDAgNTkgMCAxMiBjbQpCSQovSU0gdHJ1ZS9XIDM4L0ggNTkv
QlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDM4Ci9CbGFja0lzMSB0cnVlCj4+CklEICao
jhg4C/ITXyRfiaMPkgO+Cb6DfCb6vp+r//6v/X+l69Ypa4S1wlhLCWEsILSwgtLCC0FpcLQWlwoq
iGh666/pfk1X9f9tfXbXbXbC7DCP/YgnwwnwzQEwAQAQCkVJCmVuZHN0cmVhbQplbmRvYmoKODMg
MCBvYmoKPDwvTGVuZ3RoIDE2OCA+PgpzdHJlYW0KMCAwIDAgMTMgNTQgNjkgZDEKNTQgMCAwIDU2
IDAgMTMgY20KQkkKL0lNIHRydWUvVyA1NC9IIDU2L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29s
dW1ucyA1NAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoEFQHkC4e11tf///////////////////////
/+Rvhb/+v17//71/Xh68PC8R/8AEAEAKRUkKZW5kc3RyZWFtCmVuZG9iago4NCAwIG9iago8PC9M
ZW5ndGggMTY+PgpzdHJlYW0KMzkgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKODUgMCBv
YmoKPDwvTGVuZ3RoIDIxMiA+PgpzdHJlYW0KMCAwIDAgMTIgNTYgNzEgZDEKNTYgMCAwIDU5IDAg
MTIgY20KQkkKL0lNIHRydWUvVyA1Ni9IIDU5L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1u
cyA1NgovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoZh4G8hsGYIkw8IhmHhE4YB4QQN6C8JegvS9fr0v
S/9L1+v/X6//4+v//XTwnkDAOQVzXJqv9/v/e5DUf/b/Xb/9tdv213XbS2Gu2uwwuGGC7E8fBlOJ
wZQCYAIAIApFSQplbmRzdHJlYW0KZW5kb2JqCjg2IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVh
bQo2MiAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago4NyAwIG9iago8PC9MZW5ndGggMTk1
ID4+CnN0cmVhbQowIDAgMCAxMyA1MiA2OSBkMQo1MiAwIDAgNTYgMCAxMyBjbQpCSQovSU0gdHJ1
ZS9XIDUyL0ggNTYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDUyCi9CbGFja0lzMSB0
cnVlCj4+CklEICDDEmpkgM4LYUF6W0gvr19L0v/S9L/0vS/9L0v/S9L/0vS9friv4PnxQfg34b8N
+39+3/7/f/////r9f+v16XpeEtEM1oQohSkAwACACApFSQplbmRzdHJlYW0KZW5kb2JqCjg4IDAg
b2JqCjw8L0xlbmd0aCAxNzkgPj4Kc3RyZWFtCjAgMCAwIDEzIDQ0IDY5IGQxCjQ0IDAgMCA1NiAw
IDEzIGNtCkJJCi9JTSB0cnVlL1cgNDQvSCA1Ni9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVt
bnMgNDQKL0JsYWNrSXMxIHRydWUKPj4KSUQgJSyan2Tgx2g30/v7+3/7/fv/7fD///kNA///r/6/
+F4//nwX+H/9////H///8gXf//6/9f/X11C6HHwAQAQKRUkKZW5kc3RyZWFtCmVuZG9iago4OSAw
IG9iago8PC9MZW5ndGggMjMwID4+CnN0cmVhbQowIDAgMCAtMiA1MSA3MSBkMQo1MSAwIDAgNzMg
MCAtMiBjbQpCSQovSU0gdHJ1ZS9XIDUxL0ggNzMvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1
bW5zIDUxCi9CbGFja0lzMSB0cnVlCj4+CklEICasuDBQDHIcR4IPssgio4ggb4IN8JvpvpvhN9X7
9f31//evr/S/66WKWuF0sJYXCWlhLCWEFhLQWEsILQWloLQWgtLhaC60F0Qyn69L6/+vdev1//3X
/bX12121212wuwwuyQyc+GIT4YLyGj3gAgAgCkVJCmVuZHN0cmVhbQplbmRvYmoKOTAgMCBvYmoK
PDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjUxIDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjkx
IDAgb2JqCjw8L0xlbmd0aCAyNTkgPj4Kc3RyZWFtCjAgMCAwIC0yIDc4IDg3IGQxCjc4IDAgMCA4
OSAwIC0yIGNtCkJJCi9JTSB0cnVlL1cgNzgvSCA4OS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0Nv
bHVtbnMgNzgKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqB4iyB6IyC0fILB8ILBBYQWEsILCWEtLCWE
tdLCWlrpYQPBA8IkBA8IEQYPhAgw8JBvQTD0m9JvSb1b0m9JvW9Jv/Sb+9J/vX9vr1/v/30v7///
//////W6/9/1v+v1t/1uvdbrt16W37pbdbaW6W2ltpYYaC2wlhhhBYYYQWGSCCwxCyDSMyGrOACA
CApFSQplbmRzdHJlYW0KZW5kb2JqCjkyIDAgb2JqCjw8L0xlbmd0aCAxNzUgPj4Kc3RyZWFtCjAg
MCAwIDAgNjAgNjkgZDEKNjAgMCAwIDY5IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDYwL0ggNjkvQlBD
IDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDYwCi9CbGFja0lzMSB0cnVlCj4+CklEICaxVTkU
Kw+zoGfsIG/D7Qf2//f2/f/3+//f74P////////////////////////////96/p4QeYD+ACACApF
SQplbmRzdHJlYW0KZW5kb2JqCjkzIDAgb2JqCjw8L0xlbmd0aCAyMDggPj4Kc3RyZWFtCjAgMCAw
IC0xIDUyIDczIGQxCjUyIDAgMCA3NCAwIC0xIGNtCkJJCi9JTSB0cnVlL1cgNTIvSCA3NC9CUEMg
MS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTIKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqGchhok
MCMEHgjqKHhAgw9IN8Jvpvpv79v2//v3+//b///+/////X//9L//19L/hpdr2lydBhfgwl7Fe14a
9r2F4YXgwXj//////////+sfJrcPg+Hw8AEAEApFSQplbmRzdHJlYW0KZW5kb2JqCjk0IDAgb2Jq
Cjw8L0xlbmd0aCAyMjYgPj4Kc3RyZWFtCjAgMCAwIC0yIDY4IDcxIGQxCjY4IDAgMCA3MyAwIC0y
IGNtCkJJCi9JTSB0cnVlL1cgNjgvSCA3My9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMg
NjgKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqDUdAbyGYDwQeCDwg8IjAoejUGd6BBvCQb0E3pBvQTe
k/t6Tek30+reg69a9fr1/69f//////+//3+//tkFd/9/td//bX/bXb90u1212/bXDa7YXYa4YYXY
YXDOgycuDEJ8GRgPyGnTgAgAgApFSQplbmRzdHJlYW0KZW5kb2JqCjk1IDAgb2JqCjw8L0xlbmd0
aCAxNj4+CnN0cmVhbQo3MSAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago5NiAwIG9iago8
PC9MZW5ndGggMjEyID4+CnN0cmVhbQowIDAgMCAyMiA4OCA2OSBkMQo4OCAwIDAgNDcgMCAyMiBj
bQpCSQovSU0gdHJ1ZS9XIDg4L0ggNDcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDg4
Ci9CbGFja0lzMSB0cnVlCj4+CklEICaxVmVZ/8jqIY0IL67CaYW1XtO1////////////////////
///////////////////af3DXhFRdatoo2vsNWGlmgKwYSYNeNjYrDtPg4aDWHaawcMIMLBwYIMFA
BABACkVJCmVuZHN0cmVhbQplbmRvYmoKOTcgMCBvYmoKPDwvTGVuZ3RoIDIxMiA+PgpzdHJlYW0K
MCAwIDAgMjIgNTYgOTYgZDEKNTYgMCAwIDc0IDAgMjIgY20KQkkKL0lNIHRydWUvVyA1Ni9IIDc0
L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1NgovQmxhY2tJczEgdHJ1ZQo+PgpJRCAm
uSYZnyJptbX9f/////////+Ro8ED8IP0ZjD4ggb6b6b6b6b9vr9vq/f7//9v///7//////1///S/
9f/S7+GvaXNE1+GlqwYJZY6sfG1u1h2sHaw4awdhYcGCgAgAgApFSQplbmRzdHJlYW0KZW5kb2Jq
Cjk4IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo0NCAwIDAgMCAwIDAgZDEKZW5kc3RyZWFt
CmVuZG9iago5OSAwIG9iago8PC9MZW5ndGggMTcxID4+CnN0cmVhbQowIDAgMCAyMyA0OCA2OSBk
MQo0OCAwIDAgNDYgMCAyMyBjbQpCSQovSU0gdHJ1ZS9XIDQ4L0ggNDYvQlBDIDEvRi9DQ0YvRFA8
PC9LIC0xCi9Db2x1bW5zIDQ4Ci9CbGFja0lzMSB0cnVlCj4+CklEICa33yQBfcPbe2+3t9+29v33
7Ydvvb329vvfb2+9vfb2+9vfbyN79v39v2+79vt+G3xffABABApFSQplbmRzdHJlYW0KZW5kb2Jq
CjEwMCAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KNDAgMCAwIDAgMCAwIGQxCmVuZHN0cmVh
bQplbmRvYmoKMTAxIDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo3OSAwIDAgMCAwIDAgZDEK
ZW5kc3RyZWFtCmVuZG9iagoxMDIgMCBvYmoKPDwvTGVuZ3RoIDE5NyA+PgpzdHJlYW0KMCAwIDAg
LTQgNTggNjkgZDEKNTggMCAwIDczIDAgLTQgY20KQkkKL0lNIHRydWUvVyA1OC9IIDczL0JQQyAx
L0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1OAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmuVZb8i6E
GNNhNe11X///////////////////////////r/3912vBFR+w19tL2DX2K9/DXteGF4YLx///////
///1zjrx74fB8Ph8HgAgAgpFSQplbmRzdHJlYW0KZW5kb2JqCjEwMyAwIG9iago8PC9MZW5ndGgg
MTgwID4+CnN0cmVhbQowIDAgMCAyMyA1NSA3MCBkMQo1NSAwIDAgNDcgMCAyMyBjbQpCSQovSU0g
dHJ1ZS9XIDU1L0ggNDcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU1Ci9CbGFja0lz
MSB0cnVlCj4+CklEICahmGAL17171/T/T/T/k6ev16t9erfXq31630+v03r9X76V++t9PrfXq/V6
v96T/ev7evhNPBFQCGoN/gAgAgpFSQplbmRzdHJlYW0KZW5kb2JqCjEwNCAwIG9iago8PC9MZW5n
dGggMTY+PgpzdHJlYW0KNTYgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMTA1IDAgb2Jq
Cjw8L0xlbmd0aCAxNzggPj4Kc3RyZWFtCjAgMCAwIC0xIDM1IDcyIGQxCjM1IDAgMCA3MyAwIC0x
IGNtCkJJCi9JTSB0cnVlL1cgMzUvSCA3My9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMg
MzUKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrEGE+RkYa63/////////////////////////8wT/yE/
//////9/8g7+nun1v9bfdLtdtLDFbCwwoAIAIApFSQplbmRzdHJlYW0KZW5kb2JqCjEwNiAwIG9i
ago8PC9MZW5ndGggMTY+PgpzdHJlYW0KODEgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoK
MTA3IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo3MCAwIDAgMCAwIDAgZDEKZW5kc3RyZWFt
CmVuZG9iagoxMDggMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjg4IDAgMCAwIDAgMCBkMQpl
bmRzdHJlYW0KZW5kb2JqCjEwOSAwIG9iago8PC9MZW5ndGggMjEzID4+CnN0cmVhbQowIDAgMCAw
IDQ3IDcxIGQxCjQ3IDAgMCA3MSAwIDAgY20KQkkKL0lNIHRydWUvVyA0Ny9IIDcxL0JQQyAxL0Yv
Q0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0NwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmop0AxBEGGiik
Beg+axh8hg4fBBvYJh4t7e3v3t/3v/df/6+ta6wuuEsJYLkF0nWDWQUVYawwsMFt4Yfe3t97f99/
/euW//2uw17XYaWwwuwYS2K2trYWGFhhYMnAgAEAEApFSQplbmRzdHJlYW0KZW5kb2JqCjExMCAw
IG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KNzggMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRv
YmoKMTExIDAgb2JqCjw8L0xlbmd0aCAyNDcgPj4Kc3RyZWFtCjAgMCAwIC0xIDk5IDcwIGQxCjk5
IDAgMCA3MSAwIC0xIGNtCkJJCi9JTSB0cnVlL1cgOTkvSCA3MS9CUEMgMS9GL0NDRi9EUDw8L0sg
LTEKL0NvbHVtbnMgOTkKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqDWbDNMA0b/XW+/09f107/9dO//
XTv/Ve79FC6KF/rq/tX0n7/r+1fSer//W1fp6v9fW9+nq/1fX/pur11frr+1vV9+uv7W9X366v4/
Vp+u9f9p+u9f9p+lvX+qfVb+vpX17+vpW9f/9Um+v9fVb+09MKnphBhB5yYImAXB/wAQAQpFSQpl
bmRzdHJlYW0KZW5kb2JqCjExMiAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KOTkgMCAwIDAg
MCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMTEzIDAgb2JqCjw8L0xlbmd0aCAyMDQgPj4Kc3RyZWFt
CjAgMCAwIDIzIDU1IDk3IGQxCjU1IDAgMCA3NCAwIDIzIGNtCkJJCi9JTSB0cnVlL1cgNTUvSCA3
NC9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTUKL0JsYWNrSXMxIHRydWUKPj4KSUQg
JqIeBshB6D0+++++9+9mZvYQfF9v9v9+9+/373/T/T/XvXvX9Pk6630+v1er9Xq/XrfvpX76X7el
/ek/3pP/pX76V++l/er9Xr/evreE0HhFQDh/ABABCkVJCmVuZHN0cmVhbQplbmRvYmoKMTE0IDAg
b2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo4MCAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9i
agoxMTUgMCBvYmoKPDwvTGVuZ3RoIDE4NyA+PgpzdHJlYW0KMCAwIDAgMCA0MCA3MCBkMQo0MCAw
IDAgNzAgMCAwIGNtCkJJCi9JTSB0cnVlL1cgNDAvSCA3MC9CUEMgMS9GL0NDRi9EUDw8L0sgLTEK
L0NvbHVtbnMgNDAKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqGg2C9B6evf//7W1sLH/8hsf/7/9+/2
/7372/2+9vvfvb7372/73yJHhO6+/9fX/X+/pfW6/W2u2ltpbBhLYhYYWGCgAgAgCkVJCmVuZHN0
cmVhbQplbmRvYmoKMTE2IDAgb2JqCjw8L0xlbmd0aCAyMDggPj4Kc3RyZWFtCjAgMCAwIC0xIDc3
IDY5IGQxCjc3IDAgMCA3MCAwIC0xIGNtCkJJCi9JTSB0cnVlL1cgNzcvSCA3MC9CUEMgMS9GL0ND
Ri9EUDw8L0sgLTEKL0NvbHVtbnMgNzcKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrkGBjDRBoCYMoDV
NZ2mFvW1X+3X+6XfvXrt1/tr9drvX+2v1trxW/WzgF/r9bf6W3+u3Xrt1/tpf9rvXa7137r3W691
uv1t/r3Wx9b/tftftf+1+1+/UAEAEApFSQplbmRzdHJlYW0KZW5kb2JqCjExNyAwIG9iago8PC9M
ZW5ndGggMjE1ID4+CnN0cmVhbQowIDAgMCAyMiA4MiA3MCBkMQo4MiAwIDAgNDggMCAyMiBjbQpC
SQovSU0gdHJ1ZS9XIDgyL0ggNDgvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDgyCi9C
bGFja0lzMSB0cnVlCj4+CklEICahlFwzTAN+un/emv32uv3eq9+mn/pp8nX9uTrpaV+3vpaX7fel
7+2lev/TaT+33pe/tpXpf+2k+l9+3v8V6T39PpPf0/X6rfVPqv9N6/63pbemqeEwg08IgxQyCa/w
AQAQCkVJCmVuZHN0cmVhbQplbmRvYmoKMTE4IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo3
NCAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxMTkgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4K
c3RyZWFtCjg1IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjEyMCAwIG9iago8PC9MZW5n
dGggMjA1ID4+CnN0cmVhbQowIDAgMCAxMyA2MyA3MCBkMQo2MyAwIDAgNTcgMCAxMyBjbQpCSQov
SU0gdHJ1ZS9XIDYzL0ggNTcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDYzCi9CbGFj
a0lzMSB0cnVlCj4+CklEICasiAaCOLIh12l2l/2l9fX19fX1/9fRmvpfpfr+l+l/X6X6/pfpfpfp
fpf/6X6X6X6X6/pfpf1+l+v6X6X6X6Xx/X19fX/pfXpeEk9fPUE+iGUIg1gAgAgKRUkKZW5kc3Ry
ZWFtCmVuZG9iagoxMjEgMCBvYmoKPDwvTGVuZ3RoIDIwMSA+PgpzdHJlYW0KMCAwIDAgMCA3MiA3
MCBkMQo3MiAwIDAgNzAgMCAwIGNtCkJJCi9JTSB0cnVlL1cgNzIvSCA3MC9CUEMgMS9GL0NDRi9E
UDw8L0sgLTEKL0NvbHVtbnMgNzIKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqGqYBq3+vev6f96/p/r
3+idP30v29L/9vS/vSf/Sv3/0m/9L9vS/v30v29L/9vS/vSf/Sb//0m/9K/fS/vV+v29fq9X/+9b
1T008JhB50gIH8AEAEAKRUkKZW5kc3RyZWFtCmVuZG9iagoxMjIgMCBvYmoKPDwvTGVuZ3RoIDE2
Pj4Kc3RyZWFtCjg2IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjEyMyAwIG9iago8PC9M
ZW5ndGggMTY2ID4+CnN0cmVhbQowIDAgMCAxMyA0NSA2OSBkMQo0NSAwIDAgNTYgMCAxMyBjbQpC
SQovSU0gdHJ1ZS9XIDQ1L0ggNTYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQ1Ci9C
bGFja0lzMSB0cnVlCj4+CklEICVMmp8MnBf0G9oP7+37/+37//+3w///////////////////////
/6f6eg4kYGwAEAEKRUkKZW5kc3RyZWFtCmVuZG9iagoxMjQgMCBvYmoKPDwvTGVuZ3RoIDIwMyA+
PgpzdHJlYW0KMCAwIDAgMTIgNTIgNzEgZDEKNTIgMCAwIDU5IDAgMTIgY20KQkkKL0lNIHRydWUv
VyA1Mi9IIDU5L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1MgovQmxhY2tJczEgdHJ1
ZQo+PgpJRCAmoZRwNkhorwQeEHhGph4RDB3oEDek3oIN6Tek3pN6v03pN8Ol+vX/8V///yar/f7+
CC/21/3Xv3+139tdtdtLbXbXbXYYXDBgjP4YgnwwT5BQjgAgAgpFSQplbmRzdHJlYW0KZW5kb2Jq
CjEyNSAwIG9iago8PC9MZW5ndGggMjA5ID4+CnN0cmVhbQowIDAgMCAwIDY4IDY5IGQxCjY4IDAg
MCA2OSAwIDAgY20KQkkKL0lNIHRydWUvVyA2OC9IIDY5L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQov
Q29sdW1ucyA2OAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmsUgaPQWRKkdCsKFtJeltV6Xpev16Xr9e
l6/Xpev16Xr6X16+l9evpfXr6XFf/NBAfgwfhvww/b9v2/f79/v3/+///////X6/9fr19L0vS00u
aiC0IWCBZhOACACACkVJCmVuZHN0cmVhbQplbmRvYmoKMTI2IDAgb2JqCjw8L0xlbmd0aCAyMDYg
Pj4Kc3RyZWFtCjAgMCAwIDAgNzYgNjkgZDEKNzYgMCAwIDY5IDAgMCBjbQpCSQovSU0gdHJ1ZS9X
IDc2L0ggNjkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDc2Ci9CbGFja0lzMSB0cnVl
Cj4+CklEICaxBAzJELMMHs1A4fKAUB7hh+G/b8MP2/b9v39v79v3+/f7/9v//2////b/////////
9fX///pf/+l/6/Xr6X16+l6Xpel6XpeEFqEuwguawQLQgsECzFkAEAEKRUkKZW5kc3RyZWFtCmVu
ZG9iagoxMjcgMCBvYmoKPDwvTGVuZ3RoIDI0MSA+PgpzdHJlYW0KMCAwIDAgMSA5NCA3MCBkMQo5
NCAwIDAgNjkgMCAxIGNtCkJJCi9JTSB0cnVlL1cgOTQvSCA2OS9CUEMgMS9GL0NDRi9EUDw8L0sg
LTEKL0NvbHVtbnMgOTQKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrFQDBgGP+QiEyDerYWGuk2t/6Ta
//T//0////T//0UJ/1/q3/X+rf9f6t/1/rf+/6V/7/pX/v+lf+/9f6t/1/q3/X+rf9f6t/1/q3//
6V/7/pX/v+lf+/6V/7/1/q3/X+rf9f6t/1/Gx/9P/16v1fvpXhWHmESXDfuACACACkVJCmVuZHN0
cmVhbQplbmRvYmoKMTI4IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo5NSAwIDAgMCAwIDAg
ZDEKZW5kc3RyZWFtCmVuZG9iagoxMjkgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjU1IDAg
MCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjEzMCAwIG9iago8PC9MZW5ndGggMjA1ID4+CnN0
cmVhbQowIDAgMCAwIDc3IDcxIGQxCjc3IDAgMCA3MSAwIDAgY20KQkkKL0lNIHRydWUvVyA3Ny9I
IDcxL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA3NwovQmxhY2tJczEgdHJ1ZQo+PgpJ
RCAmoNZDBpkMwHhA8IoCh4QIgR+gg3pBvSb0m9JvSb1+m9X++vVv//r1b///////////////////
////////////////////////7T1+09PwmEHnAyGcn8AEAEAKRUkKZW5kc3RyZWFtCmVuZG9iagox
MzEgMCBvYmoKPDwvTGVuZ3RoIDE4MiA+PgpzdHJlYW0KMCAwIDAgMTMgNDUgNjkgZDEKNDUgMCAw
IDU2IDAgMTMgY20KQkkKL0lNIHRydWUvVyA0NS9IIDU2L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQov
Q29sdW1ucyA0NQovQmxhY2tJczEgdHJ1ZQo+PgpJRCAqw0E1M6gYsLa36////////////8kfyk/E
PlAofBBvw37fv9+3/7/f/////X1/6X/pel6WqXIZBaEKIUgQLgAgAgpFSQplbmRzdHJlYW0KZW5k
b2JqCjEzMiAwIG9iago8PC9MZW5ndGggMTkzID4+CnN0cmVhbQowIDAgMCAxMyA1OCA2OSBkMQo1
OCAwIDAgNTYgMCAxMyBjbQpCSQovSU0gdHJ1ZS9XIDU4L0ggNTYvQlBDIDEvRi9DQ0YvRFA8PC9L
IC0xCi9Db2x1bW5zIDU4Ci9CbGFja0lzMSB0cnVlCj4+CklEICKg3JqREwIs6BA+aAQHuGH4b9h+
37ft+/t/fv9+/3/7f///t/////////S///9L//0v/S9fr0vS9fS9BeEtQlzoEC0IUQUigKAAQAQK
RUkKZW5kc3RyZWFtCmVuZG9iagoxMzMgMCBvYmoKPDwvTGVuZ3RoIDE5MSA+PgpzdHJlYW0KMCAw
IDAgMTMgNjYgNjkgZDEKNjYgMCAwIDU2IDAgMTMgY20KQkkKL0lNIHRydWUvVyA2Ni9IIDU2L0JQ
QyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA2NgovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoynD
PhyChPDNAaCQ7VbVb137167devfvXa7167df7H1+zYZ1/tr9ba/W3+u3Xr3W691v9rvXa7169+9c
e1+/W/W/X79b9QAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjEzNCAwIG9iago8PC9MZW5ndGggMTY+
PgpzdHJlYW0KODQgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMTM1IDAgb2JqCjw8L0xl
bmd0aCAxODMgPj4Kc3RyZWFtCjAgMCAwIDEzIDYzIDY5IGQxCjYzIDAgMCA1NiAwIDEzIGNtCkJJ
Ci9JTSB0cnVlL1cgNjMvSCA1Ni9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNjMKL0Js
YWNrSXMxIHRydWUKPj4KSUQgKsPJqZ1BQdChhNdNbTX/////////////////////H/8zBo//////
///////////////9p6+mnoMIOJEByTDcAEAECkVJCmVuZHN0cmVhbQplbmRvYmoKMTM2IDAgb2Jq
Cjw8L0xlbmd0aCAxNz4+CnN0cmVhbQoxMDggMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoK
MTM3IDAgb2JqCjw8L0xlbmd0aCAyMzQgPj4Kc3RyZWFtCjAgMCAwIC0yIDc4IDcxIGQxCjc4IDAg
MCA3MyAwIC0yIGNtCkJJCi9JTSB0cnVlL1cgNzgvSCA3My9CUEMgMS9GL0NDRi9EUDw8L0sgLTEK
L0NvbHVtbnMgNzgKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqDWQwapDNL4IHgiQEB4QIgxTQQYeEEG
9Jh4Sb0m9JvSb0m/vSb0r9vS9W/vSf7/0m//9b/9+vX+////////+9evf//vX+2l//ul371tpf7p
bdbaW6W3W2ltpbaW2EsNoLDDCWwwQWDKCCwxBYMFkNWcAEAECkVJCmVuZHN0cmVhbQplbmRvYmoK
MTM4IDAgb2JqCjw8L0xlbmd0aCAyMDkgPj4Kc3RyZWFtCjAgMCAwIDAgNTkgNjkgZDEKNTkgMCAw
IDY5IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDU5L0ggNjkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9D
b2x1bW5zIDU5Ci9CbGFja0lzMSB0cnVlCj4+CklEICasiwESKLYYPZ1Ch7NAzh+G92/Df37+3/7f
////3///Xr//6Xr6X/hL0vCXgguK4LhcPk4OHwgb9v2/f2//v3/+////////X69fr1+vX0tQl6C0
DBLQhYQLLE4AIAIKRUkKZW5kc3RyZWFtCmVuZG9iagoxMzkgMCBvYmoKPDwvTGVuZ3RoIDE4NSA+
PgpzdHJlYW0KMCAwIDAgMTIgNTggNjkgZDEKNTggMCAwIDU3IDAgMTIgY20KQkkKL0lNIHRydWUv
VyA1OC9IIDU3L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1OAovQmxhY2tJczEgdHJ1
ZQo+PgpJRCAmoNyXDEhlEYa63////////////171715/ev03r6Tf3pP7el9N6/TevpN/6TfXq316
t/6V6t+ut4Th6YQegYQdcAEAEApFSQplbmRzdHJlYW0KZW5kb2JqCjE0MCAwIG9iago8PC9MZW5n
dGggMjI1ID4+CnN0cmVhbQowIDAgMCAzIDgyIDczIGQxCjgyIDAgMCA3MCAwIDMgY20KQkkKL0lN
IHRydWUvVyA4Mi9IIDcwL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA4MgovQmxhY2tJ
czEgdHJ1ZQo+PgpJRCAmohVhqkcJ1yGA1wwl2l9dr9fX19fX1/9fX19E6+l+l//pfpfpfpfpfr+l
/X6X6X6/pfpfpf1+v6X6X6X6X6X/+l+l+l+l+v6X9fpfpfr+l8V9fX1/9fXpel6+knpeEk8mITw4
QPIUMg1qwAQAQApFSQplbmRzdHJlYW0KZW5kb2JqCjE0MSAwIG9iago8PC9MZW5ndGggMTkyID4+
CnN0cmVhbQowIDAgMCAxNiA2NyA3NCBkMQo2NyAwIDAgNTggMCAxNiBjbQpCSQovSU0gdHJ1ZS9X
IDY3L0ggNTgvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDY3Ci9CbGFja0lzMSB0cnVl
Cj4+CklEICahpHAzJDMrwg8IoMPCNAcPQQb0m9JvSb6fVv/Sb//69W//////////////////////
/////////////+71/T0/TCDyNQQwXABABApFSQplbmRzdHJlYW0KZW5kb2JqCjE0MiAwIG9iago8
PC9MZW5ndGggMTg0ID4+CnN0cmVhbQowIDAgMCAwIDQ4IDY5IGQxCjQ4IDAgMCA2OSAwIDAgY20K
QkkKL0lNIHRydWUvVyA0OC9IIDY5L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0OAov
QmxhY2tJczEgdHJ1ZQo+PgpJRCAmoNBoJ///////////ygr//+zYFzQS37f/t+3/7ft/+37f37+3
7f/t+39+/t/fv7f37+37f37+39+/sf77/vvv+8AEAEAKRUkKZW5kc3RyZWFtCmVuZG9iagoxNDMg
MCBvYmoKPDwvTGVuZ3RoIDE3Pj4Kc3RyZWFtCjExMiAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVu
ZG9iagoxNDQgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjc3IDAgMCAwIDAgMCBkMQplbmRz
dHJlYW0KZW5kb2JqCjE0NSAwIG9iago8PC9MZW5ndGggMTUwID4+CnN0cmVhbQowIDAgMCAyMyAx
OSA3MCBkMQoxOSAwIDAgNDcgMCAyMyBjbQpCSQovSU0gdHJ1ZS9XIDE5L0ggNDcvQlBDIDEvRi9D
Q0YvRFA8PC9LIC0xCi9Db2x1bW5zIDE5Ci9CbGFja0lzMSB0cnVlCj4+CklEICahQWE9P9P/31tY
ax///////8hcwnp/p/+1vtbCgAgAgApFSQplbmRzdHJlYW0KZW5kb2JqCjE0NiAwIG9iago8PC9M
ZW5ndGggMTY+PgpzdHJlYW0KNjMgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMTQ3IDAg
b2JqCjw8L0xlbmd0aCAxNTEgPj4Kc3RyZWFtCjAgMCAwIDU3IDIzIDg0IGQxCjIzIDAgMCAyNyAw
IDU3IGNtCkJJCi9JTSB0cnVlL1cgMjMvSCAyNy9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVt
bnMgMjMKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrGAYweDB4YeG8MPb29vvfvfvyXcIdf9f11tbCww
UAEAEApFSQplbmRzdHJlYW0KZW5kb2JqCjE0OCAwIG9iago8PC9MZW5ndGggMjIyID4+CnN0cmVh
bQowIDAgMCAxNyA4MCA3MyBkMQo4MCAwIDAgNTYgMCAxNyBjbQpCSQovSU0gdHJ1ZS9XIDgwL0gg
NTYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDgwCi9CbGFja0lzMSB0cnVlCj4+CklE
ICajIgHLgmQSikCNNqwwulfauvV/v9f/9P//T/ma/7f6/9X+r/1f6v/V/q/9X+r/1f6v/V/q/9X+
r/9/1/q3/X+rf9f6t/1/q3/X+rf9f6t//+k//f9fxsfX79er9Xq+leR1t/NQbgAgAgpFSQplbmRz
dHJlYW0KZW5kb2JqCjE0OSAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KNzYgMCAwIDAgMCAw
IGQxCmVuZHN0cmVhbQplbmRvYmoKMTUwIDAgb2JqCjw8L0xlbmd0aCAxOTMgPj4Kc3RyZWFtCjAg
MCAwIDAgODIgNjkgZDEKODIgMCAwIDY5IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDgyL0ggNjkvQlBD
IDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDgyCi9CbGFja0lzMSB0cnVlCj4+CklEICaxGwx/
IROQzU+GEGFtNf7TX//////////////////////////H/8nDV//////////////////////////6
afrpp4QYQeYbIYG/gAgAgApFSQplbmRzdHJlYW0KZW5kb2JqCjE1MSAwIG9iago8PC9MZW5ndGgg
MTg5ID4+CnN0cmVhbQowIDAgMCAxMyA2MiA3MCBkMQo2MiAwIDAgNTcgMCAxMyBjbQpCSQovSU0g
dHJ1ZS9XIDYyL0ggNTcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDYyCi9CbGFja0lz
MSB0cnVlCj4+CklEICahplwMb1/T/vX9P9e/0Zp++l+3pf/t6X96T/6t9f+k3/pX7/6V++l+3pf/
t6X96T/6Tf/+k3/rfvpX2nhU8IGnhBhB9QAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjE1MiAwIG9i
ago8PC9MZW5ndGggMTU3ID4+CnN0cmVhbQowIDAgMCAxMyAyMyA2OSBkMQoyMyAwIDAgNTYgMCAx
MyBjbQpCSQovSU0gdHJ1ZS9XIDIzL0ggNTYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5z
IDIzCi9CbGFja0lzMSB0cnVlCj4+CklEIJNTIZ2tra///////////////////////////////T/T
wnEjA3ABABAKRUkKZW5kc3RyZWFtCmVuZG9iagoxNTMgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3Ry
ZWFtCjMxIDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjE1NCAwIG9iago8PC9MZW5ndGgg
MTc5ID4+CnN0cmVhbQowIDAgMCAwIDMyIDg4IGQxCjMyIDAgMCA4OCAwIDAgY20KQkkKL0lNIHRy
dWUvVyAzMi9IIDg4L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAzMgovQmxhY2tJczEg
dHJ1ZQo+PgpJRCAmrNAz09B6xNJ7dfe9X/f1yar7V4///f//////////////////////////////
////////6/3+nrhB5InwAQAQCkVJCmVuZHN0cmVhbQplbmRvYmoKMTU1IDAgb2JqCjw8L0xlbmd0
aCAxNj4+CnN0cmVhbQo5MiAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxNTYgMCBvYmoK
PDwvTGVuZ3RoIDIwOCA+PgpzdHJlYW0KMCAwIDAgMjUgNTcgOTkgZDEKNTcgMCAwIDc0IDAgMjUg
Y20KQkkKL0lNIHRydWUvVyA1Ny9IIDc0L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1
NwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoNXJeyGsG7XW//////////+Q0f4IH4T9B+n6fp+n6NQr
+CDfpBj6fSfp/9L/6/9L///6//////9////f7/9//b/9v3Xv3Xb9tdtdhrhgwuxPPgwnwYIPABAB
CkVJCmVuZHN0cmVhbQplbmRvYmoKMTU3IDAgb2JqCjw8L0xlbmd0aCAxNzMgPj4Kc3RyZWFtCjAg
MCAwIDAgNjAgNjkgZDEKNjAgMCAwIDY5IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDYwL0ggNjkvQlBD
IDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDYwCi9CbGFja0lzMSB0cnVlCj4+CklEICaguQMH
+QUV4YXW/X///////////////////////////////mHwv/f/X//3rv/rh671weC4j/ABABAKRUkK
ZW5kc3RyZWFtCmVuZG9iagoxNTggMCBvYmoKPDwvTGVuZ3RoIDE4MCA+PgpzdHJlYW0KMCAwIDAg
MyAyNiAxMDAgZDEKMjYgMCAwIDk3IDAgMyBjbQpCSQovSU0gdHJ1ZS9XIDI2L0ggOTcvQlBDIDEv
Ri9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDI2Ci9CbGFja0lzMSB0cnVlCj4+CklEICainwsIHp80
n037fX03v9Xj9//9///////////////////////19ZByIe8PDw8Pf///8hofCD0+///a/YUAEAEK
RUkKZW5kc3RyZWFtCmVuZG9iagoxNTkgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjI2IDAg
MCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjE2MCAwIG9iago8PC9MZW5ndGggMjA4ID4+CnN0
cmVhbQowIDAgMCAtMSA1NiA3MyBkMQo1NiAwIDAgNzQgMCAtMSBjbQpCSQovSU0gdHJ1ZS9XIDU2
L0ggNzQvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU2Ci9CbGFja0lzMSB0cnVlCj4+
CklEICaxCD4LkegZqOGmvraS+vr0vS9fS+vS9L19L69L0vX0vr0vX0vriuaJeH9r2/b9v2/b9vww
/b9v2/b9v2/Qfw/BGsvJf4///////////r+arfD4Ph8Ph4AIAIAKRUkKZW5kc3RyZWFtCmVuZG9i
agoxNjEgMCBvYmoKPDwvTGVuZ3RoIDE5MCA+PgpzdHJlYW0KMCAwIDAgMjIgNTEgNjkgZDEKNTEg
MCAwIDQ3IDAgMjIgY20KQkkKL0lNIHRydWUvVyA1MS9IIDQ3L0JQQyAxL0YvQ0NGL0RQPDwvSyAt
MQovQ29sdW1ucyA1MQovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmsagmGEwthEM5G1W9bpbful3W67aW
3W691trtpb12u2lt1se11r1pa/p/onT1b6b0m9fpvSb0m/9JvSv71vW8Jp4IMIH/ABABCkVJCmVu
ZHN0cmVhbQplbmRvYmoKMTYyIDAgb2JqCjw8L0xlbmd0aCAxODUgPj4Kc3RyZWFtCjAgMCAwIC00
IDQ1IDgxIGQxCjQ1IDAgMCA4NSAwIC00IGNtCkJJCi9JTSB0cnVlL1cgNDUvSCA4NS9CUEMgMS9G
L0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNDUKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrng1ft/t/3v
+3+3+3/7f7f7f97/t/t/t/+3+3+3/e/7f7f97/t/t/t/3v+3+3/e/7f7f7f97/t/t/3v+3+3/YAI
AIAKRUkKZW5kc3RyZWFtCmVuZG9iagoxNjMgMCBvYmoKPDwvTGVuZ3RoIDE4MiA+PgpzdHJlYW0K
MCAwIDAgMCA1NSA2OSBkMQo1NSAwIDAgNjkgMCAwIGNtCkJJCi9JTSB0cnVlL1cgNTUvSCA2OS9C
UEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTUKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrED
Bv8iV4YW1+1///////////+Q2P//////6+vheP/5oC/w/v7/+/////j////4L/16//+v/rqvrqC6
HguZUgAgAgpFSQplbmRzdHJlYW0KZW5kb2JqCjE2NCAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJl
YW0KNjkgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMTY1IDAgb2JqCjw8L0xlbmd0aCAy
MDMgPj4Kc3RyZWFtCjAgMCAwIDEzIDU2IDY5IGQxCjU2IDAgMCA1NiAwIDEzIGNtCkJJCi9JTSB0
cnVlL1cgNTYvSCA1Ni9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTYKL0JsYWNrSXMx
IHRydWUKPj4KSUQgIMJyOpNTKA0HU7VbUL4Xpel6Xpel6Xr6Xpel6Xpel6Xpel6Xpel6XpcVz6Xt
e17ft+37ft+37ft+37ft+37ft+37ft+39+33eqD00D0GCDiU4mACACAKRUkKZW5kc3RyZWFtCmVu
ZG9iagoxNjYgMCBvYmoKPDwvTGVuZ3RoIDIwMiA+PgpzdHJlYW0KMCAwIDAgMCA0NyA3MSBkMQo0
NyAwIDAgNzEgMCAwIGNtCkJJCi9JTSB0cnVlL1cgNDcvSCA3MS9CUEMgMS9GL0NDRi9EUDw8L0sg
LTEKL0NvbHVtbnMgNDcKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqIUBlyYjQPQfD0HyGFfCBh7CBvY
TeIb2+99v9v+//v/1/9f16110tdLXCWFwlhLBLIOoyxLYXWwthcLYXBbJwzM2Glb/b/b/b732TD+
3+3+3+2ACACACkVJCmVuZHN0cmVhbQplbmRvYmoKMTY3IDAgb2JqCjw8L0xlbmd0aCAxNDUgPj4K
c3RyZWFtCjAgMCAwIC0yIDI0IDI0IGQxCjI0IDAgMCAyNiAwIC0yIGNtCkJJCi9JTSB0cnVlL1cg
MjQvSCAyNi9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgMjQKL0JsYWNrSXMxIHRydWUK
Pj4KSUQgJqRgMYe33v3t/t9/t/3t/3+3/f9weDwagAgAgApFSQplbmRzdHJlYW0KZW5kb2JqCjE2
OCAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KMzUgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQpl
bmRvYmoKMTY5IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo0NyAwIDAgMCAwIDAgZDEKZW5k
c3RyZWFtCmVuZG9iagoxNzAgMCBvYmoKPDwvTGVuZ3RoIDEyMiA+PgpzdHJlYW0KMCAwIDAgNDAg
MzIgNDcgZDEKMzIgMCAwIDcgMCA0MCBjbQpCSQovSU0gdHJ1ZS9XIDMyL0ggNy9CUEMgMS9GL0ND
Ri9EUDw8L0sgLTEKL0NvbHVtbnMgMzIKL0JsYWNrSXMxIHRydWUKPj4KSUQgJr///wAQAQpFSQpl
bmRzdHJlYW0KZW5kb2JqCjE3MSAwIG9iago8PC9MZW5ndGggMTkyID4+CnN0cmVhbQowIDAgMCAx
NiA0NCA3MiBkMQo0NCAwIDAgNTYgMCAxNiBjbQpCSQovSU0gdHJ1ZS9XIDQ0L0ggNTYvQlBDIDEv
Ri9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQ0Ci9CbGFja0lzMSB0cnVlCj4+CklEICNAhNTIGJZI
ED5mGA9w37ft+/t//+3///9f/6X/r9el4S9LwQXELhcPnwQPwb9v3+//f7//////9fr/0vX68Jap
cGCWhCiFBQAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjE3MiAwIG9iago8PC9MZW5ndGggMTY+Pgpz
dHJlYW0KNDEgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMTczIDAgb2JqCjw8L0xlbmd0
aCAxNj4+CnN0cmVhbQoyNSAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxNzQgMCBvYmoK
PDwvTGVuZ3RoIDIxMiA+PgpzdHJlYW0KMCAwIDAgLTQgNjAgNjkgZDEKNjAgMCAwIDczIDAgLTQg
Y20KQkkKL0lNIHRydWUvVyA2MC9IIDczL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA2
MAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmsSZfyLUGCwwRDYjaf6////3/////////////////////
//////8mTX17NXg/h32aFIiPEgn+H8GvH//f//9/IZY+4QP090+/ddv3IS34YX2Ot2twwtxw++DB
QAQAQApFSQplbmRzdHJlYW0KZW5kb2JqCjE3NSAwIG9iago8PC9MZW5ndGggMTkzID4+CnN0cmVh
bQowIDAgMCAwIDU4IDY5IGQxCjU4IDAgMCA2OSAwIDAgY20KQkkKL0lNIHRydWUvVyA1OC9IIDY5
L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1OAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAm
sVM5FBMN7JAbPQPtN+/v7+37/+3/7/ffh////8gYH//9f//X/wvheP/5oGj7+/v/7////+P////k
Gh/////X/1/9dQvhdDwuZTgAgAgKRUkKZW5kc3RyZWFtCmVuZG9iagoxNzYgMCBvYmoKPDwvTGVu
Z3RoIDIxNSA+PgpzdHJlYW0KMCAwIDAgMCA0OCA3MSBkMQo0OCAwIDAgNzEgMCAwIGNtCkJJCi9J
TSB0cnVlL1cgNDgvSCA3MS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNDgKL0JsYWNr
SXMxIHRydWUKPj4KSUQgJqDc0BiCB4QeEaEHoIN6CDek3pN63pP1er9Xr+3pf3/r9f3+v/r//+v/
Xa/+lv+l2vDS2GlwYS5ohXZwe4YXhhbYMF479797977fe3vt7e3t7ew9vYeG9g8Mhjhmrg+DwAQA
QApFSQplbmRzdHJlYW0KZW5kb2JqCjE3NyAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KOTYg
MCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMTc4IDAgb2JqCjw8L0xlbmd0aCAxNTMgPj4K
c3RyZWFtCjAgMCAwIDE4IDU2IDY4IGQxCjU2IDAgMCA1MCAwIDE4IGNtCkJJCi9JTSB0cnVlL1cg
NTYvSCA1MC9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTYKL0JsYWNrSXMxIHRydWUK
Pj4KSUQgJqGabBR//////////////8kp/yGbf///////////////ABABCkVJCmVuZHN0cmVhbQpl
bmRvYmoKMTgyIDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo5MCAwIDAgMCAwIDAgZDEKZW5k
c3RyZWFtCmVuZG9iagoxODMgMCBvYmoKPDwvTGVuZ3RoIDIyNCA+PgpzdHJlYW0KMCAwIDAgMTIg
NTkgODMgZDEKNTkgMCAwIDcxIDAgMTIgY20KQkkKL0lNIHRydWUvVyA1OS9IIDcxL0JQQyAxL0Yv
Q0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1OQovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoKayCtPBAsEF
ggsILCWlhLCWlpYS10sLhA8InGDwjMHeEEGHpBvCTD0m9JvSb0m/vSfW+m9f2+vX+/+njv////8m
q169/1v+u3X+6Xfult16W2lt1tpbaWGwlsMILDBglhiFgwWDBQAQAQpFSQplbmRzdHJlYW0KZW5k
b2JqCjE4NCAwIG9iago8PC9MZW5ndGggMTc2ID4+CnN0cmVhbQowIDAgMCAwIDUxIDY5IGQxCjUx
IDAgMCA2OSAwIDAgY20KQkkKL0lNIHRydWUvVyA1MS9IIDY5L0JQQyAxL0YvQ0NGL0RQPDwvSyAt
MQovQ29sdW1ucyA1MQovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoaDwGN/v3+/e/f79/v3+3+/f79/v
3v3+/f79/t/v3+/f7f79/v3+Tdvb+/dvv4b7d8H8Xv+3/7f4AIAICkVJCmVuZHN0cmVhbQplbmRv
YmoKMTg1IDAgb2JqCjw8L0xlbmd0aCAyMzEgPj4Kc3RyZWFtCjAgMCAwIDAgNDcgNzEgZDEKNDcg
MCAwIDcxIDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDQ3L0ggNzEvQlBDIDEvRi9DQ0YvRFA8PC9LIC0x
Ci9Db2x1bW5zIDQ3Ci9CbGFja0lzMSB0cnVlCj4+CklEICahnJALwRGB4IPRQKHhBBh6CDek3pN6
T/ek3/r9X//X/X916Xa7rul2luu2luEttLbCWG0ttLYrDC60sILXT0dUHpN6TegmHpN9N6Tegm+m
+vSb6/vp//+v/f7X/ette0tuttLYYS2DCCwxCwwWQ0UgAgAgCkVJCmVuZHN0cmVhbQplbmRvYmoK
MTg2IDAgb2JqCjw8L0xlbmd0aCAxNzAgPj4Kc3RyZWFtCjAgMCAwIDE2IDQxIDcyIGQxCjQxIDAg
MCA1NiAwIDE2IGNtCkJJCi9JTSB0cnVlL1cgNDEvSCA1Ni9CUEMgMS9GL0NDRi9EUDw8L0sgLTEK
L0NvbHVtbnMgNDEKL0JsYWNrSXMxIHRydWUKPj4KSUQgIQCCas6Aohrra//////////IMD////+v
r68f/zME+H9///f/x////C/6//1/1qvC0McAEAEKRUkKZW5kc3RyZWFtCmVuZG9iagoxODcgMCBv
YmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjY0IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2Jq
CnhyZWYKMCAxODkKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDEwNzYyIDAwMDAwIG4gCjAwMDAw
MTA2OTUgMDAwMDAgbiAKMDAwMDAwNjc2MiAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAw
MDAwMDY3NDIgMDAwMDAgbiAKMDAwMDAxMDkwNCAwMDAwMCBuIAowMDAwMDA4MDEwIDAwMDAwIG4g
CjAwMDAwMTIxNDEgMDAwMDAgbiAKMDAwMDAxMjQxOSAwMDAwMCBuIAowMDAwMDEyNjQ3IDAwMDAw
IG4gCjAwMDAwMTI3MTEgMDAwMDAgbiAKMDAwMDAxMjk1OSAwMDAwMCBuIAowMDAwMDEzMDIzIDAw
MDAwIG4gCjAwMDAwMTMyNzAgMDAwMDAgbiAKMDAwMDAxMzMzNCAwMDAwMCBuIAowMDAwMDEzNTg1
IDAwMDAwIG4gCjAwMDAwMTM2NDkgMDAwMDAgbiAKMDAwMDAxMzk3MiAwMDAwMCBuIAowMDAwMDE0
MDM2IDAwMDAwIG4gCjAwMDAwMTQyODkgMDAwMDAgbiAKMDAwMDAxNDM1NCAwMDAwMCBuIAowMDAw
MDE0NjM4IDAwMDAwIG4gCjAwMDAwMTQ3MDIgMDAwMDAgbiAKMDAwMDAxNDk0NCAwMDAwMCBuIAow
MDAwMDE1MDA4IDAwMDAwIG4gCjAwMDAwMTUyMzMgMDAwMDAgbiAKMDAwMDAxNTI5NyAwMDAwMCBu
IAowMDAwMDE1NTYwIDAwMDAwIG4gCjAwMDAwMTU2MjQgMDAwMDAgbiAKMDAwMDAxNTg3MCAwMDAw
MCBuIAowMDAwMDE1OTM0IDAwMDAwIG4gCjAwMDAwMTYyMzUgMDAwMDAgbiAKMDAwMDAxNjQ2MiAw
MDAwMCBuIAowMDAwMDE2NTI2IDAwMDAwIG4gCjAwMDAwMTY4MDMgMDAwMDAgbiAKMDAwMDAxNjg2
NyAwMDAwMCBuIAowMDAwMDE2OTMxIDAwMDAwIG4gCjAwMDAwMTcxNTcgMDAwMDAgbiAKMDAwMDAx
NzIyMSAwMDAwMCBuIAowMDAwMDE3NDg1IDAwMDAwIG4gCjAwMDAwMTc2OTQgMDAwMDAgbiAKMDAw
MDAxNzc1OCAwMDAwMCBuIAowMDAwMDE3ODIyIDAwMDAwIG4gCjAwMDAwMTgxMDggMDAwMDAgbiAK
MDAwMDAxODMyMyAwMDAwMCBuIAowMDAwMDE4NTA1IDAwMDAwIG4gCjAwMDAwMTg1NjkgMDAwMDAg
biAKMDAwMDAxODc4MCAwMDAwMCBuIAowMDAwMDE5MDE1IDAwMDAwIG4gCjAwMDAwMTkwNzkgMDAw
MDAgbiAKMDAwMDAxOTI5OCAwMDAwMCBuIAowMDAwMDE5NTIwIDAwMDAwIG4gCjAwMDAwMTk1ODQg
MDAwMDAgbiAKMDAwMDAxOTgyOCAwMDAwMCBuIAowMDAwMDE5ODkyIDAwMDAwIG4gCjAwMDAwMjAx
NTggMDAwMDAgbiAKMDAwMDAyMDIyMiAwMDAwMCBuIAowMDAwMDIwNDU4IDAwMDAwIG4gCjAwMDAw
MjA1MjIgMDAwMDAgbiAKMDAwMDAyMDc1OCAwMDAwMCBuIAowMDAwMDIwOTc1IDAwMDAwIG4gCjAw
MDAwMjEwMzkgMDAwMDAgbiAKMDAwMDAyMTEwMyAwMDAwMCBuIAowMDAwMDIxMzUwIDAwMDAwIG4g
CjAwMDAwMjE1OTYgMDAwMDAgbiAKMDAwMDAyMTY2MCAwMDAwMCBuIAowMDAwMDIxOTEwIDAwMDAw
IG4gCjAwMDAwMjIxMjYgMDAwMDAgbiAKMDAwMDAyMjE5MCAwMDAwMCBuIAowMDAwMDIyMjU0IDAw
MDAwIG4gCjAwMDAwMjI0OTEgMDAwMDAgbiAKMDAwMDAyMjcyOSAwMDAwMCBuIAowMDAwMDIzMDEz
IDAwMDAwIG4gCjAwMDAwMjMwNzcgMDAwMDAgbiAKMDAwMDAyMzMxOCAwMDAwMCBuIAowMDAwMDIz
MzgyIDAwMDAwIG4gCjAwMDAwMjM0NDYgMDAwMDAgbiAKMDAwMDAyMzczMyAwMDAwMCBuIAowMDAw
MDIzOTc0IDAwMDAwIG4gCjAwMDAwMjQwMzggMDAwMDAgbiAKMDAwMDAyNDI5OCAwMDAwMCBuIAow
MDAwMDI0MzYyIDAwMDAwIG4gCjAwMDAwMjQ2MjEgMDAwMDAgbiAKMDAwMDAyNDgzOSAwMDAwMCBu
IAowMDAwMDI0OTAzIDAwMDAwIG4gCjAwMDAwMjUxNjUgMDAwMDAgbiAKMDAwMDAyNTIyOSAwMDAw
MCBuIAowMDAwMDI1NDc0IDAwMDAwIG4gCjAwMDAwMjU3MDMgMDAwMDAgbiAKMDAwMDAyNTk4MyAw
MDAwMCBuIAowMDAwMDI2MDQ3IDAwMDAwIG4gCjAwMDAwMjYzNTYgMDAwMDAgbiAKMDAwMDAyNjU4
MSAwMDAwMCBuIAowMDAwMDI2ODM5IDAwMDAwIG4gCjAwMDAwMjcxMTUgMDAwMDAgbiAKMDAwMDAy
NzE3OSAwMDAwMCBuIAowMDAwMDI3NDQxIDAwMDAwIG4gCjAwMDAwMjc3MDMgMDAwMDAgbiAKMDAw
MDAyNzc2NyAwMDAwMCBuIAowMDAwMDI3OTg4IDAwMDAwIG4gCjAwMDAwMjgwNTMgMDAwMDAgbiAK
MDAwMDAyODExOCAwMDAwMCBuIAowMDAwMDI4MzY2IDAwMDAwIG4gCjAwMDAwMjg1OTcgMDAwMDAg
biAKMDAwMDAyODY2MiAwMDAwMCBuIAowMDAwMDI4ODkxIDAwMDAwIG4gCjAwMDAwMjg5NTYgMDAw
MDAgbiAKMDAwMDAyOTAyMSAwMDAwMCBuIAowMDAwMDI5MDg2IDAwMDAwIG4gCjAwMDAwMjkzNTAg
MDAwMDAgbiAKMDAwMDAyOTQxNSAwMDAwMCBuIAowMDAwMDI5NzEzIDAwMDAwIG4gCjAwMDAwMjk3
NzggMDAwMDAgbiAKMDAwMDAzMDAzMyAwMDAwMCBuIAowMDAwMDMwMDk4IDAwMDAwIG4gCjAwMDAw
MzAzMzYgMDAwMDAgbiAKMDAwMDAzMDU5NSAwMDAwMCBuIAowMDAwMDMwODYxIDAwMDAwIG4gCjAw
MDAwMzA5MjYgMDAwMDAgbiAKMDAwMDAzMDk5MSAwMDAwMCBuIAowMDAwMDMxMjQ3IDAwMDAwIG4g
CjAwMDAwMzE0OTkgMDAwMDAgbiAKMDAwMDAzMTU2NCAwMDAwMCBuIAowMDAwMDMxNzgxIDAwMDAw
IG4gCjAwMDAwMzIwMzUgMDAwMDAgbiAKMDAwMDAzMjI5NSAwMDAwMCBuIAowMDAwMDMyNTUyIDAw
MDAwIG4gCjAwMDAwMzI4NDQgMDAwMDAgbiAKMDAwMDAzMjkwOSAwMDAwMCBuIAowMDAwMDMyOTc0
IDAwMDAwIG4gCjAwMDAwMzMyMzAgMDAwMDAgbiAKMDAwMDAzMzQ2MyAwMDAwMCBuIAowMDAwMDMz
NzA3IDAwMDAwIG4gCjAwMDAwMzM5NDkgMDAwMDAgbiAKMDAwMDAzNDAxNCAwMDAwMCBuIAowMDAw
MDM0MjQ4IDAwMDAwIG4gCjAwMDAwMzQzMTQgMDAwMDAgbiAKMDAwMDAzNDU5OSAwMDAwMCBuIAow
MDAwMDM0ODU5IDAwMDAwIG4gCjAwMDAwMzUwOTUgMDAwMDAgbiAKMDAwMDAzNTM3MSAwMDAwMCBu
IAowMDAwMDM1NjE0IDAwMDAwIG4gCjAwMDAwMzU4NDkgMDAwMDAgbiAKMDAwMDAzNTkxNSAwMDAw
MCBuIAowMDAwMDM1OTgwIDAwMDAwIG4gCjAwMDAwMzYxODEgMDAwMDAgbiAKMDAwMDAzNjI0NiAw
MDAwMCBuIAowMDAwMDM2NDQ4IDAwMDAwIG4gCjAwMDAwMzY3MjEgMDAwMDAgbiAKMDAwMDAzNjc4
NiAwMDAwMCBuIAowMDAwMDM3MDMwIDAwMDAwIG4gCjAwMDAwMzcyNzAgMDAwMDAgbiAKMDAwMDAz
NzQ3OCAwMDAwMCBuIAowMDAwMDM3NTQzIDAwMDAwIG4gCjAwMDAwMzc3NzMgMDAwMDAgbiAKMDAw
MDAzNzgzOCAwMDAwMCBuIAowMDAwMDM4MDk3IDAwMDAwIG4gCjAwMDAwMzgzMjEgMDAwMDAgbiAK
MDAwMDAzODU1MiAwMDAwMCBuIAowMDAwMDM4NjE3IDAwMDAwIG4gCjAwMDAwMzg4NzYgMDAwMDAg
biAKMDAwMDAzOTExNyAwMDAwMCBuIAowMDAwMDM5MzUzIDAwMDAwIG4gCjAwMDAwMzk1ODYgMDAw
MDAgbiAKMDAwMDAzOTY1MSAwMDAwMCBuIAowMDAwMDM5OTA1IDAwMDAwIG4gCjAwMDAwNDAxNTgg
MDAwMDAgbiAKMDAwMDA0MDM1NCAwMDAwMCBuIAowMDAwMDQwNDE5IDAwMDAwIG4gCjAwMDAwNDA0
ODQgMDAwMDAgbiAKMDAwMDA0MDY1NyAwMDAwMCBuIAowMDAwMDQwOTAwIDAwMDAwIG4gCjAwMDAw
NDA5NjUgMDAwMDAgbiAKMDAwMDA0MTAzMCAwMDAwMCBuIAowMDAwMDQxMjkzIDAwMDAwIG4gCjAw
MDAwNDE1MzcgMDAwMDAgbiAKMDAwMDA0MTgwMyAwMDAwMCBuIAowMDAwMDQxODY4IDAwMDAwIG4g
CjAwMDAwMDc4NTEgMDAwMDAgbiAKMDAwMDAwNjkxNyAwMDAwMCBuIAowMDAwMDA3ODMwIDAwMDAw
IG4gCjAwMDAwNDIwNzIgMDAwMDAgbiAKMDAwMDA0MjEzNyAwMDAwMCBuIAowMDAwMDQyNDEyIDAw
MDAwIG4gCjAwMDAwNDI2MzkgMDAwMDAgbiAKMDAwMDA0MjkyMSAwMDAwMCBuIAowMDAwMDQzMTQy
IDAwMDAwIG4gCjAwMDAwMTA4MTEgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAxODkgL1Jvb3Qg
MSAwIFIgL0luZm8gMTg4IDAgUgo+PgpzdGFydHhyZWYKNDMyMDcKJSVFT0YK

--ELM939748145-27176-0_

--ELM939748145-27176-0_--

From bouncefilter Tue Oct 12 13:12:34 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA04903;
Tue, 12 Oct 1999 13:11:56 -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 NAA29184;
Tue, 12 Oct 1999 13:11:45 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121711.NAA29184@candle.pha.pa.us>
Subject: Book PDF file was corrupt
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
Date: Tue, 12 Oct 1999 13:11:45 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM939748305-27176-1_
Content-Transfer-Encoding: 7bit

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

Here is the new PDF version of the outline. The previous version used
the Palatino font, which didn't convert to PDF for some reason.

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

--ELM939748305-27176-1_
Content-Type: application/pdf
Content-Disposition: inline; filename="/root/book.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjIKJcfsj6IKNCAwIG9iago8PC9MZW5ndGggNSAwIFIvRmlsdGVyIC9GbGF0ZURlY29k
ZT4+CnN0cmVhbQp4nL1ZSW/cNhQGevSvmFsdNMOIWqleCm9JnNqx49gJCuQiS/JY8YzkaEnj/vpy
FR9FaiZpgMKHMbi8jd977yPlIbzw2J/8zTd7X/a+LDAfUz/5ZnF4vffiKl7gBPlkcX23J1bjhY89
RMJFnIiJzf5l0/Wrtnz/7uzZ9ec9QlAYpCldel3sHzbNAxsMMYrHwcu2eWy6bM0muAafiV8mPorS
lCyWPkGpz3e3Q16yVQFGUaS2nzebz1VWs/FlEKEI04mlHyAcs9mLvG9uy1YqpZNE7ML+czZGvSGJ
kkR3pqMRHjfCD0MU+ItlEKOE24AR3+ajUAo6rfu2KYa8rxphg5hb4hRF3ALf3tH12XqdqR0RIsTz
Amo0Zmvoik/72adnfFeMvNG8V2XfV/WKB8CH8VM282OJxeAFG4yRT1f5YuQ9jwFK8ThyLbTTJWkg
VVi7rsSahIYbi5ETM0TGfq5DWvCO/Z+gmNovR85EfDwfpRE9IxyhWHh7O3obj94eNZvHai39XapA
sE3iID7t544YndZVX2Xr6p9Mn4eUCvQVDn3v+6wdwxswC+VEf88xh0MeBDHWle1XKUEDUaBsSTAK
Iuoy0Fc6LD1qy2zUR9E1IjMTZ8AMkHErsj67zTpuxjIizOjEiMSdlB/JIHTdoCRjxFBty6EqyYig
vNlssrroxvNhAB7RGOyCfISB+X3DV3sowGNoRSVYRjHCETOdig7ieaB/vH9iYz4Xm+6Kyh9cdhix
qBMjLE5YzYWdCluXIgKRj5JUyornsXZQFDodAyPKfG0K1v5d9ffcJw+sPDUSN+AHkoiptzoREyt9
Y5CIIv1CmazXk/KFPTLNNRf2PwhtUm5V6liHynzhqO+DY93laKQB4KpQwPwA1AdjxF5zZNUjy2dW
ebFZKlwJeFVuOFRpq9CJ/VU56iEv+HFHjw1HRfFLfsZdu0SfTN31uRp4xJNycN4U1d2TdIzmCR4x
//1QvXE4RkD7EcBMQBQi3ljlmgPtBrEci2YcCzxWXKFjKwd2r8qub6uxFoUxK3hkiysfDVdSmHWv
rayzT2RnQ6QA9AAAPSxsv3f1nEa3HMxqzg+XkIv5cwGGhuBchHvhVve0MwTOHU6UMdvk1F8WKrke
eHiVDEAIYdVlK15tKIiDMQmbO74QgxR8O+/njeWVnVhnpnkJ79py9VeB30RjM1sPpeqFIYp80AvD
aS88KL5KHulJeVmdlwX3KQLkQPZA0fkUwdFNl3Z1wW92cEDKHUuNmYRl3bZcvmubjVSru30miJmn
idn/W5/tvHY16oMVvUNw20NAxlZZX3a/82F65LqrzyPzwoKHDZi31sjEaAEPWaieW8XMGT9bzbkL
hdgSKg0v+xwJENILkKonFh3R7fjVzlIAiu33ROVyam6o576/FBB+Uxl5xFjD8Him2XjSPiCr/KRl
ElKcT7i/ZjHpGIDX8wGQ/YfpNCkPKPWcjQWsO6og2STs1dS3SK/+T76lEQvPzsvCm6aqXY0CkFba
+KakdcIDbjpFbmDqcBF2jVhXlFoLyTFHv3njWDniv4Uj2AkGop1YkIQkeCba+Tob5I0oJIzGJ9Bz
Z7Mdbr8MZVspVMk+tKNDXet6JvO6zeou43xDCFLnDcPz2SHpaGi7ppXK7Tvpg8Pk07ooZXfRFPXb
SFHpiceLkMRKxHrefl8Xe3XeRqMoyjvZ2MCVa1j3sjvFKFAISKWyjVSWghJ02VabrH168ZK3VA88
/DRtWa1q2ek1zB4s7liKkUCPPMlMCZm5pg31GDOdEgcOFAZzKDw2EWbMvRAIBSO7yBaEKtYEY1Ak
h8XRU9mufGgcPpwZimL2DqZ8sKvUn25WBws3MFTnjUG5tI1xgjhWhI2KvT6OVmpKY1P4cvPYtBQA
8vjjxFGnYv50Jc6RA4HL/+KQf8qkKa4T+uJ+b3CdZRLLxxBavJSxEbKQvOuFLARtfO6FjIAOYOyy
ebbzhQxSBfuFzGRYceh5khf8apgu3gigufCYsYbJTV3RYmf1i5dl1g+t6j0xCpM0kMEzOWcEONfF
7ecy7w07/BR0EABJf3da/ahDElqf9if7om1k5sdMEj4vScQKVmBk560Dl+e0LlZLTvsplQ3HOJRt
Jy+htMHq59mjps6Hti3rnMOLI1aC4UkAALhJF/dtw5/CA5/doMlu98+FlEi3qA9WQGxafjQFKWhx
MiCYEDZqBCR3AOSsyR8UO4lAp6K3Gxk86cVxmRVrulhWgpQdUDKpNIUj4tIfLM8yy4dhI3qvr5+F
0wl/ghZKAZHOQ/jIpS7Ysp/zDxZkYtbd2Fv194KrQRU1ZS20Y+Vw5H1Js5LeD1277IcCq9RCFlKt
VmVrM5B0C5c5y/gLNQ5ARRBVn961k0m+dxLfuopaGCT6M8GhZSC4LM6m6aGFykkJCGHrUqj0eCsw
vHXxrZnn2ZtOvNNjot47l0X5Sy2u7EEEuPvLoQY0j6ml9A5qfXCc1G6tGnBzii8eyzbrR67oeexL
ElTsIno/7S5giqo8PSqgYo9RzV307+Rb01e8yrEb69itLyn3E5+8hNYwBZNbtKYpy854hvGBkLdt
9mRnFAlVRjUuclHf07tAzx5r+M5AcE7QDGPHZ4+y5TTZuMxluSLkAagN42cQvVB/SCLw6XQLL7Gf
/pM56rWVl8AXnSkvibbyEgKSmXD3JME4ht+k2Bt0YgTPzSR4z0kheT3L6tUgqWcIi9DB5amio2Ew
of2upnyyuS2LQgKMv3FDncsYs0ZBdrayo99+my3ohYOpv3GUxARcRESCwbZsvEIcmCeypPV2/Iq1
rZ9dHB8Kv1Q/ghvGaz+IghNpWx+3YRmHFvJPo2Sm0yXmvdN9hTnapcQwyb6GuUQTcBc6uV6823u3
9y9o6stQZW5kc3RyZWFtCmVuZG9iago1IDAgb2JqCjIxNjEKZW5kb2JqCjMgMCBvYmoKPDwKL1R5
cGUgL1BhZ2UKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1BhcmVudCAyIDAgUgovUmVzb3VyY2Vz
IDw8IC9Qcm9jU2V0IFsvUERGIC9UZXh0XQovRm9udCA8PAovUjYgNiAwIFIKPj4KPj4KL0NvbnRl
bnRzIDQgMCBSCj4+CmVuZG9iago5IDAgb2JqCjw8L0xlbmd0aCAxMCAwIFIvRmlsdGVyIC9GbGF0
ZURlY29kZT4+CnN0cmVhbQp4nIVVUW+bMBB+z6/gbelDPAzYxo9t1XaT2q1JkKZJeSHgtLQhpAYm
db9+ts8YKMmqSEn7cT7f9913h4+w5+uP/c3K2dvszcMG636y0rtKZl9XVAPJbgah2OMMBR7zufpO
yvlm/ry5uEheZpgijjlXIUk+f9SIPhrrkxTA3xqkKAg5jwBJNEKQAjgB5Nsk5ucE+dElh7oWUYQY
4dRbYII49bGO2cwLW1Zk0sPJXxqJEVF1MkDE1gQF8F+aZaKuNRIwFIfdsc18RCdERGUMB0wjQ/0s
hcdxwRGijHMrClS5iANkMgAHuPTlBIO1kH8MGJsLLAmpIYYIcWkXdZELQwQj5tpylNWTTMuyODwZ
5Smi/ydJzpG87zs3FcKqedcLYZH1JGY5ibkfiwWsrJDpIR8ViRnCxEkzKXJQkm3393HyEOH+me1E
gANtEE/9YTvBEHhkIORJfw+cys6VNHX83cQuK4hhPe+bcdkj3c0ddKAmG9rrHhwfMxd/mav2141M
m6I6GMbKBup5ZBjHEXghdUPts470tRTqEFgnpFqNGB60tZAwNSHynaFss1QK5uybp026TWthohc8
1LTpyPRbdzF1F1+l2Wt7NNcGhsrHC/rFI0XdVNI4f0GJDmaj9NkJXo9C7ipZpofMnCOhltdSa9qD
Zbxgvj4Tj9LlJ6pN+vbZJsiq3e5F/VxVnXxGaq3UMJk4pXmr+JTFX9ct6uvBtNVVRw2DmIzoB8DW
pDY5dzYn6dZH4zroD/w8WnzcjdRRyLKoa3cHNwPD7GzApo276YjizmB5octK98b9RB+xj1airlqZ
2faHXLc/Hkzaad/dSvHWikOzf7cJewEu61eghzqtBXhCyWtDlq2yRMcgCsxaO7Px4n4Gb2Fyw35y
L5fjIezeGV/OJ1l/3PuDxWe3DaZY72DoWnR+BB7SYt81Lhx0aF/UjX1JMAfW7fFYyQaGINLj9/kQ
rNWZfQHqhUxXavXLq6wtlfqDfRFBBz4bhOuqLIXMCjACwYONMaqQ6QrjT0fhocqL3bsVYWSr5llY
DfrXGRjNODpGkYOzCl6L2MdIbbyQRQibOwON3iTecrac/QNjpTeVZW5kc3RyZWFtCmVuZG9iagox
MCAwIG9iago4MjAKZW5kb2JqCjggMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL01lZGlhQm94IFswIDAg
NjEyIDc5Ml0KL1BhcmVudCAyIDAgUgovUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsvUERGIC9UZXh0
XQovRm9udCA8PAovUjYgNiAwIFIKPj4KPj4KL0NvbnRlbnRzIDkgMCBSCj4+CmVuZG9iago2IDAg
b2JqCjw8L1R5cGUvRm9udC9OYW1lL1I2L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvVGltZXMtUm9t
YW4vRW5jb2RpbmcgNyAwIFI+PgplbmRvYmoKNyAwIG9iago8PC9UeXBlL0VuY29kaW5nL0RpZmZl
cmVuY2VzWwoyL2ZpXT4+CmVuZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvS2lkcyBbCjMg
MCBSCjggMCBSCl0gL0NvdW50IDIKPj4KZW5kb2JqCjEgMCBvYmoKPDwgL1R5cGUgL0NhdGFsb2cg
L1BhZ2VzIDIgMCBSCj4+CmVuZG9iagoxMSAwIG9iago8PCAvQ3JlYXRpb25EYXRlIChEOjE5OTkx
MDEyMTMxMDMxKQovUHJvZHVjZXIgKEFsYWRkaW4gR2hvc3RzY3JpcHQgNS41MCkKPj4KZW5kb2Jq
CnhyZWYKMCAxMgowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDM2NzkgMDAwMDAgbiAKMDAwMDAw
MzYxNCAwMDAwMCBuIAowMDAwMDAyMjY2IDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAw
MDAwMjI0NiAwMDAwMCBuIAowMDAwMDAzNDczIDAwMDAwIG4gCjAwMDAwMDM1NjEgMDAwMDAgbiAK
MDAwMDAwMzMyNSAwMDAwMCBuIAowMDAwMDAyNDE0IDAwMDAwIG4gCjAwMDAwMDMzMDUgMDAwMDAg
biAKMDAwMDAwMzcyOCAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDEyIC9Sb290IDEgMCBSIC9J
bmZvIDExIDAgUgo+PgpzdGFydHhyZWYKMzgyMAolJUVPRgo=

--ELM939748305-27176-1_

--ELM939748305-27176-1_--

From bouncefilter Tue Oct 12 13:17:34 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA06076;
Tue, 12 Oct 1999 13:16:47 -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 NAA29586;
Tue, 12 Oct 1999 13:16:35 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121716.NAA29586@candle.pha.pa.us>
Subject: Outline for PostgreSQL book
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
Date: Tue, 12 Oct 1999 13:16:35 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM939748595-29371-0_
Content-Transfer-Encoding: 7bit

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

Here is my proposal for an outline for a PostgreSQL book. Many of us
have been asked by publishers about writing a book. Here is what I
think would be a good outline for the book.

Any comments would be welcome.

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

The attached document is in both web page and text formats.
View the one which looks best.

--ELM939748595-29371-0_
Content-Type: text/html
Content-Disposition: inline; filename="/tmp/book.html"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<HTML>
<HEAD>
<TITLE>PostgreSQL Book Proposal</TITLE>
<META NAME="description" CONTENT="PostgreSQL Book Proposal">
<META NAME="keywords" CONTENT="29552">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<LINK REL="STYLESHEET" HREF="29552.css">
</HEAD>
<BODY >

<H1 ALIGN="CENTER">PostgreSQL Book Proposal</H1>
Bruce Momjian

</BODY>
</HTML>

--ELM939748595-29371-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/tmp/book.txt"
Content-Transfer-Encoding: 7bit

PostgreSQL Book Proposal

Bruce Momjian

--ELM939748595-29371-0_

--ELM939748595-29371-0_--

From bouncefilter Tue Oct 12 13:22:38 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA07227
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 13:22:17 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id NAA02115;
Tue, 12 Oct 1999 13:22:05 -0400
Message-ID: <38036E35.474A6B1B@wgcr.org>
Date: Tue, 12 Oct 1999 13:21:57 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: Bruce Momjian <maillist@candle.pha.pa.us>, vev@michvhf.com,
lockhart@alumni.caltech.edu, pgsql-hackers@postgreSQL.org, jwieck@debis.com
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might enjoy about PGSQL.)
References: <m11b4ew-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Wieck wrote:

I've setup an example for the new developers page at

<http://www.PostgreSQL.ORG/~wieck>

The image size is adjusted for the page width.

To maintain the hotspots I made a little, slightly
overspecialized, Tcl/Tk application that creates the imagemap
so it can easily be pasted into the page.

I get a Javascript error:
JavaScript Error: http://www.PostgreSQL.ORG/~wieck/, line 51:

pg_dot_start is not defined.

Netscape Communicator 4.61.

Otherwise, this globe is stunning.

There are a couple of typos (to be pedantic...): (;-))
Under Thomas, 'documentation' is incorrectly spelled.
Under Tom Lane, 'He has works on the optimizer', unless some arcane
usage of works is in vogue, should be either 'He works on' or 'He has
worked on', with the latter fitting with the tense already used in his
description.

If Vince wants to add my name as RPM maintainer, and no one objects, I
volunteer to continue to maintain the RedHat Linux RPM set (the last
revision of which shipped with RedHat 6.1).

Again, THIS GLOBE IS STUNNING!

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Oct 12 13:27:34 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA08319
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 13:26:58 -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 NAA29776;
Tue, 12 Oct 1999 13:26:26 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121726.NAA29776@candle.pha.pa.us>
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might enjoy about PGSQL.)
In-Reply-To: <38036E35.474A6B1B@wgcr.org> from Lamar Owen at "Oct 12,
1999 01:21:57 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Tue, 12 Oct 1999 13:26:25 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>, vev@michvhf.com, lockhart@alumni.caltech.edu,
pgsql-hackers@postgreSQL.org, jwieck@debis.com
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Again, THIS GLOBE IS STUNNING!

Yep. That's the word for it. I will fix the wording once Jan is
finished. The mistakes are mine.

-- 
  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 12 13:27:34 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id NAA08249
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 13:26:40 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 5119 invoked by uid 1001); 12 Oct 1999 17:26:43 -0000
Date: Tue, 12 Oct 1999 13:26:43 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Lamar Owen <lamar.owen@wgcr.org>
cc: Jan Wieck <wieck@debis.com>, Bruce Momjian <maillist@candle.pha.pa.us>,
lockhart@alumni.caltech.edu, pgsql-hackers@postgreSQL.org, jwieck@debis.com
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might enjoy about PGSQL.)
In-Reply-To: <38036E35.474A6B1B@wgcr.org>
Message-ID: <Pine.BSF.4.05.9910121324270.4296-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 12 Oct 1999, Lamar Owen wrote:

If Vince wants to add my name as RPM maintainer, and no one objects, I
volunteer to continue to maintain the RedHat Linux RPM set (the last
revision of which shipped with RedHat 6.1).

Vince always thought that was Bruce's page.

From bouncefilter Tue Oct 12 13:33:34 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 NAA09832
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 13:32:38 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11b5hT-0003kLC; Tue, 12 Oct 99 19:26 MET DST
Message-Id: <m11b5hT-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might
To: lamar.owen@wgcr.org (Lamar Owen)
Date: Tue, 12 Oct 1999 19:26:59 +0200 (MET DST)
Cc: wieck@debis.com, maillist@candle.pha.pa.us, vev@michvhf.com,
lockhart@alumni.caltech.edu, pgsql-hackers@postgreSQL.org, jwieck@debis.com
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <38036E35.474A6B1B@wgcr.org> from "Lamar Owen" at Oct 12,
99 01:21:57 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Lamar Owen wrote:

Jan Wieck wrote:

I've setup an example for the new developers page at

<http://www.PostgreSQL.ORG/~wieck>

The image size is adjusted for the page width.

To maintain the hotspots I made a little, slightly
overspecialized, Tcl/Tk application that creates the imagemap
so it can easily be pasted into the page.

I get a Javascript error:
JavaScript Error: http://www.PostgreSQL.ORG/~wieck/, line 51:

pg_dot_start is not defined.

Ooops - thanks and corrected, try again. I forgot to remove
the onLoad() in the <body>. That blinking-dot stuff isn't
required anymore since the globe looks already nice enough
without animation.

Again, THIS GLOBE IS STUNNING!

Tnx :-)

Jan

From bouncefilter Tue Oct 12 13:28:34 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA08459
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 13:27:38 -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 NAA29831;
Tue, 12 Oct 1999 13:27:04 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121727.NAA29831@candle.pha.pa.us>
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might enjoy about PGSQL.)
In-Reply-To: <Pine.BSF.4.05.9910121324270.4296-100000@paprika.michvhf.com>
from
Vince Vielhaber at "Oct 12, 1999 01:26:43 pm"
To: Vince Vielhaber <vev@michvhf.com>
Date: Tue, 12 Oct 1999 13:27:04 -0400 (EDT)
CC: Lamar Owen <lamar.owen@wgcr.org>, Jan Wieck <wieck@debis.com>,
lockhart@alumni.caltech.edu, pgsql-hackers@postgreSQL.org, jwieck@debis.com
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 12 Oct 1999, Lamar Owen wrote:

If Vince wants to add my name as RPM maintainer, and no one objects, I
volunteer to continue to maintain the RedHat Linux RPM set (the last
revision of which shipped with RedHat 6.1).

Vince always thought that was Bruce's page.

Sure, I'll add you once Jan finishes.

-- 
  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 12 13:40:34 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA11755
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 13:40:17 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id NAA02184;
Tue, 12 Oct 1999 13:40:12 -0400
Message-ID: <38037275.4FADDA73@wgcr.org>
Date: Tue, 12 Oct 1999 13:40:05 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might
References: <m11b5hT-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Wieck wrote:

pg_dot_start is not defined.

Ooops - thanks and corrected, try again. I forgot to remove
the onLoad() in the <body>. That blinking-dot stuff isn't
required anymore since the globe looks already nice enough
without animation.

Ah, yes. Much better.

--
Lamar Owen
WGCR Internet Radio
Pisgah Forest, North Carolina
1 Peter 4:11

From bouncefilter Tue Oct 12 13:45:35 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA13162
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 13:45:07 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id OAA94199;
Tue, 12 Oct 1999 14:43:58 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 12 Oct 1999 14:43:54 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Jan Wieck <wieck@debis.com>, vev@michvhf.com, lockhart@alumni.caltech.edu,
lamar.owen@wgcr.org, pgsql-hackers@postgreSQL.org, jwieck@debis.com
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might enjoy about PGSQL.)
In-Reply-To: <199910121635.MAA26990@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910121441260.30583-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 12 Oct 1999, Bruce Momjian wrote:

I have tcl 8.0.5 and povray here too.

I've setup an example for the new developers page at

<http://www.PostgreSQL.ORG/~wieck>

The image size is adjusted for the page width.

To maintain the hotspots I made a little, slightly
overspecialized, Tcl/Tk application that creates the imagemap
so it can easily be pasted into the page.

I'll contact you and Vince via private mail after packing it
up.

I just realized I can put my mouse over a pin, and the name appears.
That is great.

most cool...one thing though...considering teh width of those tags, how
about adding location info in there also? For instance "Edmund, Mergyl:
Stuttgart, Germany" ... :)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 12 13:46:37 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA13358
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 13:46:17 -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 NAA00739;
Tue, 12 Oct 1999 13:45:15 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121745.NAA00739@candle.pha.pa.us>
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might enjoy about PGSQL.)
In-Reply-To: <Pine.BSF.4.10.9910121441260.30583-100000@thelab.hub.org> from
The
Hermit Hacker at "Oct 12, 1999 02:43:54 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 12 Oct 1999 13:45:15 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>, vev@michvhf.com, lockhart@alumni.caltech.edu,
lamar.owen@wgcr.org, pgsql-hackers@postgreSQL.org, jwieck@debis.com
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I'll contact you and Vince via private mail after packing it
up.

I just realized I can put my mouse over a pin, and the name appears.
That is great.

most cool...one thing though...considering teh width of those tags, how
about adding location info in there also? For instance "Edmund, Mergyl:
Stuttgart, Germany" ... :)

Marc, let's not get Jan upset. :-)

Their location is already in the lower page next to their name anyway.

-- 
  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 12 14:31:35 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 OAA24452
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 14:30:46 -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 WAA07471
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 22:30:40 +0400 (MSD)
Date: Tue, 12 Oct 1999 22:30:40 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: hackers@postgreSQL.org
Subject: cvsweb
Message-ID: <Pine.GSO.3.96.SK.991012222833.11898F-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Is it worth to install cvsweb
( http://stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi/ )

Here is some info:
his is a WWW interface to a sample CVS tree to demonstrate the features of this
improved cvsweb. You can browse the file hierarchy by picking directories (which
have slashes after them, e.g. src/). If you pick a file, you will see the revision history
for that file. Selecting a revision number will download that revision of the file. There
is a link at each revision to display (colored) diffs between that revision and the
previous one or to annotate a revision. A form at the bottom of the page that allows
you to display diffs between arbitrary revisions.

Regards,

From bouncefilter Tue Oct 12 14:34:35 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 OAA25062
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 14:33: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 OAA17454;
Tue, 12 Oct 1999 14:32:31 -0400 (EDT)
To: Bernard Frankpitt <frankpit@pop.dn.net>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
In-reply-to: Your message of Tue, 12 Oct 1999 17:04:13 +0000
<38036A0D.363234BC@pop.dn.net>
Date: Tue, 12 Oct 1999 14:32:31 -0400
Message-ID: <17452.939753151@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bernard Frankpitt <frankpit@pop.dn.net> writes:

With all due respect to people who I am sure know a lot more about this
than I do, it seems to me that extensive use of TIDs in user code might
place an unwelcome restraint on the internal database design.

Yes, we'd certainly have to label it as an implementation-dependent
feature that might change or vanish in the future. But as long as
people understand that they are tying themselves to a particular
implementation, I can see the usefulness of making this feature
accessible. I'm still dubious that it's actually worth the work ...
but as long as I'm not the one doing the work, I can hardly object ;-).

I just want to be sure that we don't create a maintenance headache
for ourselves by corrupting the system structure. We've spent a
lot of time cleaning up after past shortcuts, and still have many
more to deal with; introducing new ones doesn't seem good.

regards, tom lane

From bouncefilter Tue Oct 12 14:42:35 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA26608
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 14:41:50 -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 OAA03133;
Tue, 12 Oct 1999 14:40:03 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121840.OAA03133@candle.pha.pa.us>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
In-Reply-To: <17452.939753151@sss.pgh.pa.us> from Tom Lane at "Oct 12,
1999 02:32:31 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 12 Oct 1999 14:40:03 -0400 (EDT)
CC: Bernard Frankpitt <frankpit@pop.dn.net>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bernard Frankpitt <frankpit@pop.dn.net> writes:

With all due respect to people who I am sure know a lot more about this
than I do, it seems to me that extensive use of TIDs in user code might
place an unwelcome restraint on the internal database design.

Yes, we'd certainly have to label it as an implementation-dependent
feature that might change or vanish in the future. But as long as
people understand that they are tying themselves to a particular
implementation, I can see the usefulness of making this feature
accessible. I'm still dubious that it's actually worth the work ...
but as long as I'm not the one doing the work, I can hardly object ;-).

I just want to be sure that we don't create a maintenance headache
for ourselves by corrupting the system structure. We've spent a
lot of time cleaning up after past shortcuts, and still have many
more to deal with; introducing new ones doesn't seem good.

Agreed.

-- 
  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 12 14:46:35 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA27640
for <pgsql-hackers@postgresql.org>;
Tue, 12 Oct 1999 14:46:28 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id OAA02313
for <pgsql-hackers@postgresql.org>; Tue, 12 Oct 1999 14:46:33 -0400
Message-ID: <38038201.8932A7A3@wgcr.org>
Date: Tue, 12 Oct 1999 14:46:25 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Packaging questions and ideas for 7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

As I begin to get a feel for the changes in PostgreSQL 7, I begin to
think about the changes I will have to make to the RedHat RPMs. Since
the 7 code is nowhere near a packageable condition as yet, I have
restricted my thinking to some general issues.

In the latest RPM's for RedHat for version 6.5.2, a couple of scripts
and some documentation is packaged that is not part of the main
tarball. Of the
additions, I find that there are pieces that could be useful as part of
the main tarball.

The first and foremost piece that I would like to see included (in a
modified form) is the migration script set that Oliver Elphick wrote and
I modified. A further modification could be made to let these scripts
work for the general case -- environment variables, et al, to direct the
migration work.

There are two scripts of interest:

1.) pg_dumpall_new: A modified pg_dumpall that uses a different port
number and linking loader directives to allow execution of backup copies
of postmaster, postgres, libpq.so, and psql to dump an old format
database after the new version has been installed.

2.) postgresql-dump: A script that performs the work of migrating --
whether it be a dump-restore, or whatnot. This is a quite comprehensive
script.

Work would have to be done to these two scripts for the general case --
would such work be worth the effort for those who don't run the RPM or
Debian versions?? The work to be done would comprise: writing a script
(as part of make install?) to pull the backup executables, and modifying
the two scripts above to work with postgresql installed WHEREVER. The
scripts could be integrated with a configure directive, maybe?

I realize that these scripts solve a problem that is not widespread
(wide relative to number of platforms, not number of users), but someone
other than a Debian or RedHat user might find them useful.

Also packaged in the RPM set is a README for the rpm set, an initscript
for the RedHat SysV-style init system, and the PostgreSQL-HOWTO. Of
these three, for the general case, the PostgreSQL-HOWTO is by far the
most useful -- in fact, a good portion of Bruce's outline is contained
within the HOWTO. The PostgreSQL HOWTO can be found on the Linux
Documentation Project's site (metalab.unc.edu/linux).

With the popularity of the RPM version (RedHat and Mandrake ship
substantially the same RPM set, with SuSE and Caldera shipping others),
would it be prudent to include some RPM-specific (and Debian specific)
notes in the main documentation, and where?? With all the different
layouts between the various packages, is it desireable to maybe make a
'packages FAQ'??

My next substantial challenge is going to be making the RedHat-specific
RPM set function on a non-RedHat RPM-based distribution, such as the
aforementioned Caldera and SuSE. A generic RPM set will then be the
result -- and then any RPM-based distribution can use the enhancements
and will be generally compatible. I got e-mail last week from a SuSE
user who wanted to use the 6.5.2-1 RPM set that I put together -- and,
quite frankly, I was clueless to SuSE, which was embarassing. The
situation with Caldera is worse -- they packaged 6.2.1 a long time ago
(COL 1.3), and the latest version of COL doesn't even have PostgreSQL.

I am open to suggestions.

In any case, have a good one...

--
Lamar Owen
WGCR Internet Radio
Pisgah Forest, North Carolina
1 Peter 4:11

From bouncefilter Tue Oct 12 14:53:35 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA29287
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 14:53:24 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA94745;
Tue, 12 Oct 1999 15:52:26 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 12 Oct 1999 15:52:26 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Oleg Bartunov <oleg@sai.msu.su>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] cvsweb
In-Reply-To: <Pine.GSO.3.96.SK.991012222833.11898F-100000@ra>
Message-ID: <Pine.BSF.4.10.9910121551480.30583-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

there was a time when we did...wasn't there? *raised eyebrow8 I swore I
remember it, but I just went looking around the directory structure and
only found:

http://www.postgresql.org/cgi/cvswebtest.cgi

On Tue, 12 Oct 1999, Oleg Bartunov wrote:

Is it worth to install cvsweb
( http://stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi/ )

Here is some info:
his is a WWW interface to a sample CVS tree to demonstrate the features of this
improved cvsweb. You can browse the file hierarchy by picking directories (which
have slashes after them, e.g. src/). If you pick a file, you will see the revision history
for that file. Selecting a revision number will download that revision of the file. There
is a link at each revision to display (colored) diffs between that revision and the
previous one or to annotate a revision. A form at the bottom of the page that allows
you to display diffs between arbitrary revisions.

Regards,

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

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

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 12 14:53:35 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA29296
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 14:53:26 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id OAA02346;
Tue, 12 Oct 1999 14:53:13 -0400
Message-ID: <38038391.8F602C2D@wgcr.org>
Date: Tue, 12 Oct 1999 14:53:05 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Oleg Bartunov <oleg@sai.msu.su>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] cvsweb
References: <Pine.GSO.3.96.SK.991012222833.11898F-100000@ra>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oleg Bartunov wrote:

Is it worth to install cvsweb
( http://stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi/ )

Must have been...

http://www.postgresql.org/cgi/cvswebtest.cgi/pgsql

--
Lamar Owen
WGCR Internet Radio
Pisgah Forest, North Carolina
1 Peter 4:11

From bouncefilter Tue Oct 12 15:17:36 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 PAA34520
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 15:17:22 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11b7KV-0003kLC; Tue, 12 Oct 99 21:11 MET DST
Message-Id: <m11b7KV-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Tue, 12 Oct 1999 21:11:23 +0200 (MET DST)
Cc: scrappy@hub.org, wieck@debis.com, 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: <199910121745.NAA00739@candle.pha.pa.us> from "Bruce Momjian" at
Oct 12, 99 01:45:15 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

I'll contact you and Vince via private mail after packing it
up.

I just realized I can put my mouse over a pin, and the name appears.
That is great.

most cool...one thing though...considering teh width of those tags, how
about adding location info in there also? For instance "Edmund, Mergyl:
Stuttgart, Germany" ... :)

Marc, let's not get Jan upset. :-)

Bruce, to upset me Marc needs alot of more efford!

And why not? If you UPDATE you'll see that we can get rid of
most of the entire body. Remember - a picture says more than
a thousand words :-)

Instead there could be more important information like our
release policy (no features in bufix releases, backward
compatibility in minor releases), how to submit
patches/improvements, where to find documentation on how to
enhance/hack PostgreSQL etc.

Their location is already in the lower page next to their name anyway.

Jan

From bouncefilter Tue Oct 12 15:15: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 PAA33801
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 15:14:24 -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 XAA08267;
Tue, 12 Oct 1999 23:13:13 +0400 (MSD)
Date: Tue, 12 Oct 1999 23:13:13 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: The Hermit Hacker <scrappy@hub.org>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] cvsweb
In-Reply-To: <Pine.BSF.4.10.9910121551480.30583-100000@thelab.hub.org>
Message-ID: <Pine.GSO.3.96.SK.991012230954.11898H-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 12 Oct 1999, The Hermit Hacker wrote:

Date: Tue, 12 Oct 1999 15:52:26 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Oleg Bartunov <oleg@sai.msu.su>
Cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] cvsweb

there was a time when we did...wasn't there? *raised eyebrow8 I swore I
remember it, but I just went looking around the directory structure and
only found:

http://www.postgresql.org/cgi/cvswebtest.cgi

Yes, I've seen it. The version I wrote about is a little better (imo)

Oleg

On Tue, 12 Oct 1999, Oleg Bartunov wrote:

Is it worth to install cvsweb
( http://stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi/ )

Here is some info:
his is a WWW interface to a sample CVS tree to demonstrate the features of this
improved cvsweb. You can browse the file hierarchy by picking directories (which
have slashes after them, e.g. src/). If you pick a file, you will see the revision history
for that file. Selecting a revision number will download that revision of the file. There
is a link at each revision to display (colored) diffs between that revision and the
previous one or to annotate a revision. A form at the bottom of the page that allows
you to display diffs between arbitrary revisions.

Regards,

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

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

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

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

From bouncefilter Tue Oct 12 15:15:36 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 PAA34202
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 15:15:17 -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 XAA08275
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 23:15:12 +0400 (MSD)
Date: Tue, 12 Oct 1999 23:15:11 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: hackers@postgreSQL.org
Subject: createlang plpgsql template1 failed in current CVS
Message-ID: <Pine.GSO.3.96.SK.991012231327.11898J-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Just to mention - there is a problem in current CVS:

om:~$ createlang plpgsql template1
ERROR: Unable to locate type oid 0 in catalog
Cannot install language

Oleg

From bouncefilter Tue Oct 12 15:29:36 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 PAA36751
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 15:29:06 -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 XAA08645;
Tue, 12 Oct 1999 23:28:48 +0400 (MSD)
Date: Tue, 12 Oct 1999 23:28:48 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might enjoy about PGSQL.)
In-Reply-To: <199910121726.NAA29776@candle.pha.pa.us>
Message-ID: <Pine.GSO.3.96.SK.991012231549.11898K-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

who is a maintainer of Developers List.
I understand that I'm not a postgres coder but is't
possible to mention somewhere:

Bartunov, Oleg in Moscow, Russia (oleg@sai.msu.su)
has introduced locale support.

It was rather long ago and was very limited but
I still proud for this little hack many people
used. (take into account I'm not a C-programmer at all :-)

Regards,

Oleg

From bouncefilter Tue Oct 12 14:32:36 1999
Received: from ns.infoset.cz (ns.infoset.cz [194.213.32.210])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA24660
for <pgsql-hackers@postgresql.org>;
Tue, 12 Oct 1999 14:31:38 -0400 (EDT)
(envelope-from dpeder@infoset.cz)
Received: from WinProxy.anywhere ([62.168.15.178])
by ns.infoset.cz (8.8.7/8.8.7) with SMTP id UAA01688
for <pgsql-hackers@postgresql.org>; Tue, 12 Oct 1999 20:31:06 +0200
Received: from 192.168.1.1 by 192.168.1.3 (WinProxy);
Tue, 12 Oct 1999 20:37:34 +0100
Received: by Dan with Microsoft Mail
id <01BF14F0.C158EBC0@Dan>; Tue, 12 Oct 1999 20:31:25 +0100
Message-ID: <01BF14F0.C158EBC0@Dan>
From: =?iso-8859-2?Q?Daniel_P=E9der?= <dpeder@infoset.cz>
To: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: empty/automatic insert availability
Date: Tue, 12 Oct 1999 20:31:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id OAA24828

it would be good idea to enable "empty automatic insert" like this:

mydb => create table pgx_replid ( repltime time DEFAULT current_time );
mydb => insert into pgx_replid;

====
the above should insert the value of current_time into database pgx_replid, however it is impossible yet (ver.6.3.x / 6.5.2). Now, everytime needed, one should type more complex lines like:

mydb => insert into pgx_replid values ( current_time );

====
in case the table was created without any DEFAULT the empty insert should insert NULL or NULLs into all (or specified) fields of table as the general behavior.

--
dan peder
dpeder@infoset.cz

From bouncefilter Tue Oct 12 15:40:36 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA38528
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 15:39:44 -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 PAA05618;
Tue, 12 Oct 1999 15:37:39 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121937.PAA05618@candle.pha.pa.us>
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might
In-Reply-To: <m11b7KV-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 12, 1999 09:11:23 pm"
To: Jan Wieck <wieck@debis.com>
Date: Tue, 12 Oct 1999 15:37:39 -0400 (EDT)
CC: scrappy@hub.org, vev@michvhf.com, lockhart@alumni.caltech.edu,
lamar.owen@wgcr.org, pgsql-hackers@postgreSQL.org, jwieck@debis.com
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Marc, let's not get Jan upset. :-)

Bruce, to upset me Marc needs alot of more efford!

And why not? If you UPDATE you'll see that we can get rid of
most of the entire body. Remember - a picture says more than
a thousand words :-)

Wow, that is cool. No need for text at bottom, except to list names and
e-mail addresses.

Instead there could be more important information like our
release policy (no features in bufix releases, backward
compatibility in minor releases), how to submit
patches/improvements, where to find documentation on how to
enhance/hack PostgreSQL etc.

That's an interesting idea, though I think the documentation or download
page may be a better place for that.

-- 
  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 12 15:39:35 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA38460
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 15:39: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 PAA05631;
Tue, 12 Oct 1999 15:38:23 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121938.PAA05631@candle.pha.pa.us>
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might enjoy about PGSQL.)
In-Reply-To: <Pine.GSO.3.96.SK.991012231549.11898K-100000@ra> from Oleg
Bartunov at "Oct 12, 1999 11:28:48 pm"
To: Oleg Bartunov <oleg@sai.msu.su>
Date: Tue, 12 Oct 1999 15:38:22 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

who is a maintainer of Developers List.
I understand that I'm not a postgres coder but is't
possible to mention somewhere:

Bartunov, Oleg in Moscow, Russia (oleg@sai.msu.su)
has introduced locale support.

It was rather long ago and was very limited but
I still proud for this little hack many people
used. (take into account I'm not a C-programmer at all :-)

Sure, let me do that when Jan is done.

-- 
  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 12 15:56:36 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA41679
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 15:55:37 -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 PAA06352;
Tue, 12 Oct 1999 15:53:35 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910121953.PAA06352@candle.pha.pa.us>
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might
In-Reply-To: From "(env:" "maillist)" at "Oct 12, 1999 03:37:39 pm"
To: maillist@candle.pha.pa.us
Date: Tue, 12 Oct 1999 15:53:35 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>, scrappy@hub.org, vev@michvhf.com,
lockhart@alumni.caltech.edu, lamar.owen@wgcr.org,
pgsql-hackers@postgreSQL.org, jwieck@debis.com
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Marc, let's not get Jan upset. :-)

Bruce, to upset me Marc needs alot of more efford!

And why not? If you UPDATE you'll see that we can get rid of
most of the entire body. Remember - a picture says more than
a thousand words :-)

Wow, that is cool. No need for text at bottom, except to list names and
e-mail addresses.

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

-- 
  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 12 16:07:36 1999
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net
[194.217.242.41]) by hub.org (8.9.3/8.9.3) with ESMTP id QAA45359
for <hackers@postgresql.org>; Tue, 12 Oct 1999 16:07:13 -0400 (EDT)
(envelope-from peter@retep.org.uk)
Received: from maidast.demon.co.uk ([158.152.22.37] helo=maidast.retep.org.uk)
by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 11b8CU-000Jzm-0C; Tue, 12 Oct 1999 20:07:10 +0000
Received: from localhost (peter@localhost [127.0.0.1])
by maidast.retep.org.uk (8.9.3/8.9.3) with ESMTP id VAA01042;
Tue, 12 Oct 1999 21:07:15 +0100
Date: Tue, 12 Oct 1999 21:07:15 +0100 (GMT)
From: Peter Mount <peter@retep.org.uk>
To: PostgreSQL Hackers <hackers@postgresql.org>
cc: Yin-So Chen <ychen1@uswest.net>
Subject: Re: [GENERAL] stored procedure revisited (fwd)
Message-ID: <Pine.LNX.4.10.9910122052520.32422-100000@maidast.retep.org.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

While catching up with my email, I noticed this on the general list. Is
there any news/updates on when SP will be available.

If were going for a 7.0 release after 6.5.3, it would be nice (and I'm
thinking of JDBC here) of having this. It would allow me to remove the
kludge that's always been there for PrepareStatement, where it emulates
this by filling in the gaps on the client.

Peter

--
Peter T Mount peter@retep.org.uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf

---------- Forwarded message ----------
Date: Sun, 10 Oct 1999 13:44:00 -0700
From: Yin-So Chen <ychen1@uswest.net>
To: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] stored procedure revisited

amy cheng wrote:

forgive my ignorance. why "multi-resultset, multi-level transaction" SP is
so important? no work-around? I rememeber there were some discussion on
multiple-return-value-function in the past. My impression is that they are
not that crucial and usually can
find rather simple work-arounds.

SP is important for a lot of reasons. First it allows faster network
transmission because you don't have to send the query over and over
again, second it allows for faster execution because the server doesn't
need to reparse the query every time, third it allows for conceptual
abstraction so the queries can be moved into the database layer, etc...
"multi-resultset, multi-level transaction" is just an indication of what
other database can do with SP's. All I want to know is if there is SP
for postgresql, or _better_than_SP_ alternatives.

Work-arounds are, exactly that, work-arounds. They are something that
will work _for_now_, but not the best solution. I ask the question not
because I don't know how to live without SP, but because I want to see
what the mentality is behind the whole thing - is there something
intrinsically wrong with having SP, or is there some better stuffs than
SP out there, etc. What makes a piece of software great? When its
developers do not settle for work-arounds.

My questions still stand. Please can someone fill in on the status with
SP, thanks.

Regards,

yin-so chen

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

From bouncefilter Tue Oct 12 16:13:36 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id QAA46350
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 16:13:06 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 5611 invoked by uid 1001); 12 Oct 1999 20:13:09 -0000
Message-ID: <XFMail.991012161309.vev@michvhf.com>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.GSO.3.96.SK.991012230954.11898H-100000@ra>
Date: Tue, 12 Oct 1999 16:13:09 -0400 (EDT)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: Oleg Bartunov <oleg@sai.msu.su>
Subject: Re: [HACKERS] cvsweb
Cc: hackers@postgreSQL.org, The Hermit Hacker <scrappy@hub.org>

On 12-Oct-99 Oleg Bartunov wrote:

On Tue, 12 Oct 1999, The Hermit Hacker wrote:

Date: Tue, 12 Oct 1999 15:52:26 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Oleg Bartunov <oleg@sai.msu.su>
Cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] cvsweb

there was a time when we did...wasn't there? *raised eyebrow8 I swore I
remember it, but I just went looking around the directory structure and
only found:

http://www.postgresql.org/cgi/cvswebtest.cgi

Yes, I've seen it. The version I wrote about is a little better (imo)

Oleg

Do you mean this?

http://www.postgresql.org/cgi/cvswebtest.cgi/pgsql

It's in Info Central. Besides the gray background, it works.

From bouncefilter Tue Oct 12 16:17:36 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA47092
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 16:17:09 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id QAA02548;
Tue, 12 Oct 1999 16:16:31 -0400
Message-ID: <38039717.A9FFAA27@wgcr.org>
Date: Tue, 12 Oct 1999 16:16:23 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Jan Wieck <wieck@debis.com>, scrappy@hub.org, vev@michvhf.com,
lockhart@alumni.caltech.edu, pgsql-hackers@postgreSQL.org, jwieck@debis.com
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might
References: <199910121953.PAA06352@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Wow, that is cool. No need for text at bottom, except to list names and
e-mail addresses.

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

It is way cool.

Until you turn off Javascript for security reasons. Or you surf with
Konqueror (the KDE file manager)....

Or if you surf with images turned off because, on your Toshiba 225CDS
notebook, Netscape farkles the video driver with regularity IF AND ONLY
IF images are loaded.... :-)

The globe is stunning -- but the text below also has a place, IMHO.

--
Lamar Owen
WGCR Internet Radio
Pisgah Forest, North Carolina
1 Peter 4:11

From bouncefilter Tue Oct 12 16:21:36 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA47784
for <pgsql-hackers@postgresql.org>;
Tue, 12 Oct 1999 16:21:17 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id QAA02572
for <pgsql-hackers@postgresql.org>; Tue, 12 Oct 1999 16:21:24 -0400
Message-ID: <3803983B.DE67DDD8@wgcr.org>
Date: Tue, 12 Oct 1999 16:21:15 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: [Fwd: cvsweb-1.73-1.noarch]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Man, talk about serendipity! Here's the latest on cvsweb, straight from
the redhat-announce list!

--
Lamar Owen
WGCR Internet Radio
Pisgah Forest, North Carolina
1 Peter 4:11
--------------------------------------------

Peter Hanecak wrote:

hello,

i made cvsweb-1.73-1.noarch RPMs available at:

http://www.megaloman.com/~hany/RPM/cvsweb.html

$ rpm -qi cvsweb
Name : cvsweb Relocations: (not relocateable)
Version : 1.73 Vendor: Mega & Loman (http://www.megaloman.com/)
Release : 1 Build Date: Tue Oct 12 21:39:55 1999
Install date: Tue Oct 12 21:40:03 1999 Build Host: megaloman.megaloman.sk
Group : Development/Tools Source RPM: cvsweb-1.73-1.src.rpm
Size : 101941 License: BSD type
Packager : Peter Hanecak <hanecak@megaloman.sk>
URL : http://stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi/
Summary : visual (www) interface to explore a cvs repository
Description :
cvsweb is a visual (www) interface to explore a cvs repository. This is an
enhanced cvsweb developed by Henner Zeller. Enhancements include
recognition
and display of popular mime-types, visual, color-coded, side by side diffs
of changes and the ability sort the file display and to hide old files
from view. One living example of the enhanced cvsweb is the KDE cvsweb

cvsweb requires the server to have cvs and a cvs repository worth
exploring.

have fun

hany

===================================================================
Peter Hanecak - production manager
Mega & Loman, Stare grunty 52, 842 44 Bratislava, Slovakia
tel., fax: +421-7-654 211 52
hanecak@megaloman.com, http://www.megaloman.com
GPG pub.key: http://www.megaloman.com/gpg/hanecak-megaloman.txt
===================================================================

--
To unsubscribe:
mail -s unsubscribe redhat-announce-list-request@redhat.com < /dev/null

From bouncefilter Tue Oct 12 16:51:37 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 QAA53671;
Tue, 12 Oct 1999 16:50:44 -0400 (EDT) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max06-028.enterprise.net
[194.72.197.88])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id VAA21082;
Tue, 12 Oct 1999 21:50:42 +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/GNU) with ESMTP id VAA04297;
Tue, 12 Oct 1999 21:49:56 +0100
Message-Id: <199910122049.VAA04297@linda.lfix.co.uk>
X-Mailer: exmh version 2.0.2 2/24/98 (debian)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
Subject: Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: Message from Bruce Momjian <maillist@candle.pha.pa.us> of "Tue,
12 Oct 1999 13:16:35 EDT." <199910121716.NAA29586@candle.pha.pa.us>
References: <199910121716.NAA29586@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 12 Oct 1999 21:49:55 +0100
From: "Oliver Elphick" <olly@lfix.co.uk>

Bruce Momjian wrote:

Here is my proposal for an outline for a PostgreSQL book. Many of us
have been asked by publishers about writing a book. Here is what I
think would be a good outline for the book.

I am interested in whether this is a good outline for a PostgreSQL book,
how our existing documentation matches this outline, where our existing
documentation can be managed into a published book, etc.

Any comments would be welcome.

PostgreSQL Book Proposal

Bruce Momjian

1.
Introduction
2.
Installation

...

3.
Introduction to SQL

...

It looks good; I have a comment on the order of chapters, however.

I suggest that Installlation goes in an Appendix. More and more, people
will be coming to machines that already have software installed, or have
them installed as packages (.rpm or .deb).

Installation is the administrator's job, and not of interest to `normal'
users, so it should not be placed in the book as if every user had to do
it.

From bouncefilter Tue Oct 12 16:54:36 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 QAA54137
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 16:54:09 -0400 (EDT) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max03-038.enterprise.net
[194.72.196.38])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id VAA21749;
Tue, 12 Oct 1999 21:54:06 +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/GNU) with ESMTP id VAA04468;
Tue, 12 Oct 1999 21:53:56 +0100
Message-Id: <199910122053.VAA04468@linda.lfix.co.uk>
X-Mailer: exmh version 2.0.2 2/24/98 (debian)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Jan Wieck <wieck@debis.com>, scrappy@hub.org, vev@michvhf.com,
lockhart@alumni.caltech.edu, lamar.owen@wgcr.org,
pgsql-hackers@postgreSQL.org, jwieck@debis.com
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might
In-Reply-To: Message from Bruce Momjian <maillist@candle.pha.pa.us> of "Tue,
12 Oct 1999 15:37:39 EDT." <199910121937.PAA05618@candle.pha.pa.us>
References: <199910121937.PAA05618@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 12 Oct 1999 21:53:56 +0100
From: "Oliver Elphick" <olly@lfix.co.uk>

Bruce Momjian wrote:

Marc, let's not get Jan upset. :-)

Bruce, to upset me Marc needs alot of more efford!

And why not? If you UPDATE you'll see that we can get rid of
most of the entire body. Remember - a picture says more than
a thousand words :-)

Wow, that is cool. No need for text at bottom, except to list names and
e-mail addresses.

Don't forget the people who use Lynx and other such browsers.

In Lynx the JavaScript stuff is not visible at all, so there ought to be
normal text for those who cannot display images.

From bouncefilter Tue Oct 12 16:56:40 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA54821;
Tue, 12 Oct 1999 16:56:24 -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 QAA09210;
Tue, 12 Oct 1999 16:56:04 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910122056.QAA09210@candle.pha.pa.us>
Subject: Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <199910122049.VAA04297@linda.lfix.co.uk> from Oliver Elphick at
"Oct 12, 1999 09:49:55 pm"
To: Oliver Elphick <olly@lfix.co.uk>
Date: Tue, 12 Oct 1999 16:56:04 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM939761764-8469-0_
Content-Transfer-Encoding: 7bit

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

It looks good; I have a comment on the order of chapters, however.

I suggest that Installlation goes in an Appendix. More and more, people
will be coming to machines that already have software installed, or have
them installed as packages (.rpm or .deb).

Installation is the administrator's job, and not of interest to `normal'
users, so it should not be placed in the book as if every user had to do
it.

Done. Certainly better to get that at the end. That chapter is going
to be a mess to look at.

New version attached. No PDF version this time. Do people like PDF?

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

The attached document is in both web page and text formats.
View the one which looks best.

--ELM939761764-8469-0_
Content-Type: text/html
Content-Disposition: inline; filename="/tmp/book.html"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<HTML>
<HEAD>
<TITLE>PostgreSQL Book Proposal</TITLE>
<META NAME="description" CONTENT="PostgreSQL Book Proposal">
<META NAME="keywords" CONTENT="9162">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<LINK REL="STYLESHEET" HREF="9162.css">
</HEAD>
<BODY >

<H1 ALIGN="CENTER">PostgreSQL Book Proposal</H1>
Bruce Momjian

<DL COMPACT>
<DT>1.
<DD>Introduction

<DL COMPACT>
<DT>(a)
<DD>History of POSTGRESQL
<DT>(b)
<DD>Open source software
<DT>(c)
<DD>When to use a database
</DL><DT>2.
<DD>Issuing database commands

<DL COMPACT>
<DT>(a)
<DD>Starting a database session
<DT>(b)
<DD>Controlling a session
<DT>(c)
<DD>Sending queries
<DT>(d)
<DD>Getting help
</DL><DT>3.
<DD>Introduction to SQL

<DL COMPACT>
<DT>(a)
<DD>Creating tables
<DT>(b)
<DD>Adding data with INSERT
<DT>(c)
<DD>Viewing data with SELECT
<DT>(d)
<DD>Removing data with DELETE
<DT>(e)
<DD>Modifying data with UPDATE
<DT>(f)
<DD>Restricting with WHERE
<DT>(g)
<DD>Sorting data with ORDER BY
<DT>(h)
<DD>Using NULL values
</DL><DT>4.
<DD>Advanced SQL Commands

<DL COMPACT>
<DT>(a)
<DD>Inserting data from a SELECT
<DT>(b)
<DD>Aggregates: COUNT, SUM, ...
<DT>(c)
<DD>GROUP BY with aggregates
<DT>(d)
<DD>HAVING with aggregates
<DT>(e)
<DD>Joining tables
<DT>(f)
<DD>Using table aliases
<DT>(g)
<DD>UNION clause
<DT>(h)
<DD>Subqueries
<DT>(i)
<DD>Transactions
<DT>(j)
<DD>Cursors
<DT>(k)
<DD>Indexing
<DT>(l)
<DD>Column defaults
<DT>(m)
<DD>Primary/foreign keys
<DT>(n)
<DD>AND/OR usage
<DT>(o)
<DD>LIKE clause usage
<DT>(p)
<DD>Temporary tables
<DT>(q)
<DD>Importing data
</DL><DT>5.
<DD>POSTGRESQL'S Unique Features

<DL COMPACT>
<DT>(a)
<DD>Object ID'S (OID'S)
<DT>(b)
<DD>Multi-Version Concurrency Control
<DT>(c)
<DD>Locking and deadlocks
<DT>(d)
<DD>Vacuum
<DT>(e)
<DD>Views
<DT>(f)
<DD>Rules
<DT>(g)
<DD>Sequences
<DT>(h)
<DD>Triggers
<DT>(i)
<DD>Large objects(BLOBS)
<DT>(j)
<DD>Adding user-defined functions
<DT>(k)
<DD>Adding user-defined operators
<DT>(l)
<DD>Adding user-defined types
<DT>(m)
<DD>Exotic pre-installed types
<DT>(n)
<DD>Arrays
<DT>(o)
<DD>Inheritance
</DL><DT>6.
<DD>Interfacing to the POSTGRESQL Database

<DL COMPACT>
<DT>(a)
<DD>Creating users and databases
<DT>(b)
<DD>Backup and restore
<DT>(c)
<DD>Performance
<DT>(d)
<DD>Troubleshooting
<DT>(e)
<DD>Customization
<DT>(f)
<DD>Setting access permissions
<DT>(g)
<DD>International character encodings
</DL><DT>8.
<DD>Additional Resources

<DL COMPACT>
<DT>(a)
<DD>Getting POSTGRESQL
<DT>(b)
<DD>Compiling
<DT>(c)
<DD>Initialization
<DT>(d)
<DD>Starting the server
<DT>(e)
<DD>Creating a database
</DL><DT>10.
<DD>Annotated Bibliography
</DL>

</BODY>
</HTML>

--ELM939761764-8469-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/tmp/book.txt"
Content-Transfer-Encoding: 7bit

PostgreSQL Book Proposal

Bruce Momjian

1.
Introduction
(a)
History of POSTGRESQL
(b)
Open source software
(c)
When to use a database
2.
Issuing database commands
(a)
Starting a database session
(b)
Controlling a session
(c)
Sending queries
(d)
Getting help
3.
Introduction to SQL
(a)
Creating tables
(b)
Adding data with INSERT
(c)
Viewing data with SELECT
(d)
Removing data with DELETE
(e)
Modifying data with UPDATE
(f)
Restricting with WHERE
(g)
Sorting data with ORDER BY
(h)
Using NULL values
4.
Advanced SQL Commands
(a)
Inserting data from a SELECT
(b)
Aggregates: COUNT, SUM, ...
(c)
GROUP BY with aggregates
(d)
HAVING with aggregates
(e)
Joining tables
(f)
Using table aliases
(g)
UNION clause
(h)
Subqueries
(i)
Transactions
(j)
Cursors
(k)
Indexing
(l)
Column defaults
(m)
Primary/foreign keys
(n)
AND/OR usage
(o)
LIKE clause usage
(p)
Temporary tables
(q)
Importing data
5.
POSTGRESQL'S Unique Features
(a)
Object ID'S (OID'S)
(b)
Multi-Version Concurrency Control
(c)
Locking and deadlocks
(d)
Vacuum
(e)
Views
(f)
Rules
(g)
Sequences
(h)
Triggers
(i)
Large objects(BLOBS)
(j)
Adding user-defined functions
(k)
Adding user-defined operators
(l)
Adding user-defined types
(m)
Exotic pre-installed types
(n)
Arrays
(o)
Inheritance
6.
Interfacing to the POSTGRESQL Database
(a)
C Language API
(b)
Embedded C
(c)
C++
(d)
JAVA
(e)
ODBC
(f)
PERL
(g)
TCL/TK
(h)
PYTHON
(i)
Web access (PHP)
(j)
Server-side programming (PLPGSQL and SPI)
7.
POSTGRESQL Administration
(a)
Creating users and databases
(b)
Backup and restore
(c)
Performance
(d)
Troubleshooting
(e)
Customization
(f)
Setting access permissions
(g)
International character encodings
8.
Additional Resources
(a)
Frequently Asked Questions (FAQ'S)
(b)
Mailing list support
(c)
Supplied documentation
(d)
Commercial support
(e)
Modifying the source code
9.
Appendix: Installation
(a)
Getting POSTGRESQL
(b)
Compiling
(c)
Initialization
(d)
Starting the server
(e)
Creating a database
10.
Annotated Bibliography

--ELM939761764-8469-0_

--ELM939761764-8469-0_--

From bouncefilter Tue Oct 12 16:56:37 1999
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net
[194.217.242.41]) by hub.org (8.9.3/8.9.3) with ESMTP id QAA54798
for <hackers@postgresql.org>; Tue, 12 Oct 1999 16:56:16 -0400 (EDT)
(envelope-from peter@retep.org.uk)
Received: from maidast.demon.co.uk ([158.152.22.37] helo=maidast.retep.org.uk)
by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 11b8xz-000PA3-0C; Tue, 12 Oct 1999 20:56:15 +0000
Received: from localhost (peter@localhost [127.0.0.1])
by maidast.retep.org.uk (8.9.3/8.9.3) with ESMTP id VAA01342;
Tue, 12 Oct 1999 21:56:29 +0100
Date: Tue, 12 Oct 1999 21:56:29 +0100 (GMT)
From: Peter Mount <peter@retep.org.uk>
To: PostgreSQL Hackers <hackers@postgreSQL.org>,
The Hermit Hacker <scrappy@hub.org>
Subject: JDBC Driver
Message-ID: <Pine.LNX.4.10.9910122155180.32422-100000@maidast.retep.org.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

The copy on cvs looks ok, although should I update it to say 6.5.3, or as
6.5.3 is simply to include pgaccess, leave it alone?

I'd go for the latter.

Peter

--
Peter T Mount peter@retep.org.uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf

From bouncefilter Tue Oct 12 17:13:37 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA58664
for <hackers@postgreSQL.org>; Tue, 12 Oct 1999 17:13:30 -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 RAA10117;
Tue, 12 Oct 1999 17:11:55 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910122111.RAA10117@candle.pha.pa.us>
Subject: Re: [HACKERS] JDBC Driver
In-Reply-To: <Pine.LNX.4.10.9910122155180.32422-100000@maidast.retep.org.uk>
from Peter Mount at "Oct 12, 1999 09:56:29 pm"
To: Peter Mount <peter@retep.org.uk>
Date: Tue, 12 Oct 1999 17:11:53 -0400 (EDT)
CC: PostgreSQL Hackers <hackers@postgreSQL.org>,
The Hermit Hacker <scrappy@hub.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

The copy on cvs looks ok, although should I update it to say 6.5.3, or as
6.5.3 is simply to include pgaccess, leave it alone?

I'd go for the latter.

I can update files as part of the release, but I don't see anywhere in
the jdbc directory that says 6.5.x.

-- 
  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 12 17:18:37 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id RAA59797
for <docs@postgreSQL.org>; Tue, 12 Oct 1999 17:18:11 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 5819 invoked by uid 1001); 12 Oct 1999 21:18:11 -0000
Message-ID: <XFMail.991012171811.vev@michvhf.com>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199910122056.QAA09210@candle.pha.pa.us>
Date: Tue, 12 Oct 1999 17:18:11 -0400 (EDT)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Outline for PostgreSQL book
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>,
Oliver Elphick <olly@lfix.co.uk>

On 12-Oct-99 Bruce Momjian wrote:

It looks good; I have a comment on the order of chapters, however.

I suggest that Installlation goes in an Appendix. More and more, people
will be coming to machines that already have software installed, or have
them installed as packages (.rpm or .deb).

Installation is the administrator's job, and not of interest to `normal'
users, so it should not be placed in the book as if every user had to do
it.

Done. Certainly better to get that at the end. That chapter is going
to be a mess to look at.

New version attached. No PDF version this time. Do people like PDF?

Not at this early stage. Wait till it's further along.

From bouncefilter Wed Oct 13 13:59:53 1999
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net
[194.217.242.39]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA69839;
Wed, 13 Oct 1999 13:59:05 -0400 (EDT)
(envelope-from bruce@cenderis.demon.co.uk)
Received: from cenderis.demon.co.uk ([193.237.0.193])
by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1)
id 11bSg2-000O74-0B; Wed, 13 Oct 1999 17:59:03 +0000
Received: by cenderis.demon.co.uk (Postfix, from userid 1000)
id 83B7D2A567; Wed, 13 Oct 1999 18:58:34 +0100 (BST)
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: PostgreSQL-documentation <docs@postgresql.org>
Subject: Re: [DOCS] Outline for PostgreSQL book
References: <199910121716.NAA29586@candle.pha.pa.us>
From: Bruce Stephens <bruce@cenderis.demon.co.uk>
Date: 12 Oct 1999 23:08:05 +0100
In-Reply-To: Bruce Momjian's message of "Tue,
12 Oct 1999 13:16:35 -0400 (EDT)"
Message-ID: <87u2nw8c6x.fsf@cenderis.demon.co.uk>
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) XEmacs/21.2 (Shinjuku)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 50

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

PostgreSQL Book Proposal

Bruce Momjian

[...]

4.
Advanced SQL Commands

[...]

6.
Interfacing to the POSTGRESQL Database
(a)
C Language API
(b)
Embedded C
(c)
C++
(d)
JAVA
(e)
ODBC
(f)
PERL
(g)
TCL/TK
(h)
PYTHON
(i)
Web access (PHP)
(j)
Server-side programming (PLPGSQL and SPI)

Isn't (j) logically part of chapter 4? (Or 5, if it's PostgreSQL
specific.) Or am I completely confused? (Where can I read about
PLPGSQL and/or SPI, other than in the forthcoming book?)

If it came to a choice between having very short sections in chapter
6, and having two or three of them covered in more depth, I'd go for
the latter.

(Of course, you'll inevitably choose two or three which don't match
what many readers will want (whichever two or three you choose), but
even so, I think I'd get more out of a reasonably thorough coverage of
a couple of languages that I won't use than superficial coverage of
all of them which doesn't really reveal anything useful.)

From bouncefilter Tue Oct 12 19:14:38 1999
Received: from epg-gw1.lewis.army.mil (epg-gw1.lewis.army.mil [150.192.56.10])
by hub.org (8.9.3/8.9.3) with SMTP id TAA79405;
Tue, 12 Oct 1999 19:14:01 -0400 (EDT)
(envelope-from craig@epg-gw1.lewis.army.mil)
Received: from delenn.eng by epg-gw1.lewis.army.mil with SMTP
(1.37.109.4/15.6) id AA09139; Tue, 12 Oct 99 16:13:48 -0700
Received: by delenn.eng
(8.7.6/16.2) id TAA19366; Tue, 12 Oct 1999 19:13:48 -0400 (EDT)
Message-Id: <XFMail.991012161348.orsingerc@epg-gw1.lewis.army.mil>
X-Mailer: XFMail 1.3 [p0] on HP-UX (unknown)
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Mime-Version: 1.0
In-Reply-To: <199910111704.NAA05891@candle.pha.pa.us>
Date: Tue, 12 Oct 1999 16:13:48 -0700 (PDT)
Reply-To: Craig Orsinger <orsingerc@epg-gw1.lewis.army.mil>
Organization: EPG Ft. Lewis Field Office
Sender: craig@epg-gw1.lewis.army.mil
From: Craig Orsinger <orsingerc@epg-gw1.lewis.army.mil>
To: pgsql-interfaces@postgreSQL.org
Subject: Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
Cc: pgsql-hackers@postgreSQL.org

On 11-Oct-99 Bruce Momjian wrote:

You could make the actual command pg_createuser, and make a symlink of
createuser, but allow the symlink creation to fail. Best of both
worlds, I think. I vote for underscore. That's what I normally use.
Dashes look too much like command arguments.

Agreed. I don't like underscores, but hyphens can be worse.
I think the best idea is to use a name that identifies the script as
being a part of PostgreSQL, and can somehow clearly define what the
script is designed to do, and then whatever you choose, _stick_with_it_!
System administrators and programmers can make symbolic links if they
need them.

----------------------------------
Date: 12-Oct-99 Time: 16:10:10

Craig Orsinger (email: <orsingerc@epg-gw1.lewis.army.mil>)
Logicon RDA
Bldg. 8B28 "Just another megalomaniac with ideas above his
6th & F Streets station. The Universe is full of them."
Ft. Lewis, WA 98433 - The Doctor
----------------------------------

From bouncefilter Tue Oct 12 19:23:38 1999
Received: from smtp2.a2000.nl (spartacus.a2000.nl [62.108.1.20])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA80759;
Tue, 12 Oct 1999 19:22:43 -0400 (EDT)
(envelope-from z.nijmeyers@cable.a2000.nl)
Received: from node10065.a2000.nl ([24.132.0.101] helo=node10066)
by smtp2.a2000.nl with smtp (Exim 2.02 #4)
id 11bBFS-0005aY-00; Wed, 13 Oct 1999 01:22:27 +0200
Message-Id: <4.1.19991013011938.00a80e50@mail.a2000.nl>
X-Sender: znijmeye@mail.a2000.nl
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Wed, 13 Oct 1999 01:27:29 +0200
To: Bruce Momjian <maillist@candle.pha.pa.us>,
Oliver Elphick <olly@lfix.co.uk>
From: gravity <z.nijmeyers@cable.a2000.nl>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
PostgreSQL-documentation <docs@postgresql.org>
In-Reply-To: <199910122056.QAA09210@candle.pha.pa.us>
References: <199910122049.VAA04297@linda.lfix.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 16:56 12-10-99 -0400, Bruce Momjian wrote:

Installation is the administrator's job, and not of interest to `normal'
users, so it should not be placed in the book as if every user had to do
it.

Done. Certainly better to get that at the end. That chapter is going
to be a mess to look at.

I agree on this particular item BUT...

wouldn't it be nice if the book would be a 'hard' book?
there already are lots of database tutorials, introductions to sql etc.

focus on db developers, go into (maybe not that deep) how and why postgres
is/was developed the way it is/was.

'hard' books are a 'good thing' (tm) and it would be too bad if this would
become another entry-level booklet.

OTOH an entry-level book is probably required to get as big a user-base as
possible.

From bouncefilter Tue Oct 12 19:36:38 1999
Received: from smtp2.a2000.nl (spartacus.a2000.nl [62.108.1.20])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA82628;
Tue, 12 Oct 1999 19:36:27 -0400 (EDT) (envelope-from gravity@dds.nl)
Received: from node10065.a2000.nl ([24.132.0.101] helo=node10066)
by smtp2.a2000.nl with smtp (Exim 2.02 #4)
id 11bBSv-0005yT-00; Wed, 13 Oct 1999 01:36:22 +0200
Message-Id: <4.1.19991013014049.00a81350@mail.a2000.nl>
X-Sender: gravity@pop.dds.nl
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Wed, 13 Oct 1999 01:41:27 +0200
To: Bruce Momjian <maillist@candle.pha.pa.us>,
Oliver Elphick <olly@lfix.co.uk>
From: gravity <gravity@dds.nl>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
PostgreSQL-documentation <docs@postgresql.org>
In-Reply-To: <199910122056.QAA09210@candle.pha.pa.us>
References: <199910122049.VAA04297@linda.lfix.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 16:56 12-10-99 -0400, Bruce Momjian wrote:

Installation is the administrator's job, and not of interest to `normal'
users, so it should not be placed in the book as if every user had to do
it.

Done. Certainly better to get that at the end. That chapter is going
to be a mess to look at.

I agree on this particular item BUT...

wouldn't it be nice if the book would be a 'hard' book?
there already are lots of database tutorials, introductions to sql etc.

focus on db developers, go into (maybe not that deep) how and why postgres
is/was developed the way it is/was.

'hard' books are a 'good thing' (tm) and it would be too bad if this would
become another entry-level booklet.

OTOH an entry-level book is probably required to get as big a user-base as
possible.

From bouncefilter Tue Oct 12 19:56:39 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id TAA86022
for <docs@postgreSQL.org>; Tue, 12 Oct 1999 19:56:07 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 6192 invoked by uid 1001); 12 Oct 1999 23:56:12 -0000
Message-ID: <XFMail.991012195611.vev@michvhf.com>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199910122056.QAA09210@candle.pha.pa.us>
Date: Tue, 12 Oct 1999 19:56:11 -0400 (EDT)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: RE: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>,
Oliver Elphick <olly@lfix.co.uk>

On 12-Oct-99 Bruce Momjian wrote:

It looks good; I have a comment on the order of chapters, however.

I suggest that Installlation goes in an Appendix. More and more, people
will be coming to machines that already have software installed, or have
them installed as packages (.rpm or .deb).

Installation is the administrator's job, and not of interest to `normal'
users, so it should not be placed in the book as if every user had to do
it.

Done. Certainly better to get that at the end. That chapter is going
to be a mess to look at.

It doesn't have to be a mess.

From bouncefilter Tue Oct 12 20:31:44 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 UAA91404;
Tue, 12 Oct 1999 20:31:15 -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 UAA14644;
Tue, 12 Oct 1999 20:02:35 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910130002.UAA14644@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <4.1.19991013011938.00a80e50@mail.a2000.nl> from gravity at "Oct
13, 1999 01:27:29 am"
To: gravity <z.nijmeyers@cable.a2000.nl>
Date: Tue, 12 Oct 1999 20:02:35 -0400 (EDT)
CC: Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I agree on this particular item BUT...

wouldn't it be nice if the book would be a 'hard' book?
there already are lots of database tutorials, introductions to sql etc.

focus on db developers, go into (maybe not that deep) how and why postgres
is/was developed the way it is/was.

'hard' books are a 'good thing' (tm) and it would be too bad if this would
become another entry-level booklet.

OTOH an entry-level book is probably required to get as big a user-base as
possible.

Publishers have already talked to me about multiple books. I think we
need to start with an newbie book, with the chapters clearly arranged so
experienced people can skip newbie chapters.

-- 
  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 12 20:31:46 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 UAA91409;
Tue, 12 Oct 1999 20:31:22 -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 UAA14654;
Tue, 12 Oct 1999 20:03:47 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910130003.UAA14654@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <XFMail.991012195611.vev@michvhf.com> from Vince Vielhaber at
"Oct
12, 1999 07:56:11 pm"
To: Vince Vielhaber <vev@michvhf.com>
Date: Tue, 12 Oct 1999 20:03:47 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>,
Oliver Elphick <olly@lfix.co.uk>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On 12-Oct-99 Bruce Momjian wrote:

It looks good; I have a comment on the order of chapters, however.

I suggest that Installlation goes in an Appendix. More and more, people
will be coming to machines that already have software installed, or have
them installed as packages (.rpm or .deb).

Installation is the administrator's job, and not of interest to `normal'
users, so it should not be placed in the book as if every user had to do
it.

Done. Certainly better to get that at the end. That chapter is going
to be a mess to look at.

It doesn't have to be a mess.

Frankly, if I can get away with having whole sections that point to URL
files, so much the better. If I can just point them to the INSTALL
file, and be done with it, great.

-- 
  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 12 20:27:39 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 UAA90749
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 20:26:57 -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 JAA03507; Wed, 13 Oct 1999 09:25:25 +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: Wed, 13 Oct 1999 09:29:16 +0900
Message-ID: <001201bf1511$fba22c80$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <16557.939740257@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

Currently only the first segment is opened when mdopen() etc is
called. Would you change to check all segments at first open ?

No, I don't see a need to change that logic. I was thinking that
since mdnblocks adds another link to the chain whenever it sees that
the current segment is exactly RELSEG_SIZE, it could just assume that
if the next-segment link is not NULL then this segment must be of
size RELSEG_SIZE and it doesn't need to check that again. It'd only
need to do an actual check on the last chain element (plus any elements
it adds during the current call, of course). We'd rely on the
higher-level interlock to close and reopen the virtual file when a
truncate has happened.

You are right.
The last segment is always lseeked.
And does this mean that the first mdnblocks() opens all segments and
checks them ?

If there is a relation which has multi-segment of size 0,which would
be the last segment ?

Only the last segment can have any size other than RELSEG_SIZE, I think.

This may be another issue.
I have been suspicious about current implementation of md.c.
It relies so much on information about existent phisical files.

How do you think about the following ?

1. Partial blocks(As you know,I have changed the handling of this
kind of blocks recently).
2. If a backend was killed or crashed in the middle of execution of
mdunlink()/mdtruncate(),half of segments wouldn't be unlink/
truncated.
3. In cygwin port,mdunlink()/mdtruncate() may leave segments of 0
length.
4. We couldn't mdcreate() existent files and coudn't mdopen()/md
unlink() non-existent files. So there are some cases that we
could neither CREATE TABLE nor DROP TABLE.

I have no solution but seems the count of valid segments and blocks
should be held in other places.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Oct 12 20:56:39 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id UAA96135
for <docs@postgreSQL.org>; Tue, 12 Oct 1999 20:55:55 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 6379 invoked by uid 1001); 13 Oct 1999 00:55:59 -0000
Message-ID: <XFMail.991012205559.vev@michvhf.com>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199910130003.UAA14654@candle.pha.pa.us>
Date: Tue, 12 Oct 1999 20:55:59 -0400 (EDT)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>,
Oliver Elphick <olly@lfix.co.uk>

On 13-Oct-99 Bruce Momjian wrote:

On 12-Oct-99 Bruce Momjian wrote:

It looks good; I have a comment on the order of chapters, however.

I suggest that Installlation goes in an Appendix. More and more, people
will be coming to machines that already have software installed, or have
them installed as packages (.rpm or .deb).

Installation is the administrator's job, and not of interest to `normal'
users, so it should not be placed in the book as if every user had to do
it.

Done. Certainly better to get that at the end. That chapter is going
to be a mess to look at.

It doesn't have to be a mess.

Frankly, if I can get away with having whole sections that point to URL
files, so much the better. If I can just point them to the INSTALL
file, and be done with it, great.

The installation can be quick and painless. I'll explain more tomorrow.

From bouncefilter Tue Oct 12 22:20: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 WAA09778;
Tue, 12 Oct 1999 22:20:21 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for docs@postgreSQL.org
id m11bDwZ-0003kLC; Wed, 13 Oct 99 04:15 MET DST
Message-Id: <m11bDwZ-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Wed, 13 Oct 1999 04:15:07 +0200 (MET DST)
Cc: z.nijmeyers@cable.a2000.nl, olly@lfix.co.uk, pgsql-hackers@postgreSQL.org,
docs@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199910130002.UAA14644@candle.pha.pa.us> from "Bruce Momjian" at
Oct 12, 99 08:02:35 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

OTOH an entry-level book is probably required to get as big a user-base as
possible.

Publishers have already talked to me about multiple books. I think we
need to start with an newbie book, with the chapters clearly arranged so
experienced people can skip newbie chapters.

I don't think it really matters that much if the first book
about PostgreSQL is more for a newbie than a professional or
vice versa. What count's is that it is up to date and
correct. If I go to a book store and find only one book on a
topic, it's usually not the one "I" was looking for. But
what would make other authors write another book on the same
topic - most likely the authors who write details I haven't
known before? It's the success of the former one.

Think about it a little.

The first book has to be successful. Therefore it has to
address most of the interested people. Those who know how to
get the information they need out of manpages, RFC's and W3C
recommendations aren't the ppl who to address in this case.
So let it please be a newbie book, and the hard ones will
follow.

Another problem is that during the last release cycles, it
wasn't that easy to follow all the changes in the
capabilities of PostgreSQL. Not even for me, and I'm not
counting myself to the outermost circle. Now what chance do
you give a book that's written based on v6.5 if we are about
to release v7.1 some months ahead? And more important, if it
happens this way, does our "aggressive" development invite
other authors to take a chance on the same topic? I don't
think so.

If we really want professional publishing about PostgreSQL
(we want - no?), the core team has to co-operate with the
authors of those books in a way, that they can write their
book based on the upcoming release and sell it with a CD
where that release is included. At the time it is published,
there should only be bugfixes available on the net - not
already two newer releases.

Jan

From bouncefilter Tue Oct 12 22:41:40 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 WAA12807;
Tue, 12 Oct 1999 22:41:04 -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 WAA18587;
Tue, 12 Oct 1999 22:36:54 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910130236.WAA18587@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <m11bDwZ-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 13, 1999 04:15:07 am"
To: Jan Wieck <wieck@debis.com>
Date: Tue, 12 Oct 1999 22:36:54 -0400 (EDT)
CC: z.nijmeyers@cable.a2000.nl, olly@lfix.co.uk, pgsql-hackers@postgreSQL.org,
docs@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

OTOH an entry-level book is probably required to get as big a user-base as
possible.

Publishers have already talked to me about multiple books. I think we
need to start with an newbie book, with the chapters clearly arranged so
experienced people can skip newbie chapters.

I don't think it really matters that much if the first book
about PostgreSQL is more for a newbie than a professional or
vice versa. What count's is that it is up to date and
correct. If I go to a book store and find only one book on a
topic, it's usually not the one "I" was looking for. But
what would make other authors write another book on the same
topic - most likely the authors who write details I haven't
known before? It's the success of the former one.

Think about it a little.

The first book has to be successful. Therefore it has to
address most of the interested people. Those who know how to
get the information they need out of manpages, RFC's and W3C
recommendations aren't the ppl who to address in this case.
So let it please be a newbie book, and the hard ones will
follow.

That was my thought too.

Another problem is that during the last release cycles, it
wasn't that easy to follow all the changes in the
capabilities of PostgreSQL. Not even for me, and I'm not
counting myself to the outermost circle. Now what chance do
you give a book that's written based on v6.5 if we are about
to release v7.1 some months ahead? And more important, if it
happens this way, does our "aggressive" development invite
other authors to take a chance on the same topic? I don't
think so.

If we really want professional publishing about PostgreSQL
(we want - no?), the core team has to co-operate with the
authors of those books in a way, that they can write their
book based on the upcoming release and sell it with a CD
where that release is included. At the time it is published,
there should only be bugfixes available on the net - not
already two newer releases.

I have a list of interested publishers, and am going to post it so
people can get involved and start writing.

-- 
  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 12 22:47:40 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA13472
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 22:46:41 -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 WAA19232
for pgsql-hackers@postgreSQL.org; Tue, 12 Oct 1999 22:46:28 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910130246.WAA19232@candle.pha.pa.us>
Subject: Updated book outline
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Tue, 12 Oct 1999 22:46:28 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM939782788-18549-0_
Content-Transfer-Encoding: 7bit

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

OK, new outline, updated to show subsection detail, with suggested
changes made.

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

The attached document is in both web page and text formats.
View the one which looks best.

--ELM939782788-18549-0_
Content-Type: text/html
Content-Disposition: inline; filename="/tmp/book.html"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<HTML>
<HEAD>
<TITLE>PostgreSQL Book Proposal</TITLE>
<META NAME="description" CONTENT="PostgreSQL Book Proposal">
<META NAME="keywords" CONTENT="19195">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<LINK REL="STYLESHEET" HREF="19195.css">
</HEAD>
<BODY >

<H1 ALIGN="CENTER">PostgreSQL Book Proposal</H1>
Bruce Momjian

Preface

<DL COMPACT>
<DT>1.
<DD>Introduction

<DL COMPACT>
<DT>(a)
<DD>History of POSTGRESQL

<DL COMPACT>
<DT>i.
<DD>UNIVERSITY OF CALIFORNIA AT BERKELEY
<DT>ii.
<DD>MICHAEL STONEBRAKER
<DT>iii.
<DD>JOLLY CHEN and ANDREW YU
<DT>iv.
<DD>POSTGRESQL GLOBAL DEVELOPMENT TEAM
</DL><DT>(b)
<DD>Open source software

<DL COMPACT>
<DT>i.
<DD>development methods
<DT>ii.
<DD>peer review
<DT>iii.
<DD>release process
<DT>iv.
<DD>problem reporting
<DT>v.
<DD>support
</DL><DT>(c)
<DD>When to use a database

<DL COMPACT>
<DT>i.
<DD>large volume
<DT>ii.
<DD>rapid retrieval
<DT>iii.
<DD>frequent modification
<DT>iv.
<DD>reporting
</DL></DL><DT>2.
<DD>Issuing database commands

<DL COMPACT>
<DT>(a)
<DD>Starting a database session

<DL COMPACT>
<DT>i.
<DD>choosing an access method
<DT>ii.
<DD>choosing a database
<DT>iii.
<DD>starting a session
</DL><DT>(b)
<DD>Controlling a session

<DL COMPACT>
<DT>i.
<DD>typing in the query buffer
<DT>ii.
<DD>displaying the query buffer
<DT>iii.
<DD>editing the query buffer
<DT>iv.
<DD>erasing the query buffer
</DL><DT>(c)
<DD>Sendinging queries
<DT>(d)
<DD>Getting help
<DT>(e)
<DD>Requesting server information
</DL><DT>3.
<DD>Introduction to SQL

<DL COMPACT>
<DT>(a)
<DD>Relational Databases

<DL COMPACT>
<DT>i.
<DD>tables, rows, and columns
<DT>ii.
<DD>column types
<DT>iii.
<DD>column selection
<DT>iv.
<DD>row restriction
</DL><DT>(b)
<DD>Creating tables

<DL COMPACT>
<DT>i.
<DD>naming columns
<DT>ii.
<DD>column types
</DL><DT>(c)
<DD>Adding data with INSERT

<DL COMPACT>
<DT>i.
<DD>target columns
<DT>ii.
<DD>column types
<DT>iii.
<DD>missing values
</DL><DT>(d)
<DD>Viewing data with SELECT

<DL COMPACT>
<DT>i.
<DD>target columns
<DT>ii.
<DD>FROM clause
</DL><DT>(e)
<DD>Removing data with DELETE
<DT>(f)
<DD>Modifying data with UPDATE
<DT>(g)
<DD>Restricting with WHERE
<DT>(h)
<DD>Sorting data with ORDER BY
<DT>(i)
<DD>Using NULL values
</DL><DT>4.
<DD>Advanced SQL Commands

<DL COMPACT>
<DT>(a)
<DD>Inserting data using SELECT
<DT>(b)
<DD>Aggregates: COUNT, SUM, ...
<DT>(c)
<DD>GROUP BY with aggregates
<DT>(d)
<DD>HAVING with aggregates
<DT>(e)
<DD>Joining tables
<DT>(f)
<DD>Using table aliases
<DT>(g)
<DD>UNION clause
<DT>(h)
<DD>UPDATE with FROM
<DT>(i)
<DD>Subqueries

<DL COMPACT>
<DT>i.
<DD>returning a single row
<DT>ii.
<DD>returning multiple rows
<DT>iii.
<DD>correlated Subqueries
</DL><DT>(j)
<DD>Transactions

<DL COMPACT>
<DT>i.
<DD>BEGIN...END
<DT>ii.
<DD>ABORT transaction
</DL><DT>(k)
<DD>Cursors

<DL COMPACT>
<DT>i.
<DD>DECLARE
<DT>ii.
<DD>FETCH
<DT>iii.
<DD>CLOSE
</DL><DT>(l)
<DD>Indexing

<DL COMPACT>
<DT>i.
<DD>usage
<DT>ii.
<DD>types
<DT>iii.
<DD>definition
<DT>iv.
<DD>functional indexes
</DL><DT>(m)
<DD>Column defaults
<DT>(n)
<DD>Referential integrity

<DL COMPACT>
<DT>i.
<DD>primary keys
<DT>ii.
<DD>foreign keys
</DL><DT>(o)
<DD>AND/OR usage
<DT>(p)
<DD>Pattern matching

<DL COMPACT>
<DT>i.
<DD>LIKE clause
<DT>ii.
<DD>regular expressions
</DL><DT>(q)
<DD>Temporary tables
<DT>(r)
<DD>Importing data

<DL COMPACT>
<DT>i.
<DD>COPY
<DT>ii.
<DD>DELIMITERS
<DT>iii.
<DD>BINARY
<DT>iv.
<DD>frontend COPY
</DL></DL><DT>5.
<DD>POSTGRESQL'S Unique Features

<DL COMPACT>
<DT>(a)
<DD>Object ID'S (OID'S)

<DL COMPACT>
<DT>i.
<DD>unique row assignment
<DT>ii.
<DD>join usage
</DL><DT>(b)
<DD>Multi-Version Concurrency Control

<DL COMPACT>
<DT>i.
<DD>write locks
<DT>ii.
<DD>read locks
<DT>iii.
<DD>concurrency
<DT>iv.
<DD>solutions
</DL><DT>(c)
<DD>Locking and deadlocks

<DL COMPACT>
<DT>i.
<DD>need for locking
<DT>ii.
<DD>deadlocks
</DL><DT>(d)
<DD>Vacuum

<DL COMPACT>
<DT>i.
<DD>scheduling
<DT>ii.
<DD>ANALYZE
</DL><DT>(e)
<DD>Views

<DL COMPACT>
<DT>i.
<DD>creation
<DT>ii.
<DD>limitations
</DL><DT>(f)
<DD>Rules

<DL COMPACT>
<DT>i.
<DD>creation
<DT>ii.
<DD>limitations
</DL><DT>(g)
<DD>Sequences

<DL COMPACT>
<DT>i.
<DD>purpose
<DT>ii.
<DD>creation
<DT>iii.
<DD>management
</DL><DT>(h)
<DD>Triggers

<DL COMPACT>
<DT>i.
<DD>purpose
<DT>ii.
<DD>creation
</DL><DT>(i)
<DD>Large objects(BLOBS)

<DL COMPACT>
<DT>i.
<DD>applications
<DT>ii.
<DD>creation
<DT>iii.
<DD>management
</DL><DT>(j)
<DD>Adding user-defined functions

<DL COMPACT>
<DT>i.
<DD>purpose
<DT>ii.
<DD>creation
<DT>iii.
<DD>examples
</DL><DT>(k)
<DD>Adding user-defined operators

<DL COMPACT>
<DT>i.
<DD>arithmetic processing
<DT>ii.
<DD>creation
</DL><DT>(l)
<DD>Adding user-defined types

<DL COMPACT>
<DT>i.
<DD>purpose
<DT>ii.
<DD>creation
<DT>iii.
<DD>indexing
</DL><DT>(m)
<DD>Exotic pre-installed types

<DL COMPACT>
<DT>i.
<DD>date/time
<DT>ii.
<DD>geometric
<DT>iii.
<DD>character string
<DT>iv.
<DD>internet
<DT>v.
<DD>internal
</DL><DT>(n)
<DD>Arrays

<DL COMPACT>
<DT>i.
<DD>creation
<DT>ii.
<DD>access
</DL><DT>(o)
<DD>Inheritance

<DL COMPACT>
<DT>i.
<DD>purpose
<DT>ii.
<DD>creation
<DT>iii.
<DD>examples
</DL></DL><DT>6.
<DD>Interfacing to the POSTGRESQL Database

<DL COMPACT>
<DT>(a)
<DD>C Language API (LIBPQ)
<DT>(b)
<DD>Embedded C (ECPG)
<DT>(c)
<DD>C++ (LIBPQ++)
<DT>(d)
<DD>JAVA (JDBC)
<DT>(e)
<DD>ODBC
<DT>(f)
<DD>PERL (PGSQL_PERL5)
<DT>(g)
<DD>TCL/TK (LIBPGTCL)
<DT>(h)
<DD>PYTHON (PYGRESQL)
<DT>(i)
<DD>Web access (PHP)
<DT>(j)
<DD>Server-side programming

<DL COMPACT>
<DT>i.
<DD>PLPGSQL 
<DT>ii.
<DD>SPI
</DL></DL><DT>7.
<DD>POSTGRESQL Administration

<DL COMPACT>
<DT>(a)
<DD>Creating users and databases
<DT>(b)
<DD>Backup and restore
<DT>(c)
<DD>Performance
<DT>(d)
<DD>Troubleshooting
<DT>(e)
<DD>Customization
<DT>(f)
<DD>Access configuration

<DL COMPACT>
<DT>i.
<DD>server access
<DT>ii.
<DD>database access
<DT>iii.
<DD>table access
</DL><DT>(g)
<DD>Internationalization

<DL COMPACT>
<DT>i.
<DD>national character encodings
<DT>ii.
<DD>date formats
</DL></DL><DT>8.
<DD>Additional Resources

<DL COMPACT>
<DT>(a)
<DD>Getting POSTGRESQL

<DL COMPACT>
<DT>i.
<DD>FTP
<DT>ii.
<DD>web
<DT>iii.
<DD>CDROM
</DL><DT>(b)
<DD>Compiling

<DL COMPACT>
<DT>i.
<DD>compiler
<DT>ii.
<DD>RPM
</DL><DT>(c)
<DD>Initialization
<DT>(d)
<DD>Starting the server
<DT>(e)
<DD>Creating a database
</DL><DT>10.
<DD>Annotated Bibliography
</DL>

</BODY>
</HTML>

--ELM939782788-18549-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/tmp/book.txt"
Content-Transfer-Encoding: 7bit

PostgreSQL Book Proposal

Bruce Momjian

Preface

1.
Introduction
(a)
History of POSTGRESQL
i.
UNIVERSITY OF CALIFORNIA AT BERKELEY
ii.
MICHAEL STONEBRAKER
iii.
JOLLY CHEN and ANDREW YU
iv.
POSTGRESQL GLOBAL DEVELOPMENT TEAM
(b)
Open source software
i.
development methods
ii.
peer review
iii.
release process
iv.
problem reporting
v.
support
(c)
When to use a database
i.
large volume
ii.
rapid retrieval
iii.
frequent modification
iv.
reporting
2.
Issuing database commands
(a)
Starting a database session
i.
choosing an access method
ii.
choosing a database
iii.
starting a session
(b)
Controlling a session
i.
typing in the query buffer
ii.
displaying the query buffer
iii.
editing the query buffer
iv.
erasing the query buffer
(c)
Sendinging queries
(d)
Getting help
(e)
Requesting server information
3.
Introduction to SQL
(a)
Relational Databases
i.
tables, rows, and columns
ii.
column types
iii.
column selection
iv.
row restriction
(b)
Creating tables
i.
naming columns
ii.
column types
(c)
Adding data with INSERT
i.
target columns
ii.
column types
iii.
missing values
(d)
Viewing data with SELECT
i.
target columns
ii.
FROM clause
(e)
Removing data with DELETE
(f)
Modifying data with UPDATE
(g)
Restricting with WHERE
(h)
Sorting data with ORDER BY
(i)
Using NULL values
4.
Advanced SQL Commands
(a)
Inserting data using SELECT
(b)
Aggregates: COUNT, SUM, ...
(c)
GROUP BY with aggregates
(d)
HAVING with aggregates
(e)
Joining tables
(f)
Using table aliases
(g)
UNION clause
(h)
UPDATE with FROM
(i)
Subqueries
i.
returning a single row
ii.
returning multiple rows
iii.
correlated Subqueries
(j)
Transactions
i.
BEGIN...END
ii.
ABORT transaction
(k)
Cursors
i.
DECLARE
ii.
FETCH
iii.
CLOSE
(l)
Indexing
i.
usage
ii.
types
iii.
definition
iv.
functional indexes
(m)
Column defaults
(n)
Referential integrity
i.
primary keys
ii.
foreign keys
(o)
AND/OR usage
(p)
Pattern matching
i.
LIKE clause
ii.
regular expressions
(q)
Temporary tables
(r)
Importing data
i.
COPY
ii.
DELIMITERS
iii.
BINARY
iv.
frontend COPY
5.
POSTGRESQL'S Unique Features
(a)
Object ID'S (OID'S)
i.
unique row assignment
ii.
join usage
(b)
Multi-Version Concurrency Control
i.
write locks
ii.
read locks
iii.
concurrency
iv.
solutions
(c)
Locking and deadlocks
i.
need for locking
ii.
deadlocks
(d)
Vacuum
i.
scheduling
ii.
ANALYZE
(e)
Views
i.
creation
ii.
limitations
(f)
Rules
i.
creation
ii.
limitations
(g)
Sequences
i.
purpose
ii.
creation
iii.
management
(h)
Triggers
i.
purpose
ii.
creation
(i)
Large objects(BLOBS)
i.
applications
ii.
creation
iii.
management
(j)
Adding user-defined functions
i.
purpose
ii.
creation
iii.
examples
(k)
Adding user-defined operators
i.
arithmetic processing
ii.
creation
(l)
Adding user-defined types
i.
purpose
ii.
creation
iii.
indexing
(m)
Exotic pre-installed types
i.
date/time
ii.
geometric
iii.
character string
iv.
internet
v.
internal
(n)
Arrays
i.
creation
ii.
access
(o)
Inheritance
i.
purpose
ii.
creation
iii.
examples
6.
Interfacing to the POSTGRESQL Database
(a)
C Language API (LIBPQ)
(b)
Embedded C (ECPG)
(c)
C++ (LIBPQ++)
(d)
JAVA (JDBC)
(e)
ODBC
(f)
PERL (PGSQL_PERL5)
(g)
TCL/TK (LIBPGTCL)
(h)
PYTHON (PYGRESQL)
(i)
Web access (PHP)
(j)
Server-side programming
i.
PLPGSQL
ii.
SPI
7.
POSTGRESQL Administration
(a)
Creating users and databases
(b)
Backup and restore
(c)
Performance
(d)
Troubleshooting
(e)
Customization
(f)
Access configuration
i.
server access
ii.
database access
iii.
table access
(g)
Internationalization
i.
national character encodings
ii.
date formats
8.
Additional Resources
(a)
Frequently Asked Questions (FAQ'S)
(b)
Mailing list support
(c)
Supplied documentation
(d)
Commercial support
(e)
Modifying the source code
9.
Appendix: Installation
(a)
Getting POSTGRESQL
i.
FTP
ii.
web
iii.
CDROM
(b)
Compiling
i.
compiler
ii.
RPM
(c)
Initialization
(d)
Starting the server
(e)
Creating a database
10.
Annotated Bibliography

--ELM939782788-18549-0_

--ELM939782788-18549-0_--

From bouncefilter Wed Oct 13 00:11:42 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 AAA29618
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 00:11:35 -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 AAA15067;
Wed, 13 Oct 1999 00:10:35 -0400 (EDT)
Date: Wed, 13 Oct 1999 00:10:34 -0400 (EDT)
From: "Matthew N. Dodd" <winter@jurai.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Jan Wieck <wieck@debis.com>, scrappy@hub.org, vev@michvhf.com,
lockhart@alumni.caltech.edu, lamar.owen@wgcr.org,
pgsql-hackers@postgreSQL.org, jwieck@debis.com
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might
In-Reply-To: <199910121953.PAA06352@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910130010190.480-100000@sasami.jurai.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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.

From bouncefilter Wed Oct 13 00:16:41 1999
Received: from school.cs.indiana.edu (school.cs.indiana.edu [129.79.252.113])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA30260
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 00:15:57 -0400 (EDT)
(envelope-from mirobert@cs.indiana.edu)
Received: from localhost (mirobert@localhost)
by school.cs.indiana.edu (8.9.3/8.9.3/IUCS_2.28) with ESMTP id XAA04746
for <pgsql-hackers@postgreSQL.org>;
Tue, 12 Oct 1999 23:15:56 -0500 (EST)
X-Authentication-Warning: school.cs.indiana.edu: mirobert owned process doing
-bs
Date: Tue, 12 Oct 1999 23:15:56 -0500 (EST)
From: "J. Michael Roberts" <mirobert@cs.indiana.edu>
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Win32 client...
In-Reply-To: <199910130246.WAA19232@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.10.9910122313330.4741-100000@school.cs.indiana.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I know this is probably the wrong group for this, but it's the only one
I'm subscribed to -- where the heck in the build tree is the Win32 client
stuff??? How do I build it? Or can I use that 6.4.something client in
the bindist on FTP against my spiffy new 6.5.1 Solaris postmaster?

This line of inquiry started out as an innocent attempt to play around,
and here I am back in that learning curve morass. Sigh.

From bouncefilter Wed Oct 13 00:27:42 1999
Received: from ns1.prima.net.id ([202.57.0.8])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA32286;
Wed, 13 Oct 1999 00:26:31 -0400 (EDT)
(envelope-from chai@prima.net.id)
Received: from prima.net.id (chai@[202.57.0.54]) by ns1.prima.net.id
(8.8.4/8.7.2) with ESMTP id EAA11911;
Wed, 13 Oct 1999 04:26:33 +0700 (GMT)
Sender: chai@ns1.prima.net.id
Message-ID: <380408E9.9D4F554A@prima.net.id>
Date: Wed, 13 Oct 1999 11:22:01 +0700
From: Chairudin Sentosa Harjo <chai@prima.net.id>
Reply-To: chai@prima.net.id
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
Subject: Re: [HACKERS] Outline for PostgreSQL book
References: <199910121716.NAA29586@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

You should put one special section to talk about DATE. (datetime,
abstime, etc..)
That is the most asked by the mailing list.
You could put tons of samples on how to use and manipulate DATE.
ie. How to get the time, how to get the minute, how to get the hour,
how to get the month in number (1,2,3,4),
how to get the month in word (JAN, FEB, MAR)

The most important thing is to have alot of samples.
Practical samples are more useful than just syntax.

Regards,
Chairudin Sentosa

Bruce Momjian wrote:

Here is my proposal for an outline for a PostgreSQL book. Many of us
have been asked by publishers about writing a book. Here is what I
think would be a good outline for the book.

I am interested in whether this is a good outline for a PostgreSQL
book,
how our existing documentation matches this outline, where our
existing
documentation can be managed into a published book, etc.

Any comments would be welcome.
--
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
...................................................................
The attached document is in both web page and text formats.
View the one which looks best.

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

PostgreSQL Book Proposal

Bruce Momjian

1. Introduction
2. Installation

(a) Getting POSTGRESQL
(b) Compiling
(c) Initialization
(d) Starting the server
(e) Creating a database
(f) Issuing database commands
3. Introduction to SQL

(a) Why a database?
(b) Creating tables
(c) Adding data with INSERT
(d) Viewing data with SELECT
(e) Removing data with DELETE
(f) Modifying data with UPDATE
(g) Restriction with WHERE
(h) Sorting data with ORDER BY
(i) Usage of NULL values
4. Advanced SQL Commands

(a) Inserting data from a SELECT
(b) Aggregates: COUNT, SUM, etc.
(c) GROUP BY with aggregates
(d) HAVING with aggregates
(e) Joining tables
(f) Using table aliases
(g) UNION clause
(h) Subqueries
(i) Transactions
(j) Cursors
(k) Indexing
(l) Table defaults
(m) Primary/Foreign keys
(n) AND/OR usage
(o) LIKE clause usage
(p) Temporary tables
(q) Importing data
5. POSTGRESQL'S Unique Features

(a) Object ID'S (OID)
(b) Multi-version Concurrency Control (MVCC)
(c) Locking and Deadlocks
(d) Vacuum
(e) Views
(f) Rules
(g) Sequences
(h) Triggers
(i) Large Objects(BLOBS)
(j) Adding User-defined Functions
(k) Adding User-defined Operators
(l) Adding User-defined Types
(m) Exotic Preinstalled Types
(n) Arrays
(o) Inheritance
6. Interfacing to the POSTGRESQL Database

(a) C Language API
(b) Embedded C
(c) C++
(d) JAVA
(e) ODBC
(f) PERL
(g) TCL/TK
(h) PYTHON
(i) Web access (PHP)
(j) Server-side programming (PLPGSQL and SPI)
7. POSTGRESQL Adminstration

(a) Creating users and databases
(b) Backup and restore
(c) Performance tuning
(d) Troubleshooting
(e) Customization options
(f) Setting access permissions
8. Additional Resources

(a) Frequently Asked Questions (FAQ'S)
(b) Mailing list support
(c) Supplied documentation
(d) Commercial support
(e) Modifying the source code

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

PostgreSQL Book Proposal

Bruce Momjian

1.
Introduction
2.
Installation
(a)
Getting POSTGRESQL
(b)
Compiling
(c)
Initialization
(d)
Starting the server
(e)
Creating a database
(f)
Issuing database commands
3.
Introduction to SQL
(a)
Why a database?
(b)
Creating tables
(c)
Adding data with INSERT
(d)
Viewing data with SELECT
(e)
Removing data with DELETE
(f)
Modifying data with UPDATE
(g)
Restriction with WHERE
(h)
Sorting data with ORDER BY
(i)
Usage of NULL values
4.
Advanced SQL Commands
(a)
Inserting data from a SELECT
(b)
Aggregates: COUNT, SUM, etc.
(c)
GROUP BY with aggregates
(d)
HAVING with aggregates
(e)
Joining tables
(f)
Using table aliases
(g)
UNION clause
(h)
Subqueries
(i)
Transactions
(j)
Cursors
(k)
Indexing
(l)
Table defaults
(m)
Primary/Foreign keys
(n)
AND/OR usage
(o)
LIKE clause usage
(p)
Temporary tables
(q)
Importing data
5.
POSTGRESQL'S Unique Features
(a)
Object ID'S (OID)
(b)
Multi-version Concurrency Control (MVCC)
(c)
Locking and Deadlocks
(d)
Vacuum
(e)
Views
(f)
Rules
(g)
Sequences
(h)
Triggers
(i)
Large Objects(BLOBS)
(j)
Adding User-defined Functions
(k)
Adding User-defined Operators
(l)
Adding User-defined Types
(m)
Exotic Preinstalled Types
(n)
Arrays
(o)
Inheritance
6.
Interfacing to the POSTGRESQL Database
(a)
C Language API
(b)
Embedded C
(c)
C++
(d)
JAVA
(e)
ODBC
(f)
PERL
(g)
TCL/TK
(h)
PYTHON
(i)
Web access (PHP)
(j)
Server-side programming (PLPGSQL and SPI)
7.
POSTGRESQL Adminstration
(a)
Creating users and databases
(b)
Backup and restore
(c)
Performance tuning
(d)
Troubleshooting
(e)
Customization options
(f)
Setting access permissions
8.
Additional Resources
(a)
Frequently Asked Questions (FAQ'S)
(b)
Mailing list support
(c)
Supplied documentation
(d)
Commercial support
(e)
Modifying the source code

From bouncefilter Wed Oct 13 00:51:42 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 AAA35905
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 00:51: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 AAA18684;
Wed, 13 Oct 1999 00:51:03 -0400 (EDT)
To: Jan Wieck <wieck@debis.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might
In-reply-to: Your message of Tue, 12 Oct 1999 16:16:23 -0400
<38039717.A9FFAA27@wgcr.org>
Date: Wed, 13 Oct 1999 00:51:02 -0400
Message-ID: <18682.939790262@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Lamar Owen <lamar.owen@wgcr.org> writes:

The globe is stunning -- but the text below also has a place, IMHO.

Yes, we must keep the text info too. The globe is beautiful, but
not everyone will want to/be able to look at it.

Also, we seem to be missing some names/pins. Hiroshi's name is
conspicuous by its absence, and if it weren't so late at night
I'd probably think of some more...

regards, tom lane

From bouncefilter Wed Oct 13 02:53:43 1999
Received: from mecomb.com (gw.mecomb.com [161.142.249.98])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA51015
for <pgsql-general@postgresql.org>;
Wed, 13 Oct 1999 02:53:31 -0400 (EDT)
(envelope-from lylyeoh@mecomb.com)
Received: (from mail@localhost) by mecomb.com (8.8.7/8.8.7) id OAA31750
for <pgsql-general@postgresql.org>; Wed, 13 Oct 1999 14:53:30 +0800
Received: from <lylyeoh@mecomb.com> (ilab2.mecomb.po.my [192.168.3.22]) by
ns.mecomb.com via smap (V2.1)
id xma031748; Wed, 13 Oct 99 14:53:18 +0800
Message-Id: <3.0.5.32.19991013145509.00915100@pop.mecomb.po.my>
X-Sender: lylyeoh@pop.mecomb.po.my
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 13 Oct 1999 14:55:09 +0800
To: pgsql-general@postgresql.org
From: Lincoln Yeoh <lylyeoh@mecomb.com>
Subject: How do I activate and change the postgres user's password?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Right now any user on the local machine can log on as postgres to the
template1 database. I don't like that, so I wish to turn on password
checking.

OK so I edit pg_hba.conf and put:

local all password
host all 127.0.0.1 255.255.255.255 password

Then I have problems logging in as ANY user. Couldn't figure out what the
default password for the postgres user was. Only after some messing around
I found that I could log on as the postgres user with the password \N. Not
obvious, at least to me.

I only guessed it after looking at the pg_pwd file and noticing a \N there.
Is this where the passwords are stored? By the way should they be stored in
the clear and in a 666 permissions file? How about hashing them with some
salt?

Now the next problem is: How do I change the postgres user password?

I find the package's handling of passwords rather nonintuitive.

1) There is no obvious way to specify the password for users when you
create a user using the supplied shell script createuser. One has to resort
to psql and stuff.
2) Neither is there an obvious and easy way to change the user's password.
3) You can specify a password for a user by using pg_passwd and stick it
into a separate password file, but then there really is no link between
createuser and pg_passwd.

I find the bundled scripts and their associated documentation make things
very nonintuitive when one switches from a blind trust postgres to an
authenticated postgres.

Cheerio,

Link.

From bouncefilter Wed Oct 13 03:53:44 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA63957
for <pgsql-hackers@postgresql.org>;
Wed, 13 Oct 1999 03:53:09 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11bJDc-000Gby-0K; Wed, 13 Oct 1999 07:53:04 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id JAA32243;
Wed, 13 Oct 1999 09:57:27 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5KJF>; Wed, 13 Oct 1999 08:51:04 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E6CC@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'wieck@debis.com'" <wieck@debis.com>, maillist@candle.pha.pa.us
Cc: vev@michvhf.com, lockhart@alumni.caltech.edu, lamar.owen@wgcr.org,
pgsql-hackers@postgresql.org, jwieck@debis.com
Subject: RE: New developer globe (was: Re: [HACKERS] Interesting Quote you
might enjoy about PGSQL.)
Date: Wed, 13 Oct 1999 08:50:58 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

That looks good. At least this time I'm the correct side of London :-)

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: wieck@debis.com [mailto:wieck@debis.com]
Sent: 12 October 1999 17:20
To: maillist@candle.pha.pa.us
Cc: vev@michvhf.com; wieck@debis.com; lockhart@alumni.caltech.edu;
lamar.owen@wgcr.org; pgsql-hackers@postgreSQL.org; jwieck@debis.com
Subject: New developer globe (was: Re: [HACKERS] Interesting Quote you
might enjoy about PGSQL.)

Wow, that web page looks good now, with the quote at the bottom.

Jan,

we need the nicer world image.

You mean one with the mountains - no?

Well, I'll spend some time, polish up the Povray sources etc.
so Vince can easily maintain the map after - only that he
needs Povray 3.1 and maybe Tcl/Tk 8.0 to do it, but that
shouldn't be a problem since both are freely available and
easily to install.

I have tcl 8.0.5 and povray here too.

I've setup an example for the new developers page at

<http://www.PostgreSQL.ORG/~wieck>

The image size is adjusted for the page width.

To maintain the hotspots I made a little, slightly
overspecialized, Tcl/Tk application that creates the imagemap
so it can easily be pasted into the page.

I'll contact you and Vince via private mail after packing it
up.

Jan

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

From bouncefilter Wed Oct 13 03:55:44 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA64478;
Wed, 13 Oct 1999 03:55:07 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11bJFY-000GnZ-0K; Wed, 13 Oct 1999 07:55:04 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id JAA32255;
Wed, 13 Oct 1999 09:59:27 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5KJH>; Wed, 13 Oct 1999 08:53:04 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E6CD@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Bruce Momjian'" <maillist@candle.pha.pa.us>, PostgreSQL-development
<pgsql-hackers@postgresql.org>, PostgreSQL-documentation
<docs@postgresql.org>
Subject: RE: [HACKERS] Book PDF file was corrupt
Date: Wed, 13 Oct 1999 08:52:56 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

Palatino isn't one of the Base14 fonts, so unless it was included within
the PDF, it wouldn't work unless the viewer had the font.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: 12 October 1999 18:12
To: PostgreSQL-development; PostgreSQL-documentation
Subject: [HACKERS] Book PDF file was corrupt

Here is the new PDF version of the outline. The previous version used
the Palatino font, which didn't convert to PDF for some reason.

-- 
  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 Wed Oct 13 03:48:44 1999
Received: from flame.flame.co.za (flame.flame.co.za [160.124.170.1])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA63004
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 03:48:11 -0400 (EDT)
(envelope-from theo@flame.co.za)
Received: from flame.co.za (flame [160.124.170.1])
by flame.flame.co.za (8.8.7/8.8.7) with ESMTP id JAA16151
for <pgsql-hackers@postgreSQL.org>; Wed, 13 Oct 1999 09:53:45 +0200
Sender: theo@flame.flame.co.za
Message-ID: <38043A89.1891365@flame.co.za>
Date: Wed, 13 Oct 1999 09:53:45 +0200
From: Theo Kramer <theo@flame.co.za>
Organization: Flame Computing Enterprises
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.35 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Outline for PostgreSQL book
References: <199910121716.NAA29586@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Here is my proposal for an outline for a PostgreSQL book. Many of us
have been asked by publishers about writing a book. Here is what I
think would be a good outline for the book.

I am interested in whether this is a good outline for a PostgreSQL book,
how our existing documentation matches this outline, where our existing
documentation can be managed into a published book, etc.

Any comments would be welcome.

A chapter following the Introduction discussing the philosopy behind
Postgres development, the benefits of Postgres, and an outline of the
architecture would be useful.

For the rest - I can't wait :)

--------
Regards
Theo

From bouncefilter Wed Oct 13 04:00:44 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA65409
for <hackers@postgresql.org>; Wed, 13 Oct 1999 04:00:34 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11bJKs-000HQ4-0K; Wed, 13 Oct 1999 08:00:34 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id KAA32299;
Wed, 13 Oct 1999 10:04:57 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5KJJ>; Wed, 13 Oct 1999 08:58:34 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E6CF@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Bruce Momjian'" <maillist@candle.pha.pa.us>, "Peter Mount (Home)"
<peter@retep.org.uk>
Cc: PostgreSQL Hackers <hackers@postgreSQL.org>, The Hermit Hacker
<scrappy@hub.org>
Subject: RE: [HACKERS] JDBC Driver
Date: Wed, 13 Oct 1999 08:58:30 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

There's three places, but only two go down to the sub release:

src/interfaces/jdbc/postgres/jdbc1/DatabaseMetaData.java
src/interfaces/jdbc/postgres/jdbc2/DatabaseMetaData.java

There's a string currently saying "6.5.2".

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: 12 October 1999 22:12
To: Peter Mount
Cc: PostgreSQL Hackers; The Hermit Hacker
Subject: Re: [HACKERS] JDBC Driver

The copy on cvs looks ok, although should I update it to say 6.5.3, or

6.5.3 is simply to include pgaccess, leave it alone?

I'd go for the latter.

I can update files as part of the release, but I don't see anywhere in
the jdbc directory that says 6.5.x.

-- 
  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 Wed Oct 13 04:08:44 1999
Received: from ritchie.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA66807;
Wed, 13 Oct 1999 04:08:25 -0400 (EDT)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by ritchie.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id MAA10738;
Wed, 13 Oct 1999 12:06:59 +0400 (MSK/MSD)
X-Real-To: maillist@candle.pha.pa.us
Received: (from dms@localhost)
by woland.wplus.net (8.9.2/8.9.1/wplus.2) id MAA18601;
Wed, 13 Oct 1999 12:06:59 +0400 (MSD)
Message-ID: <XFMail.991013120659.dms@wplus.net>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <XFMail.991012205559.vev@michvhf.com>
Date: Wed, 13 Oct 1999 12:06:59 +0400 (MSD)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: Vince Vielhaber <vev@michvhf.com>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
Cc: Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-documentation <docs@postgresql.org>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
Bruce Momjian <maillist@candle.pha.pa.us>

On 13-Oct-99 Vince Vielhaber wrote:

On 13-Oct-99 Bruce Momjian wrote:

2BOOK Authors:
Please, try to keep rights for translating this book into another
languages by you self, not by publisher.

I may ask some St.Pitersburg's publishing company
to make russian translation of this book, but some publishers
like O'Reilly have too hard license policy
and too long reaction time.

---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

From bouncefilter Wed Oct 13 04:14:44 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA67819;
Wed, 13 Oct 1999 04:13:42 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <4YCB0SP5>; Wed, 13 Oct 1999 10:13:16 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C143@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Bruce Momjian'" <maillist@candle.pha.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
PostgreSQL-documentation <docs@postgresql.org>
Subject: RE: [HACKERS] Outline for PostgreSQL book
Date: Wed, 13 Oct 1999 10:08:40 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

New version attached. No PDF version this time. Do people like PDF?

Yes!

From bouncefilter Wed Oct 13 04:23:44 1999
Received: from ns1.prima.net.id ([202.57.0.8])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA69687;
Wed, 13 Oct 1999 04:23:09 -0400 (EDT)
(envelope-from chai@prima.net.id)
Received: from prima.net.id (chai@[202.57.0.54]) by ns1.prima.net.id
(8.8.4/8.7.2) with ESMTP id IAA14849;
Wed, 13 Oct 1999 08:26:06 +0700 (GMT)
Sender: chai@ns1.prima.net.id
Message-ID: <3804410F.A0B29C16@prima.net.id>
Date: Wed, 13 Oct 1999 15:21:35 +0700
From: Chairudin Sentosa Harjo <chai@prima.net.id>
Reply-To: chai@prima.net.id
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dmitry Samersoff <dms@wplus.net>
CC: Vince Vielhaber <vev@michvhf.com>, Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
References: <XFMail.991013120659.dms@wplus.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dmitry Samersoff wrote:

On 13-Oct-99 Vince Vielhaber wrote:

On 13-Oct-99 Bruce Momjian wrote:

2BOOK Authors:
Please, try to keep rights for translating this book into another
languages by you self, not by publisher.

I may ask some St.Pitersburg's publishing company
to make russian translation of this book, but some publishers
like O'Reilly have too hard license policy
and too long reaction time.

I may ask some Indonesian's publishing company to make
Indonesian translation of this book too.
I may help the translation from English to Indonesian language.

Regards,
Chairudin Sentosa

From bouncefilter Wed Oct 13 04:47:44 1999
Received: from meryl.csd.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA72606
for <pgsql-hackers@postgresql.org>;
Wed, 13 Oct 1999 04:47:12 -0400 (EDT)
(envelope-from e99re41@csd.uu.se)
Received: from enequist.csd.uu.se (e99re41@enequist.csd.uu.se [130.238.15.83])
by meryl.csd.uu.se (8.8.5/8.8.5) with SMTP id KAA13331
for <pgsql-hackers@postgresql.org>;
Wed, 13 Oct 1999 10:47:09 +0200 (MET DST)
Date: Wed, 13 Oct 1999 10:47:08 +0200 (MET DST)
From: Peter Eisentraut <e99re41@csd.uu.se>
Reply-To: Peter Eisentraut <e99re41@csd.uu.se>
To: pgsql-hackers@postgresql.org
Subject: Scripts again
Message-ID: <Pine.GSO.3.96.991013104136.18208A-100000@enequist.csd.uu.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Okay, I have the following voting results:

2 for pgcreatedb, pgdropdb, pgcreateuser, pgdropuser (Bruce, me)
1 for pg_createdb, pg_dropdb, etc. (Sergio K.)
1/2 for pgadduser, etc., or sth. like that (Marc)
1/2 for leave as is (Thomas)
1 for drop altogether (Marc)

Well, since this is not on the immediate agenda I'll leave it open for a
while, but you see the leading vote getter.

In addition I'll add a configure option --with-pragmatic-scrappy which
will prevent the installation of the scripts altogether.

-Peter

From bouncefilter Wed Oct 13 05:29:46 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 FAA78396
for <pgsql-general@postgreSQL.org>;
Wed, 13 Oct 1999 05:29:22 -0400 (EDT) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max04-065.enterprise.net
[194.72.196.185])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id KAA26379;
Wed, 13 Oct 1999 10:29:20 +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/GNU) with ESMTP id KAA18704;
Wed, 13 Oct 1999 10:29:19 +0100
Message-Id: <199910130929.KAA18704@linda.lfix.co.uk>
X-Mailer: exmh version 2.0.2 2/24/98 (debian)
To: Lincoln Yeoh <lylyeoh@mecomb.com>
cc: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] How do I activate and change the postgres user's
password?
In-Reply-To: Message from Lincoln Yeoh <lylyeoh@mecomb.com> of "Wed,
13 Oct 1999 14:55:09 +0800."
<3.0.5.32.19991013145509.00915100@pop.mecomb.po.my>
References: <3.0.5.32.19991013145509.00915100@pop.mecomb.po.my>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 13 Oct 1999 10:29:19 +0100
From: "Oliver Elphick" <olly@lfix.co.uk>

Lincoln Yeoh wrote:

Right now any user on the local machine can log on as postgres to the
template1 database. I don't like that, so I wish to turn on password
checking.

OK so I edit pg_hba.conf and put:

local all password
host all 127.0.0.1 255.255.255.255 password

Then I have problems logging in as ANY user. Couldn't figure out what the
default password for the postgres user was. Only after some messing around
I found that I could log on as the postgres user with the password \N. Not
obvious, at least to me.

I only guessed it after looking at the pg_pwd file and noticing a \N there.
Is this where the passwords are stored? By the way should they be stored in
the clear and in a 666 permissions file? How about hashing them with some
salt?

The PGDATA directory should have permission rwx------, so that no one can
descend into it to look at pg_pwd; therefore the file's own permissions are
unimportant.

Now the next problem is: How do I change the postgres user password?

ALTER USER will change passwords held in pg_shadow, including that of the
postgres user, but will not, I think, change those set by pg_passwd.

--
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
========================================
"And he shall judge among the nations, and shall rebuke
many people; and they shall beat their swords into
plowshares, and their spears into pruninghooks; nation
shall not lift up sword against nation, neither shall
they learn war any more." Isaiah 2:4

From bouncefilter Wed Oct 13 05:32:46 1999
Received: from web303.mail.yahoo.com (web303.mail.yahoo.com [128.11.68.234])
by hub.org (8.9.3/8.9.3) with SMTP id FAA78935
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 05:32:38 -0400 (EDT)
(envelope-from andy_j_duncan@yahoo.com)
Message-ID: <19991013093737.10457.rocketmail@web303.mail.yahoo.com>
Received: from [193.128.102.3] by web303.mail.yahoo.com;
Wed, 13 Oct 1999 02:37:37 PDT
Date: Wed, 13 Oct 1999 02:37:37 -0700 (PDT)
From: Andy Duncan <andy_j_duncan@yahoo.com>
Subject: Re: [HACKERS] Outline for PostgreSQL book
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi Everyone,

I suffer from an affliction where I can't do anything technical without one of
them stone-aged book type things to kick me off. I would really welcome one
upon PostgreSQL, because although I've been following this mailing list for a
while, and would really love to see PostgreSQL kick Oracle et al into touch, I
just gotta have that book in my hand first. I suspect there are many out there
like me (on which Tim O'Reilly has based his fortune), and that a really good
"Learning PostgreSQL" type book would become a touchstone, and really blast it
into the big time. The small furry hot-blooded PostgreSQL could then really
get its teeth into the monolithic propriertary dinosaurs, and start bringing
them down, and moving the rest of us lightweights forward.

As a pre-newbie, I'd be very much inclined to want a book in the O'Reilly
"Apache: The Definitive Guide" style or the "Learning Perl/Tk" school, with
Chapter One entitled "Getting Started", right up to Chapter Ten "Come on You
Lightweight, It's Really Not That Difficult".

I don't think everything, or indeed a tenth of everything, has to be in the
first book; all the heavy technical stuff can be in the quasi-equivalents of
"Programming PostgreSQL", "Advanced PostgreSQL" and "Effective PostgresSQL".
This will not only help pre-newbies like me, as we pick it up, and then move
onto the heavier manuals, but give many different people the chance to become
authors, without leadening a vast single comprehensive book with a dull,
politically-correct "text by large committee" style, which will crush potential
sales (thereby enabling the dinosaurs to keep a steady grip on their database
stranglehold).

All the first book has to do is get a reluctant database hack like me, to get
our first PostgreSQL database going, and our first mini-system running along
the lines of Oracle's SCOTT/TIGER set-up, with a bit more for bonus points :-)
I'm sure there is an enormous marketplace of people like me, who've been
sitting out here like lemons, waiting for this kind of thing to appear. We're
sick of the thralldom of the West Coast Database Billionaires, but we're mostly
tied-in with a salaried financial dependence on their products, and possess the
sad aspect of rabbits trapped in headlights. It's pathetic I know, but if you
get it right, you could blow all these megalomaniacs away, and set the rest of
us free.

Good luck! :-)

Rgds,
AndyD
Ex-Informix 7.14 DBA
Ex-Sybase 11 User
Oracle8 Certified Professional DBA
Chief Lickspittle of the "Propriertary Databases Against Progress" Corporation
&
Future (hopefully) PostgreSQL Hacker
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

From bouncefilter Wed Oct 13 05:41:46 1999
Received: from sid.trust.ee (ns.tm.ee [195.50.195.154])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA80449;
Wed, 13 Oct 1999 05:40:55 -0400 (EDT) (envelope-from hannu@trust.ee)
Received: from trust.ee (wink.trust.ee [194.106.111.151])
by sid.trust.ee (8.8.7/8.8.7) with ESMTP id MAA24854;
Wed, 13 Oct 1999 12:52:31 +0300
Message-ID: <3804545B.FC9376E8@trust.ee>
Date: Wed, 13 Oct 1999 12:43:55 +0300
From: Hannu Krosing <hannu@trust.ee>
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
Subject: Re: [HACKERS] Outline for PostgreSQL book
References: <199910121716.NAA29586@candle.pha.pa.us>
<380408E9.9D4F554A@prima.net.id>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chairudin Sentosa Harjo wrote:

You should put one special section to talk about DATE. (datetime,
abstime, etc..)
That is the most asked by the mailing list.
You could put tons of samples on how to use and manipulate DATE.
ie. How to get the time, how to get the minute, how to get the hour,
how to get the month in number (1,2,3,4),
how to get the month in word (JAN, FEB, MAR)

how to select all individuals that are more than 50 years old today
at 12:00PM

And ouf course about TimeZones (why sometimes I insert one date and
get out another ;-p)

And of course mention that mostly it is not PostgreSQL's problem but
just a very hairy subject ;(

And perhaps some discussion about Date/Time types also in the section
for programming languages (what you get from date field, how to be
sure that what you give to postgresql is understood correctly)

The most important thing is to have alot of samples.
Practical samples are more useful than just syntax.

Agreed.

Maybe "Advanced SQL Commands" could also contain:

* Outer Joins
* Casts (bot AS and ::, with some explanations on why and when)

Not sure if Views and Triggers should go under Uniqe features - they are
supported on most commercial SQL databases.

"Interfacing to the POSTGRESQL Database" could also contain more options
than PHP,
at least as references - there are much more of both established (CGI,
PyApache,mod_perl)
and emerging (like the recent pgxml announcement) technologies for that
purpos.

Server side programming should also mention PL/Tcl

Under which section would requirements the restrictions (db size, field
size/count, record size/count)
or lackof them :) go?
(I recently checked Oracle8i for Linux, and it quoted 128MB RAM as
minimum and 256
as recommended - I think we are a lot less demanding, I guess PG can
reasonably run in 16MB ?)

-----------------
Hannu

From bouncefilter Wed Oct 13 05:45:47 1999
Received: from sid.trust.ee (ns.tm.ee [195.50.195.154])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA81178;
Wed, 13 Oct 1999 05:45:29 -0400 (EDT) (envelope-from hannu@trust.ee)
Received: from trust.ee (wink.trust.ee [194.106.111.151])
by sid.trust.ee (8.8.7/8.8.7) with ESMTP id MAA24868;
Wed, 13 Oct 1999 12:57:34 +0300
Message-ID: <3804558A.1E15A4F4@trust.ee>
Date: Wed, 13 Oct 1999 12:48:58 +0300
From: Hannu Krosing <hannu@trust.ee>
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
Subject: Re: [HACKERS] Outline for PostgreSQL book
References: <199910122056.QAA09210@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

New version attached. No PDF version this time. Do people like PDF?

There could be also a chapter on client side tools - pgAccess et.al.
and also small (but working ;) examples for using ODBC from MS Access,
MS Query, Delphi, JBuilder, Visual Cafe - each about 2-5 pages to get
people started.

--------------
Hannu

From bouncefilter Wed Oct 13 05:53:45 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id FAA82339
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 05:53:12 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 7286 invoked by uid 1001); 13 Oct 1999 09:53:12 -0000
Date: Wed, 13 Oct 1999 05:53:12 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <XFMail.991012205559.vev@michvhf.com>
Message-ID: <Pine.BSF.4.05.9910130527030.7254-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 12 Oct 1999, Vince Vielhaber wrote:

On 13-Oct-99 Bruce Momjian wrote:

Frankly, if I can get away with having whole sections that point to URL
files, so much the better. If I can just point them to the INSTALL
file, and be done with it, great.

The installation can be quick and painless. I'll explain more tomorrow.

Ok it's tomorrow. This will apply mainly to the actual installation
process, but will also apply to the instructions for the book.

1) Add to configure: --with-postgres-user= and --with-postgres-group=
with the default being postgres:postgres.

2) When generating the makefiles, use the -g and -o parameters to install.
These, of course, will come from configure.

At this point, anyone can build PostgreSQL, but only root and the
postgres user can install it. Either way, the ownership will be correct
since we added the -g and -o to install during the configuration process.

Currently, the only difference between the way I do it and the above is
that I override INSTALL in Makefile.custom (which I believe Tom Lockhart
tipped me off to). I build as myself and use sudo to install (as many
other admins also do).

3) gmake

4) gmake install (or sudo gmake install)

Alternately, steps 3 and 4 can be done this way:

3a) gmake > gmake.out 2>&1 &
tail -f gmake.out

4a) gmake install >> gmake.out 2>&1 &
tail -f gmake.out

But I don't usually bother.

The final step may not be necessary if steps 1 and 2 are done right. I
do it just to make sure the directories have the right permissions:

5) cd /usr/local (or whatever the directory is just below postgres')
chown -R postgres:postgres pgsql (substitute as necessary).

Then do whatever initdb's and createdb's etc as necessary/desired.

Even doing step 5 (and doing the custom makefile), on a 450 P-III running
FreeBSD 3.2-RELEASE, I have the entire system installed and running in
about 20-30 minutes.

So how's that? There may be some minor differences between systems,
I seem to recall HP having some with install(1), but I believe there
was a workaround script that fixed it for most things called bsd.install
or something like that. I'll verify HPs install on systems from 8-10.2
later this mourning - think I have a couple SGIs I can check too.

From bouncefilter Wed Oct 13 05:56:45 1999
Received: from ns1.prima.net.id ([202.57.0.8])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA82953
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 05:56:11 -0400 (EDT)
(envelope-from chai@prima.net.id)
Received: from prima.net.id (chai@[202.57.0.54]) by ns1.prima.net.id
(8.8.4/8.7.2) with ESMTP id JAA15956;
Wed, 13 Oct 1999 09:59:51 +0700 (GMT)
Sender: chai@ns1.prima.net.id
Message-ID: <38045709.543BC497@prima.net.id>
Date: Wed, 13 Oct 1999 16:55:21 +0700
From: Chairudin Sentosa Harjo <chai@prima.net.id>
Reply-To: chai@prima.net.id
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Andy Duncan <andy_j_duncan@yahoo.com>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Outline for PostgreSQL book
References: <19991013093737.10457.rocketmail@web303.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Can you imagine the "PostgreSQL" book written by people from different
countries that never each other's face?
Let's imagine, 20 chapters book written by 20 people.
Each chapter is written by the person who knows best his/her part of
PostgreSQL.
Wow this is amazing!!!

I think this is like Linux to Microsoft,
but this one is PostgreSQL to Oracle.

Linux + PostgreSQL is going to beat Microsoft + Oracle.

I am waiting for this to happen.

Regards,
Chai

From bouncefilter Wed Oct 13 06:02:45 1999
Received: from ns1.prima.net.id ([202.57.0.8])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA83959
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 06:02:30 -0400 (EDT)
(envelope-from chai@prima.net.id)
Received: from prima.net.id (chai@[202.57.0.54]) by ns1.prima.net.id
(8.8.4/8.7.2) with ESMTP id KAA16061;
Wed, 13 Oct 1999 10:06:12 +0700 (GMT)
Sender: chai@ns1.prima.net.id
Message-ID: <38045886.D313B9CA@prima.net.id>
Date: Wed, 13 Oct 1999 17:01:42 +0700
From: Chairudin Sentosa Harjo <chai@prima.net.id>
Reply-To: chai@prima.net.id
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 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] Updated book outline
References: <199910130246.WAA19232@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Add a subsection on chapter 1 with title:

(d) PostgreSQL Known Limitation
(i) Maximum record
(ii) Maximum field
(iii) Maximum file size
etc....

Regards
Chairudin

Bruce Momjian wrote:

OK, new outline, updated to show subsection detail, with suggested
changes made.

PostgreSQL Book Proposal

Bruce Momjian

Preface

1. Introduction

(a) History of POSTGRESQL

i. UNIVERSITY OF CALIFORNIA AT BERKELEY
ii. MICHAEL STONEBRAKER
iii.
JOLLY CHEN and ANDREW YU
iv. POSTGRESQL GLOBAL DEVELOPMENT TEAM
(b) Open source software

i. development methods
ii. peer review
iii.
release process
iv. problem reporting
v. support
(c) When to use a database

i. large volume
ii. rapid retrieval
iii.
frequent modification
iv. reporting

From bouncefilter Wed Oct 13 06:03:45 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA84095
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 06:03:22 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id TAA06109
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 19:03:21 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id TAA06423 for
<pgsql-hackers@postgreSQL.org>; Wed, 13 Oct 1999 19:03:20 +0900 (JST)
Message-Id: <199910131003.TAA06423@srapc451.sra.co.jp>
From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: pgsql-hackers@postgreSQL.org
Subject: sort on huge table
Date: Wed, 13 Oct 1999 19:03:20 +0900
Sender: t-ishii@srapc451.sra.co.jp

I came across problems with sorting a huge (2.4GB) table.

o it took 46 minutes to complete following query:

select * from test2 order by i desc limit 100;

to get 0 results.

i|t
-+-
(0 rows)

I assume this is a failure.

note: this is Pentium III x2 with 512MB RAM running RedHat Linux 6.0.

o I got NOTICE: BufFileRead: should have flushed after writing
at the very end of the processing.

o it produced 7 sort temp files each having size of 1.4GB (total 10GB)

Here is the table I used for testing(no index):

CREATE TABLE test2 (
i int4,
t text);

This has 10000000 records and the table file sizes are:

$ ls -ls test2*
1049604 -rw------- 1 postgres postgres 1073741824 Oct 4 18:32 test2
1049604 -rw------- 1 postgres postgres 1073741824 Oct 5 01:19 test2.1
327420 -rw------- 1 postgres postgres 334946304 Oct 13 17:40 test2.2

--
Tatsuo Ishii

From bouncefilter Wed Oct 13 06:13:47 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 GAA85868
for <pgsql-hackers@postgresql.org>;
Wed, 13 Oct 1999 06:13:18 -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 TAA03883; Wed, 13 Oct 1999 19:10:55 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>,
"Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Bernard Frankpitt" <frankpit@pop.dn.net>,
"pgsql-hackers" <pgsql-hackers@postgresql.org>
Subject: RE: Scan by TID (was RE: [HACKERS] How to add a new build-in
operator)
Date: Wed, 13 Oct 1999 19:14:47 +0900
Message-ID: <000101bf1563$c6cf8e60$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
In-Reply-To: <199910121840.OAA03133@candle.pha.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

-----Original Message-----

Bernard Frankpitt <frankpit@pop.dn.net> writes:

With all due respect to people who I am sure know a lot more

about this

than I do, it seems to me that extensive use of TIDs in user

code might

place an unwelcome restraint on the internal database design.

Yes, we'd certainly have to label it as an implementation-dependent
feature that might change or vanish in the future. But as long as
people understand that they are tying themselves to a particular
implementation, I can see the usefulness of making this feature
accessible. I'm still dubious that it's actually worth the work ...
but as long as I'm not the one doing the work, I can hardly object ;-).

I just want to be sure that we don't create a maintenance headache
for ourselves by corrupting the system structure. We've spent a
lot of time cleaning up after past shortcuts, and still have many
more to deal with; introducing new ones doesn't seem good.

Agreed.

I think it isn't so difficult to implement a new type of scan
on trial. But I'm not sure my story is right and I'm afraid
to invite a maintenance headache like intersexcept ....
May I proceed the work ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Wed Oct 13 07:00:46 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA91830
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 06:59:57 -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 GAA01731;
Wed, 13 Oct 1999 06:58:13 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131058.GAA01731@candle.pha.pa.us>
Subject: Re: New developer globe (was: Re: [HACKERS] Interesting Quote you
might
In-Reply-To: <18682.939790262@sss.pgh.pa.us> from Tom Lane at "Oct 13,
1999 00:51:02 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 13 Oct 1999 06:58:13 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Lamar Owen <lamar.owen@wgcr.org> writes:

The globe is stunning -- but the text below also has a place, IMHO.

Yes, we must keep the text info too. The globe is beautiful, but
not everyone will want to/be able to look at it.

Also, we seem to be missing some names/pins. Hiroshi's name is
conspicuous by its absence, and if it weren't so late at night
I'd probably think of some more...

Vince is missing too.

-- 
  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 Wed Oct 13 07:05:46 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA92561;
Wed, 13 Oct 1999 07:04:51 -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 HAA02109;
Wed, 13 Oct 1999 07:04:10 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131104.HAA02109@candle.pha.pa.us>
Subject: Re: [DOCS] RE: [HACKERS] Book PDF file was corrupt
In-Reply-To:
<1B3D5E532D18D311861A00600865478C25E6CD@exchange1.nt.maidstone.gov.uk>
from Peter Mount at "Oct 13, 1999 08:52:56 am"
To: Peter Mount <petermount@it.maidstone.gov.uk>
Date: Wed, 13 Oct 1999 07:04:10 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Palatino isn't one of the Base14 fonts, so unless it was included within
the PDF, it wouldn't work unless the viewer had the font.

Strange thing is that it is embedded in the PDF file. I can see the
file size with Palatino is 10 times the size with Times. I later
realized that it is xpdf that has the problem. gv/ghostscript are fine
viewing the Palatino PDF file.

I then read in the xpdf manual:

At this point, the biggest problem is that embedded fonts
are not handled properly.

so it seems xpdf has a limitation here. Palatino is good for outlines.

-- 
  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 Wed Oct 13 07:10:46 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA93695
for <hackers@postgreSQL.org>; Wed, 13 Oct 1999 07:10:36 -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 HAA02362;
Wed, 13 Oct 1999 07:08:52 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131108.HAA02362@candle.pha.pa.us>
Subject: Re: [HACKERS] JDBC Driver
In-Reply-To:
<1B3D5E532D18D311861A00600865478C25E6CF@exchange1.nt.maidstone.gov.uk>
from Peter Mount at "Oct 13, 1999 08:58:30 am"
To: Peter Mount <petermount@it.maidstone.gov.uk>
Date: Wed, 13 Oct 1999 07:08:52 -0400 (EDT)
CC: "Peter Mount (Home)" <peter@retep.org.uk>,
PostgreSQL Hackers <hackers@postgreSQL.org>,
The Hermit Hacker <scrappy@hub.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

There's three places, but only two go down to the sub release:

src/interfaces/jdbc/postgres/jdbc1/DatabaseMetaData.java
src/interfaces/jdbc/postgres/jdbc2/DatabaseMetaData.java

There's a string currently saying "6.5.2".

Done, and added to release update list. Any others, let me know.

-- 
  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 Wed Oct 13 07:12:48 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA93844;
Wed, 13 Oct 1999 07:11:46 -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 HAA02403;
Wed, 13 Oct 1999 07:09:58 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131109.HAA02403@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <XFMail.991013120659.dms@wplus.net> from Dmitry Samersoff at "Oct
13, 1999 12:06:59 pm"
To: Dmitry Samersoff <dms@wplus.net>
Date: Wed, 13 Oct 1999 07:09:58 -0400 (EDT)
CC: Vince Vielhaber <vev@michvhf.com>, Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset KOI8-R unsupported, filtering to ASCII...]

On 13-Oct-99 Vince Vielhaber wrote:

On 13-Oct-99 Bruce Momjian wrote:

2BOOK Authors:
Please, try to keep rights for translating this book into another
languages by you self, not by publisher.

I may ask some St.Pitersburg's publishing company
to make russian translation of this book, but some publishers
like O'Reilly have too hard license policy
and too long reaction time.

Actually, I want to make sure the book is accessible on the web. I will
keep your translation idea in mind. Good point.

-- 
  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 Wed Oct 13 07:13:46 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA94076;
Wed, 13 Oct 1999 07:13:10 -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 HAA02615;
Wed, 13 Oct 1999 07:11:34 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131111.HAA02615@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <XFMail.991013120659.dms@wplus.net> from Dmitry Samersoff at "Oct
13, 1999 12:06:59 pm"
To: Dmitry Samersoff <dms@wplus.net>
Date: Wed, 13 Oct 1999 07:11:34 -0400 (EDT)
CC: Vince Vielhaber <vev@michvhf.com>, Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset KOI8-R unsupported, filtering to ASCII...]

On 13-Oct-99 Vince Vielhaber wrote:

On 13-Oct-99 Bruce Momjian wrote:

2BOOK Authors:
Please, try to keep rights for translating this book into another
languages by you self, not by publisher.

I may ask some St.Pitersburg's publishing company
to make russian translation of this book, but some publishers
like O'Reilly have too hard license policy
and too long reaction time.

FYI, I just did bibliography, and got:

(a) The Practical SQL Handbook, Bowman et al., Addison Wesley
(b) Web Development with PHP and PostgreSQL, \ldots{}, Addison Wesley
(c) A Guide to The SQL Standard, C.J. Date, Addison Wesley
(d) An Introduction to Database Systems, C.J. Date, Addison Wesley
(e) SQL For Smarties, Joe Celko, Morgan, Kaufmann

Looks like Addision Wesley is the winner.

-- 
  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 Wed Oct 13 07:13:46 1999
Received: from gate.plzen-city.cz (gate.plzen-city.cz [194.212.191.10])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA94051
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 07:13:01 -0400 (EDT)
(envelope-from horak@mmp.plzen-city.cz)
Received: (from mail@localhost) by gate.plzen-city.cz (8.9.3/8.9.1) id
NAA07493
for <pgsql-hackers@postgreSQL.org>; Wed, 13 Oct 1999 13:12:09 +0200
Received: from EXCHANGE.mmp.plzen-city.cz(s5srvr1.mmp.plzen-city.cz
192.168.51.21) by gate.plzen-city.cz via smap (v1.3-ps12tp)
id sma007486; Wed Oct 13 13:11:44 1999
Received: by exchange.mmp.plzen-city.cz with Internet Mail Service
(5.5.2448.0)
id <4Y9KTM59>; Wed, 13 Oct 1999 13:11:43 +0200
Message-ID:
<2E7F82FAC1FCD2118E1500A024B3BF907DEDB2@exchange.mmp.plzen-city.cz>
From: Horak Daniel <horak@mmp.plzen-city.cz>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: update for shlib makefiles on win32
Date: Wed, 13 Oct 1999 13:11:43 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01BF156B.BB121392"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF156B.BB121392
Content-Type: text/plain;
charset="iso-8859-2"

Hi,

I have changed a bit the makefiles for the win32 port - the *.def files
(created when building shared libraries) are now clean from Makefile.shlib.

I have also removed "-g" from CFLAGS in the "cygwin32" template - it can be
enabled when running configure.

Dan

------_=_NextPart_000_01BF156B.BB121392
Content-Type: application/octet-stream;
name="Makefiles.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="Makefiles.patch"

--- Makefile.shlib.orig	Wed Oct 13 11:48:15 1999=0A=
+++ Makefile.shlib	Wed Oct 13 11:49:01 1999=0A=
@@ -274,3 +274,6 @@=0A=
 =0A=
 clean-shlib:=0A=
 	rm -f $(shlib) lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) =
lib$(NAME)$(DLSUFFIX)=0A=
+ifeq ($(PORTNAME), win)=0A=
+	rm -rf $(NAME).def=0A=
+endif=0A=
--- interfaces/libpq/Makefile.in.orig	Wed Oct 13 11:49:15 1999=0A=
+++ interfaces/libpq/Makefile.in	Wed Oct 13 11:49:28 1999=0A=
@@ -88,9 +88,6 @@=0A=
 clean: clean-shlib=0A=
 	rm -f lib$(NAME).a $(OBJS)=0A=
 	rm -f dllist.c common.c wchar.c conv.c big5.c=0A=
-ifeq ($(PORTNAME), win)=0A=
-	rm -f pq.def=0A=
-endif=0A=
 =0A=
 depend dep:=0A=
 	$(CC) -MM $(CFLAGS) *.c >depend=0A=
--- interfaces/ecpg/lib/Makefile.in.orig	Wed Oct 13 11:56:25 1999=0A=
+++ interfaces/ecpg/lib/Makefile.in	Wed Oct 13 11:56:00 1999=0A=
@@ -44,9 +44,6 @@=0A=
 =0A=
 clean: clean-shlib=0A=
 	rm -f lib$(NAME).a $(OBJS)=0A=
-ifeq ($(PORTNAME), win)=0A=
-	rm -f $(NAME).def=0A=
-endif=0A=
 =0A=
 depend dep:=0A=
 	$(CC) -MM $(CFLAGS) *.c >depend=0A=
--- pl/plpgsql/src/Makefile.in.orig	Wed Oct 13 11:51:41 1999=0A=
+++ pl/plpgsql/src/Makefile.in	Wed Oct 13 11:51:55 1999=0A=
@@ -82,6 +82,3 @@=0A=
 	rm -f *.o pl.tab.h pl_gram.c pl_scan.c=0A=
 # And the garbage that might have been left behind by partial =
build:=0A=
 	rm -f y.tab.c y.tab.h lex.yy.c=0A=
-ifeq ($(PORTNAME), win)=0A=
-	rm -f $(NAME).def=0A=
-endif=0A=
--- template/cygwin32.orig	Wed Oct 13 10:45:09 1999=0A=
+++ template/cygwin32	Wed Oct 13 10:45:15 1999=0A=
@@ -1,5 +1,5 @@=0A=
 AROPT:crs=0A=
-CFLAGS:-O2 -g=0A=
+CFLAGS:-O2=0A=
 SHARED_LIB:=0A=
 ALL:=0A=
 SRCH_INC:/usr/local/include=0A=

------_=_NextPart_000_01BF156B.BB121392--

From bouncefilter Wed Oct 13 07:15:46 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA94358;
Wed, 13 Oct 1999 07:14:47 -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 HAA02733;
Wed, 13 Oct 1999 07:12:56 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131112.HAA02733@candle.pha.pa.us>
Subject: Re: [DOCS] RE: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <1BF7C7482189D211B03F00805F8527F748C143@S-NATH-EXCH2> from
"Ansley, Michael" at "Oct 13, 1999 10:08:40 am"
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
Date: Wed, 13 Oct 1999 07:12:55 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM939813175-1691-0_
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

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

New version attached. No PDF version this time. Do people like PDF?

Yes!

OK, here is the PDF. Three pages in length.

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

--ELM939813175-1691-0_
Content-Type: application/pdf
Content-Disposition: inline; filename="/root/book.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjIKJcfsj6IKNCAwIG9iago8PC9MZW5ndGggNSAwIFIvRmlsdGVyIC9GbGF0ZURlY29k
ZT4+CnN0cmVhbQp4nJVci59XR3WvaYwU+6GtbdOmrOkulRAX9nrncefBYwWXkBAxgBJIDNaQtb66
m4dRbJtGxLSSAKnYlJba2vfj3+z3e87MvXOXH6l+EsP9zm8eZ85rzpw52Hdmuec/5c/N7d1v7O47
u/yt3da4tBxS6Dvvl7crTLazZtka4zrrgbPtolu2ffadcyPe3G17b7o0NmxNDSl3PmtD6no7axmG
LsexxfahJ3BdHCqIQxe8zE8Y0RFkbI2w7wJ6DgHfMsZHIYtgooloq0FWUA5c5n6ofXPfpWZowtBc
F4lJlx7CCFKHabgiYbKpUxbkoXPcnw2Epgcz0wStVR4CFm478MEtzySxufub6Go4yxC64EQ0Ar3r
Esgxfex6isbZRi5OyVHGCtyq1DnX+TTB5CkDodZ02bAlFBGaPnGJ2lLWjaYLaXlGkxLprew2RhL5
9dXd1jpOZzxFuF2hi52BRmHybqA2DE7nJn8LAOUmxM665mfP1dwAVS3fxnTRSFfCohkY57tEdQi5
G4hB+pBGjO7o37YoVRF7J/9aimVTkAUa+tClKFsgjAlbiOgMznML0ApdC0rj0ohJWrRdH5segSqW
c5dsAcmkzg+6Y0KHpWEJJvZdJneg0MqdQRSwYG6jh9ymDkqnhb4NyzOidRcu8IdGNK7nRqAtfeK+
BCZrRKftQGACdboAl6hHXHbwssfkB7FSG6A0JBzGLTB3JlXI/rBm1Vb9HWLqB9X0RBbCXZigJmNE
ZdkiOmerFlpYUb+4RZVDWkxnJgUC7slwYPCRW4LInB0x14GCmdkUg+1yo3HW82fvuZ8CbCZpHCyw
R0eZmxuGqdTvCJ0zKiT1IYm+BAA0qRPhXq2NXmguWGhS7pUWIQqMV+/WJVoN2AingCXgZgl9ZzlF
Bimq3fAK7A93NoijFFJ3QlV9gYWGagxetCrCxm1slgOubCskTlPE2RRbsuvONTaoula40Cqe6Kbr
M9dqdRM2bKzyEYZC9cRB4dPYAhyFTLhliMw6n7tgRgwynRchNj2Mumk3ArCs99pXBC0+0EGd+wVw
EBXRnu03RAqPQQgLEbuIshtp8WrCUDSquoNxDlldJkQKTwMsLhT+VMTvjJUTEzqqh1xtKMTYMP+O
UPLgJsilyRynviPSh8h2Cy8UcyGouPCg9sBRE0QEIJUCmwtAxRSGcrRWMXlRZigoOLBdIWbEzFAj
uG9xONi5h9tOBWB1b8E0RSDd90NRsViiAt9DZmlssS6boiAV98K4yEBBToCxB6w8kbVQr0j66UvI
enhciRHQnsWAPeIZcdVZ+OfBMmcVgnbyGe7V+ApwUmfRlQIT+Q7gVTuwPwQ2wD2dN2TUS18o7TAo
5BrQWVsOeej+hHFsykrU6XKuB2XU2APzh3aEDK+zJ+mLU70vv3Ex+Eo9n0XLsd9UlE2dm4fRNc6u
4WHt4WKhlceRAsgtiRNQiCnoklwSTgGbkflq45FcYXfYnQkqDjpTpzGTlwNEAdxbnKauWuRS0dNQ
DBfyFW8IXcxlag2p4lAJhW5wcdgQRTJixH697jM6Hu4hQogMGBzPEuoOgYcXt/otipp1cvlJ1Bs2
PX6r5otxQH/0KI9ZTEEgogMHkrz1EsmAH5SDFRUhEKYnjSCyaCm5CMXMuQIbGQ9KRz8dmqLOxHB7
IkyEUsGOeLMRf+0hBDk9C1tilXrlmCvOViHCtEydBpuoV9FxJFyWMQo2G9Plb5SVHEUYKHKtGCQ4
3UNtGbwqCtQicSk4WU9ZQT0kPmIIp0pdxIEGN6idWp5zaEFUUVqSuv5gxasq8frzbGO6U/rz1Dqx
AV45uGJ1EgpNLZkGBtw3gYIdIKBhZjkDXIVtengctmrIphNLFUNzqlKN0ZF6sMCnWQv2qqt7BtPS
Mmjogunk3uB5OKvfyGrsMZSYjD0A4xixVaCLx8lrblUIc6AwfKgR4kBXN9IRIwOCzd1NgwQmA0Tj
hgWQ3aUhdhJYx6C+MuvYiSM8ja2ZmAKVder/wT/xRM6oCsJIxK06CT2E3xoLc7sUAPRftun1TjYY
vXm6KjG5nVXMAdZJ7Fw7VInTM4flnTohmjPQF4RWc0Kvzol+TzUn9HKwJVzzCleyRG3i+BiXDzi5
bPF9DIwGur04YlI2iPlPPXyZkDJSoDwLJWDnMvoNgUeva/RNGDsgCJtfrQYvnJ566LUMC5oKTF+O
IIExiZ1jYNQLXonrhqDXw+luNWjkO/YI5E2eZtjBM+VssuLpxPZ0h6L3+o1dZXKOwXlz3RlCuQGM
96EBimZM00Omxb3H129eH8qtLkBd4yzmDLkc+riMbVeIxelGgjhMVYYCeAcWBinEKeT4Gy1e7suZ
P9sAqu0I2RuOKbcdQLRsA2GqEZz18sPATFwgZCG31QT7pD2DDgKrtAjAOWSy9hUYlWgFg8QaAJ0T
7EvQiyVKZCstW00LlDZEbSmjmhYnLppZHq+6V+nDjrLQp4mTROsO3FFU21TMleEixJ/VHtAV8YG8
gpMH9ERxXIMjcLhL3IXIgu6DbBWVVrrA9kiXVjFH8NQyTQ8jB4LG67nBOA9Ee8YGKMkggoD7lMyN
57W1wvHeMrWAI0p1LCG13vQDDdm1uYAA75SaDlZvWklyDYCG57FcS5xK05ZsAtwf3WCAG8upRKaE
cr2XMCyUPZQWuL9e/E+QuGwOp2sa++fhQ1qAo3qjKEoCnCWDxz30sRLpi5tnVofbmEFXMiSChQtO
kkzl6sFF1UgaKqDBbnbFrEo00kXrHDnfWK4aN8Ijif5H407VwwUJzxTCeUETEnx2nnTcxlD0ddSl
iFNiCE0P8a5wAP0IdGb2FagSsZGhXFKl4TUo4giJQUXudeZBAyLYEP7ERVqTrLwq86CLvH3bNjom
1+SujTskUw+MsSWEQiwwcDe23KUVY8TUMtAitu5rAXZK1oitso8ZHpkCWiHhu54blgolt0UvuQmb
ahps6EvcFsEqIRzuhzkk3svEWIL8abnh0O5LclVu4oRKSGU6k54IGAxmg2XQu10hY1HyMMufchmG
nkGeetgVLFwPeterPXhP5R4mALk43YhAul6Kw6WZd69TT+6daZY0dVDC4PLt8oxm3QQ2lGZamqkO
ostySG6zxajj610xlozQRFSE+SxYQjap3MqxXoYu92a8Z9PZhTBetBNzkbZ0xQFTuB1GkKvKRDnh
LIW5VSGMjWFhiiWdl/RiweyxnLqpXj1k835s2WpaxqcB5oDTooZpDExB8thTy2DGtwJZWW5ASSMj
BeNbgcCyoa0RGrmuSrolqE/jvU7C6DzizZGY0rDVNFgVQSjpCMJvUkpZE8pVkq5PeuukWjvGE1ML
/COCNtfz0It6J8NR5noYtBy10ApD6aEHQpSkQQjU1fVx0DsJNLMAHF5ysSmQ16uBU/nOT08zrq9q
NT7V5KQ2MvF/bBmfZjJz2W7ekjT7oC2ulwMWAkDIXEAVgEIKwJNHFVoepZxmMOVMCcvjQgU35JWW
rbZFp3P1lUdh6NV5RLKpMJrWLYydi4KmBw5JniPznrpdIRROmKeXPRwsWMYznyaAe2IoMCjkqhIu
qHBGWN9SAHPxFYEmKYPt9JKCuXvJOhTM6X0oYVHpIVSBoz4szyjWLQRbTn8enttTA1N2nhoCTdGX
hzipgDqGcXF1DEo637PkWapuTPSSEMeDZOinFngxCS7hneRarlyzY8tEncnLO0hV6uujzGgxRjS4
vhQVqC9FzkChm5ciZ1x7/XYGx1HzUuT6XFJytn7XlyKF5aXIyePWlKXGtP38pQgLp7ZFqSovRTOK
ZVNGZFRfihSWlyIA074UYS0/fynCLkL7UgTqJBiUlyIF40tRgXogYqBvX4qcsXn+UuSMT81LUaFT
X4pmROsuGCG3L0XOyt17FI3CIhq+D7SisU0GEStbHMqtaEwaRtHo9ygagVU0Vi+8I+Ot9TtEw8ea
VjRWk2oqmpZi2ZQdTCsagVU0FmFOKxpr0w7R8KWyFY3V7KaKRsAkGtvEgwBpJhoLU5qLxvLwaToI
nUU0LdG6i+h3iMbxAi6UyfPMdtsysGWLLfV8G1uo1mL9TBQABjkvxGNGYqcHJIM0YYBjBszrZUiy
bs4xNpTLdmD2TSY1WiAwCLPGWdMgV2PH5wNxeIo5KxcpcGuEXr5t3vmtiziV+gi95JgkywmOOWqW
8DvxqG+wULnZjpA3K87Rl0dYSToUmJUihFNyAitE8K1ZoSQHs7QkCYSLk2cLDgDx4VFzWY7vnVpH
Aa++TLhcayoK4NVGDnGBTJTEOnK8JelKGuZRAiMtPCKLJo0tporZxHINur9FzElavGZPpxYEwnFs
UH6IZrgKlMLN+1lXhFPuZY18eJ+RRzPpE1SFxUJEuGUTM7C5u8JCPPSfufxZ8hY6R3nUipUCC3eZ
Wm0qVpwPeV6x4rwJsyh0bKghj/Mw2FnFiuNDUVOxAlwiL+qfgjEIEjhWrFTIihV8a6oAX6UIRCtW
KgladjIhCTGY950qVhqofWFgqRkK+6sVK07z4FqxUkGpWFFYK1Ywad9UrADGpmLF+RzHipXCba1Y
mUlCnJUXx1crVgrUihWIxo4VK5NcnJITfFOxUqirFSsFjlEWk9azihVM7dqKlbKuVqzMaBIiBxPn
FStwjWb+HNC0yHOAkzzjdKQxvTp7DkBL3z4HOEldTs8BbtDtiYrod03+A/r5c4Dj48PsOQAtZvYc
gIY4ew6A/7bNcwDgVMBRgS4uelefAwrU5wBMatvngJGO+hzQNIichuCb54AG6nMAGlz7HKAbL88B
BdTngMKU+hwg/GueA4B9+xwg/G6fA9AQ2ucA4Ng8B0CAfv4cgJbcPAdMEtfngJ06oZqThvlzgAux
rXUqsIRJYZjVOuFIbhPyLvSzWidMPtY6le8xTBrSVOuEcbNaJ0y7o9YJC88CJ6WqhkktxbKpUC9K
GiaFYap1csyxtmFScDtqnVwws1onUDfVOimYwiSFJUwKZlbrhG3sqHXC4m2tU6GzhEkt0bqLuKPW
yUURN3g4iC9S6CS37fiK6xtr5fNlCq10oh1ao3SR6bCs6jAI7sfp2F3gaMCxDyXuqS3MkPs8qpO0
mFI01dOdSUvsvKp0FnceslGnol2Ay3swKSigUiAw4jddThAiNy/yL/U8TupaHBOrIkX4/6yDx5aB
Zz53gENQ+LmgRUZpCyeVIgrlQF1RAXyTJPoKjPJMwnHkpeinRGqYp5QQBg6lwWcFHDqUJID8Fkt5
Sl9Bka+oQBxKSlgShAoZtyCScMxaapK15xK9JiJ7JQ7z5fqTGQtMy3d2pHEUsZUgs9nEqFJWjhuR
laqUKW9XfVUpGpNvegi98s48o103U96EJn1OMvvoahQWV5OKnVZtTXamzJy4dTVRL/LiavR7dDUC
q6spxR2jI2HSeO5qmFdrXY1QVV1NS7FsCteE1tUIrK6GZ13ralgFMXc1zLC3riZJXrO4GgGTq1FY
XI2keRtXw1z33NWIyTUdhM7ialqidRfR7XA1WXLNtaxSYSmrdElW0rLKAmpZpUuldLSUVQLHpqzS
ZVyk27JKl01uyiod08JNWSVwmpdVSsusrNIxudwvbhl9VQbrm7JKx9xnU1YJ7OZllaDUzcoqHa9L
TdEDeBaXa1llAbWsskAtq8TcUlTEskr9HssqC9SCQrAitGWVwP28rHLk3lhW6eQlcSqrdAwpp7JK
x8z5rKzSsayvLatUUnfC+mAlEzQ1kYKnssppuVpWOZE4TjFuY2qBS23KKouuVS40iie6maFJs7JK
39uoTyG1rNIzt6elGHyRAjSamk3isHxv9F11zASgxSmTYM8Eep3UyK38qKUOtW95Stmq0Evy12XY
ao6NXiX1vJOjytxk0wGBTAw6gU0Ndk6LsKYWKw+zwFG4ReMlDGrXVh+1gPkx/apltlRFoa/iafqx
RSxsa6KwWGyOoVAYy5ZsiRqra8m5lkKXHrkcEoyBFWiIK33l1uVLdnmcXL2HrO6Ug1qqge3a5fpi
pmAKqBWW1AEZoaqvqYWMIDxMD7Lszif9JvnADH0fGlXLqapMpbS8WPq+70tdhQwFrsm0MjnUYCjF
naVHVUqdfKeSqirrgvKcQ6fKMkK3XItKHF8HYnnh0R0lDRRqNTBayt/mqD00vyXPxAVkeeMUQcv5
m+kAMHXStD2TrLlKib5XzzHPXLifGVlM42PEdgsHMQLcPUKaYAilMnfAziUxAgq9G0HSXJlCzUN5
PndIarBAN8zTUp7PI325FbsgLb4cczUv5fl3cUShtI/gJnsy4Sg35M3dY0vxwltNC3zjEDnGl6d9
7kYTAyWvQSqnXU8XRXKwVnBWFr6xbORvKNU/NreXP3dh92dOLJvlC1/fXf/i0lovRRAMXIK82VzY
fvJXHvrIw7/6yEd3fezyq7/26x/fc/k7v/kbn/it3/ntR3/30xe+vXuNf70DW73wtSd/j5ivmQQf
3fX7j318zx/s/djSRx7/5KN/uLK875OP/tEK/pFBJjOXlKTnp1b2H3ji8qcvP3lwde1Q9wR/71ki
z98+Y/q91rs9w8H9cM/pyOGVQw8Px46uh+zYz0TW/xv2/Cwxw0SC1RPHNz63cfSpk6eGgyHvP/D0
MyFffvLIp549ve/zB84894W9Z/ecWzu/9MWNL3GUhYaaKAOPfqJ//sKliy++IO04PXu2fvmlc/ns
0ucvX9ZmmL00n8lf+ePT+776yMsvXdl8Jb9w7KtfO73v7NLFl174kytfv3LkjGzUgz0G5w26f+N5
zvLN587lV/K5x76ifIDMjJfZjj519Fv9S9/+0xe2t468+tqVTXR7/fyuM0dO77v44rn8Rj77tSuv
c/BZGQgrMl7Yd3RdR37n1Ol9r+RXDnzl0stvvooRF7+7uub2pKvfw3a+zw0/9md/8ed/+ZawzY2L
rr+9q3++4csS+LIHfPnuD669kk/ve+MxbE2GwDTKPn54/dxj5Ah//9HD71x+FWs9d2bjr54/99iV
Z99RnQhQsygrfNb/NZv4Zkh4fOPH795YgbjdxslTIR9e2R8h80f4fflJPxx7b2N1bX8UJTCBYjFF
LPvSEYx6+yb+cwviv7Fy+ypn2TMsycdw7P0lKshJXR/LezNy9VlZEf/uf01U7e2bR9fxx3sTJ/uG
k89ifS6C/6yeOHnqiRdvQEFDBpmXP33y1MkFDNyHHjGIAsJBrMlGZddMbBHIZLf/Ria+sQKN/AmV
2C3dKRYUK7mc7OSpwys3VqTbgUFJZIfCzlbND3XHN376t+8vCTuHY+HNwyug94PVD9KR1bXh2KrY
I8a1FIVqIegpkyczY/Ot9dUT++Odm0888vbNkG+tH165/fgTC5m6/8Dq2o2Vo+vpuuwLJnpA2Pr2
zdW1Ww9gLYxcJPB3dw+LEiwNN29fpdyOrv/9yqFu9cRwcDLuHUx+EPf4F1esOKB/EG8BGYGD6LDn
zr0f/iOmVEbgfFkkGhXxyy+GfPvq7cfFZIoSDcODncv5XZj1xEjIm2D5c+NK9McPXAn/EzU6Ne5z
jfVjk//Zd6ijKofMLtzD6gm3sXri0MNVAfe2Cr9QMvfNsNlQhyvmA6mT2XIfd4oNfvQY7PIApPMU
tvuz1c0F2zAIuU3IC42e/K1e/Nb6rXWZ5t7qB/dPs8Pqh2NP36WScVX89xq3/cRDRX32/+RpVfGw
SMUPr1x+8hicCjsqgT3u/jNGUe9OnrqxQqV/+q6usmgF0+NY/YWW4MNvXaIwDz9ynaIqC+fHpeIX
mh5x0zQ7bYK/wAyLoJ9ZPLddJG/OfRD/NqTjYmwQRS3yMud3ibPlPrCHu7rauM7RpyhFORsdFGfN
I+ybpnE6TTpy/N4PXhfNLax4RjzXrfUb6iygxGDezmHocfzeP+2dfAbPdFUfUZ79B97eI56dU2I/
dA+04yZKWOPf27RGdvbPS/0+exB+5xh9ugQUHedD1w3ECm+e3/XFd7+koUXkXyVdZP1KDnWmjFxa
PXErw9VUn5vMQm0REyuMWmN+tVgLlGRvGWlSeOD5cfLUz0+Q6Pfu8QteYSldP9QVH33V7dF5Lfy9
cbkoIGZuulxTaxppoH8eu97XWYiVlcGiJuayjVvO/V6a9Hv/Il6dbgLasD7rD8FimRAe4BfEq6u4
oFM/K3wYolnEwVujoq15XK4a/lEGt6+qXoybeNwtLdjo/8MTOuNwv9xhBfe+9246UkzgZ+WIfei9
DZr2+4/bf734IiJExGeXL0voJ9vWQ7sIGIHNnbs0gD0LxPZLUHif1LhxdaKgbAPn7wkOnQb0Zr6l
xiL/ba+GQhvKOuwKSr36QdnV9fNHJFrNW7t0TzZUF/HL7+nZf3/t7NJp885/HOpoOxKrFJbDZ4YP
M33GCAzaeJgVxlcSL/3wmgbUZ547V44h+JH75QfXcPzet/9TYw2Ap2/qUVZOxk1yYDj4/vULl360
6/tLCN/LdPTnC6a7c/f4hpDW6HxxS+/dA2EH37/00/9iGI6IuoTEC+d5fw+dq4R6B9Wr7hTBjy+d
Xfr+Xkx07xtH9NIwzGcq3Dq6fnzjwrvlJNj47423cCd55aH7lcHx/3ZCpPI/8IVUaQZsbs+hh3lQ
XTv/KBzgpZdfknjoqngZjYc+zCHyiqbeuEZEz1T7oJil5dr5laJLuVyN+nEfO93C9969c/fOXfEp
d+6SHcLo/7358punzVubF187s+vnd8/vemvfO9d//lz/cN/1MmFcLCpY7rUfXDu75/TKW5s/eh1M
vF5Ye211bcEyyuJ+IY9hMdc+t3HFfPmlF7YvvviFS+NEJ+7cxERRJ8K+G9tbOJGo9nd8yFQZ1evq
+YaFwaOeAHpy2A/R8FEDninz+fSg+R6iZhxdb0+lpy4sn999fvf/AfwlSPZlbmRzdHJlYW0KZW5k
b2JqCjUgMCBvYmoKNjY0NQplbmRvYmoKMyAwIG9iago8PAovVHlwZSAvUGFnZQovTWVkaWFCb3gg
WzAgMCA2MTIgNzkyXQovUGFyZW50IDIgMCBSCi9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWy9QREYg
L0ltYWdlQiAvVGV4dF0KL0ZvbnQgPDwKL0EgNyAwIFIKPj4KPj4KL0NvbnRlbnRzIDQgMCBSCj4+
CmVuZG9iagoxNzcgMCBvYmoKPDwvTGVuZ3RoIDE3OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+
CnN0cmVhbQp4nK1XW08bVxCWojwgHvyQh0iRV2gX1UDWXnfvu8drO3Z94VouxQQQTkWgbZoolCIa
8tKUkDRxwEZYIm5R89BEbaQ0l7Zp+wM7c87ueo2XNFIRErZ3z8x8c/tmjpxUeBn/3M/Vtd6N3g1e
oc+8j9U1/qNK74d5XuErX/R6RyX8QsykyVuKmdT5ytrQpYuVG72azmt85bOhZiu3U5m/vLiwNtp/
+dNEsp4VpZRQLA/gIUkzecXQ8RwT0pjQPodC93puc1edicnpM7tH6awR359/tj7FjSr3qageKpnO
5gozPSl8pKoGL9GHD/CnYbATj1spYaB6MXaQLsFHkeqyDV4xDSp/Tu6PWfDCiKeE2KDGpbNapDki
HhbL9NtevTRwGLNMssvwQ3Q0QgVL6evyWIhooy8l1LNGJp2twefAmdggCB8xuyoBcZvhZgoSSZPE
DqgaiFTeiMMXe9v1yNK19/WImBq4RF9f+u0FPW2x07nt73tig6KkRYplUUokEZlJNI7KKaYVjMQ1
56Xz3ddq/Pk38oE8KGdeOs8Ld9uO277jS7fmN8ho/1S1OjFiZGIHYh4UlsV84qyrnrmrGj4o/RU+
sokLqrC8iEErltF9FwrUhqm7UObu7kyTm87KhaurU9x0WOyXnq1PX5iYvOl8FR7apeXNFYA4Xq0y
ccUkPphgBdWhgtS4xtkOBPP1eZpEiocgeNMLDdawmG+2BsLCMWZkhls1wc9Gd56p9h8EKJKSEfcj
pGjtc3d65P7qEJSSxkGS2JmIKNVJuuSDaxvQFQCndjnT2MLImqReSgmNLa1A5apDuphnRcmktdBW
0rhc4UmUnscqjA3CPy2CSMR8/TyiMDLwqLkXG4TuzAyzntOD9VMT8F1jS8zHDuh73bbdCn4VrGBQ
M9xiWAxL62wpsA41gcbT2WaLhkm31A4tZpcWy1ABh9L2yWUjk+R2bgEb3V58E3m4M7XpZnGPZVGH
LBpGl1BNyBU+ELAZqcOxA20EXTLiieQ+h3FoMtfNgOtzs3MLa1+uTx9SxssHGO9YpdBWb7YwHaIU
m6RphbDh02IZSQfT7iaZWtC68D1uQU9LINDYqgnYPzTcm0ZGpKShqWGkAVTks58czqWxA+wETyk2
MvKZ7aDrVLUqm4GWmFveHO2/d/ZKKD9g+66QBarewMkBb+5vLXwO7E6mIuNMxpaP9+w1iOLldej5
6sUrJzQI8imWJa1Oe6sDhK3yqkId+12R5z7oHx0btyYmP44ChUgz3CdHs8of58ajlUfI1ZRFzzxr
gR5RMjIpNwfUqmWDnu7Ai/lc4SENhKJ4Ma5WKduChFeT0L3rC2u318EUc98jcabLZcDRfnrmz/Fk
jtWieYxutIiLcZWOn1/FPKsP6AmuscV6Myz01AF/FFJwmuJ1A1TvNu0ByWcyW2lz9INOjr7xC5Qp
5au38acObQW3QkeQZJCoIGxseuGP4ZHlJXwMEwGSVG+zuk8QuwVGHgOH9ZJJEowirDCK8NhBDWkf
UbK3A/LKO+Qxqt0Ttxs5zaouQ+uYsuVuFneIHMUBVc+mhI6pKSnE8pLVUSCJZO5o1nGBqbYZBox2
1REOTHuH0jN449SzrpAlk5O9sQkGk3lzXY5qHEjjvjAPDA8tu+5rMVUljDB97pIs7GSXdbOoqxuJ
Dt15IhLL9DeoDgqxndzR00lcM1ICTCCfJy3ZA10sI4siagc50B+3bGa2EY0BbQMRrAxe4f76lk1w
VbFCjYIysBpNI8PtFoqsQXEdIp7RRJIOFCSydMnfTjoNRhFMow+rE/kgmG5V1joNu+kGNsodPYmi
Hz51EDuYov9rmE4Aq8swLNmw9YJidxXEEvYQqKoSRFATsNCR0r2JdNz8f2Okx3AEahxdgXDyBAhI
ISS0G/YjuQLunshZMHJxpXARaqeAkFntrga8Ecw6MFstQLpo0lLW1XfSddxdQEmQqEGG/tgguEZu
kPGfGVEbWkc9i/maUKOFnEh2pe/UI23669alv18EWztXuPXIdmwH+olr/kTXD4z327i/eNKLBRAF
ThZ/TY8EVm9yCiWjy0FH6HIj5nGjqLevKow8jdBbwXs5YZIau/+A/cyx+4Pdzgvcj6Cl9rlGH72j
QYLmcD8Fekv6y9YJ5POuijO7Kg5vEO8FHJbmvfYtgV0wTr9R0SubLpYSxeMyCQllkkZfrvDSeX3e
JFgRiSV3FX2r46wolpGS6lmaPIAfD15yVKOji2FNhOof2HtzHhVB1Ya6QEvaJLSo8d4IJk/wAqcE
5pDdKTGc/yAcFPEuaGpbBkc1vjDYzYXG23DbVeZVQo/9iA9KFX6md6b3X0tFJQBlbmRzdHJlYW0K
ZW5kb2JqCjE3OCAwIG9iagoxNzQ5CmVuZG9iagoxNzYgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL01l
ZGlhQm94IFswIDAgNjEyIDc5Ml0KL1BhcmVudCAyIDAgUgovUmVzb3VyY2VzIDw8IC9Qcm9jU2V0
IFsvUERGIC9JbWFnZUIgL1RleHRdCi9Gb250IDw8Ci9BIDcgMCBSCj4+Cj4+Ci9Db250ZW50cyAx
NzcgMCBSCj4+CmVuZG9iagoxOTMgMCBvYmoKPDwvTGVuZ3RoIDE5NCAwIFIvRmlsdGVyIC9GbGF0
ZURlY29kZT4+CnN0cmVhbQp4nIVX/28bZxmXkGVZ+cE/8EMl5FPli+K4tX23+/revbFjfNhO27R1
mzVlM3hamkaUVE27tqT7ZaOLV4jXJGpQMMoCUTX1BxgbMKSyFhhf5iZLV1jbUAaUMhjj27/B87zv
nXNOLqsi5ZK7557n83z5fN7nFFmNK/jjXo9PdJ3tOhtX2T3vcnwi/oXhriecuBof/kqXZyrhH6qm
yEbcUgn8PTyx68WI0p3L61Ez3VvbnUjqQsqZ2T18skvSDPBG9Pjw2K7P4w1dj7N/dKFQnGwkkokr
KWfP5RI+0jQDTA18mvus0p2RE0lwlnLM/lyeUJ2508GbbjOTcm5cGUw5mVBGBrPSQInHY07UjXgG
j0dooaildWFOYABzebM/JenRTKiXh0aUphd6WuwTE8lpkdDSQG9g3EBwGm0b5bkZmLwppaTZndPi
TB5RcmeExjWVRfuZqsQ0o1232i4DM8JKzp8302TJTM9Fe4/3dO8b3G8dqByMHRIOS0PCk4tH3n7p
1ZQEOaBD1TLtuMTS/Ab+bxKec8rx4EMHCITcWpaUUyiOXDuSTTm6MN/sE1PO/OXe8GSjR9TQzLaJ
65i/Rflbo/Tp/rO0vuPGCwXmnkLXVJPbGQyC7VoWij/MzrIK61oHRJM/h6ztrJ3Fy8URfGAoqj+i
oXK7w/RUth45eIbHsxUL4plbssnIkE31pniT39S3wT4B2CM3rt984aaL34Cp9PD7/dnZwtQ545jw
JXqM3bZNz+PEz/GGpXC752Nn6SnB9WWRQF+QYqH4zcZLr57IjvCe0E47lxgwAoWpnsHD9JAwyu5b
ZlBBoBix/bXaje5R6RdCPcLMpR83PQxAUNPYgmG+WZi6dPRUdlT9UfTS0a+yRgA/A9x7VTooHKiA
vcT9EtUKxDwnAGTxGbA9/eV9g1/kDQ6GHXomBlMcPUw5+DHXsaIEOs7lC8Vvvc0pair+AbLd0qek
jOwXAI2aQV2vR05X67WaG43q7fK8/gOG1nLH9eJQhBHxxSherJ8apYFc2a70Hp0GQSB0vplIIp1n
LzCKMvIRy6da4XpklG70Jkg7PgOP6pGn+SNqe0rwS1U5GsDz2unJhp3l8XL50oCZRgQ+1VEte3tm
VxMWV6k0l5Q+ERQBErtSiiHj7afsCkoYVxHV1oMoylTEky5Vs6x27TZT/QTISIaTnbqe3vB76hOn
L7KwU0w8IZl+QgEhL4WlBfIGOd0jeuoI9ldmd/qUWzLV7ahbvBRJWIT28ds0KDcuygNzAqGEYlHd
pkqGZgYyiLF4pIp1RPDQl/I7Eqtv2TsFPoXXcOLBtIb4tMYyMrwifEdE3d3UVE3pOI9409yhPMNG
PuQ78zYfTnYWEbGm6poV2FMJXFahW52ODJijTSeYOxyaYW5Tv/BWL5QEHsGgPuwINvvZCOKO4KaM
20I+l3/H6SyCBmgI8YqgR9tP0Z5m5Dm44v6QCXGXZ+AXDgahdpa1svlp9ekN13al2TxdQCAlHyFZ
338FRzNyz67kysgfiAsIZuh3YyxXGCwxYXHpeRwPX2syHn77cp/IIJrpmfKevZMN9qJlWkFkwSNx
6skGewNpzwZMYG8QJVBbn33r2HM3rv/krf0ylznVoNtz9eS1lJPLQ9XLcPCfx+pDELU0ABwVcfFJ
JE3mBLLajpVDEW48U87lGVq7QqArfeLsBTfLjvVI0/GoIYpFtnADyLo4UgU67WSvQllhBcIe+/Bc
4XhwUYOCbfaAvFw8eY13Hvq65zJLjO9PC75uhfl4cO3QVB16RtHBrwWle7KBsRh2dPPmju9TnFek
OjQ+P1PeJLwWvEyCGr749efAi9nPFEWYv9gzuK97f5LpepTpevEIqwgov0pYeBjL6rMDByr19iIJ
xeI0HFdirxT5EUg6BBrMQDINzbVDy+qpyvMQY5/6sitFeDZZgQPA6z0tsiHYOMyIDxFTqNkL3Ab7
srHl0ja46iGhHnrZLafRDrdpWBZxycWlG/oq4cAw1fTtzib2NXgyhiJYfxjIdGdPfZq4MRpbXbDR
8E5CyRX5pdQCqIC3QNuK8Zj9WYXPCvxIgLtPSL9hs6JHdQEPDfTCxv9ENsf4TNRgqcRkYYEAwZoW
54Q9PG0bVWNryXCIfpt9V2pVbmVXkqvye1fX0rfL711dld/fcaf5u8bvlz5orIbuNu859z+3Lq+H
/iA/GDsB9HtlEdVML+L4sYbC2g0HO3c5M66we5Aty2TZYfqWRe5DH3DTQq2ZKcOFw9PYMhs4QF/7
Y7GVvB/+sNGy/uS0ku//eT30F+dho5W821yL/jV8u7xmvLtwK/tB49YUA8pe1vG7EV+/lV0PPbLW
Xv+bsDLeSrKMossVJaTIyvgy7YC114OVb8NSibLd/r/w0T/+Hv64ebt8z2ldXzPWB3kVWYS9d5pr
aV611dCKdU96UNv9z9gnrCYG7PYM2b+ufiJ92FiV14yWtcyj6Sb1cAcXzIfMV7BNc7zw0dLdpX8b
UB5jZXxdvid93ORdXZfvNhApRA0hvvuhVahN6/qd5n+cR8m1dCv5sPHIejA2cp63z1ZUDvXcgOKW
A77/XIDwWeiwj8nlscdiJXpnFf2E4QX7b3NdXgEgD6EgK0kE27IeJR8452AR6w2PVMGUfearmmp3
HGLE++pedlCVE9Z8E5c2t6CqYXh4/wf7Q58IyxGbW0F3NwjQZWIzLn8P75SH40NdQ13/B2wrZepl
bmRzdHJlYW0KZW5kb2JqCjE5NCAwIG9iagoyMDM0CmVuZG9iagoxOTIgMCBvYmoKPDwKL1R5cGUg
L1BhZ2UKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1BhcmVudCAyIDAgUgovUmVzb3VyY2VzIDw8
IC9Qcm9jU2V0IFsvUERGIC9JbWFnZUIgL1RleHRdCi9Gb250IDw8Ci9BIDcgMCBSCj4+Cj4+Ci9D
b250ZW50cyAxOTMgMCBSCj4+CmVuZG9iago3IDAgb2JqCjw8L1R5cGUvRm9udC9OYW1lL0EvU3Vi
dHlwZS9UeXBlMy9FbmNvZGluZyA2IDAgUi9GaXJzdENoYXIgMC9MYXN0Q2hhciAyMzEvQ2hhclBy
b2NzPDwvYTIzMQoyNDUgMCBSL2EyMzAKMjQ0IDAgUi9hMjI5CjI0MyAwIFIvYTIyOAoyNDIgMCBS
L2EyMjcKMjQxIDAgUi9hMjI2CjI0MCAwIFIvYTIyNQoyMzkgMCBSL2EyMjQKMjM4IDAgUi9hMjIy
CjIzNiAwIFIvYTIyMQoyMzUgMCBSL2EyMjAKMjM0IDAgUi9hMjE5CjIzMyAwIFIvYTIxOAoyMzIg
MCBSL2EyMTcKMjMxIDAgUi9hMjE2CjIzMCAwIFIvYTIxNAoyMjggMCBSL2EyMTMKMjI3IDAgUi9h
MjEyCjIyNiAwIFIvYTIxMQoyMjUgMCBSL2EyMTAKMjI0IDAgUi9hMjA5CjIyMyAwIFIvYTIwOAoy
MjIgMCBSL2EyMDcKMjIxIDAgUi9hMjA2CjIyMCAwIFIvYTIwNQoyMTkgMCBSL2EyMDQKMjE4IDAg
Ui9hMjAzCjIxNyAwIFIvYTIwMgoyMTYgMCBSL2EyMDEKMjE1IDAgUi9hMjAwCjIxNCAwIFIvYTE5
OQoyMTMgMCBSL2ExOTgKMjEyIDAgUi9hMTk3CjIxMSAwIFIvYTE5NgoyMTAgMCBSL2ExOTUKMjA5
IDAgUi9hMTk0CjIwOCAwIFIvYTE5MwoyMDcgMCBSL2ExOTIKMjA2IDAgUi9hMTkxCjIwNSAwIFIv
YTE5MAoyMDQgMCBSL2ExODkKMjAzIDAgUi9hMTg4CjIwMiAwIFIvYTE4NwoyMDEgMCBSL2ExODYK
MjAwIDAgUi9hMTg1CjE5OSAwIFIvYTE4NAoxOTggMCBSL2ExODMKMTk3IDAgUi9hMTgxCjE5NSAw
IFIvYTE3OAoxODkgMCBSL2ExNzcKMTg4IDAgUi9hMTc1CjE4NiAwIFIvYTE3NAoxODUgMCBSL2Ex
NzMKMTg0IDAgUi9hMTcyCjE4MyAwIFIvYTE3MQoxODIgMCBSL2ExNzAKMTgxIDAgUi9hMTY4CjE3
OSAwIFIvYTE2NwoxNzUgMCBSL2ExNjYKMTc0IDAgUi9hMTY1CjE3MyAwIFIvYTE2MQoxNjkgMCBS
L2ExNjAKMTY4IDAgUi9hMTU3CjE2NSAwIFIvYTE1NgoxNjQgMCBSL2ExNTUKMTYzIDAgUi9hMTUx
CjE1OSAwIFIvYTE1MAoxNTggMCBSL2ExNDgKMTU2IDAgUi9hMTQ1CjE1MyAwIFIvYTE0NAoxNTIg
MCBSL2ExNDEKMTQ5IDAgUi9hMTQwCjE0OCAwIFIvYTEzOQoxNDcgMCBSL2ExMzcKMTQ1IDAgUi9h
MTM1CjE0MyAwIFIvYTEzNAoxNDIgMCBSL2ExMzMKMTQxIDAgUi9hMTMyCjE0MCAwIFIvYTEzMQox
MzkgMCBSL2ExMzAKMTM4IDAgUi9hMTI4CjEzNiAwIFIvYTEyNgoxMzQgMCBSL2ExMjUKMTMzIDAg
Ui9hMTIzCjEzMSAwIFIvYTEyMQoxMjkgMCBSL2ExMjAKMTI4IDAgUi9hMTE5CjEyNyAwIFIvYTEx
NwoxMjUgMCBSL2ExMTQKMTIyIDAgUi9hMTEzCjEyMSAwIFIvYTExMAoxMTggMCBSL2ExMDgKMTE2
IDAgUi9hMTA2CjExNCAwIFIvYTEwNAoxMTIgMCBSL2ExMDMKMTExIDAgUi9hOTgKMTA2IDAgUi9h
OTcKMTA1IDAgUi9hOTYKMTA0IDAgUi9hOTUKMTAzIDAgUi9hOTMKMTAxIDAgUi9hOTAKOTggMCBS
L2E4OAo5NiAwIFIvYTg2Cjk0IDAgUi9hODQKOTIgMCBSL2E4Mwo5MSAwIFIvYTgyCjkwIDAgUi9h
ODEKODkgMCBSL2E4MAo4OCAwIFIvYTc5Cjg3IDAgUi9hNzcKODUgMCBSL2E3Ngo4NCAwIFIvYTc1
CjgzIDAgUi9hNzMKODEgMCBSL2E3MQo3OSAwIFIvYTY4Cjc2IDAgUi9hNjYKNzQgMCBSL2E2NAo3
MiAwIFIvYTYzCjcxIDAgUi9hNjAKNjggMCBSL2E1OAo2NiAwIFIvYTU2CjY0IDAgUi9hNTQKNjIg
MCBSL2E1Mwo2MSAwIFIvYTUxCjU5IDAgUi9hNTAKNTggMCBSL2E0OAo1NiAwIFIvYTQ3CjU1IDAg
Ui9hNDQKNTIgMCBSL2E0Mgo1MCAwIFIvYTQwCjQ4IDAgUi9hMzgKNDYgMCBSL2EzNwo0NSAwIFIv
YTM2CjQ0IDAgUi9hMzUKNDMgMCBSL2EzMgo0MCAwIFIvYTMxCjM5IDAgUi9hMjkKMzcgMCBSL2Ey
NgozNCAwIFIvYTI0CjMyIDAgUi9hMjMKMzEgMCBSL2EyMQoyOSAwIFIvYTE5CjI3IDAgUi9hMTcK
MjUgMCBSL2ExNQoyMyAwIFIvYTEzCjIxIDAgUi9hMTEKMTkgMCBSL2E5CjE3IDAgUi9hNwoxNSAw
IFIvYTUKMTMgMCBSL2EzCjExIDAgUi9hMQo5IDAgUi9hMAo4IDAgUi9hMTAxCjEwOSAwIFIvYTE3
OQoxOTAgMCBSL2ExNjkKMTgwIDAgUi9hMjE1CjIyOSAwIFIvYTY5Cjc3IDAgUi9hNjIKNzAgMCBS
L2ExMDkKMTE3IDAgUi9hNjEKNjkgMCBSL2E0Mwo1MSAwIFIvYTUyCjYwIDAgUi9hMTc2CjE4NyAw
IFIvYTE4CjI2IDAgUi9hMTA1CjExMyAwIFIvYTU1CjYzIDAgUi9hMzkKNDcgMCBSL2ExNDMKMTUx
IDAgUi9hMTU5CjE2NyAwIFIvYTcwCjc4IDAgUi9hMjAKMjggMCBSL2E0Ngo1NCAwIFIvYTQKMTIg
MCBSL2EyNQozMyAwIFIvYTkyCjEwMCAwIFIvYTQxCjQ5IDAgUi9hMTAwCjEwOCAwIFIvYTY1Cjcz
IDAgUi9hNDUKNTMgMCBSL2EyMgozMCAwIFIvYTgKMTYgMCBSL2E1Nwo2NSAwIFIvYTE0OQoxNTcg
MCBSL2ExMzgKMTQ2IDAgUi9hMTQKMjIgMCBSL2EyOAozNiAwIFIvYTQ5CjU3IDAgUi9hMzMKNDEg
MCBSL2E1OQo2NyAwIFIvYTc4Cjg2IDAgUi9hMTExCjExOSAwIFIvYTE4MAoxOTEgMCBSL2ExMjQK
MTMyIDAgUi9hMjcKMzUgMCBSL2EzNAo0MiAwIFIvYTc0CjgyIDAgUi9hODUKOTMgMCBSL2E5MQo5
OSAwIFIvYTg5Cjk3IDAgUi9hNgoxNCAwIFIvYTIKMTAgMCBSL2ExNDcKMTU1IDAgUi9hOTkKMTA3
IDAgUi9hMTEyCjEyMCAwIFIvYTE1MwoxNjEgMCBSL2ExMzYKMTQ0IDAgUi9hMTE1CjEyMyAwIFIv
YTE1NAoxNjIgMCBSL2E3Mgo4MCAwIFIvYTE1MgoxNjAgMCBSL2E2Nwo3NSAwIFIvYTEyNwoxMzUg
MCBSL2ExMjkKMTM3IDAgUi9hODcKOTUgMCBSL2EzMAozOCAwIFIvYTExOAoxMjYgMCBSL2ExMAox
OCAwIFIvYTE4MgoxOTYgMCBSL2ExMTYKMTI0IDAgUi9hOTQKMTAyIDAgUi9hMTAyCjExMCAwIFIv
YTE2MwoxNzEgMCBSL2ExNgoyNCAwIFIvYTE0NgoxNTQgMCBSL2ExMDcKMTE1IDAgUi9hMjIzCjIz
NyAwIFIvYTE2NAoxNzIgMCBSL2ExNTgKMTY2IDAgUi9hMTYyCjE3MCAwIFIvYTE0MgoxNTAgMCBS
L2ExMjIKMTMwIDAgUi9hMTIKMjAgMCBSPj4vRm9udEJCb3hbMCAtNzcgMTE1IDExN10vRm9udE1h
dHJpeFsxIDAgMCAxIDAgMF0vV2lkdGhzWwowIDAgNzMgMCA0NSAwIDcyIDAgNTMgMCA4OSAwIDEy
MSAwIDU3IDAKOTcgMCAzNiAwIDQzIDAgNTIgMCAwIDQ2IDAgNjYgNTggMCA4NyAwCjAgNjAgNjcg
MCAwIDAgMCAzOSAwIDQ4IDAgMzMgMCA1MSA0NCAwCjAgNTkgMCAwIDM0IDAgMCAzOCAwIDU0IDAg
NjEgMCAzMiAyOSAwCjAgNTAgMCA4MyAwIDI4IDQyIDAgODEgMCA2OCAwIDAgMCA2MiAwCjAgMCAw
IDAgMCA2OSAwIDg2IDAgNzEgMCA3MCA0NyAwIDkyIDAKMCAwIDAgNzUgNDkgMjQgOTMgMCAwIDM3
IDAgMTAzIDAgMzEgMCA2Mwo3NiAwIDAgNzkgOTEgMCA4OCAwIDAgMCAxMTYgMCA2NSAwIDAgODQK
MCA4NSAwIDAgMCAwIDAgMCA3OCAwIDU2IDAgMCAwIDExMiA0MAowIDAgOTkgNzQgMCA1NSAwIDAg
ODIgNzcgODAgMCAwIDAgMTA4IDQxCjAgMCAxMTAgOTUgMTA3IDAgMCAwIDAgMjYgMCAwIDAgMCAw
IDAKMzUgMCAwIDI1IDY0IDAgOTAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDI3IDAgMCAwIDAgMCAwIDAgMTA1CjAgMCAwIDAg
MCAwIDAgMF0+PgplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwozIDAgUgox
NzYgMCBSCjE5MiAwIFIKXSAvQ291bnQgMwo+PgplbmRvYmoKMSAwIG9iago8PCAvVHlwZSAvQ2F0
YWxvZyAvUGFnZXMgMiAwIFIKPj4KZW5kb2JqCjI0NiAwIG9iago8PCAvQ3JlYXRpb25EYXRlIChE
OjE5OTkxMDEzMDcxMjIzKQovUHJvZHVjZXIgKEFsYWRkaW4gR2hvc3RzY3JpcHQgNS41MCkKPj4K
ZW5kb2JqCjYgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9EaWZmZXJlbmNlc1swCi9hMC9hMS9hMi9h
My9hNC9hNS9hNi9hNy9hOC9hOS9hMTAvYTExL2ExMi9hMTMvYTE0L2ExNQovYTE2L2ExNy9hMTgv
YTE5L2EyMC9hMjEvYTIyL2EyMy9hMjQvYTI1L2EyNi9hMjcvYTI4L2EyOS9hMzAvYTMxCi9hMzIv
YTMzL2EzNC9hMzUvYTM2L2EzNy9hMzgvYTM5L2E0MC9hNDEvYTQyL2E0My9hNDQvYTQ1L2E0Ni9h
NDcKL2E0OC9hNDkvYTUwL2E1MS9hNTIvYTUzL2E1NC9hNTUvYTU2L2E1Ny9hNTgvYTU5L2E2MC9h
NjEvYTYyL2E2MwovYTY0L2E2NS9hNjYvYTY3L2E2OC9hNjkvYTcwL2E3MS9hNzIvYTczL2E3NC9h
NzUvYTc2L2E3Ny9hNzgvYTc5Ci9hODAvYTgxL2E4Mi9hODMvYTg0L2E4NS9hODYvYTg3L2E4OC9h
ODkvYTkwL2E5MS9hOTIvYTkzL2E5NC9hOTUKL2E5Ni9hOTcvYTk4L2E5OS9hMTAwL2ExMDEvYTEw
Mi9hMTAzL2ExMDQvYTEwNS9hMTA2L2ExMDcvYTEwOC9hMTA5L2ExMTAvYTExMQovYTExMi9hMTEz
L2ExMTQvYTExNS9hMTE2L2ExMTcvYTExOC9hMTE5L2ExMjAvYTEyMS9hMTIyL2ExMjMvYTEyNC9h
MTI1L2ExMjYvYTEyNwovYTEyOC9hMTI5L2ExMzAvYTEzMS9hMTMyL2ExMzMvYTEzNC9hMTM1L2Ex
MzYvYTEzNy9hMTM4L2ExMzkvYTE0MC9hMTQxL2ExNDIvYTE0MwovYTE0NC9hMTQ1L2ExNDYvYTE0
Ny9hMTQ4L2ExNDkvYTE1MC9hMTUxL2ExNTIvYTE1My9hMTU0L2ExNTUvYTE1Ni9hMTU3L2ExNTgv
YTE1OQovYTE2MC9hMTYxL2ExNjIvYTE2My9hMTY0L2ExNjUvYTE2Ni9hMTY3L2ExNjgvYTE2OS9h
MTcwL2ExNzEvYTE3Mi9hMTczL2ExNzQvYTE3NQovYTE3Ni9hMTc3L2ExNzgvYTE3OS9hMTgwL2Ex
ODEvYTE4Mi9hMTgzL2ExODQvYTE4NS9hMTg2L2ExODcvYTE4OC9hMTg5L2ExOTAvYTE5MQovYTE5
Mi9hMTkzL2ExOTQvYTE5NS9hMTk2L2ExOTcvYTE5OC9hMTk5L2EyMDAvYTIwMS9hMjAyL2EyMDMv
YTIwNC9hMjA1L2EyMDYvYTIwNwovYTIwOC9hMjA5L2EyMTAvYTIxMS9hMjEyL2EyMTMvYTIxNC9h
MjE1L2EyMTYvYTIxNy9hMjE4L2EyMTkvYTIyMC9hMjIxL2EyMjIvYTIyMwovYTIyNC9hMjI1L2Ey
MjYvYTIyNy9hMjI4L2EyMjkvYTIzMC9hMjMxL2EyMzIvYTIzMy9hMjM0L2EyMzUvYTIzNi9hMjM3
L2EyMzgvYTIzOQovYTI0MC9hMjQxL2EyNDIvYTI0My9hMjQ0L2EyNDUvYTI0Ni9hMjQ3L2EyNDgv
YTI0OS9hMjUwL2EyNTEvYTI1Mi9hMjUzL2EyNTQvYTI1NQpdID4+CmVuZG9iago4IDAgb2JqCjw8
L0xlbmd0aCAyMjkgPj4Kc3RyZWFtCjAgMCAwIDAgNzMgODMgZDEKNzMgMCAwIDgzIDAgMCBjbQpC
SQovSU0gdHJ1ZS9XIDczL0ggODMvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDczCi9C
bGFja0lzMSB0cnVlCj4+CklEICajJaDfKkDEg4JsHs1g4eygG78G92/Dft+3/7fv9/+/3//////r
//r1/9L1+vS9L0vCXpeEuawoXEFwXB8Pk4Z34N+G/b9v3+/f7/9//v///////1+v/X69fr19L0tU
vCXhLQMJaELCCyMF5KwLgAgAgApFSQplbmRzdHJlYW0KZW5kb2JqCjkgMCBvYmoKPDwvTGVuZ3Ro
IDE3OSA+PgpzdHJlYW0KMCAwIDAgMjcgNDkgODMgZDEKNDkgMCAwIDU2IDAgMjcgY20KQkkKL0lN
IHRydWUvVyA0OS9IIDU2L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0OQovQmxhY2tJ
czEgdHJ1ZQo+PgpJRCAmoyBh/kOMwwutr+v///////////////////+/7/sgl8EVAT/T9tdbTqww
sjGMf4d4drB3w7WDtYcMKACACApFSQplbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCjw8L0xlbmd0
aCAxNj4+CnN0cmVhbQo3MyAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxMSAwIG9iago8
PC9MZW5ndGggMTk4ID4+CnN0cmVhbQowIDAgMCAyNyA3NCA4NCBkMQo3NCAwIDAgNTcgMCAyNyBj
bQpCSQovSU0gdHJ1ZS9XIDc0L0ggNTcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDc0
Ci9CbGFja0lzMSB0cnVlCj4+CklEICahlEgMHgxBBw9BweEHB6cPuD0HDo6hHOkuEG6HSDddBv6Y
r31foP////////////////////////////////////66rquFC5IQQYL/wAQAQApFSQplbmRzdHJl
YW0KZW5kb2JqCjEyIDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo0NSAwIDAgMCAwIDAgZDEK
ZW5kc3RyZWFtCmVuZG9iagoxMyAwIG9iago8PC9MZW5ndGggMTk3ID4+CnN0cmVhbQowIDAgMCAy
NyA1MyA4NSBkMQo1MyAwIDAgNTggMCAyNyBjbQpCSQovSU0gdHJ1ZS9XIDUzL0ggNTgvQlBDIDEv
Ri9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDUzCi9CbGFja0lzMSB0cnVlCj4+CklEICagXIYLwgeE
8IPT09PT09eawr0ED9N6T9N6T9N++l+3r766/D1///X//7//7kMyPBB7af/p7fv/W2u3/W2uw620
sMMILYrDCwwsGTguACACCkVJCmVuZHN0cmVhbQplbmRvYmoKMTQgMCBvYmoKPDwvTGVuZ3RoIDE2
Pj4Kc3RyZWFtCjcyIDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjE1IDAgb2JqCjw8L0xl
bmd0aCAyMDEgPj4Kc3RyZWFtCjAgMCAwIDI3IDU4IDg1IGQxCjU4IDAgMCA1OCAwIDI3IGNtCkJJ
Ci9JTSB0cnVlL1cgNTgvSCA1OC9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTgKL0Js
YWNrSXMxIHRydWUKPj4KSUQgJqGWQwIkFAzCDwg9PQenp6euiIBHoEG+EG9J+m9BP/03pP1+3rqD
1/X//X//78qYb/3z4Zf1v/7aX+/3W2u6W3W2ltpbDS2DCWGKwwsMLBgoAIAICkVJCmVuZHN0cmVh
bQplbmRvYmoKMTYgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjUzIDAgMCAwIDAgMCBkMQpl
bmRzdHJlYW0KZW5kb2JqCjE3IDAgb2JqCjw8L0xlbmd0aCAyNzMgPj4Kc3RyZWFtCjAgMCAwIDEg
MTE1IDg1IGQxCjExNSAwIDAgODQgMCAxIGNtCkJJCi9JTSB0cnVlL1cgMTE1L0ggODQvQlBDIDEv
Ri9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDExNQovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmpEDDQYDR
/yFEKQME8hgiyGYn2la2ra/fdOuv9N//0//9P//T//0//+SE/1f+r/V/6v9X/r/Vv+v9b/p/1v+n
/7/Sf/v9X/q/1f+r/V/6v9X/q/1f+r//9Jv//0m///V/6v9X/q/1f+r/V/6v9X/q/9/0r//9Jv//
1b/r/Vv+v42Pr9+v369X6v30vW8K3kaiHqyoDfWACACACkVJCmVuZHN0cmVhbQplbmRvYmoKMTgg
MCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjg5IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5k
b2JqCjE5IDAgb2JqCjw8L0xlbmd0aCAyMDMgPj4Kc3RyZWFtCjAgMCAwIDI3IDU4IDg1IGQxCjU4
IDAgMCA1OCAwIDI3IGNtCkJJCi9JTSB0cnVlL1cgNTgvSCA1OC9CUEMgMS9GL0NDRi9EUDw8L0sg
LTEKL0NvbHVtbnMgNTgKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqGg6gohA8ED0HhEMK9BBh6CDek3
pN6t6V6Tf+lft6X96X7ev/1f8f/a///Xk1X/69d/67Xf9Lf20vrddtLbS+tsJYbS2GgthglhiFhh
YYWQUEQAQAQKRUkKZW5kc3RyZWFtCmVuZG9iagoyMCAwIG9iago8PC9MZW5ndGggMTc+PgpzdHJl
YW0KMTIxIDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjIxIDAgb2JqCjw8L0xlbmd0aCAy
MzQgPj4Kc3RyZWFtCjAgMCAwIDI3IDEwOCA4MyBkMQoxMDggMCAwIDU2IDAgMjcgY20KQkkKL0lN
IHRydWUvVyAxMDgvSCA1Ni9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgMTA4Ci9CbGFj
a0lzMSB0cnVlCj4+CklEICakQMiBl/yFGEGBBBcRhoMIMLpprar6drf/////////////////////
/////////////////////////tNe4dcNENP5Qntrqw1Yfqw0mGlkoUMMKwwvGxTFYdprB2msOGms
HaDWDhhBhYcGEGFABABACkVJCmVuZHN0cmVhbQplbmRvYmoKMjIgMCBvYmoKPDwvTGVuZ3RoIDE2
Pj4Kc3RyZWFtCjU3IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjIzIDAgb2JqCjw8L0xl
bmd0aCAxOTIgPj4Kc3RyZWFtCjAgMCAwIDAgMzIgMTE3IGQxCjMyIDAgMCAxMTcgMCAwIGNtCkJJ
Ci9JTSB0cnVlL1cgMzIvSCAxMTcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDMyCi9C
bGFja0lzMSB0cnVlCj4+CklEICahTMEhA9Ph6KJ9P7fV9PvfXtXj/3///f//////////////////
/////////9fIEaXvD3h4eHg/////+QL5p6f91v/9b9bUAEAECkVJCmVuZHN0cmVhbQplbmRvYmoK
MjQgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjk3IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0K
ZW5kb2JqCjI1IDAgb2JqCjw8L0xlbmd0aCAxNzUgPj4Kc3RyZWFtCjAgMCAwIDAgMzcgODMgZDEK
MzcgMCAwIDgzIDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDM3L0ggODMvQlBDIDEvRi9DQ0YvRFA8PC9L
IC0xCi9Db2x1bW5zIDM3Ci9CbGFja0lzMSB0cnVlCj4+CklEICaj+Q4zYW1+1///////////////
/////////+v5G68e+D4Pg+HwfH////8gx+E9B66f/+/7XW1hhQAQAQpFSQplbmRzdHJlYW0KZW5k
b2JqCjI2IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQozNiAwIDAgMCAwIDAgZDEKZW5kc3Ry
ZWFtCmVuZG9iagoyNyAwIG9iago8PC9MZW5ndGggMjEzID4+CnN0cmVhbQowIDAgMCAyNyA1MyA4
NCBkMQo1MyAwIDAgNTcgMCAyNyBjbQpCSQovSU0gdHJ1ZS9XIDUzL0ggNTcvQlBDIDEvRi9DQ0Yv
RFA8PC9LIC0xCi9Db2x1bW5zIDUzCi9CbGFja0lzMSB0cnVlCj4+CklEICailAMGYkINB6DTwg09
OH2ug750FchzigboPQY3pp0Hd/r+TVf//f79/b9v2/b9h+GH4Yfhh+GH4YPwYPwx4Pg+D/l96+n/
9////rv+lv9pbDS2GEsMVhrDBZBfWACACApFSQplbmRzdHJlYW0KZW5kb2JqCjI4IDAgb2JqCjw8
L0xlbmd0aCAxNj4+CnN0cmVhbQo0MyAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoyOSAw
IG9iago8PC9MZW5ndGggMTk2ID4+CnN0cmVhbQowIDAgMCAyNyA3MyA4MyBkMQo3MyAwIDAgNTYg
MCAyNyBjbQpCSQovSU0gdHJ1ZS9XIDczL0ggNTYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1
bW5zIDczCi9CbGFja0lzMSB0cnVlCj4+CklEICamQMfvIQYQ0J8MJhbTX+01////////////////
//////////////////2vf3Xa8oQfq2vsNLJuoYMLxsVh2sO1g4awcNYOGFhwwoAIAIAKRUkKZW5k
c3RyZWFtCmVuZG9iagozMCAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KNTIgMCAwIDAgMCAw
IGQxCmVuZHN0cmVhbQplbmRvYmoKMzEgMCBvYmoKPDwvTGVuZ3RoIDI1MSA+PgpzdHJlYW0KMCAw
IDAgMCA5NiA4NyBkMQo5NiAwIDAgODcgMCAwIGNtCkJJCi9JTSB0cnVlL1cgOTYvSCA4Ny9CUEMg
MS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgOTYKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqDaU4as
hqk8EDwgeEdAwHhAgYeEEGHoIN4QTD0m9IN6TD0m9K9W9Jvr1b0m/vSfW/vSf70n+/9fpv/X+//f
r1/v/////////+9evf//vX/rt1/vXa/W/tpf7pd1uu3W6XaW3W6W2ltpYbS20thhLbQWGGEsMMIL
DBkE0wxCwwsGCyCpVABABApFSQplbmRzdHJlYW0KZW5kb2JqCjMyIDAgb2JqCjw8L0xlbmd0aCAx
NzcgPj4Kc3RyZWFtCjAgMCAwIDkgNDIgODQgZDEKNDIgMCAwIDc1IDAgOSBjbQpCSQovSU0gdHJ1
ZS9XIDQyL0ggNzUvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQyCi9CbGFja0lzMSB0
cnVlCj4+CklEICagoJxIQeg9PT175DJ6T9N8H0///////////////////////////kYl/74ZrDEP
vvvvvvvv++/7/v/wAQAQCkVJCmVuZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKPDwvTGVuZ3RoIDE2
Pj4Kc3RyZWFtCjQ2IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjM0IDAgb2JqCjw8L0xl
bmd0aCAyMjcgPj4Kc3RyZWFtCjAgMCAwIC00IDY1IDg0IGQxCjY1IDAgMCA4OCAwIC00IGNtCkJJ
Ci9JTSB0cnVlL1cgNjUvSCA4OC9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNjUKL0Js
YWNrSXMxIHRydWUKPj4KSUQgJqGUdQLyDcHggeCDwjWFeECDD0m+EG+m+Fft+39+37/f/t//f/t/
///f/////X///6X//r9ev12vDXtLtLlCDX2wl8GEvYr2vDXte14YXhheDMw0cf///////////9fz
QF0PB8Pg+D4fB4AIAIAKRUkKZW5kc3RyZWFtCmVuZG9iagozNSAwIG9iago8PC9MZW5ndGggMTY+
PgpzdHJlYW0KNjYgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMzYgMCBvYmoKPDwvTGVu
Z3RoIDE2Pj4Kc3RyZWFtCjU4IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjM3IDAgb2Jq
Cjw8L0xlbmd0aCAxNzYgPj4Kc3RyZWFtCjAgMCAwIDAgNDYgODEgZDEKNDYgMCAwIDgxIDAgMCBj
bQpCSQovSU0gdHJ1ZS9XIDQ2L0ggODEvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQ2
Ci9CbGFja0lzMSB0cnVlCj4+CklEICan8ghMEsGCHDXW/X//////////////////////////////
/////////+v65fLx4Pg+D4fB8HwfB4AIAIAKRUkKZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iago8
PC9MZW5ndGggMTY+PgpzdHJlYW0KODcgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMzkg
MCBvYmoKPDwvTGVuZ3RoIDIzMSA+PgpzdHJlYW0KMCAwIDAgMCA1OSA4NSBkMQo1OSAwIDAgODUg
MCAwIGNtCkJJCi9JTSB0cnVlL1cgNTkvSCA4NS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVt
bnMgNTkKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqFIgMyEUgKKB6B6D5Lih81hh8EGHsEG8GYBoeLe
3t97f7f9//f//r6+vrWlrpYXCWFyDQryDcb6wayGaXwawwsMLYWG9vb729vvvb/v+/7/XI4/9te/
Ya9pba7DS2GF5IEWxW1hra2FhhYMFgygG4AIAIAKRUkKZW5kc3RyZWFtCmVuZG9iago0MCAwIG9i
ago8PC9MZW5ndGggMTU5ID4+CnN0cmVhbQowIDAgMCA2OCAzMCAxMDEgZDEKMzAgMCAwIDMzIDAg
NjggY20KQkkKL0lNIHRydWUvVyAzMC9IIDMzL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1u
cyAzMAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmpGw0YPDDwYPDDw3sPDe3t97e/e/9/yEmsIda6/+u
tra6wwsMFABABApFSQplbmRzdHJlYW0KZW5kb2JqCjQxIDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0
cmVhbQo2MCAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago0MiAwIG9iago8PC9MZW5ndGgg
MTY+PgpzdHJlYW0KNjcgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKNDMgMCBvYmoKPDwv
TGVuZ3RoIDIzNiA+PgpzdHJlYW0KMCAwIDAgMCA1OSA4NSBkMQo1OSAwIDAgODUgMCAwIGNtCkJJ
Ci9JTSB0cnVlL1cgNTkvSCA4NS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTkKL0Js
YWNrSXMxIHRydWUKPj4KSUQgJqKSA181BpyDFMMHgw8N7Dww9vbw3sPb2+9vb32+9v9vb/b7/b/f
IF6XkNFfhBt4QfoP0GUjRqEHoIH0EDek+kH69fq/0v+ur/1///X/1//v+v1/v/Xrt1/ul/tpf7aW
6Xdba7aW2lthBbBhLDFbCwYWDNAUAAgAgApFSQplbmRzdHJlYW0KZW5kb2JqCjQ0IDAgb2JqCjw8
L0xlbmd0aCAxOTEgPj4Kc3RyZWFtCjAgMCAwIDAgNTkgNjkgZDEKNTkgMCAwIDY5IDAgMCBjbQpC
SQovSU0gdHJ1ZS9XIDU5L0ggNjkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU5Ci9C
bGFja0lzMSB0cnVlCj4+CklEICaxGwL/IRPhhbX7X////////////////k9OJTh8PkMIHwQb8N+3
7ft+/37/f/v9/////9f+vX6/9L0vS9LVL0Fo1jWhBYILMKwAQAQKRUkKZW5kc3RyZWFtCmVuZG9i
ago0NSAwIG9iago8PC9MZW5ndGggMTcyID4+CnN0cmVhbQowIDAgMCAyMiAzOCA2OSBkMQozOCAw
IDAgNDcgMCAyMiBjbQpCSQovSU0gdHJ1ZS9XIDM4L0ggNDcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0x
Ci9Db2x1bW5zIDM4Ci9CbGFja0lzMSB0cnVlCj4+CklEICaxVhIMLDOgL2tr+v//////////////
//77/shL4Ip0/tPtrWGFmqY7vDvDvB2sO1g4YUAEAEAKRUkKZW5kc3RyZWFtCmVuZG9iago0NiAw
IG9iago8PC9MZW5ndGggMTkxID4+CnN0cmVhbQowIDAgMCAyMiA0NiA3MSBkMQo0NiAwIDAgNDkg
MCAyMiBjbQpCSQovSU0gdHJ1ZS9XIDQ2L0ggNDkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1
bW5zIDQ2Ci9CbGFja0lzMSB0cnVlCj4+CklEICahsNAXggeCD08IPT09PmoR6BB9BBvpvSfp9Jvr
9+rpPw/1//1//vyVBv/ZwFH1/v9rvXfultpbdbaWwwlsMJYYhYYWQb0gAgAgCkVJCmVuZHN0cmVh
bQplbmRvYmoKNDcgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjM5IDAgMCAwIDAgMCBkMQpl
bmRzdHJlYW0KZW5kb2JqCjQ4IDAgb2JqCjw8L0xlbmd0aCAxNzggPj4Kc3RyZWFtCjAgMCAwIC00
IDM1IDY5IGQxCjM1IDAgMCA3MyAwIC00IGNtCkJJCi9JTSB0cnVlL1cgMzUvSCA3My9CUEMgMS9G
L0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgMzUKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrEGE+RkYa63
/////////////////////////8wT/yE///////9/8g7+nun1v9bfdLtdtLDFbCwwoAIAIApFSQpl
bmRzdHJlYW0KZW5kb2JqCjQ5IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo0OCAwIDAgMCAw
IDAgZDEKZW5kc3RyZWFtCmVuZG9iago1MCAwIG9iago8PC9MZW5ndGggMjAwID4+CnN0cmVhbQow
IDAgMCAyMiA0OCA3MCBkMQo0OCAwIDAgNDggMCAyMiBjbQpCSQovSU0gdHJ1ZS9XIDQ4L0ggNDgv
QlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQ4Ci9CbGFja0lzMSB0cnVlCj4+CklEICah
zMHPCwQaB6DTwnfDT075IG5PdBBjDeg0/d6D/9f+//v9+/t+37D8N+w/DB+GH4YPwY8HwfD75H3r
9/////rvXa7dbYXYYQWGKwwsgQiACACACkVJCmVuZHN0cmVhbQplbmRvYmoKNTEgMCBvYmoKPDwv
TGVuZ3RoIDE2Pj4Kc3RyZWFtCjMzIDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjUyIDAg
b2JqCjw8L0xlbmd0aCAxODYgPj4Kc3RyZWFtCjAgMCAwIDIyIDQyIDcxIGQxCjQyIDAgMCA0OSAw
IDIyIGNtCkJJCi9JTSB0cnVlL1cgNDIvSCA0OS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVt
bnMgNDIKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqGc0B4IHhPQenp6eujqN8IG9BP0G9J/vSfp/vT/
r6D///X//7//kG97oPtd0/9v+ttd/brbS2GlsNLYhYYWDMwcAEAECkVJCmVuZHN0cmVhbQplbmRv
YmoKNTMgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjUxIDAgMCAwIDAgMCBkMQplbmRzdHJl
YW0KZW5kb2JqCjU0IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo0NCAwIDAgMCAwIDAgZDEK
ZW5kc3RyZWFtCmVuZG9iago1NSAwIG9iago8PC9MZW5ndGggMTY1ID4+CnN0cmVhbQowIDAgMCAw
IDQzIDY3IGQxCjQzIDAgMCA2NyAwIDAgY20KQkkKL0lNIHRydWUvVyA0My9IIDY3L0JQQyAxL0Yv
Q0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0MwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmonyBFW11tf//
//////////////////////////////+v65H64Y8HwfB8HwfB4AIAIApFSQplbmRzdHJlYW0KZW5k
b2JqCjU2IDAgb2JqCjw8L0xlbmd0aCAxMzIgPj4Kc3RyZWFtCjAgMCAwIDU4IDEyIDcwIGQxCjEy
IDAgMCAxMiAwIDU4IGNtCkJJCi9JTSB0cnVlL1cgMTIvSCAxMi9CUEMgMS9GL0NDRi9EUDw8L0sg
LTEKL0NvbHVtbnMgMTIKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrHHCD7jvyapbW1ABABACkVJCmVu
ZHN0cmVhbQplbmRvYmoKNTcgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjU5IDAgMCAwIDAg
MCBkMQplbmRzdHJlYW0KZW5kb2JqCjU4IDAgb2JqCjw8L0xlbmd0aCAxNjEgPj4Kc3RyZWFtCjAg
MCAwIDAgMzMgNjkgZDEKMzMgMCAwIDY5IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDMzL0ggNjkvQlBD
IDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDMzCi9CbGFja0lzMSB0cnVlCj4+CklEICa3yJXh
hbX7X/////////////////////////////////////p/p4QeYD4AIAIKRUkKZW5kc3RyZWFtCmVu
ZG9iago1OSAwIG9iago8PC9MZW5ndGggMTg1ID4+CnN0cmVhbQowIDAgMCAyMiA1OCA2OSBkMQo1
OCAwIDAgNDcgMCAyMiBjbQpCSQovSU0gdHJ1ZS9XIDU4L0ggNDcvQlBDIDEvRi9DQ0YvRFA8PC9L
IC0xCi9Db2x1bW5zIDU4Ci9CbGFja0lzMSB0cnVlCj4+CklEICa5Vl5CF5HqGdDsJrdrqv//////
//////////////////////+GvdcEVC+w/VtLO6sGF42Kw74OGsHaw4YWDgwUAEAECkVJCmVuZHN0
cmVhbQplbmRvYmoKNjAgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjM0IDAgMCAwIDAgMCBk
MQplbmRzdHJlYW0KZW5kb2JqCjYxIDAgb2JqCjw8L0xlbmd0aCAxNjkgPj4Kc3RyZWFtCjAgMCAw
IDcgMzMgNzAgZDEKMzMgMCAwIDYzIDAgNyBjbQpCSQovSU0gdHJ1ZS9XIDMzL0ggNjMvQlBDIDEv
Ri9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDMzCi9CbGFja0lzMSB0cnVlCj4+CklEICagwZiwg9PT
0++Tm9IP7egf//////////////////////zGPw+GQwS+++++++/7/v+/wAQAQApFSQplbmRzdHJl
YW0KZW5kb2JqCjYyIDAgb2JqCjw8L0xlbmd0aCAxOTQgPj4Kc3RyZWFtCjAgMCAwIDIyIDUyIDcx
IGQxCjUyIDAgMCA0OSAwIDIyIGNtCkJJCi9JTSB0cnVlL1cgNTIvSCA0OS9CUEMgMS9GL0NDRi9E
UDw8L0sgLTEKL0NvbHVtbnMgNTIKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqDcnDRBGsF4QeEUDD0E
DD0E3pN6Telerel+3pX/pX76/V/6//3r////9b//Xrv91uv1v7aXpbfultpbaCwwwlsMJYYhYYLI
F6QAQAQKRUkKZW5kc3RyZWFtCmVuZG9iago2MyAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0K
MzggMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKNjQgMCBvYmoKPDwvTGVuZ3RoIDIxNiA+
PgpzdHJlYW0KMCAwIDAgLTQgNTkgNzAgZDEKNTkgMCAwIDc0IDAgLTQgY20KQkkKL0lNIHRydWUv
VyA1OS9IIDc0L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1OQovQmxhY2tJczEgdHJ1
ZQo+PgpJRCAmobCcIcBIIHDwnB4QcHpwenDo6iuUGtBAxjpNaCfoPr9fXr9f+v1///9f////+///
/t/+//t/rt+/2u2u2u2uGGuwwj64YrwwvBgvH/////////9f1yDWn3wfD4Ph8HgAgAgKRUkKZW5k
c3RyZWFtCmVuZG9iago2NSAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KNTQgMCAwIDAgMCAw
IGQxCmVuZHN0cmVhbQplbmRvYmoKNjYgMCBvYmoKPDwvTGVuZ3RoIDE4NiA+PgpzdHJlYW0KMCAw
IDAgMjIgNTkgNzAgZDEKNTkgMCAwIDQ4IDAgMjIgY20KQkkKL0lNIHRydWUvVyA1OS9IIDQ4L0JQ
QyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1OQovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoZyc
ENgkIODwg4PQcPTg+4dEgVyi0EDDoHoN/sV0+ofp//////////////////////////////9V9cKF
zVEMV/wAQAQKRUkKZW5kc3RyZWFtCmVuZG9iago2NyAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJl
YW0KNjEgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKNjggMCBvYmoKPDwvTGVuZ3RoIDE2
NyA+PgpzdHJlYW0KMCAwIDAgMCAyOCA2OSBkMQoyOCAwIDAgNjkgMCAwIGNtCkJJCi9JTSB0cnVl
L1cgMjgvSCA2OS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgMjgKL0JsYWNrSXMxIHRy
dWUKPj4KSUQgJrZGXhnQ7XW////////////////////+v5h148Pg+HwfB8f///8hZ4T17//362sM
KACACApFSQplbmRzdHJlYW0KZW5kb2JqCjY5IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQoz
MiAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago3MCAwIG9iago8PC9MZW5ndGggMTY+Pgpz
dHJlYW0KMjkgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKNzEgMCBvYmoKPDwvTGVuZ3Ro
IDE4NyA+PgpzdHJlYW0KMCAwIDAgMCAzMSA5MyBkMQozMSAwIDAgOTMgMCAwIGNtCkJJCi9JTSB0
cnVlL1cgMzEvSCA5My9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgMzEKL0JsYWNrSXMx
IHRydWUKPj4KSUQgJqGbpYS0tLXS0tLS1610utdL9etf61/S//1/r9f//1///////////f///37/
9//b/f+9/2/32/29vfvb329vb28N7e2ACACACkVJCmVuZHN0cmVhbQplbmRvYmoKNzIgMCBvYmoK
PDwvTGVuZ3RoIDE4OCA+PgpzdHJlYW0KMCAwIDAgLTMgMjggOTAgZDEKMjggMCAwIDkzIDAgLTMg
Y20KQkkKL0lNIHRydWUvVyAyOC9IIDkzL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAy
OAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmrLg3t7D29vYe3t797e33v3v33v3+/f97//f/+3///9//
//////6///+v1/r/0v/S/rXrXr9LS/S60tetLS0FpaWgoAIAIApFSQplbmRzdHJlYW0KZW5kb2Jq
CjczIDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo1MCAwIDAgMCAwIDAgZDEKZW5kc3RyZWFt
CmVuZG9iago3NCAwIG9iago8PC9MZW5ndGggMTkzID4+CnN0cmVhbQowIDAgMCAwIDgyIDY5IGQx
CjgyIDAgMCA2OSAwIDAgY20KQkkKL0lNIHRydWUvVyA4Mi9IIDY5L0JQQyAxL0YvQ0NGL0RQPDwv
SyAtMQovQ29sdW1ucyA4MgovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmsRsMfyETkM1PhhBhbTX+01//
////////////////////////x//Jw1f/////////////////////////+mn66aeEGEHmGyGBv4AI
AIAKRUkKZW5kc3RyZWFtCmVuZG9iago3NSAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KODMg
MCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKNzYgMCBvYmoKPDwvTGVuZ3RoIDE5NiA+Pgpz
dHJlYW0KMCAwIDAgMjIgNDAgNzEgZDEKNDAgMCAwIDQ5IDAgMjIgY20KQkkKL0lNIHRydWUvVyA0
MC9IIDQ5L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0MAovQmxhY2tJczEgdHJ1ZQo+
PgpJRCAmrLhCgExOomH3yQFfBBh9Pwm+r6/+r0v+vWK1hLC4SwSwlhLCWEFoLQLQWgXC4WguiGcf
hL1/9L/uv+2vrtrsMLsGWHseGU64MzCYAIAICkVJCmVuZHN0cmVhbQplbmRvYmoKNzcgMCBvYmoK
PDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjI4IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjc4
IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo0MiAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVu
ZG9iago3OSAwIG9iago8PC9MZW5ndGggMjA0ID4+CnN0cmVhbQowIDAgMCAyMyA1NSA5NyBkMQo1
NSAwIDAgNzQgMCAyMyBjbQpCSQovSU0gdHJ1ZS9XIDU1L0ggNzQvQlBDIDEvRi9DQ0YvRFA8PC9L
IC0xCi9Db2x1bW5zIDU1Ci9CbGFja0lzMSB0cnVlCj4+CklEICaiHgbIQeg9PvvvvvfvZmb2EHxf
b/b/fvfv9+9/0/0/17171/T5Out9Pr9Xq/V6v16376V++l+3pf3pP96T/6V++lfvpf3q/V6/3r63
hNB4RUA4fwAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjgwIDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0
cmVhbQo4MSAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago4MSAwIG9iago8PC9MZW5ndGgg
MjEwID4+CnN0cmVhbQowIDAgMCAxMiA1OSA3MSBkMQo1OSAwIDAgNTkgMCAxMiBjbQpCSQovSU0g
dHJ1ZS9XIDU5L0ggNTkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU5Ci9CbGFja0lz
MSB0cnVlCj4+CklEICahlHAzJDRXhA8ESGHo0BA8IIMPQQb0mHhJvSb6b1b0vSb+9J/vX6b/1v/3
647/////Jqtdr//vX+2l/vXa712lv7aW2lultpbaWw0sNhBYYMEFhiFhhZAuRABABApFSQplbmRz
dHJlYW0KZW5kb2JqCjgyIDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo2OCAwIDAgMCAwIDAg
ZDEKZW5kc3RyZWFtCmVuZG9iago4MyAwIG9iago8PC9MZW5ndGggMjA5ID4+CnN0cmVhbQowIDAg
MCAxMiAzOCA3MSBkMQozOCAwIDAgNTkgMCAxMiBjbQpCSQovSU0gdHJ1ZS9XIDM4L0ggNTkvQlBD
IDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDM4Ci9CbGFja0lzMSB0cnVlCj4+CklEICaojhg4
C/ITXyRfiaMPkgO+Cb6DfCb6vp+r//6v/X+l69Ypa4S1wlhLCWEsILSwgtLCC0FpcLQWlwoqiGh6
66/pfk1X9f9tfXbXbXbC7DCP/YgnwwnwzQEwAQAQCkVJCmVuZHN0cmVhbQplbmRvYmoKODQgMCBv
YmoKPDwvTGVuZ3RoIDE2OCA+PgpzdHJlYW0KMCAwIDAgMTMgNTQgNjkgZDEKNTQgMCAwIDU2IDAg
MTMgY20KQkkKL0lNIHRydWUvVyA1NC9IIDU2L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1u
cyA1NAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoEFQHkC4e11tf////////////////////////+Rv
hb/+v17//71/Xh68PC8R/8AEAEAKRUkKZW5kc3RyZWFtCmVuZG9iago4NSAwIG9iago8PC9MZW5n
dGggMjEyID4+CnN0cmVhbQowIDAgMCAxMiA1NiA3MSBkMQo1NiAwIDAgNTkgMCAxMiBjbQpCSQov
SU0gdHJ1ZS9XIDU2L0ggNTkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU2Ci9CbGFj
a0lzMSB0cnVlCj4+CklEICahmHgbyGwZgiTDwiGYeEThgHhBA3oLwl6C9L1+vS9L/0vX6/9fr//j
6//9dPCeQMA5BXNcmq/3+/97kNR/9v9dv/212/bXddtLYa7a7DC4YYLsTx8GU4nBlAJgAgAgCkVJ
CmVuZHN0cmVhbQplbmRvYmoKODYgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjYyIDAgMCAw
IDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjg3IDAgb2JqCjw8L0xlbmd0aCAxOTUgPj4Kc3RyZWFt
CjAgMCAwIDEzIDUyIDY5IGQxCjUyIDAgMCA1NiAwIDEzIGNtCkJJCi9JTSB0cnVlL1cgNTIvSCA1
Ni9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTIKL0JsYWNrSXMxIHRydWUKPj4KSUQg
IMMSamSAzgthQXpbSC+vX0vS/9L0v/S9L/0vS/9L0v/S9L1+uK/g+fFB+Dfhvw37f37f/v9/////
+v1/6/Xpel4S0QzWhCiFKQDAAIAICkVJCmVuZHN0cmVhbQplbmRvYmoKODggMCBvYmoKPDwvTGVu
Z3RoIDE3OSA+PgpzdHJlYW0KMCAwIDAgMTMgNDQgNjkgZDEKNDQgMCAwIDU2IDAgMTMgY20KQkkK
L0lNIHRydWUvVyA0NC9IIDU2L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0NAovQmxh
Y2tJczEgdHJ1ZQo+PgpJRCAlLJqfZODHaDfT+/v7f/v9+//t8P//+Q0D//+v/r/4Xj/+fBf4f/3/
//8f///yBd///r/1/9fXULocfABABApFSQplbmRzdHJlYW0KZW5kb2JqCjg5IDAgb2JqCjw8L0xl
bmd0aCAyMzAgPj4Kc3RyZWFtCjAgMCAwIC0yIDUxIDcxIGQxCjUxIDAgMCA3MyAwIC0yIGNtCkJJ
Ci9JTSB0cnVlL1cgNTEvSCA3My9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTEKL0Js
YWNrSXMxIHRydWUKPj4KSUQgJqy4MFAMchxHgg+yyCKjiCBvgg3wm+m+m+E31fv1/fX/96+v9L/r
pYpa4XSwlhcJaWEsJYQWEtBYSwgtBaWgtBaC0uFoLrQXRDKfr0vr/6916/X//df9tfXbXbXbXbC7
DC7JDJz4YhPhgvIaPeACACAKRUkKZW5kc3RyZWFtCmVuZG9iago5MCAwIG9iago8PC9MZW5ndGgg
MjU5ID4+CnN0cmVhbQowIDAgMCAtMiA3OCA4NyBkMQo3OCAwIDAgODkgMCAtMiBjbQpCSQovSU0g
dHJ1ZS9XIDc4L0ggODkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDc4Ci9CbGFja0lz
MSB0cnVlCj4+CklEICageIsgeiMgtHyCwfCCwQWEFhLCCwlhLSwlhLXSwlpa6WEDwQPCJAQPCBEG
D4QIMPCQb0Ew9JvSb0m9W9JvSb1vSb/0m/vSf71/b69f7/99L+/////////1uv/f9b/r9bf9br3W
67delt+6W3W2lultpbaWGGgtsJYYYQWGGEFhkggsMQsg0jMhqzgAgAgKRUkKZW5kc3RyZWFtCmVu
ZG9iago5MSAwIG9iago8PC9MZW5ndGggMTc1ID4+CnN0cmVhbQowIDAgMCAwIDYwIDY5IGQxCjYw
IDAgMCA2OSAwIDAgY20KQkkKL0lNIHRydWUvVyA2MC9IIDY5L0JQQyAxL0YvQ0NGL0RQPDwvSyAt
MQovQ29sdW1ucyA2MAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmsVU5FCsPs6Bn7CBvw+0H9v/39v3/
9/v/3++D/////////////////////////////ev6eEHmA/gAgAgKRUkKZW5kc3RyZWFtCmVuZG9i
ago5MiAwIG9iago8PC9MZW5ndGggMjA1ID4+CnN0cmVhbQowIDAgMCAwIDc3IDcxIGQxCjc3IDAg
MCA3MSAwIDAgY20KQkkKL0lNIHRydWUvVyA3Ny9IIDcxL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQov
Q29sdW1ucyA3NwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoNZDBpkMwHhA8IoCh4QIgR+gg3pBvSb0
m9JvSb1+m9X++vVv//r1b///////////////////////////////////////////7T1+09PwmEHn
AyGcn8AEAEAKRUkKZW5kc3RyZWFtCmVuZG9iago5MyAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJl
YW0KNjkgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKOTQgMCBvYmoKPDwvTGVuZ3RoIDIw
NSA+PgpzdHJlYW0KMCAwIDAgMTMgNjMgNzAgZDEKNjMgMCAwIDU3IDAgMTMgY20KQkkKL0lNIHRy
dWUvVyA2My9IIDU3L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA2MwovQmxhY2tJczEg
dHJ1ZQo+PgpJRCAmrIgGgjiyIddpdpf9pfX19fX19f/X0Zr6X6X6/pfpf1+l+v6X6X6X6X6X/+l+
l+l+l+v6X6X9fpfr+l+l+l+l8f19fX1/6X16XhJPXz1BPohlCINYAIAICkVJCmVuZHN0cmVhbQpl
bmRvYmoKOTUgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjg2IDAgMCAwIDAgMCBkMQplbmRz
dHJlYW0KZW5kb2JqCjk2IDAgb2JqCjw8L0xlbmd0aCAxNTcgPj4Kc3RyZWFtCjAgMCAwIDEzIDIz
IDY5IGQxCjIzIDAgMCA1NiAwIDEzIGNtCkJJCi9JTSB0cnVlL1cgMjMvSCA1Ni9CUEMgMS9GL0ND
Ri9EUDw8L0sgLTEKL0NvbHVtbnMgMjMKL0JsYWNrSXMxIHRydWUKPj4KSUQgk1Mhna2tr///////
///////////////////////9P9PCcSMDcAEAEApFSQplbmRzdHJlYW0KZW5kb2JqCjk3IDAgb2Jq
Cjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo3MSAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago5
OCAwIG9iago8PC9MZW5ndGggMTg5ID4+CnN0cmVhbQowIDAgMCAxMyA2MiA3MCBkMQo2MiAwIDAg
NTcgMCAxMyBjbQpCSQovSU0gdHJ1ZS9XIDYyL0ggNTcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9D
b2x1bW5zIDYyCi9CbGFja0lzMSB0cnVlCj4+CklEICahplwMb1/T/vX9P9e/0Zp++l+3pf/t6X96
T/6t9f+k3/pX7/6V++l+3pf/t6X96T/6Tf/+k3/rfvpX2nhU8IGnhBhB9QAQAQpFSQplbmRzdHJl
YW0KZW5kb2JqCjk5IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo3MCAwIDAgMCAwIDAgZDEK
ZW5kc3RyZWFtCmVuZG9iagoxMDAgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjQ3IDAgMCAw
IDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjEwMSAwIG9iago8PC9MZW5ndGggMTg1ID4+CnN0cmVh
bQowIDAgMCAxMiA1OCA2OSBkMQo1OCAwIDAgNTcgMCAxMiBjbQpCSQovSU0gdHJ1ZS9XIDU4L0gg
NTcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU4Ci9CbGFja0lzMSB0cnVlCj4+CklE
ICag3JcMSGURhrrf////////////XvXvXn96/TevpN/ek/t6X03r9N6+k3/pN9erfXq3/pXq3663
hOHphB6BhB1wAQAQCkVJCmVuZHN0cmVhbQplbmRvYmoKMTAyIDAgb2JqCjw8L0xlbmd0aCAxNj4+
CnN0cmVhbQo5MiAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxMDMgMCBvYmoKPDwvTGVu
Z3RoIDE3MCA+PgpzdHJlYW0KMCAwIDAgMTMgNDEgNjkgZDEKNDEgMCAwIDU2IDAgMTMgY20KQkkK
L0lNIHRydWUvVyA0MS9IIDU2L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0MQovQmxh
Y2tJczEgdHJ1ZQo+PgpJRCAhAIJqzoCiGutr/////////8gwP////6+vrx//MwT4f3//9//H///8
L/r//X/Wq8LQxwAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjEwNCAwIG9iago8PC9MZW5ndGggMjI2
ID4+CnN0cmVhbQowIDAgMCAtMiA2OCA3MSBkMQo2OCAwIDAgNzMgMCAtMiBjbQpCSQovSU0gdHJ1
ZS9XIDY4L0ggNzMvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDY4Ci9CbGFja0lzMSB0
cnVlCj4+CklEICag1HQG8hmA8EHgg8IPCIwKHo1BnegQbwkG9BN6Qb0E3pP7ek3pN9Pq3oOvWvX6
9f+vX///////v/9/v/7ZBXf/f7Xf/21/212/dLtdtdv21w2u2F2GuGGF2GFwzoMnLgxCfBkYD8hp
04AIAIAKRUkKZW5kc3RyZWFtCmVuZG9iagoxMDUgMCBvYmoKPDwvTGVuZ3RoIDE5MSA+PgpzdHJl
YW0KMCAwIDAgMTMgNjYgNjkgZDEKNjYgMCAwIDU2IDAgMTMgY20KQkkKL0lNIHRydWUvVyA2Ni9I
IDU2L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA2NgovQmxhY2tJczEgdHJ1ZQo+PgpJ
RCAmoynDPhyChPDNAaCQ7VbVb137167devfvXa7167df7H1+zYZ1/tr9ba/W3+u3Xr3W691v9rvX
a7169+9ce1+/W/W/X79b9QAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjEwNiAwIG9iago8PC9MZW5n
dGggMTY2ID4+CnN0cmVhbQowIDAgMCAxMyA0NSA2OSBkMQo0NSAwIDAgNTYgMCAxMyBjbQpCSQov
SU0gdHJ1ZS9XIDQ1L0ggNTYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQ1Ci9CbGFj
a0lzMSB0cnVlCj4+CklEICVMmp8MnBf0G9oP7+37/+37//+3w////////////////////////6f6
eg4kYGwAEAEKRUkKZW5kc3RyZWFtCmVuZG9iagoxMDcgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3Ry
ZWFtCjc1IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjEwOCAwIG9iago8PC9MZW5ndGgg
MTY+PgpzdHJlYW0KNDkgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMTA5IDAgb2JqCjw8
L0xlbmd0aCAxNj4+CnN0cmVhbQoyNCAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxMTAg
MCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjkzIDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5k
b2JqCjExMSAwIG9iago8PC9MZW5ndGggMjA5ID4+CnN0cmVhbQowIDAgMCAwIDU5IDY5IGQxCjU5
IDAgMCA2OSAwIDAgY20KQkkKL0lNIHRydWUvVyA1OS9IIDY5L0JQQyAxL0YvQ0NGL0RQPDwvSyAt
MQovQ29sdW1ucyA1OQovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmrIsBEii2GD2dQoezQM4fhvdvw39+
/t/+3////9///16//+l6+l/4S9Lwl4ILiuC4XD5ODh8IG/b9v39v/79//v///////1+vX69fr19L
UJegtAwS0IWECyxOACACCkVJCmVuZHN0cmVhbQplbmRvYmoKMTEyIDAgb2JqCjw8L0xlbmd0aCAy
MDMgPj4Kc3RyZWFtCjAgMCAwIDEzIDU2IDY5IGQxCjU2IDAgMCA1NiAwIDEzIGNtCkJJCi9JTSB0
cnVlL1cgNTYvSCA1Ni9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTYKL0JsYWNrSXMx
IHRydWUKPj4KSUQgIMJyOpNTKA0HU7VbUL4Xpel6Xpel6Xr6Xpel6Xpel6Xpel6Xpel6XpcVz6Xt
e17ft+37ft+37ft+37ft+37ft+37ft+39+33eqD00D0GCDiU4mACACAKRUkKZW5kc3RyZWFtCmVu
ZG9iagoxMTMgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjM3IDAgMCAwIDAgMCBkMQplbmRz
dHJlYW0KZW5kb2JqCjExNCAwIG9iago8PC9MZW5ndGggMjQxID4+CnN0cmVhbQowIDAgMCAxIDk0
IDcwIGQxCjk0IDAgMCA2OSAwIDEgY20KQkkKL0lNIHRydWUvVyA5NC9IIDY5L0JQQyAxL0YvQ0NG
L0RQPDwvSyAtMQovQ29sdW1ucyA5NAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmsVAMGAY/5CITIN6t
hYa6Ta3/pNr/9P//T///9P//RQn/X+rf9f6t/1/q3/X+t/7/pX/v+lf+/6V/7/1/q3/X+rf9f6t/
1/q3/X+rf//pX/v+lf+/6V/7/pX/v/X+rf9f6t/1/q3/X8bH/0//Xq/V++leFYeYRJcN+4AIAIAK
RUkKZW5kc3RyZWFtCmVuZG9iagoxMTUgMCBvYmoKPDwvTGVuZ3RoIDE3Pj4Kc3RyZWFtCjEwMyAw
IDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxMTYgMCBvYmoKPDwvTGVuZ3RoIDIwMyA+Pgpz
dHJlYW0KMCAwIDAgMTIgNTIgNzEgZDEKNTIgMCAwIDU5IDAgMTIgY20KQkkKL0lNIHRydWUvVyA1
Mi9IIDU5L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1MgovQmxhY2tJczEgdHJ1ZQo+
PgpJRCAmoZRwNkhorwQeEHhGph4RDB3oEDek3oIN6Tek3pN6v03pN8Ol+vX/8V///yar/f7+CC/2
1/3Xv3+139tdtdtLbXbXbXYYXDBgjP4YgnwwT5BQjgAgAgpFSQplbmRzdHJlYW0KZW5kb2JqCjEx
NyAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KMzEgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQpl
bmRvYmoKMTE4IDAgb2JqCjw8L0xlbmd0aCAxODMgPj4Kc3RyZWFtCjAgMCAwIDEzIDYzIDY5IGQx
CjYzIDAgMCA1NiAwIDEzIGNtCkJJCi9JTSB0cnVlL1cgNjMvSCA1Ni9CUEMgMS9GL0NDRi9EUDw8
L0sgLTEKL0NvbHVtbnMgNjMKL0JsYWNrSXMxIHRydWUKPj4KSUQgKsPJqZ1BQdChhNdNbTX/////
////////////////H/8zBo/////////////////////9p6+mnoMIOJEByTDcAEAECkVJCmVuZHN0
cmVhbQplbmRvYmoKMTE5IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo2MyAwIDAgMCAwIDAg
ZDEKZW5kc3RyZWFtCmVuZG9iagoxMjAgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjc2IDAg
MCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjEyMSAwIG9iago8PC9MZW5ndGggMTkyID4+CnN0
cmVhbQowIDAgMCAxMyA0NCA2OSBkMQo0NCAwIDAgNTYgMCAxMyBjbQpCSQovSU0gdHJ1ZS9XIDQ0
L0ggNTYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQ0Ci9CbGFja0lzMSB0cnVlCj4+
CklEICNAhNTIGJZIED5mGA9w37ft+/t//+3///9f/6X/r9el4S9LwQXELhcPnwQPwb9v3+//f7//
////9fr/0vX68JapcGCWhCiFBQAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjEyMiAwIG9iago8PC9M
ZW5ndGggMTc5ID4+CnN0cmVhbQowIDAgMCAwIDMyIDg4IGQxCjMyIDAgMCA4OCAwIDAgY20KQkkK
L0lNIHRydWUvVyAzMi9IIDg4L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAzMgovQmxh
Y2tJczEgdHJ1ZQo+PgpJRCAmrNAz09B6xNJ7dfe9X/f1yar7V4///f//////////////////////
////////////////6/3+nrhB5InwAQAQCkVJCmVuZHN0cmVhbQplbmRvYmoKMTIzIDAgb2JqCjw8
L0xlbmd0aCAxNj4+CnN0cmVhbQo3OSAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxMjQg
MCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjkxIDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5k
b2JqCjEyNSAwIG9iago8PC9MZW5ndGggMjA4ID4+CnN0cmVhbQowIDAgMCAtMSA3NyA2OSBkMQo3
NyAwIDAgNzAgMCAtMSBjbQpCSQovSU0gdHJ1ZS9XIDc3L0ggNzAvQlBDIDEvRi9DQ0YvRFA8PC9L
IC0xCi9Db2x1bW5zIDc3Ci9CbGFja0lzMSB0cnVlCj4+CklEICa5BgYw0QaAmDKA1TWdphb1tV/t
1/ul37167df7a/Xa71/tr9ba8Vv1s4Bf6/W3+lt/rt167df7aX/a712u9d+691uvdbr9bf691sfW
/7X7X7X/tftfv1ABABAKRUkKZW5kc3RyZWFtCmVuZG9iagoxMjYgMCBvYmoKPDwvTGVuZ3RoIDE2
Pj4Kc3RyZWFtCjg4IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjEyNyAwIG9iago8PC9M
ZW5ndGggMTkzID4+CnN0cmVhbQowIDAgMCAxMyA1OCA2OSBkMQo1OCAwIDAgNTYgMCAxMyBjbQpC
SQovSU0gdHJ1ZS9XIDU4L0ggNTYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU4Ci9C
bGFja0lzMSB0cnVlCj4+CklEICKg3JqREwIs6BA+aAQHuGH4b9h+37ft+/t/fv9+/3/7f///t///
//////S///9L//0v/S9fr0vS9fS9BeEtQlzoEC0IUQUigKAAQAQKRUkKZW5kc3RyZWFtCmVuZG9i
agoxMjggMCBvYmoKPDwvTGVuZ3RoIDIyNCA+PgpzdHJlYW0KMCAwIDAgMTMgODUgNzAgZDEKODUg
MCAwIDU3IDAgMTMgY20KQkkKL0lNIHRydWUvVyA4NS9IIDU3L0JQQyAxL0YvQ0NGL0RQPDwvSyAt
MQovQ29sdW1ucyA4NQovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoNRgFBcDHvTX/W+1/1T7/9U/9P9P
5mun3zPr/0+la37//T6Wt+3Xr79a3916vv1rf3Xq6v1963X06v/V6/9Mbf1679Pf1679Vev+r9Ve
v+r9Veq/76Xfr/V6p+mqeEU4jTwmWDIPWACACApFSQplbmRzdHJlYW0KZW5kb2JqCjEyOSAwIG9i
ago8PC9MZW5ndGggMTk5ID4+CnN0cmVhbQowIDAgMCAtMSA2NiA2OSBkMQo2NiAwIDAgNzAgMCAt
MSBjbQpCSQovSU0gdHJ1ZS9XIDY2L0ggNzAvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5z
IDY2Ci9CbGFja0lzMSB0cnVlCj4+CklEICahoKQM/yGXptbX7X//////////////6f6f6evNN6/T
er9Xq3pfTev03r9N6/Tel6t9erfXq303r6TfXq3/pX/ret63pp4WHgirDQH2EGACACAKRUkKZW5k
c3RyZWFtCmVuZG9iagoxMzAgMCBvYmoKPDwvTGVuZ3RoIDE3Pj4Kc3RyZWFtCjExNiAwIDAgMCAw
IDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxMzEgMCBvYmoKPDwvTGVuZ3RoIDE5MiA+PgpzdHJlYW0K
MCAwIDAgMTMgNjcgNzEgZDEKNjcgMCAwIDU4IDAgMTMgY20KQkkKL0lNIHRydWUvVyA2Ny9IIDU4
L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA2NwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAm
oaRwMyQzK8IPCKDDwjQHD0EG9JvSb0m+n1b/0m//+vVv////////////////////////////////
///u9f09P0wg8jUEMFwAQAQKRUkKZW5kc3RyZWFtCmVuZG9iagoxMzIgMCBvYmoKPDwvTGVuZ3Ro
IDE2Pj4Kc3RyZWFtCjY1IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjEzMyAwIG9iago8
PC9MZW5ndGggMTgwID4+CnN0cmVhbQowIDAgMCAyMyA1NSA3MCBkMQo1NSAwIDAgNDcgMCAyMyBj
bQpCSQovSU0gdHJ1ZS9XIDU1L0ggNDcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU1
Ci9CbGFja0lzMSB0cnVlCj4+CklEICahmGAL17171/T/T/T/k6ev16t9erfXq31630+v03r9X76V
++t9PrfXq/V6v96T/ev7evhNPBFQCGoN/gAgAgpFSQplbmRzdHJlYW0KZW5kb2JqCjEzNCAwIG9i
ago8PC9MZW5ndGggMjM0ID4+CnN0cmVhbQowIDAgMCAtMiA3NCA3MSBkMQo3NCAwIDAgNzMgMCAt
MiBjbQpCSQovSU0gdHJ1ZS9XIDc0L0ggNzMvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5z
IDc0Ci9CbGFja0lzMSB0cnVlCj4+CklEICahpnQDEg0K8hlDeEQwoPCKAIDwggYeEEG9Lwl6C9L1
9L0vr19L69fS//9L/1+v//X/6///T/9PwT8g0mP8gVmv3/v9//b/9sgrD+u/2u/tr/tpbfuva7ft
rhsLtrsNdhhcMMFwyGMhvhiaCcGCrIaU+ACACApFSQplbmRzdHJlYW0KZW5kb2JqCjEzNSAwIG9i
ago8PC9MZW5ndGggMTY+PgpzdHJlYW0KODQgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoK
MTM2IDAgb2JqCjw8L0xlbmd0aCAyMDYgPj4Kc3RyZWFtCjAgMCAwIDAgNzYgNjkgZDEKNzYgMCAw
IDY5IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDc2L0ggNjkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9D
b2x1bW5zIDc2Ci9CbGFja0lzMSB0cnVlCj4+CklEICaxBAzJELMMHs1A4fKAUB7hh+G/b8MP2/b9
v39v79v3+/f7/9v//2////b/////////9fX///pf/+l/6/Xr6X16+l6Xpel6XpeEFqEuwguawQLQ
gsECzFkAEAEKRUkKZW5kc3RyZWFtCmVuZG9iagoxMzcgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3Ry
ZWFtCjg1IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjEzOCAwIG9iago8PC9MZW5ndGgg
MTgyID4+CnN0cmVhbQowIDAgMCAxMyA0NSA2OSBkMQo0NSAwIDAgNTYgMCAxMyBjbQpCSQovSU0g
dHJ1ZS9XIDQ1L0ggNTYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQ1Ci9CbGFja0lz
MSB0cnVlCj4+CklEICrDQTUzqBiwtrfr////////////yR/KT8Q+UCh8EG/Dft+/37f/v9/////9
fX/pf+l6XpapchkFoQohSBAuACACCkVJCmVuZHN0cmVhbQplbmRvYmoKMTM5IDAgb2JqCjw8L0xl
bmd0aCAyMjIgPj4Kc3RyZWFtCjAgMCAwIDE0IDgwIDcwIGQxCjgwIDAgMCA1NiAwIDE0IGNtCkJJ
Ci9JTSB0cnVlL1cgODAvSCA1Ni9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgODAKL0Js
YWNrSXMxIHRydWUKPj4KSUQgJqMiAcuCZBKKQI02rDC6V9q69X+/1//0//9P+Zr/t/r/1f6v/V/q
/9X+r/1f6v/V/q/9X+r/1f6v/3/X+rf9f6t/1/q3/X+rf9f6t/1/q3//6T/9/1/Gx9fv16v1er6V
5HW381BuACACCkVJCmVuZHN0cmVhbQplbmRvYmoKMTQwIDAgb2JqCjw8L0xlbmd0aCAxNzMgPj4K
c3RyZWFtCjAgMCAwIDAgNjAgNjkgZDEKNjAgMCAwIDY5IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDYw
L0ggNjkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDYwCi9CbGFja0lzMSB0cnVlCj4+
CklEICaguQMH+QUV4YXW/X///////////////////////////////mHwv/f/X//3rv/rh671weC4
j/ABABAKRUkKZW5kc3RyZWFtCmVuZG9iagoxNDEgMCBvYmoKPDwvTGVuZ3RoIDIwOCA+PgpzdHJl
YW0KMCAwIDAgLTEgNTIgNzMgZDEKNTIgMCAwIDc0IDAgLTEgY20KQkkKL0lNIHRydWUvVyA1Mi9I
IDc0L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1MgovQmxhY2tJczEgdHJ1ZQo+PgpJ
RCAmoZyGGiQwIwQeCOooeECDD0g3wm+m+m/v2/b/+/f7/9v///7////9f//0v//X0v+Gl2vaXJ0G
F+DCXsV7Xhr2vYXhheDBeP//////////6x8mtw+D4fDwAQAQCkVJCmVuZHN0cmVhbQplbmRvYmoK
MTQyIDAgb2JqCjw8L0xlbmd0aCAyMzQgPj4Kc3RyZWFtCjAgMCAwIC0yIDc4IDcxIGQxCjc4IDAg
MCA3MyAwIC0yIGNtCkJJCi9JTSB0cnVlL1cgNzgvSCA3My9CUEMgMS9GL0NDRi9EUDw8L0sgLTEK
L0NvbHVtbnMgNzgKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqDWQwapDNL4IHgiQEB4QIgxTQQYeEEG
9Jh4Sb0m9JvSb0m/vSb0r9vS9W/vSf7/0m//9b/9+vX+////////+9evf//vX+2l//ul371tpf7p
bdbaW6W3W2ltpbaW2EsNoLDDCWwwQWDKCCwxBYMFkNWcAEAECkVJCmVuZHN0cmVhbQplbmRvYmoK
MTQzIDAgb2JqCjw8L0xlbmd0aCAyMTIgPj4Kc3RyZWFtCjAgMCAwIDIyIDU2IDk2IGQxCjU2IDAg
MCA3NCAwIDIyIGNtCkJJCi9JTSB0cnVlL1cgNTYvSCA3NC9CUEMgMS9GL0NDRi9EUDw8L0sgLTEK
L0NvbHVtbnMgNTYKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrkmGZ8iabW1/X//////////kaPBA/CD
9GYw+IIG+m+m+m+m/b6/b6v3+///b///+//////9f//0v/X/0u/hr2lzRNfhpasGCWWOrHxtbtYd
rB2sOGsHYWHBgoAIAIAKRUkKZW5kc3RyZWFtCmVuZG9iagoxNDQgMCBvYmoKPDwvTGVuZ3RoIDE2
Pj4Kc3RyZWFtCjc4IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjE0NSAwIG9iago8PC9M
ZW5ndGggMjE1ID4+CnN0cmVhbQowIDAgMCAyMiA4MiA3MCBkMQo4MiAwIDAgNDggMCAyMiBjbQpC
SQovSU0gdHJ1ZS9XIDgyL0ggNDgvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDgyCi9C
bGFja0lzMSB0cnVlCj4+CklEICahlFwzTAN+un/emv32uv3eq9+mn/pp8nX9uTrpaV+3vpaX7fel
7+2lev/TaT+33pe/tpXpf+2k+l9+3v8V6T39PpPf0/X6rfVPqv9N6/63pbemqeEwg08IgxQyCa/w
AQAQCkVJCmVuZHN0cmVhbQplbmRvYmoKMTQ2IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo1
NiAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxNDcgMCBvYmoKPDwvTGVuZ3RoIDE2NiA+
PgpzdHJlYW0KMCAwIDAgLTQgMjggNjkgZDEKMjggMCAwIDczIDAgLTQgY20KQkkKL0lNIHRydWUv
VyAyOC9IIDczL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAyOAovQmxhY2tJczEgdHJ1
ZQo+PgpJRCAmt8i67W11v/////////////////////////////////////6/rmr3wfD4Ph8PABAB
CkVJCmVuZHN0cmVhbQplbmRvYmoKMTQ4IDAgb2JqCjw8L0xlbmd0aCAyMTIgPj4Kc3RyZWFtCjAg
MCAwIDIyIDg4IDY5IGQxCjg4IDAgMCA0NyAwIDIyIGNtCkJJCi9JTSB0cnVlL1cgODgvSCA0Ny9C
UEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgODgKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrFW
ZVn/yOohjQgvrsJphbVe07X//////////////////////////////////////9p/cNeEVF1q2ija
+w1YaWaArBhJg142NisO0+DhoNYdprBwwgwsHBggwUAEAEAKRUkKZW5kc3RyZWFtCmVuZG9iagox
NDkgMCBvYmoKPDwvTGVuZ3RoIDE5NyA+PgpzdHJlYW0KMCAwIDAgLTQgNTggNjkgZDEKNTggMCAw
IDczIDAgLTQgY20KQkkKL0lNIHRydWUvVyA1OC9IIDczL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQov
Q29sdW1ucyA1OAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmuVZb8i6EGNNhNe11X///////////////
////////////r/3912vBFR+w19tL2DX2K9/DXteGF4YLx//////////1zjrx74fB8Ph8HgAgAgpF
SQplbmRzdHJlYW0KZW5kb2JqCjE1MCAwIG9iago8PC9MZW5ndGggMTc+PgpzdHJlYW0KMTEyIDAg
MCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjE1MSAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJl
YW0KNDAgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMTUyIDAgb2JqCjw8L0xlbmd0aCAy
MzcgPj4Kc3RyZWFtCjAgMCAwIDIyIDU1IDk3IGQxCjU1IDAgMCA3NSAwIDIyIGNtCkJJCi9JTSB0
cnVlL1cgNTUvSCA3NS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTUKL0JsYWNrSXMx
IHRydWUKPj4KSUQgJqGchgokHCYQPBA9B6eg9FOC75DDKegQN9N7Qb6f73ff+7fftrdbYLbIo1Yr
XCWl1oLguawzc0DVtdb/t77e3sM6NiD4eEUEHoIN6CDek3rfTev03/r/fX/////6W//9ba/W6Kdb
907a20thhGgYhiFhhYMFABABCkVJCmVuZHN0cmVhbQplbmRvYmoKMTUzIDAgb2JqCjw8L0xlbmd0
aCAyNDcgPj4Kc3RyZWFtCjAgMCAwIC0xIDk5IDcwIGQxCjk5IDAgMCA3MSAwIC0xIGNtCkJJCi9J
TSB0cnVlL1cgOTkvSCA3MS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgOTkKL0JsYWNr
SXMxIHRydWUKPj4KSUQgJqDWbDNMA0b/XW+/09f107/9dO//XTv/Ve79FC6KF/rq/tX0n7/r+1fS
er//W1fp6v9fW9+nq/1fX/pur11frr+1vV9+uv7W9X366v4/Vp+u9f9p+u9f9p+lvX+qfVb+vpX1
7+vpW9f/9Um+v9fVb+09MKnphBhB5yYImAXB/wAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjE1NCAw
IG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KOTkgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRv
YmoKMTU1IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo3NCAwIDAgMCAwIDAgZDEKZW5kc3Ry
ZWFtCmVuZG9iagoxNTYgMCBvYmoKPDwvTGVuZ3RoIDIwOCA+PgpzdHJlYW0KMCAwIDAgMjIgNTcg
OTYgZDEKNTcgMCAwIDc0IDAgMjIgY20KQkkKL0lNIHRydWUvVyA1Ny9IIDc0L0JQQyAxL0YvQ0NG
L0RQPDwvSyAtMQovQ29sdW1ucyA1NwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoNXJeyGsG7XW////
//////+Q0f4IH4T9B+n6fp+n6NQr+CDfpBj6fSfp/9L/6/9L///6//////9////f7/9//b/9v3Xv
3Xb9tdtdhrhgwuxPPgwnwYIPABABCkVJCmVuZHN0cmVhbQplbmRvYmoKMTU3IDAgb2JqCjw8L0xl
bmd0aCAxNj4+CnN0cmVhbQo1NSAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxNTggMCBv
YmoKPDwvTGVuZ3RoIDIxMiA+PgpzdHJlYW0KMCAwIDAgLTQgNjAgNjkgZDEKNjAgMCAwIDczIDAg
LTQgY20KQkkKL0lNIHRydWUvVyA2MC9IIDczL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1u
cyA2MAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmsSZfyLUGCwwRDYjaf6////3/////////////////
//////////8mTX17NXg/h32aFIiPEgn+H8GvH//f//9/IZY+4QP090+/ddv3IS34YX2Ot2twwtxw
++DBQAQAQApFSQplbmRzdHJlYW0KZW5kb2JqCjE1OSAwIG9iago8PC9MZW5ndGggMTk3ID4+CnN0
cmVhbQowIDAgMCAwIDQ4IDY5IGQxCjQ4IDAgMCA2OSAwIDAgY20KQkkKL0lNIHRydWUvVyA0OC9I
IDY5L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0OAovQmxhY2tJczEgdHJ1ZQo+PgpJ
RCAmsSk9/vhvffb2bAx2wb2323227YO3t7e3t7e3t7e33t7e3t/t7fe/e3+33/e/f//f/lv+vf/t
r/2l2u38MJbDXgwlsVtbW1tYYWwsGThoABABCkVJCmVuZHN0cmVhbQplbmRvYmoKMTYwIDAgb2Jq
Cjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo4MiAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagox
NjEgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjc3IDAgMCAwIDAgMCBkMQplbmRzdHJlYW0K
ZW5kb2JqCjE2MiAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KODAgMCAwIDAgMCAwIGQxCmVu
ZHN0cmVhbQplbmRvYmoKMTYzIDAgb2JqCjw8L0xlbmd0aCAyMDkgPj4Kc3RyZWFtCjAgMCAwIDAg
NjggNjkgZDEKNjggMCAwIDY5IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDY4L0ggNjkvQlBDIDEvRi9D
Q0YvRFA8PC9LIC0xCi9Db2x1bW5zIDY4Ci9CbGFja0lzMSB0cnVlCj4+CklEICaxSBo9BZEqR0Kw
oW0l6W1Xpel6/Xpev16Xr9el6/XpevpfXr6X16+l9evpcV/80EB+DB+G/DD9v2/b9/v3+/f/7///
///9fr/1+vX0vS9LTS5qILQhYIFmE4AIAIAKRUkKZW5kc3RyZWFtCmVuZG9iagoxNjQgMCBvYmoK
PDwvTGVuZ3RoIDIxMyA+PgpzdHJlYW0KMCAwIDAgMCA0NyA3MSBkMQo0NyAwIDAgNzEgMCAwIGNt
CkJJCi9JTSB0cnVlL1cgNDcvSCA3MS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNDcK
L0JsYWNrSXMxIHRydWUKPj4KSUQgJqKdAMQRBhoopAXoPmsYfIYOHwQb2CYeLe3t797f97/3X/+v
rWusLrhLCWC5BdJ1g1kFFWGsMLDBbeGH3t7fe3/ff/3rlv/9rsNe12GlsMLsGEtitra2FhhYYWDJ
wIABABAKRUkKZW5kc3RyZWFtCmVuZG9iagoxNjUgMCBvYmoKPDwvTGVuZ3RoIDE1MSA+PgpzdHJl
YW0KMCAwIDAgNTcgMjMgODQgZDEKMjMgMCAwIDI3IDAgNTcgY20KQkkKL0lNIHRydWUvVyAyMy9I
IDI3L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAyMwovQmxhY2tJczEgdHJ1ZQo+PgpJ
RCAmsYBjB4MHhh4bww9vb2+9+9+/Jdwh1/1/XW1sLDBQAQAQCkVJCmVuZHN0cmVhbQplbmRvYmoK
MTY2IDAgb2JqCjw8L0xlbmd0aCAxNz4+CnN0cmVhbQoxMDggMCAwIDAgMCAwIGQxCmVuZHN0cmVh
bQplbmRvYmoKMTY3IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo0MSAwIDAgMCAwIDAgZDEK
ZW5kc3RyZWFtCmVuZG9iagoxNjggMCBvYmoKPDwvTGVuZ3RoIDIwMSA+PgpzdHJlYW0KMCAwIDAg
MCA3MiA3MCBkMQo3MiAwIDAgNzAgMCAwIGNtCkJJCi9JTSB0cnVlL1cgNzIvSCA3MC9CUEMgMS9G
L0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNzIKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqGqYBq3+vev
6f96/p/r3+idP30v29L/9vS/vSf/Sv3/0m/9L9vS/v30v29L/9vS/vSf/Sb//0m/9K/fS/vV+v29
fq9X/+9b1T008JhB50gIH8AEAEAKRUkKZW5kc3RyZWFtCmVuZG9iagoxNjkgMCBvYmoKPDwvTGVu
Z3RoIDE4MiA+PgpzdHJlYW0KMCAwIDAgMCA1NSA2OSBkMQo1NSAwIDAgNjkgMCAwIGNtCkJJCi9J
TSB0cnVlL1cgNTUvSCA2OS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTUKL0JsYWNr
SXMxIHRydWUKPj4KSUQgJrEDBv8iV4YW1+1///////////+Q2P//////6+vheP/5oC/w/v7/+///
//j////4L/16//+v/rqvrqC6HguZUgAgAgpFSQplbmRzdHJlYW0KZW5kb2JqCjE3MCAwIG9iago8
PC9MZW5ndGggMTc+PgpzdHJlYW0KMTEwIDAgMCAwIDAgMCBkMQplbmRzdHJlYW0KZW5kb2JqCjE3
MSAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KOTUgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQpl
bmRvYmoKMTcyIDAgb2JqCjw8L0xlbmd0aCAxNz4+CnN0cmVhbQoxMDcgMCAwIDAgMCAwIGQxCmVu
ZHN0cmVhbQplbmRvYmoKMTczIDAgb2JqCjw8L0xlbmd0aCAyMjUgPj4Kc3RyZWFtCjAgMCAwIDAg
ODIgNzAgZDEKODIgMCAwIDcwIDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDgyL0ggNzAvQlBDIDEvRi9D
Q0YvRFA8PC9LIC0xCi9Db2x1bW5zIDgyCi9CbGFja0lzMSB0cnVlCj4+CklEICaiFWGqRwnXIYDX
DCXaX12v19fX19fX/19fX0Tr6X6X/+l+l+l+l+l+v6X9fpfpfr+l+l+l/X6/pfpfpfpfpf/6X6X6
X6X6/pf1+l+l+v6XxX19fX/19el6Xr6Sel4STyYhPDhA8hQyDWrABABACkVJCmVuZHN0cmVhbQpl
bmRvYmoKMTc0IDAgb2JqCjw8L0xlbmd0aCAxODQgPj4Kc3RyZWFtCjAgMCAwIDAgNDggNjkgZDEK
NDggMCAwIDY5IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDQ4L0ggNjkvQlBDIDEvRi9DQ0YvRFA8PC9L
IC0xCi9Db2x1bW5zIDQ4Ci9CbGFja0lzMSB0cnVlCj4+CklEICag0Ggn///////////KCv//7NgX
NBLft/+37f/t+3/7ft/fv7ft/+37f37+39+/t/fv7ft/fv7f37+x/vv+++/7wAQAQApFSQplbmRz
dHJlYW0KZW5kb2JqCjE3NSAwIG9iago8PC9MZW5ndGggMTUwID4+CnN0cmVhbQowIDAgMCAyMyAx
OSA3MCBkMQoxOSAwIDAgNDcgMCAyMyBjbQpCSQovSU0gdHJ1ZS9XIDE5L0ggNDcvQlBDIDEvRi9D
Q0YvRFA8PC9LIC0xCi9Db2x1bW5zIDE5Ci9CbGFja0lzMSB0cnVlCj4+CklEICahQWE9P9P/31tY
ax///////8hcwnp/p/+1vtbCgAgAgApFSQplbmRzdHJlYW0KZW5kb2JqCjE3OSAwIG9iago8PC9M
ZW5ndGggMTgwID4+CnN0cmVhbQowIDAgMCAzIDI2IDEwMCBkMQoyNiAwIDAgOTcgMCAzIGNtCkJJ
Ci9JTSB0cnVlL1cgMjYvSCA5Ny9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgMjYKL0Js
YWNrSXMxIHRydWUKPj4KSUQgJqKfCwgenzSfTft9fTe/1eP3//3///////////////////////X1
kHIh7w8PDw9////yGh8IPT7//9r9hQAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjE4MCAwIG9iago8
PC9MZW5ndGggMTY+PgpzdHJlYW0KMjYgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMTgx
IDAgb2JqCjw8L0xlbmd0aCAxOTMgPj4Kc3RyZWFtCjAgMCAwIDAgNTggNjkgZDEKNTggMCAwIDY5
IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDU4L0ggNjkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1
bW5zIDU4Ci9CbGFja0lzMSB0cnVlCj4+CklEICaxUzkUEw3skBs9A+037+/v7fv/7f/v99+H////
yBgf//1//9f/C+F4//mgaPv7+//v////4////+QaH////9f/X/11C+F0PC5lOACACApFSQplbmRz
dHJlYW0KZW5kb2JqCjE4MiAwIG9iago8PC9MZW5ndGggMjA4ID4+CnN0cmVhbQowIDAgMCAtMSA1
NiA3MyBkMQo1NiAwIDAgNzQgMCAtMSBjbQpCSQovSU0gdHJ1ZS9XIDU2L0ggNzQvQlBDIDEvRi9D
Q0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU2Ci9CbGFja0lzMSB0cnVlCj4+CklEICaxCD4LkegZqOGm
vraS+vr0vS9fS+vS9L19L69L0vX0vr0vX0vriuaJeH9r2/b9v2/b9vww/b9v2/b9v2/Qfw/BGsvJ
f4///////////r+arfD4Ph8Ph4AIAIAKRUkKZW5kc3RyZWFtCmVuZG9iagoxODMgMCBvYmoKPDwv
TGVuZ3RoIDE5MCA+PgpzdHJlYW0KMCAwIDAgMjIgNTEgNjkgZDEKNTEgMCAwIDQ3IDAgMjIgY20K
QkkKL0lNIHRydWUvVyA1MS9IIDQ3L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1MQov
QmxhY2tJczEgdHJ1ZQo+PgpJRCAmsagmGEwthEM5G1W9bpbful3W67aW3W691trtpb12u2lt1se1
1r1pa/p/onT1b6b0m9fpvSb0m/9JvSv71vW8Jp4IMIH/ABABCkVJCmVuZHN0cmVhbQplbmRvYmoK
MTg0IDAgb2JqCjw8L0xlbmd0aCAxODUgPj4Kc3RyZWFtCjAgMCAwIC00IDQ1IDgxIGQxCjQ1IDAg
MCA4NSAwIC00IGNtCkJJCi9JTSB0cnVlL1cgNDUvSCA4NS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEK
L0NvbHVtbnMgNDUKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrng1ft/t/3v+3+3+3/7f7f7f97/t/t/
t/+3+3+3/e/7f7f97/t/t/t/3v+3+3/e/7f7f7f97/t/t/3v+3+3/YAIAIAKRUkKZW5kc3RyZWFt
CmVuZG9iagoxODUgMCBvYmoKPDwvTGVuZ3RoIDIwMiA+PgpzdHJlYW0KMCAwIDAgMCA0NyA3MSBk
MQo0NyAwIDAgNzEgMCAwIGNtCkJJCi9JTSB0cnVlL1cgNDcvSCA3MS9CUEMgMS9GL0NDRi9EUDw8
L0sgLTEKL0NvbHVtbnMgNDcKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqIUBlyYjQPQfD0HyGFfCBh7
CBvYTeIb2+99v9v+//v/1/9f16110tdLXCWFwlhLBLIOoyxLYXWwthcLYXBbJwzM2Glb/b/b/b73
2TD+3+3+3+2ACACACkVJCmVuZHN0cmVhbQplbmRvYmoKMTg2IDAgb2JqCjw8L0xlbmd0aCAxNDUg
Pj4Kc3RyZWFtCjAgMCAwIC0yIDI0IDI0IGQxCjI0IDAgMCAyNiAwIC0yIGNtCkJJCi9JTSB0cnVl
L1cgMjQvSCAyNi9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgMjQKL0JsYWNrSXMxIHRy
dWUKPj4KSUQgJqRgMYe33v3t/t9/t/3t/3+3/f9weDwagAgAgApFSQplbmRzdHJlYW0KZW5kb2Jq
CjE4NyAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KMzUgMCAwIDAgMCAwIGQxCmVuZHN0cmVh
bQplbmRvYmoKMTg4IDAgb2JqCjw8L0xlbmd0aCAxMjIgPj4Kc3RyZWFtCjAgMCAwIDQwIDMyIDQ3
IGQxCjMyIDAgMCA3IDAgNDAgY20KQkkKL0lNIHRydWUvVyAzMi9IIDcvQlBDIDEvRi9DQ0YvRFA8
PC9LIC0xCi9Db2x1bW5zIDMyCi9CbGFja0lzMSB0cnVlCj4+CklEICa///8AEAEKRUkKZW5kc3Ry
ZWFtCmVuZG9iagoxODkgMCBvYmoKPDwvTGVuZ3RoIDE4NSA+PgpzdHJlYW0KMCAwIDAgMTMgNTcg
NjkgZDEKNTcgMCAwIDU2IDAgMTMgY20KQkkKL0lNIHRydWUvVyA1Ny9IIDU2L0JQQyAxL0YvQ0NG
L0RQPDwvSyAtMQovQ29sdW1ucyA1NwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmowW3ycM3th9sP77d
7b7/b7fu3vt9sO/e3v3t77fe3v3t77fe+33t77fe+33vkEHb9v77f2/vt/b7b7+Db4vveACACApF
SQplbmRzdHJlYW0KZW5kb2JqCjE5MCAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KMjUgMCAw
IDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMTkxIDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVh
bQo2NCAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoxOTUgMCBvYmoKPDwvTGVuZ3RoIDIx
NSA+PgpzdHJlYW0KMCAwIDAgMCA0OCA3MSBkMQo0OCAwIDAgNzEgMCAwIGNtCkJJCi9JTSB0cnVl
L1cgNDgvSCA3MS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNDgKL0JsYWNrSXMxIHRy
dWUKPj4KSUQgJqDc0BiCB4QeEaEHoIN6CDek3pN63pP1er9Xr+3pf3/r9f3+v/r//+v/Xa/+lv+l
2vDS2GlwYS5ohXZwe4YXhhbYMF479797977fe3vt7e3t7ew9vYeG9g8Mhjhmrg+DwAQAQApFSQpl
bmRzdHJlYW0KZW5kb2JqCjE5NiAwIG9iago8PC9MZW5ndGggMTY+PgpzdHJlYW0KOTAgMCAwIDAg
MCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMTk3IDAgb2JqCjw8L0xlbmd0aCAyMjQgPj4Kc3RyZWFt
CjAgMCAwIDEyIDU5IDgzIGQxCjU5IDAgMCA3MSAwIDEyIGNtCkJJCi9JTSB0cnVlL1cgNTkvSCA3
MS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTkKL0JsYWNrSXMxIHRydWUKPj4KSUQg
JqCmsgrTwQLBBYILCCwlpYSwlpaWEtdLC4QPCJxg8IzB3hBBh6Qbwkw9JvSb0m9Jv70n1vpvX9vr
1/v/p47/////Jqtevf9b/rt1/ul37pbdeltpbdbaW2lhsJbDCCwwYJYYhYMFgwUAEAEKRUkKZW5k
c3RyZWFtCmVuZG9iagoxOTggMCBvYmoKPDwvTGVuZ3RoIDE1MyA+PgpzdHJlYW0KMCAwIDAgMTgg
NTYgNjggZDEKNTYgMCAwIDUwIDAgMTggY20KQkkKL0lNIHRydWUvVyA1Ni9IIDUwL0JQQyAxL0Yv
Q0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1NgovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoZpsFH//////
////////ySn/IZt///////////////8AEAEKRUkKZW5kc3RyZWFtCmVuZG9iagoxOTkgMCBvYmoK
PDwvTGVuZ3RoIDE3NSA+PgpzdHJlYW0KMCAwIDAgMTYgMzEgODggZDEKMzEgMCAwIDcyIDAgMTYg
Y20KQkkKL0lNIHRydWUvVyAzMS9IIDcyL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAz
MQovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmocjgRIs9PT0Zz++n+//vr/2r2vH/v///////////////
/////////////////9P9PCeCJcN+ACACCkVJCmVuZHN0cmVhbQplbmRvYmoKMjAwIDAgb2JqCjw8
L0xlbmd0aCAxMjIgPj4Kc3RyZWFtCjAgMCAwIDc3IDUxIDgyIGQxCjUxIDAgMCA1IDAgNzcgY20K
QkkKL0lNIHRydWUvVyA1MS9IIDUvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDUxCi9C
bGFja0lzMSB0cnVlCj4+CklEICar/+ACACAKRUkKZW5kc3RyZWFtCmVuZG9iagoyMDEgMCBvYmoK
PDwvTGVuZ3RoIDE3NiA+PgpzdHJlYW0KMCAwIDAgMCA1MSA2OSBkMQo1MSAwIDAgNjkgMCAwIGNt
CkJJCi9JTSB0cnVlL1cgNTEvSCA2OS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTEK
L0JsYWNrSXMxIHRydWUKPj4KSUQgJqGg8Bjf79/v3v3+/f79/t/v3+/f7979/v3+/f7f79/v3+3+
/f79/k3b2/v3b7+G+3fB/F7/t/+3+ACACApFSQplbmRzdHJlYW0KZW5kb2JqCjIwMiAwIG9iago8
PC9MZW5ndGggMTcxID4+CnN0cmVhbQowIDAgMCAyMyA0OCA2OSBkMQo0OCAwIDAgNDYgMCAyMyBj
bQpCSQovSU0gdHJ1ZS9XIDQ4L0ggNDYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQ4
Ci9CbGFja0lzMSB0cnVlCj4+CklEICa33yQBfcPbe2+3t9+29v337Ydvvb329vvfb2+9vfb2+9vf
byN79v39v2+79vt+G3xffABABApFSQplbmRzdHJlYW0KZW5kb2JqCjIwMyAwIG9iago8PC9MZW5n
dGggMjMxID4+CnN0cmVhbQowIDAgMCAwIDQ3IDcxIGQxCjQ3IDAgMCA3MSAwIDAgY20KQkkKL0lN
IHRydWUvVyA0Ny9IIDcxL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0NwovQmxhY2tJ
czEgdHJ1ZQo+PgpJRCAmoZyQC8ERgeCD0UCh4QQYegg3pN6Tek/3pN/6/V//1/1/del2u67pdpbr
tpbhLbS2wlhtLbS2KwwutLCC109HVB6Tek3oJh6TfTek3oJvpvr0m+v76f//r/3+1/3rbXtLbrbS
2GEtgwgsMQsMFkNFIAIAIApFSQplbmRzdHJlYW0KZW5kb2JqCjIwNCAwIG9iago8PC9MZW5ndGgg
MjE2ID4+CnN0cmVhbQowIDAgMCAwIDQ3IDcxIGQxCjQ3IDAgMCA3MSAwIDAgY20KQkkKL0lNIHRy
dWUvVyA0Ny9IIDcxL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0NwovQmxhY2tJczEg
dHJ1ZQo+PgpJRCAmrNA0shg0SFpgw8GHsPDew9vDe3t97e3t977fe/e3+3+QYpeCBvhB+g70GVTC
Ogx8IG9BB9IPpP/1dfX+r6///r/6//3/S//3r12/0t67Xeu0t120ttLYaC2GEsMVhgsGCgAgAgpF
SQplbmRzdHJlYW0KZW5kb2JqCjIwNSAwIG9iago8PC9MZW5ndGggMjAzID4+CnN0cmVhbQowIDAg
MCAwIDQ3IDcxIGQxCjQ3IDAgMCA3MSAwIDAgY20KQkkKL0lNIHRydWUvVyA0Ny9IIDcxL0JQQyAx
L0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0NwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoNzMGIIH
hPR8g9IN6Cb0m9fSb+9J/vSf71+r1f/769f/7/1f//q//r//////////+v9/v9frf//+tv9frb/r
de639tL/bS3S262GlsMJbFYYWDBQAQAQCkVJCmVuZHN0cmVhbQplbmRvYmoKMjA2IDAgb2JqCjw8
L0xlbmd0aCAxOTEgPj4Kc3RyZWFtCjAgMCAwIC0xIDY0IDY5IGQxCjY0IDAgMCA3MCAwIC0xIGNt
CkJJCi9JTSB0cnVlL1cgNjQvSCA3MC9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNjQK
L0JsYWNrSXMxIHRydWUKPj4KSUQgJqRAgzb5BKsMLa/f+9//b//2//vf/2//9v/73/9v//b//2//
b//28iD5DO/f/t+37f/323/+3/99t/eu3/D0+214PC8Rd/wAQAQKRUkKZW5kc3RyZWFtCmVuZG9i
agoyMDcgMCBvYmoKPDwvTGVuZ3RoIDIyMCA+PgpzdHJlYW0KMCAwIDAgLTQgNDggNzAgZDEKNDgg
MCAwIDc0IDAgLTQgY20KQkkKL0lNIHRydWUvVyA0OC9IIDc0L0JQQyAxL0YvQ0NGL0RQPDwvSyAt
MQovQ29sdW1ucyA0OAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoNRwLPNB+nvf33e80n+327f/vt92
38O793/77f99vt/t9/d7v38EVF77+39t37vvf23ftvu3/f23fbe7ftv7fdhr2Pb9rd+w14YXjv3+
/f/v3+/f/v3++n+FyCVd5AgjIGMgAgAgCkVJCmVuZHN0cmVhbQplbmRvYmoKMjA4IDAgb2JqCjw8
L0xlbmd0aCAxOTYgPj4Kc3RyZWFtCjAgMCAwIDIxIDM4IDcwIGQxCjM4IDAgMCA0OSAwIDIxIGNt
CkJJCi9JTSB0cnVlL1cgMzgvSCA0OS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgMzgK
L0JsYWNrSXMxIHRydWUKPj4KSUQgJqHMwIhB4Qeg9PvRQN6CDfQb6Dft6Tft9D////+ygFGdQz4P
nmHuRZ9hh+G9ww/b7b3b7b3f29u9379tu/vt9vt8NpbfsGlhisGCgAgAgApFSQplbmRzdHJlYW0K
ZW5kb2JqCjIwOSAwIG9iago8PC9MZW5ndGggMTk4ID4+CnN0cmVhbQowIDAgMCAtMSA2MCA2OSBk
MQo2MCAwIDAgNzAgMCAtMSBjbQpCSQovSU0gdHJ1ZS9XIDYwL0ggNzAvQlBDIDEvRi9DQ0YvRFA8
PC9LIC0xCi9Db2x1bW5zIDYwCi9CbGFja0lzMSB0cnVlCj4+CklEICa5UBpfI9cMLa/9+//fv9/7
/f+/3/v9/7/f+ySOIPYfD5QI+EDe4Yfh/b7b3b/7b/3b/7/bv/3/v/3/vXr3716XfqloGloGEsgQ
J8LgoAIAIApFSQplbmRzdHJlYW0KZW5kb2JqCjIxMCAwIG9iago8PC9MZW5ndGggMTgyID4+CnN0
cmVhbQowIDAgMCAyMSAzOSA3MCBkMQozOSAwIDAgNDkgMCAyMSBjbQpCSQovSU0gdHJ1ZS9XIDM5
L0ggNDkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDM5Ci9CbGFja0lzMSB0cnVlCj4+
CklEICas+GZ//fv/37/9v+//b/v9v/4RT7Hwin/9vbb/9v/tve/ciP9p9tp7t/3fbXbH3/I4Cvi3
h3kHmHkM8BqACACACkVJCmVuZHN0cmVhbQplbmRvYmoKMjExIDAgb2JqCjw8L0xlbmd0aCAxOTgg
Pj4Kc3RyZWFtCjAgMCAwIDIxIDQxIDcwIGQxCjQxIDAgMCA0OSAwIDIxIGNtCkJJCi9JTSB0cnVl
L1cgNDEvSCA0OS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNDEKL0JsYWNrSXMxIHRy
dWUKPj4KSUQgJqM8DnBKDT0HenenffzRuenoIN/027ft7+930317eP/7F+/+7/ff77/v3f+79+9+
/fv/e2/+3/7d7v37a7337cuu3+2t20nhhpdiuDQcAEAECkVJCmVuZHN0cmVhbQplbmRvYmoKMjEy
IDAgb2JqCjw8L0xlbmd0aCAxODQgPj4Kc3RyZWFtCjAgMCAwIDIxIDQwIDcwIGQxCjQwIDAgMCA0
OSAwIDIxIGNtCkJJCi9JTSB0cnVlL1cgNDAvSCA0OS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0Nv
bHVtbnMgNDAKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqCGYZ4QPCD09B6KBvhA3pN9BvpvVv2+n9/H
////fv/37/f9v+9yGd9tB+u3e/3dt79t7b2+3Ww1wwaWGIWDBQAQAQpFSQplbmRzdHJlYW0KZW5k
b2JqCjIxMyAwIG9iago8PC9MZW5ndGggMTc5ID4+CnN0cmVhbQowIDAgMCA0IDMyIDcwIGQxCjMy
IDAgMCA2NiAwIDQgY20KQkkKL0lNIHRydWUvVyAzMi9IIDY2L0JQQyAxL0YvQ0NGL0RQPDwvSyAt
MQovQ29sdW1ucyAzMgovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmopwM8IPvT75pvpvdvtv3++2/fcf7
3/v9/7/fv9/7/f+9/7/f+9/7/f8iqPeDwyQUPh9vffb3/fb3/fbgAgAgCkVJCmVuZHN0cmVhbQpl
bmRvYmoKMjE0IDAgb2JqCjw8L0xlbmd0aCAxODMgPj4Kc3RyZWFtCjAgMCAwIC0yIDI3IDcwIGQx
CjI3IDAgMCA3MiAwIC0yIGNtCkJJCi9JTSB0cnVlL1cgMjcvSCA3Mi9CUEMgMS9GL0NDRi9EUDw8
L0sgLTEKL0NvbHVtbnMgMjcKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqM2C8IPh6fe3zOfT937fvvf
b+P7f/v3/79/+3/79/+/f/t//7f/+nkq98G8gvPIN3x///yDd8IPXT//vragAgAgCkVJCmVuZHN0
cmVhbQplbmRvYmoKMjE1IDAgb2JqCjw8L0xlbmd0aCAxODAgPj4Kc3RyZWFtCjAgMCAwIC00IDI2
IDcwIGQxCjI2IDAgMCA3NCAwIC00IGNtCkJJCi9JTSB0cnVlL1cgMjYvSCA3NC9CUEMgMS9GL0ND
Ri9EUDw8L0sgLTEKL0NvbHVtbnMgMjYKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqRwMU+++++f/Te/
7fd+/1uPf/v3//v3/79//79/+/f/+/f/v3//t//79//7f/+/f//f65Dh/kGKSDewAQAQCkVJCmVu
ZHN0cmVhbQplbmRvYmoKMjE2IDAgb2JqCjw8L0xlbmd0aCAyMTMgPj4Kc3RyZWFtCjAgMCAwIC0y
IDUxIDcxIGQxCjUxIDAgMCA3MyAwIC0yIGNtCkJJCi9JTSB0cnVlL1cgNTEvSCA3My9CUEMgMS9G
L0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTEKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqZcHPgo4IHt
hB9gjMw+IIG+m+m9pvpvr9vr+9p//v//f//9f/XevXH0v10tL9LS160tLS0v0tLrS/S6/SIaH/6/
+r///3/v17917vde12Gu2F2LsiHsIPYLgwTgAgAgCkVJCmVuZHN0cmVhbQplbmRvYmoKMjE3IDAg
b2JqCjw8L0xlbmd0aCAyNzcgPj4Kc3RyZWFtCjAgMCAwIC0yIDc2IDg5IGQxCjc2IDAgMCA5MSAw
IC0yIGNtCkJJCi9JTSB0cnVlL1cgNzYvSCA5MS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVt
bnMgNzYKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqGoQwy5GOQbhOyC41xD2HsiQO9lIDcPZBhmPZ9G
YaTw23tt7b7be2+Gx29vYe3hvCIYa8ES4aUIHhFAgeggYeEEGHpBh9N6hh6Tek37erfTft6t9X7e
rft/+39+/37f/t9/vvf/t/7b/f+3+/+3f7+3v779v/b7++3W/trt1t+/tpbftpbdbDXDaW2lhhpY
YYQWGDCWGIWDCyCsiACACApFSQplbmRzdHJlYW0KZW5kb2JqCjIxOCAwIG9iago8PC9MZW5ndGgg
MTg3ID4+CnN0cmVhbQowIDAgMCAtMSA1MyA2OSBkMQo1MyAwIDAgNzAgMCAtMSBjbQpCSQovSU0g
dHJ1ZS9XIDUzL0ggNzAvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDUzCi9CbGFja0lz
MSB0cnVlCj4+CklEICaxBDvkUpwyQDvaB+gf39vbf39v32/2//fb/b/cPf/t//7f/+3//t//7f/+
3//t/+/f/v3/79/+/evegeiXEkM6v4AIAIAKRUkKZW5kc3RyZWFtCmVuZG9iagoyMTkgMCBvYmoK
PDwvTGVuZ3RoIDIxMiA+PgpzdHJlYW0KMCAwIDAgLTEgODEgNjkgZDEKODEgMCAwIDcwIDAgLTEg
Y20KQkkKL0lNIHRydWUvVyA4MS9IIDcwL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA4
MQovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmqKsOVYEd8lqQUa4YQYW9e+/7f/fu/3/37t//9+7f/+2/
3//tt//9+7f/+2/3x/t/zQM37733/++3f/+7ff//tt///7bf/+3f/v/3f/d9p6cPQYRLqQYJkOTv
gAgAgApFSQplbmRzdHJlYW0KZW5kb2JqCjIyMCAwIG9iago8PC9MZW5ndGggMjA3ID4+CnN0cmVh
bQowIDAgMCAyMSA1MiA3MCBkMQo1MiAwIDAgNDkgMCAyMSBjbQpCSQovSU0gdHJ1ZS9XIDUyL0gg
NDkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDUyCi9CbGFja0lzMSB0cnVlCj4+CklE
ICahpnA8uaD9B/f3twRUft/Tfbb77f7fdt3evx7v32/37vf7fu/fb+799v5mm32VH7fu239/b+7b
+3fbf9+7bfb9t92/sP2w1qxyLU9N4cNZDBw1kNlhhQAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjIy
MSAwIG9iago8PC9MZW5ndGggMjIzID4+CnN0cmVhbQowIDAgMCAtNCA0OSA3MCBkMQo0OSAwIDAg
NzQgMCAtNCBjbQpCSQovSU0gdHJ1ZS9XIDQ5L0ggNzQvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9D
b2x1bW5zIDQ5Ci9CbGFja0lzMSB0cnVlCj4+CklEICaiHAwYBiEGg9B3p336cIp+Zm6b6bv0m9v3
f6b2/bx97+/239/7vdj/7f73f/v3b7/ff792+/d+/e9v7ff272/v2/bT2/DDCOLsV4avDCfH/9v/
/b//73/+9//+/1yGmH3INs5BVsAEAEAKRUkKZW5kc3RyZWFtCmVuZG9iagoyMjIgMCBvYmoKPDwv
TGVuZ3RoIDIxMiA+PgpzdHJlYW0KMCAwIDAgLTQgNDQgNzAgZDEKNDQgMCAwIDc0IDAgLTQgY20K
QkkKL0lNIHRydWUvVyA0NC9IIDc0L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0NAov
QmxhY2tJczEgdHJ1ZQo+PgpJRCAmoOaBsggeEeGHhBBvSb0gw/b7/b3b++2/92/+2/92+/7/3b7/
/vb/f//bv/99/f/fdd138EVC7ZUV7DX2K9rba8NeGF47f/+3//t//7f/+3/66eQTX8hnpkC+QAQA
QApFSQplbmRzdHJlYW0KZW5kb2JqCjIyMyAwIG9iago8PC9MZW5ndGggMTg3ID4+CnN0cmVhbQow
IDAgMCAyMSA0MiA3MCBkMQo0MiAwIDAgNDkgMCAyMSBjbQpCSQovSU0gdHJ1ZS9XIDQyL0ggNDkv
QlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQyCi9CbGFja0lzMSB0cnVlCj4+CklEICag
hoGiCD0cIPSDD0m9W9Jv29W+r9v31v2//b/+/fu//ff++3/3+7/d9/79v/b/263+/dLb9uttdusN
pbDCWGIWDCgAgAgKRUkKZW5kc3RyZWFtCmVuZG9iagoyMjQgMCBvYmoKPDwvTGVuZ3RoIDIxNCA+
PgpzdHJlYW0KMCAwIDAgLTQgNDYgNzAgZDEKNDYgMCAwIDc0IDAgLTQgY20KQkkKL0lNIHRydWUv
VyA0Ni9IIDc0L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0NgovQmxhY2tJczEgdHJ1
ZQo+PgpJRCAmoZRsF5/Qf36D3vuZr6Tf03vt97+rf1749//rvXf/2u3Xf39+xX8+vvu12/v7e7fb
ft+3u3237ft7t937D9A9smX78hlGv2//9v//b//2//9v//vIVwux75AimQUXABABCkVJCmVuZHN0
cmVhbQplbmRvYmoKMjI1IDAgb2JqCjw8L0xlbmd0aCAxNDYgPj4Kc3RyZWFtCjAgMCAwIDU3IDIy
IDgzIGQxCjIyIDAgMCAyNiAwIDU3IGNtCkJJCi9JTSB0cnVlL1cgMjIvSCAyNi9CUEMgMS9GL0ND
Ri9EUDw8L0sgLTEKL0NvbHVtbnMgMjIKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrFwYoHhh4YeG9vY
e33t/3/euun6/+11tbUAEAEKRUkKZW5kc3RyZWFtCmVuZG9iagoyMjYgMCBvYmoKPDwvTGVuZ3Ro
IDI1NCA+PgpzdHJlYW0KMCAwIDAgLTEgOTEgNzAgZDEKOTEgMCAwIDcxIDAgLTEgY20KQkkKL0lN
IHRydWUvVyA5MS9IIDcxL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA5MQovQmxhY2tJ
czEgdHJ1ZQo+PgpJRCAmuXBoLgT7v77+7++37v72/u/vu+/77b7/vbvv++aJ39ydPsq9/be/vb99
927b++/ff29v777ff23b++/fb3bt/b7+9v339vvu9v339t7+9vd7f2+/vb99v29+7799v2yqP8d+
7e7b/37t+997+7fvf7/d+t996p3ppoPQaBhBxISIGKD+wAQAQApFSQplbmRzdHJlYW0KZW5kb2Jq
CjIyNyAwIG9iago8PC9MZW5ndGggMjE5ID4+CnN0cmVhbQowIDAgMCAtMSA3NSA2OSBkMQo3NSAw
IDAgNzAgMCAtMSBjbQpCSQovSU0gdHJ1ZS9XIDc1L0ggNzAvQlBDIDEvRi9DQ0YvRFA8PC9LIC0x
Ci9Db2x1bW5zIDc1Ci9CbGFja0lzMSB0cnVlCj4+CklEICasi4NeSwMyQhThkgOH0QID2gb8MPw3
thh+G/b9vbb9v2/b2/2/b792//b2/2//vbf/7/23/+7+/v+3//+3//+3Xr/v91/6712v167devpb
12l4S9LwlpglxCwgshsFeRsG4AIAIApFSQplbmRzdHJlYW0KZW5kb2JqCjIyOCAwIG9iago8PC9M
ZW5ndGggMTgyID4+CnN0cmVhbQowIDAgMCAyMSA0OSA3MCBkMQo0OSAwIDAgNDkgMCAyMSBjbQpC
SQovSU0gdHJ1ZS9XIDQ5L0ggNDkvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQ5Ci9C
bGFja0lzMSB0cnVlCj4+CklEICagwXBo33p9999998EVHt+37f3037+37ft/fv7ft637+39+/303
/q3/7f/V6//p1XS1WvXmr4eshKNZDFsKACACCkVJCmVuZHN0cmVhbQplbmRvYmoKMjI5IDAgb2Jq
Cjw8L0xlbmd0aCAxNj4+CnN0cmVhbQoyNyAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagoy
MzAgMCBvYmoKPDwvTGVuZ3RoIDIxNCA+PgpzdHJlYW0KMCAwIDAgMjEgNDcgOTcgZDEKNDcgMCAw
IDc2IDAgMjEgY20KQkkKL0lNIHRydWUvVyA0Ny9IIDc2L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQov
Q29sdW1ucyA0NwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAjAzCarwWTpv1v/97//97//97//9mnuEHx
NmHwg303tN+39+377d+/37f+3fv/7ffvf/v99+/7/f/fv9t//vv7/7/2/BFP9tfddtr7frDCWQch
j7a3fIZ5hrIKLDCgAgAgCkVJCmVuZHN0cmVhbQplbmRvYmoKMjMxIDAgb2JqCjw8L0xlbmd0aCAy
NDggPj4Kc3RyZWFtCjAgMCAwIDIxIDc1IDcwIGQxCjc1IDAgMCA0OSAwIDIxIGNtCkJJCi9JTSB0
cnVlL1cgNzUvSCA0OS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNzUKL0JsYWNrSXMx
IHRydWUKPj4KSUQgJqCycDy/IMTQfd37p/3t9+2wRUf0G+773e2/3fu9vfuvbce/+73f73+73f7t
/u+/3bfuCKf4RTxbexsEU/win2/+7vsp3d977/e279vd9u3v9vbv3tt+7dv3b/9u277bsN7d7f2G
ra9tWGtNjY5HW73drDhoPkMHaayGywYQMKACACAKRUkKZW5kc3RyZWFtCmVuZG9iagoyMzIgMCBv
YmoKPDwvTGVuZ3RoIDIxNiA+PgpzdHJlYW0KMCAwIDAgMjEgNzEgNzAgZDEKNzEgMCAwIDQ5IDAg
MjEgY20KQkkKL0lNIHRydWUvVyA3MS9IIDQ5L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1u
cyA3MQovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoMEcDBcMqFXu+7++7++77v17gio/b7773/b4IqKb
6/9vb1fb+9/bW/9v29v3/7pv29v//b2+vfVvv21b//29v//bpv//Y/3vS/3X9OrrV1mHSpcb/+Rk
PWQv7WQxDtQAQAQKRUkKZW5kc3RyZWFtCmVuZG9iagoyMzMgMCBvYmoKPDwvTGVuZ3RoIDE4NCA+
PgpzdHJlYW0KMCAwIDAgMjEgMzUgNzAgZDEKMzUgMCAwIDQ5IDAgMjEgY20KQkkKL0lNIHRydWUv
VyAzNS9IIDQ5L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAzNQovQmxhY2tJczEgdHJ1
ZQo+PgpJRCAmuRxDQHwwg+wRwnxCDD2n6b9vr+/+ve//X//1x9LX9LXrXS0v0uteutIEF/0n//1/
7/r921/bWwwjfsQnhgnABABACkVJCmVuZHN0cmVhbQplbmRvYmoKMjM0IDAgb2JqCjw8L0xlbmd0
aCAyNDggPj4Kc3RyZWFtCjAgMCAwIDIxIDU5IDk2IGQxCjU5IDAgMCA3NSAwIDIxIGNtCkJJCi9J
TSB0cnVlL1cgNTkvSCA3NS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTkKL0JsYWNr
SXMxIHRydWUKPj4KSUQgJqBBDDMkEB4QPCIYUPROBAeggb0m+m9Jv36v/7/3/XbX1212yGgPcFw2
Q4zYYJYbOr2IW1wtAuU4GM6Bm4LhcLfrb29vDeGHo0DLhGoG9B6MzD0EDek3q303q31fvrfv9/+/
/337//vt/+69+81K37a7ftrtpwwwjMHhisGThnABABAKRUkKZW5kc3RyZWFtCmVuZG9iagoyMzUg
MCBvYmoKPDwvTGVuZ3RoIDIwOSA+PgpzdHJlYW0KMCAwIDAgLTIgNzcgNjkgZDEKNzcgMCAwIDcx
IDAgLTIgY20KQkkKL0lNIHRydWUvVyA3Ny9IIDcxL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29s
dW1ucyA3NwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoyEBdb3IfUhlJ8GEGFu1tVv7b7+37f/t+37b
7d7f37+37ft+x/vt7OBn7f/t+37ftvt/3t+37ft+39+77ft3t+39+/t+37f2VTYvffff99999v99
999/3gAgAgpFSQplbmRzdHJlYW0KZW5kb2JqCjIzNiAwIG9iago8PC9MZW5ndGggMjMwID4+CnN0
cmVhbQowIDAgMCAtMiA3MCA3MCBkMQo3MCAwIDAgNzIgMCAtMiBjbQpCSQovSU0gdHJ1ZS9XIDcw
L0ggNzIvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDcwCi9CbGFja0lzMSB0cnVlCj4+
CklEICahmkgM2QMCMEDwgeEUCB6BECD6QfCCvS+n0r19J+r1+vV/vr1/b/69W////v3/+/X0/CD8
hmJLfyBwa//2//b/fvfvfshtD7337+37d9+/t+2nt+2u34Yae2uGGuw1wwwnhlAnBifHwYJ8htIb
ABABCkVJCmVuZHN0cmVhbQplbmRvYmoKMjM3IDAgb2JqCjw8L0xlbmd0aCAxNz4+CnN0cmVhbQox
MDUgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoKMjM4IDAgb2JqCjw8L0xlbmd0aCAyMTAg
Pj4Kc3RyZWFtCjAgMCAwIDIxIDUyIDcwIGQxCjUyIDAgMCA0OSAwIDIxIGNtCkJJCi9JTSB0cnVl
L1cgNTIvSCA0OS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTIKL0JsYWNrSXMxIHRy
dWUKPj4KSUQgJqIfAg8HoNPQcPTvu+5n+aN7fhvb6b79t37De3u317tj23/fu3fbv7fvd+79t+9/
vfbZX7x9t/7v3e7/9vvfb//e2+W/7f7bt937D/bVvY/f3bhrvwwiDQagAgAgCkVJCmVuZHN0cmVh
bQplbmRvYmoKMjM5IDAgb2JqCjw8L0xlbmd0aCAyMTkgPj4Kc3RyZWFtCjAgMCAwIC0yIDY2IDcx
IGQxCjY2IDAgMCA3MyAwIC0yIGNtCkJJCi9JTSB0cnVlL1cgNjYvSCA3My9CUEMgMS9GL0NDRi9E
UDw8L0sgLTEKL0NvbHVtbnMgNjYKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqGYZg0SCivCDwg8I6DD
0UBh4QQb0gw9JvpvSfSb6b1b6fVvq9X6H/16///////9+//9+/3/vf9v9vyGu+3/7d/7ft+/3e37
a7ft3trt+2uGGntrhg1wwYLhieJwwTyGugOACACACkVJCmVuZHN0cmVhbQplbmRvYmoKMjQwIDAg
b2JqCjw8L0xlbmd0aCAxMzIgPj4Kc3RyZWFtCjAgMCAwIDU4IDE3IDcwIGQxCjE3IDAgMCAxMiAw
IDU4IGNtCkJJCi9JTSB0cnVlL1cgMTcvSCAxMi9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVt
bnMgMTcKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqIC09PT//9r8MKACACACkVJCmVuZHN0cmVhbQpl
bmRvYmoKMjQxIDAgb2JqCjw8L0xlbmd0aCAxOTMgPj4Kc3RyZWFtCjAgMCAwIC0xIDQ1IDkwIGQx
CjQ1IDAgMCA5MSAwIC0xIGNtCkJJCi9JTSB0cnVlL1cgNDUvSCA5MS9CUEMgMS9GL0NDRi9EUDw8
L0sgLTEKL0NvbHVtbnMgNDUKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqHMA0QgeE9B/o83037er/fb
/fv3f/vvf/+03te14/e///f/v/9/+///f/v///e////3v///7f///+3///97//9//f6egeuE+ACA
CApFSQplbmRzdHJlYW0KZW5kb2JqCjI0MiAwIG9iago8PC9MZW5ndGggMTcyID4+CnN0cmVhbQow
IDAgMCAtMSAzNiA2OSBkMQozNiAwIDAgNzAgMCAtMSBjbQpCSQovSU0gdHJ1ZS9XIDM2L0ggNzAv
QlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDM2Ci9CbGFja0lzMSB0cnVlCj4+CklEICa5
LgnyMja2v3/+9//v9//vf/7/f/73/+/3/+9//v9//vf//vf/73//73/+/0+HoHILiOACACAKRUkK
ZW5kc3RyZWFtCmVuZG9iagoyNDMgMCBvYmoKPDwvTGVuZ3RoIDIwOSA+PgpzdHJlYW0KMCAwIDAg
MjEgNTAgOTcgZDEKNTAgMCAwIDc2IDAgMjEgY20KQkkKL0lNIHRydWUvVyA1MC9IIDc2L0JQQyAx
L0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1MAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmsXBVhA+H
F3czTk1Sb99w3hpvG99vb2/29vvfb77/vv+9Pv+CKj79/b+/fq/f2/v31v39v79/v36v3+/f79/v
V/v3/9v/r/9PharVa8hKulwesH8GmsHagAgAgApFSQplbmRzdHJlYW0KZW5kb2JqCjI0NCAwIG9i
ago8PC9MZW5ndGggMTkzID4+CnN0cmVhbQowIDAgMCAtMSA1NiA2OSBkMQo1NiAwIDAgNzAgMCAt
MSBjbQpCSQovSU0gdHJ1ZS9XIDU2L0ggNzAvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5z
IDU2Ci9CbGFja0lzMSB0cnVlCj4+CklEICaolw0r5IjYW//v/f/v/f7//f7/5Bgfv3v///v3v19f
Xj2//mYXuH9v37/ff9v37Hf/8hlD9+//99+//9+vfuv+oT8LoeFwvYAIAIAKRUkKZW5kc3RyZWFt
CmVuZG9iagoyNDUgMCBvYmoKPDwvTGVuZ3RoIDIxOCA+PgpzdHJlYW0KMCAwIDAgMCA3MyA2OSBk
MQo3MyAwIDAgNjkgMCAwIGNtCkJJCi9JTSB0cnVlL1cgNzMvSCA2OS9CUEMgMS9GL0NDRi9EUDw8
L0sgLTEKL0NvbHVtbnMgNzMKL0JsYWNrSXMxIHRydWUKPj4KSUQgJrEwHwYQNZCaslztMLaa6hbp
fXpel6Xpel6Xpel6Xpel6Xpel6Xpel6Xpel6Xpel6XpcV11zRL2vf2/b9v2/b9v2/b9v2/b9v2/b
9v2/b9v2/b9v2/v29O/h6d4QaB5jBCqP4AIAIApFSQplbmRzdHJlYW0KZW5kb2JqCnhyZWYKMCAy
NDcKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDE0Nzk5IDAwMDAwIG4gCjAwMDAwMTQ3MjQgMDAw
MDAgbiAKMDAwMDAwNjc1MCAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAwMDY3MzAg
MDAwMDAgbiAKMDAwMDAxNDk0MSAwMDAwMCBuIAowMDAwMDExMTk4IDAwMDAwIG4gCjAwMDAwMTYx
NzggMDAwMDAgbiAKMDAwMDAxNjQ1NiAwMDAwMCBuIAowMDAwMDE2Njg0IDAwMDAwIG4gCjAwMDAw
MTY3NDggMDAwMDAgbiAKMDAwMDAxNjk5NiAwMDAwMCBuIAowMDAwMDE3MDYwIDAwMDAwIG4gCjAw
MDAwMTczMDcgMDAwMDAgbiAKMDAwMDAxNzM3MSAwMDAwMCBuIAowMDAwMDE3NjIyIDAwMDAwIG4g
CjAwMDAwMTc2ODYgMDAwMDAgbiAKMDAwMDAxODAwOSAwMDAwMCBuIAowMDAwMDE4MDczIDAwMDAw
IG4gCjAwMDAwMTgzMjYgMDAwMDAgbiAKMDAwMDAxODM5MSAwMDAwMCBuIAowMDAwMDE4Njc1IDAw
MDAwIG4gCjAwMDAwMTg3MzkgMDAwMDAgbiAKMDAwMDAxODk4MSAwMDAwMCBuIAowMDAwMDE5MDQ1
IDAwMDAwIG4gCjAwMDAwMTkyNzAgMDAwMDAgbiAKMDAwMDAxOTMzNCAwMDAwMCBuIAowMDAwMDE5
NTk3IDAwMDAwIG4gCjAwMDAwMTk2NjEgMDAwMDAgbiAKMDAwMDAxOTkwNyAwMDAwMCBuIAowMDAw
MDE5OTcxIDAwMDAwIG4gCjAwMDAwMjAyNzIgMDAwMDAgbiAKMDAwMDAyMDQ5OSAwMDAwMCBuIAow
MDAwMDIwNTYzIDAwMDAwIG4gCjAwMDAwMjA4NDAgMDAwMDAgbiAKMDAwMDAyMDkwNCAwMDAwMCBu
IAowMDAwMDIwOTY4IDAwMDAwIG4gCjAwMDAwMjExOTQgMDAwMDAgbiAKMDAwMDAyMTI1OCAwMDAw
MCBuIAowMDAwMDIxNTM5IDAwMDAwIG4gCjAwMDAwMjE3NDggMDAwMDAgbiAKMDAwMDAyMTgxMiAw
MDAwMCBuIAowMDAwMDIxODc2IDAwMDAwIG4gCjAwMDAwMjIxNjIgMDAwMDAgbiAKMDAwMDAyMjQw
MyAwMDAwMCBuIAowMDAwMDIyNjI1IDAwMDAwIG4gCjAwMDAwMjI4NjYgMDAwMDAgbiAKMDAwMDAy
MjkzMCAwMDAwMCBuIAowMDAwMDIzMTU4IDAwMDAwIG4gCjAwMDAwMjMyMjIgMDAwMDAgbiAKMDAw
MDAyMzQ3MiAwMDAwMCBuIAowMDAwMDIzNTM2IDAwMDAwIG4gCjAwMDAwMjM3NzIgMDAwMDAgbiAK
MDAwMDAyMzgzNiAwMDAwMCBuIAowMDAwMDIzOTAwIDAwMDAwIG4gCjAwMDAwMjQxMTUgMDAwMDAg
biAKMDAwMDAyNDI5NyAwMDAwMCBuIAowMDAwMDI0MzYxIDAwMDAwIG4gCjAwMDAwMjQ1NzIgMDAw
MDAgbiAKMDAwMDAyNDgwNyAwMDAwMCBuIAowMDAwMDI0ODcxIDAwMDAwIG4gCjAwMDAwMjUwOTAg
MDAwMDAgbiAKMDAwMDAyNTMzNCAwMDAwMCBuIAowMDAwMDI1Mzk4IDAwMDAwIG4gCjAwMDAwMjU2
NjQgMDAwMDAgbiAKMDAwMDAyNTcyOCAwMDAwMCBuIAowMDAwMDI1OTY0IDAwMDAwIG4gCjAwMDAw
MjYwMjggMDAwMDAgbiAKMDAwMDAyNjI0NSAwMDAwMCBuIAowMDAwMDI2MzA5IDAwMDAwIG4gCjAw
MDAwMjYzNzMgMDAwMDAgbiAKMDAwMDAyNjYxMCAwMDAwMCBuIAowMDAwMDI2ODQ4IDAwMDAwIG4g
CjAwMDAwMjY5MTIgMDAwMDAgbiAKMDAwMDAyNzE1NSAwMDAwMCBuIAowMDAwMDI3MjE5IDAwMDAw
IG4gCjAwMDAwMjc0NjUgMDAwMDAgbiAKMDAwMDAyNzUyOSAwMDAwMCBuIAowMDAwMDI3NTkzIDAw
MDAwIG4gCjAwMDAwMjc4NDcgMDAwMDAgbiAKMDAwMDAyNzkxMSAwMDAwMCBuIAowMDAwMDI4MTcx
IDAwMDAwIG4gCjAwMDAwMjgyMzUgMDAwMDAgbiAKMDAwMDAyODQ5NCAwMDAwMCBuIAowMDAwMDI4
NzEyIDAwMDAwIG4gCjAwMDAwMjg5NzQgMDAwMDAgbiAKMDAwMDAyOTAzOCAwMDAwMCBuIAowMDAw
MDI5MjgzIDAwMDAwIG4gCjAwMDAwMjk1MTIgMDAwMDAgbiAKMDAwMDAyOTc5MiAwMDAwMCBuIAow
MDAwMDMwMTAxIDAwMDAwIG4gCjAwMDAwMzAzMjYgMDAwMDAgbiAKMDAwMDAzMDU4MSAwMDAwMCBu
IAowMDAwMDMwNjQ1IDAwMDAwIG4gCjAwMDAwMzA5MDAgMDAwMDAgbiAKMDAwMDAzMDk2NCAwMDAw
MCBuIAowMDAwMDMxMTcxIDAwMDAwIG4gCjAwMDAwMzEyMzUgMDAwMDAgbiAKMDAwMDAzMTQ3NCAw
MDAwMCBuIAowMDAwMDMxNTM4IDAwMDAwIG4gCjAwMDAwMzE2MDMgMDAwMDAgbiAKMDAwMDAzMTgz
OSAwMDAwMCBuIAowMDAwMDMxOTA0IDAwMDAwIG4gCjAwMDAwMzIxMjUgMDAwMDAgbiAKMDAwMDAz
MjQwMiAwMDAwMCBuIAowMDAwMDMyNjQ0IDAwMDAwIG4gCjAwMDAwMzI4NjEgMDAwMDAgbiAKMDAw
MDAzMjkyNiAwMDAwMCBuIAowMDAwMDMyOTkxIDAwMDAwIG4gCjAwMDAwMzMwNTYgMDAwMDAgbiAK
MDAwMDAzMzEyMSAwMDAwMCBuIAowMDAwMDMzMzgxIDAwMDAwIG4gCjAwMDAwMzM2MzUgMDAwMDAg
biAKMDAwMDAzMzcwMCAwMDAwMCBuIAowMDAwMDMzOTkyIDAwMDAwIG4gCjAwMDAwMzQwNTggMDAw
MDAgbiAKMDAwMDAzNDMxMiAwMDAwMCBuIAowMDAwMDM0Mzc3IDAwMDAwIG4gCjAwMDAwMzQ2MTEg
MDAwMDAgbiAKMDAwMDAzNDY3NiAwMDAwMCBuIAowMDAwMDM0NzQxIDAwMDAwIG4gCjAwMDAwMzQ5
ODQgMDAwMDAgbiAKMDAwMDAzNTIxNCAwMDAwMCBuIAowMDAwMDM1Mjc5IDAwMDAwIG4gCjAwMDAw
MzUzNDQgMDAwMDAgbiAKMDAwMDAzNTYwMyAwMDAwMCBuIAowMDAwMDM1NjY4IDAwMDAwIG4gCjAw
MDAwMzU5MTIgMDAwMDAgbiAKMDAwMDAzNjE4NyAwMDAwMCBuIAowMDAwMDM2NDM3IDAwMDAwIG4g
CjAwMDAwMzY1MDMgMDAwMDAgbiAKMDAwMDAzNjc0NiAwMDAwMCBuIAowMDAwMDM2ODExIDAwMDAw
IG4gCjAwMDAwMzcwNDIgMDAwMDAgbiAKMDAwMDAzNzMyNyAwMDAwMCBuIAowMDAwMDM3MzkyIDAw
MDAwIG4gCjAwMDAwMzc2NDkgMDAwMDAgbiAKMDAwMDAzNzcxNCAwMDAwMCBuIAowMDAwMDM3OTQ3
IDAwMDAwIG4gCjAwMDAwMzgyMjAgMDAwMDAgbiAKMDAwMDAzODQ0NCAwMDAwMCBuIAowMDAwMDM4
NzAzIDAwMDAwIG4gCjAwMDAwMzg5ODggMDAwMDAgbiAKMDAwMDAzOTI1MSAwMDAwMCBuIAowMDAw
MDM5MzE2IDAwMDAwIG4gCjAwMDAwMzk1ODIgMDAwMDAgbiAKMDAwMDAzOTY0NyAwMDAwMCBuIAow
MDAwMDM5ODY0IDAwMDAwIG4gCjAwMDAwNDAxMjcgMDAwMDAgbiAKMDAwMDA0MDM3NSAwMDAwMCBu
IAowMDAwMDQwNDQxIDAwMDAwIG4gCjAwMDAwNDA1MDYgMDAwMDAgbiAKMDAwMDA0MDc5NCAwMDAw
MCBuIAowMDAwMDQxMDkyIDAwMDAwIG4gCjAwMDAwNDExNTcgMDAwMDAgbiAKMDAwMDA0MTIyMiAw
MDAwMCBuIAowMDAwMDQxNDgxIDAwMDAwIG4gCjAwMDAwNDE1NDYgMDAwMDAgbiAKMDAwMDA0MTgw
OSAwMDAwMCBuIAowMDAwMDQyMDU3IDAwMDAwIG4gCjAwMDAwNDIxMjIgMDAwMDAgbiAKMDAwMDA0
MjE4NyAwMDAwMCBuIAowMDAwMDQyMjUyIDAwMDAwIG4gCjAwMDAwNDI1MTIgMDAwMDAgbiAKMDAw
MDA0Mjc3NiAwMDAwMCBuIAowMDAwMDQyOTc4IDAwMDAwIG4gCjAwMDAwNDMwNDQgMDAwMDAgbiAK
MDAwMDA0MzEwOSAwMDAwMCBuIAowMDAwMDQzMzYxIDAwMDAwIG4gCjAwMDAwNDM1OTQgMDAwMDAg
biAKMDAwMDA0MzY2MCAwMDAwMCBuIAowMDAwMDQzNzI1IDAwMDAwIG4gCjAwMDAwNDM3OTEgMDAw
MDAgbiAKMDAwMDA0NDA2NyAwMDAwMCBuIAowMDAwMDQ0MzAyIDAwMDAwIG4gCjAwMDAwMDg3NTAg
MDAwMDAgbiAKMDAwMDAwNjkwNSAwMDAwMCBuIAowMDAwMDA4NzI4IDAwMDAwIG4gCjAwMDAwNDQ1
MDMgMDAwMDAgbiAKMDAwMDA0NDczNCAwMDAwMCBuIAowMDAwMDQ0Nzk5IDAwMDAwIG4gCjAwMDAw
NDUwNDMgMDAwMDAgbiAKMDAwMDA0NTMwMiAwMDAwMCBuIAowMDAwMDQ1NTQzIDAwMDAwIG4gCjAw
MDAwNDU3NzkgMDAwMDAgbiAKMDAwMDA0NjAzMiAwMDAwMCBuIAowMDAwMDQ2MjI4IDAwMDAwIG4g
CjAwMDAwNDYyOTMgMDAwMDAgbiAKMDAwMDA0NjQ2NiAwMDAwMCBuIAowMDAwMDQ2NzAyIDAwMDAw
IG4gCjAwMDAwNDY3NjcgMDAwMDAgbiAKMDAwMDAxMTAzOSAwMDAwMCBuIAowMDAwMDA4OTA5IDAw
MDAwIG4gCjAwMDAwMTEwMTcgMDAwMDAgbiAKMDAwMDA0NjgzMiAwMDAwMCBuIAowMDAwMDQ3MDk4
IDAwMDAwIG4gCjAwMDAwNDcxNjMgMDAwMDAgbiAKMDAwMDA0NzQzOCAwMDAwMCBuIAowMDAwMDQ3
NjQyIDAwMDAwIG4gCjAwMDAwNDc4NjggMDAwMDAgbiAKMDAwMDA0ODA0MSAwMDAwMCBuIAowMDAw
MDQ4MjY4IDAwMDAwIG4gCjAwMDAwNDg0OTAgMDAwMDAgbiAKMDAwMDA0ODc3MiAwMDAwMCBuIAow
MDAwMDQ5MDM5IDAwMDAwIG4gCjAwMDAwNDkyOTMgMDAwMDAgbiAKMDAwMDA0OTUzNSAwMDAwMCBu
IAowMDAwMDQ5ODA2IDAwMDAwIG4gCjAwMDAwNTAwNTMgMDAwMDAgbiAKMDAwMDA1MDMwMiAwMDAw
MCBuIAowMDAwMDUwNTM1IDAwMDAwIG4gCjAwMDAwNTA3ODQgMDAwMDAgbiAKMDAwMDA1MTAxOSAw
MDAwMCBuIAowMDAwMDUxMjQ5IDAwMDAwIG4gCjAwMDAwNTE0ODMgMDAwMDAgbiAKMDAwMDA1MTcx
NCAwMDAwMCBuIAowMDAwMDUxOTc4IDAwMDAwIG4gCjAwMDAwNTIzMDYgMDAwMDAgbiAKMDAwMDA1
MjU0NCAwMDAwMCBuIAowMDAwMDUyODA3IDAwMDAwIG4gCjAwMDAwNTMwNjUgMDAwMDAgbiAKMDAw
MDA1MzMzOSAwMDAwMCBuIAowMDAwMDUzNjAyIDAwMDAwIG4gCjAwMDAwNTM4NDAgMDAwMDAgbiAK
MDAwMDA1NDEwNSAwMDAwMCBuIAowMDAwMDU0MzAyIDAwMDAwIG4gCjAwMDAwNTQ2MDcgMDAwMDAg
biAKMDAwMDA1NDg3NyAwMDAwMCBuIAowMDAwMDU1MTEwIDAwMDAwIG4gCjAwMDAwNTUxNzUgMDAw
MDAgbiAKMDAwMDA1NTQ0MCAwMDAwMCBuIAowMDAwMDU1NzM5IDAwMDAwIG4gCjAwMDAwNTYwMDYg
MDAwMDAgbiAKMDAwMDA1NjI0MSAwMDAwMCBuIAowMDAwMDU2NTQwIDAwMDAwIG4gCjAwMDAwNTY4
MDAgMDAwMDAgbiAKMDAwMDA1NzA4MSAwMDAwMCBuIAowMDAwMDU3MTQ3IDAwMDAwIG4gCjAwMDAw
NTc0MDggMDAwMDAgbiAKMDAwMDA1NzY3OCAwMDAwMCBuIAowMDAwMDU3ODYxIDAwMDAwIG4gCjAw
MDAwNTgxMDUgMDAwMDAgbiAKMDAwMDA1ODMyOCAwMDAwMCBuIAowMDAwMDU4NTg4IDAwMDAwIG4g
CjAwMDAwNTg4MzIgMDAwMDAgbiAKMDAwMDAxNDg0OCAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXpl
IDI0NyAvUm9vdCAxIDAgUiAvSW5mbyAyNDYgMCBSCj4+CnN0YXJ0eHJlZgo1OTEwMQolJUVPRgo=

--ELM939813175-1691-0_

--ELM939813175-1691-0_--

From bouncefilter Wed Oct 13 07:21:47 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA95622;
Wed, 13 Oct 1999 07:21:02 -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 HAA02994;
Wed, 13 Oct 1999 07:20:13 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131120.HAA02994@candle.pha.pa.us>
Subject: Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <3804545B.FC9376E8@trust.ee> from Hannu Krosing at "Oct 13, 1999
12:43:55 pm"
To: Hannu Krosing <hannu@trust.ee>
Date: Wed, 13 Oct 1999 07:20:13 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

And perhaps some discussion about Date/Time types also in the section
for programming languages (what you get from date field, how to be
sure that what you give to postgresql is understood correctly)

The most important thing is to have alot of samples.
Practical samples are more useful than just syntax.

Agreed.

Maybe "Advanced SQL Commands" could also contain:

* Outer Joins

But we don't have them yet.

* Casts (bot AS and ::, with some explanations on why and when)

Not sure if Views and Triggers should go under Uniqe features - they are
supported on most commercial SQL databases.

Yes, I know, but Triggers are specific to the database, and I guess I
have to move views to the other section.

"Interfacing to the POSTGRESQL Database" could also contain more options
than PHP,
at least as references - there are much more of both established (CGI,
PyApache,mod_perl)

That's probably too advanced for this book. Not sure how much detail I
am going to give each interface anyway. Probably just two examples of
each.

and emerging (like the recent pgxml announcement) technologies for that
purpos.

Server side programming should also mention PL/Tcl

Added.

Under which section would requirements the restrictions (db size, field
size/count, record size/count)
or lackof them :) go?

Under Administration, or Installation.

-- 
  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 Wed Oct 13 07:22:47 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA95830;
Wed, 13 Oct 1999 07:22:36 -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 HAA03047;
Wed, 13 Oct 1999 07:21:43 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131121.HAA03047@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <3804558A.1E15A4F4@trust.ee> from Hannu Krosing at "Oct 13, 1999
12:48:58 pm"
To: Hannu Krosing <hannu@trust.ee>
Date: Wed, 13 Oct 1999 07:21:43 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

New version attached. No PDF version this time. Do people like PDF?

There could be also a chapter on client side tools - pgAccess et.al.
and also small (but working ;) examples for using ODBC from MS Access,
MS Query, Delphi, JBuilder, Visual Cafe - each about 2-5 pages to get
people started.

I wasn't sure where to put pgaccess. I will add it to interfaces. The
others are probably better left to another book, Interfaces PostgreSQL
to PC's.

-- 
  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 Wed Oct 13 07:35:49 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA98618
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 07:35:45 -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 HAA04051;
Wed, 13 Oct 1999 07:34:50 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131134.HAA04051@candle.pha.pa.us>
Subject: Re: [HACKERS] Updated book outline
In-Reply-To: <38045886.D313B9CA@prima.net.id> from Chairudin Sentosa Harjo at
"Oct 13, 1999 05:01:42 pm"
To: chai@prima.net.id
Date: Wed, 13 Oct 1999 07:34:50 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Add a subsection on chapter 1 with title:

(d) PostgreSQL Known Limitation
(i) Maximum record
(ii) Maximum field
(iii) Maximum file size
etc....

I will get those in there somewhere.

-- 
  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 Wed Oct 13 07:36:00 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id HAA98571
for <docs@postgreSQL.org>; Wed, 13 Oct 1999 07:35:20 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 7553 invoked by uid 1001); 13 Oct 1999 11:35:21 -0000
Date: Wed, 13 Oct 1999 07:35:21 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Hannu Krosing <hannu@trust.ee>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
Subject: Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <199910131120.HAA02994@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.05.9910130734280.7254-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 13 Oct 1999, Bruce Momjian wrote:

And perhaps some discussion about Date/Time types also in the section
for programming languages (what you get from date field, how to be
sure that what you give to postgresql is understood correctly)

The most important thing is to have alot of samples.
Practical samples are more useful than just syntax.

Agreed.

Maybe "Advanced SQL Commands" could also contain:

* Outer Joins

But we don't have them yet.

Yes, but we will (or should) by the time the book comes out.

From bouncefilter Wed Oct 13 07:39:50 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA99271
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 07:38:54 -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 HAA04504;
Wed, 13 Oct 1999 07:38:28 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131138.HAA04504@candle.pha.pa.us>
Subject: Re: [HACKERS] update for shlib makefiles on win32
In-Reply-To:
<2E7F82FAC1FCD2118E1500A024B3BF907DEDB2@exchange.mmp.plzen-city.cz>
from Horak Daniel at "Oct 13, 1999 01:11:43 pm"
To: Horak Daniel <horak@mmp.plzen-city.cz>
Date: Wed, 13 Oct 1999 07:38:28 -0400 (EDT)
CC: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied to 7.0 tree.

[Charset iso-8859-2 unsupported, filtering to ASCII...]

Hi,

I have changed a bit the makefiles for the win32 port - the *.def files
(created when building shared libraries) are now clean from Makefile.shlib.

I have also removed "-g" from CFLAGS in the "cygwin32" template - it can be
enabled when running configure.

Dan

----------------------------------------------
Daniel Horak
network and system administrator
e-mail: horak@mmp.plzen-city.cz
privat e-mail: dan.horak@email.cz ICQ:36448176
----------------------------------------------

[Attachment, skipping...]

-- 
  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 Wed Oct 13 07:40:49 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA99885;
Wed, 13 Oct 1999 07:40:36 -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 HAA04661;
Wed, 13 Oct 1999 07:40:23 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131140.HAA04661@candle.pha.pa.us>
Subject: PDF version of book outline
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
Date: Wed, 13 Oct 1999 07:40:22 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM939814822-4332-0_
Content-Transfer-Encoding: 7bit

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

New version attached. No PDF version this time. Do people like PDF?

Yes!

OK, here is the PDF. Three pages in length. Seems I have to use Times
Roman to get the file size acceptible for the mailing list filter.

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

--ELM939814822-4332-0_
Content-Type: application/pdf
Content-Disposition: inline; filename="/root/book.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjIKJcfsj6IKNCAwIG9iago8PC9MZW5ndGggNSAwIFIvRmlsdGVyIC9GbGF0ZURlY29k
ZT4+CnN0cmVhbQp4nL1aS3PbNhCe6dG/Qkd3JmIJkADB3hw3rzbOw1aSyUwutETbbCVRIalk8u8L
YAFiSYCSMmkzOTgGyX0/vl04jsgsVv/Mz+Xm7PPZ5xnRZ/bHcjN7vDj77ZrPSBZRMVvcncHbZEZJ
HIl0xjN4sDl/U7fdfVPevH356+LvMyGiNMlz+epidf64rv9RhymJeH/4pql3dVus1QPNgSry84xG
LM/FbE5FlFP9dbNfluqthESM2c+v6s3fVbFV5/OERYzIB3OaRISrp6+XXX1bNoapfCjgK5I8UmdS
G5FZSvLLvBci1kLQNI0SOpsnPMooCFve6Q85EqEAseb2cE6JeZ1E+mUapYbvi23X1Kv9sqtqLTKL
hIjjBH3y6bz49KthEfeyPa/arm6+ae1pJG1nzmuQJo5y0tvT6qDdxOHwtTrkEZVfpnByo22iv6Nw
sgCBFHEGJ8/cVxmcXMM7mVSTwMmTocng+wTxMBK8Vf/PIi5VMic6PuYyQKTRpI2lvkIdV5FRycXN
u4FKQMQY9JWn2AttpIiQXo333jtPnKrJlGK+gXzKC4/ORx30mk7qmd7I/HRoskxraihejlRVIWBI
X3jeeOmx90V86tTIPIEmvXrQrBTJI3QCYQlBHoEMhBKKyOjNiEwRAikd0JZ7LmJTUv7lpKRTjvVt
5L/zcSQlS5RWTEqZmNpTmaiUBuhz72ogfB4l7EAMXjrhzTvPPeEvPKNPqINjB8XnTSjzTYhS5yXf
/763fcaPPev7/vAV+OsEytfjGCFCZfjA+sb8uCT+OdBW1mlnbF9DPwpeQl6ogs2DUTBI4gNp+fwE
FV+NSTMnbLFdmVZEODLj0XJnNPvDYz9RowcCfRgKNKi2HwPs+agQ9+mcqU6uXQXFW71AsXpfwM6p
kziCTsCcdb+/Zfn1129Z9H9qWTkugs8Cxsq9mPNbQTrIKkZCRQDH7jjlGfJ+2Fe+0997tjmlXPpC
v/E645Vz6WTI+UXGaw6cysfCNofFMCoUHLRq+9T90nM1oi6LuowB4YDGp/PbHmnxvqy83pUamVFD
pq33DeA7KhDma+u77qs+pagmFQ0gQa4lyQKgxhhsVUIkIXm/eI26XNe7TbntdDOB/gIPNmX3UK9a
yyrNNKtxr6JR3n+xKwEEkxypCsJmuAZ+qUr4Fn7VGs4ZUypmoYIs8WviyK3LogWEHuscMbybelm2
IK3C0xrVO1KnV4zEBZykebsuN5oXQ8NEU+7qpqu298AtizQRx+0U2u1+p4hoCkkK9kJBswzA8w8P
Jmi4brRw2NXG5w4y7ME80mxZb54CIjd3TlgVXXFrLDlnsQpbPh1K66IxB66E3wMboqvewKqZw2b1
er8BHjK4ctZ7JSZTUdQUu2plgt4NHE3ZNRA2NEbjlGFomMF8N+fa9hlqGKFIumvKz3sb+Ni9m3pV
/bIs7PQ0T3Mlx4+H0zBsZKWIEz16EjXayufUm+Padm9el9No0s+VfyDXJUboy3qzkU2+HRpADXzK
hIupke+mK3qRkgR54XDAyFHVGbKVeWdtxXUFORBIy4e6bi1DgYZMmK5tTSiWNptphlhBTdKcchKR
/GhJmmbn9MsDCcE1dXGsGrXYfNQnL1zlxVbKUhU72bEucVmrQX69NgxSoWwrpvyDGaRcheyB1tB9
2xmq0r7OXNXWqybdA6R5ijJE5g2sCShDb956yb/XiwMREWflO2gRcxJrwx723qpqd+vim9U/hYz5
X8WS/PlRt5erqvc6bkJOKFcSsVAu7w4LxYdC5ZlSh/9wASqbonX1JOTi/1RsN2IdbGs35XYlpbJO
xssyJURV9jWNQftgpl5+Ol8FkuZZ2QUz8qFc7wCcxBHjs1TIj4BKaagwFHnXqje0nRPKLVbasvli
uDqkVtr26PSqtnd1s3FthMQyf7muyak2R3J0b6ertw142+jtHA6rzznjKisyRNdV+qFGay0L9Mg0
UaEy6idgaNkLYwsr0zRYPAoJi9pHBq4mrkfXXl59hdcG2WNnUY7a+1LhhC0IIKir7GKysOsPPC/L
umbUkNWS2K49BgEZOUKmlShz2aFqKuNLnDiA5pP9P2AedZLroSOxIKGVQMfxZtSCD67CdtQrXABe
NmXRx71uPAI7S9OiwuKiKc9ui00od7B3UgYzwo95h3MLBp1ay0DUXqxWIYFUr4ZkRgn3teoeDEDE
G7J+uEtwO/YHRX8VawZAu/EYT5KiX+BNJ0oINXde48L2lSgFcOFPiP5N1bYO/Lmw9GF8sd4bylli
67Dz3CoQkGYPwBwNgO8DzPXVghCKLHTMuU7f4C7S3+m+9E78d9Dq1CwXxu7OdV1Mfpa78RL4aUjP
a6eDMbC/RBmtJ/QEZp8t18Xeol1qR1jn03BX3OgaRhM881kfxrqyfa8PQ8ul4Q49Pd2L/qputIab
E6pXERpGGE3vjKYpQh5Xcga864Eng2Q6STPWZ1foQslohpZbeMPKJu45TtdOwtGRdveB3Ly2Tcbo
x2HYmVblw0CVHBfSg5vpyUsVT3Ci2WnB7RXlQ0DyGzdBSwibhRoCyacbwuuAS8SUjP7Se9QQhjoI
fP0RunOauAciVPPAPqv6iHR58s5Wavm6c8yraYXeeeKjDBLoBG99UYza1Uocx3Yo75tATlU5w6Az
HYPZixWgZKl7anHfsoTFDsMeBRwrCdG+QA6WGUwPqMcB7outROZ9cGQAm6ZTdt/bM0VLz5/aUQjV
CT8I+hC2u7i/hy2qFNXpe190Zfu7iQi3EDxwieT3Bz9Gji7Q+2XbI9AP3SoEjeezuBoHHdroI6J4
jPWRNZyk6ETfE9kaMoKUHFWF0GXK8H4eOfEUk70J6cOn68DUTSBSGlUu59miDwNqEYeOAVA+lhGf
D5R3qMzVyefTypt+g6YT/08a/Pt5P16ejfXi7hnSy2GFg3rlejObDnIkBE3+rKttqDGg8ceNcQdb
Py60aM+u6JhChUbZddXPzVxv8bOBpPcBFxyABaf8nYkfkYfufRHIkyMBgy1Sr/7D94mHUAu+GZxC
LfivMwYno+Y/SJgg/DiGfydNo0vNk8Xs7dnbs38BF3Um9GVuZHN0cmVhbQplbmRvYmoKNSAwIG9i
agoyMzAzCmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9NZWRpYUJveCBbMCAwIDYxMiA3
OTJdCi9QYXJlbnQgMiAwIFIKL1Jlc291cmNlcyA8PCAvUHJvY1NldCBbL1BERiAvVGV4dF0KL0Zv
bnQgPDwKL1I2IDYgMCBSCj4+Cj4+Ci9Db250ZW50cyA0IDAgUgo+PgplbmRvYmoKOSAwIG9iago8
PC9MZW5ndGggMTAgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJytWcly2zgQrZqj
v0K3UQ5kCC4gecziZFzjbLYmVTOlC03BMm0uMkhO7L8fLE0CFCBKGad8cBnE0v26+/Viz0ULj//A
77w6ezx7XCCxNvzKq8Xb1dnrK8wXVrdncitapKkbJovYS11/saqW62WxfvVqdX+GQjdI05TtWW2W
1/3NY09oQVr+KXFDz/PihYOwG2EP8R2FKw557BZxgpKup3VRb/lyANdk/A/splGaYrnSsh0l4cs+
dv14eI828h2kdv7gK04auEHElhwUuIl4Fx72xa0zb1d92RU7+VYQuXE091YrH0v4tslj8FrkJsFw
Pm8oJWXWkQ3/FPpcQCtsThzxb4nALeTn2Zb18t6C94qvSCFBJJrVbZZ3RVOLu3wXhx5C8qrQZoC3
5x8vPou1IJSviWW5optAWwnlyvnn90LeiMmL0tgEO3DRKOobvsLdKuFeFbuYGTEBEZQWSK58kQ7g
B+NbV6vhPLilbshOaS0EwsJKU8dbLx8AQCzeliff9bRtqOGte1ApWN4f1uJcasGNE8Dlhl6Xxp43
SlMwyJVx6nyquhOmXKJoHu8PE0nxIRlXJ0j9x977QeLiwOrv2PUUtHtQ8S+BAUN0yODXIkrcFI17
9mGIsJvEqW6w9bK0BMlFvRHRjGItmp8g7J1UxBoGX7FFSN9mW3GBMzjdLKt0zzuI4yH853lhQ36r
i9F1meSC3tQZGcaRwuFfiQx3ylgLzZgH4eBEt30twiErgWzUe4WCA4FbPCms4cZBA49phicIV4Bw
qkXFd2k9uK0gir7DCVFGPCwTPMNGOSWZwuIUuMuiKrpsJDyHcbafaNZcL2tb3DdlX9XAelGkbHEL
D8RoWMtYQpBXY8F+3OEiF+5uLHdfkVtCSd0VAL74lgzgdwQcNBkPbGnRPUuAAo7QHEA7WlQZfQbJ
VbQ9GOFC5EoAB5/BBCJ9Wrhax/S2oaTYSniQxikPpp/AI2rlecxhDMKpIXYjWCk6IS18NjhhZF/J
APIbvPtapidt9xfL1VjjWHVR4nqKf1W4M6w8yXOjvR8t9v5qsFnWdYQK+PxIs1GVdfndwDu+z79A
kg/3iiMVWpdTGncj9cqF1Bgpk/+pEIutnClBABbOy6xvpaYB5gRxxCsokTSj4bjty4wKPX3NpppT
gGBPO0radoxRlp8jNOZniSwFZCMjLw3+XO0aCq4fehr+XXZTAl9hxIN5EqHtcK8bjicu+FUdWEJW
YuBzm6zLJCIi1pP5asCW4rCR0GLNTSYR+vd+XkX87mQ+r/9UBWLWG6bTfJJWjVS+1/b4h6qEc8M+
Wt2ip3BNPyy0D4/UDW8P1w2aYLHOEUYpBV+vDITxwOAvy660YTxei0KeXRmeUvOYFc5xh0CeKFkW
jo9488V2RENYqvz01Vbome5n1lNmiH00ZDSNuscoE6e41qzxzSALcEasZPp9InogipTY6juxiAB4
5q+6YO0SZCdFOx9Y6dBTYIJUUKWvQbdeZiN5K2/7cnNP8m4ih59qHaYZL3NJyKaQf1yh9XLvXGSt
jP1fJZI9PifOIaFycMrvCmYKkn40BsMNj9R4qDNPRbTASsZywrauWK0kH/P4Y0ey0H1TiMyKEiNd
B9xu05LjxpKvP/EO3/kO/qPWCW2h8vSxpsm7ps571rrXuarm4NOz9HGkrMU2d7QpoXjmahxG7gcr
+4iRPMsmfxgr2SS2pYNpUs4EDbF6XMk13uEzESJ/gRmPsDpwNelAFIPkUw1DQYeahk6UuCLL8O7E
C4/ypj5CmPBmy6purVKHypsjlPpDl56P+Vopecn0GcY0+kgmkxTMzg/pm6GhAGSajGOA1LeZoCZy
GsNIItCrX7FLnNYQHSq3MOE+LO0C11oMMxUliORlDuu6POikNqNvqgYEOikE8mV531cSaj/x0ASq
fV3a/I5s+nKQEkHnti/jsZlMMJtYQ43Kpfmwlrome/5R6UWvT7T0Fnvc7/EEFGIx/1VfagNFNGNP
o320ITDbPQYym6sn1svbcaagWrZrwkivzvfEGtQwmrae7pqWnCzVVA0IVf2IJYirrGZEOHKpzeG2
FoezTBCL7ZZQbXoYzgD+Is1sMt5ZZLyUPYagQdl2yB4aaVTQiDwupU60s0Zq1WoMc+4IJYreQE58
2jxh5FAthiCHxjEPgmAGxWy3K4tcc8MXOMnI0Kc4STBxdNtE/81mMzCvry2zxpGCnULAxuGDLEmn
zLDemD+HUdQ4FwjjWU7+RcEyi4PWocKrT1m1G7rIQCStZIKNbfr+cmyaHaFZBwPoE7DJWMlwV5Gu
kJnalz2qhI02Oe+xgf6jiHPrJGWfHo5K7QdLOJ6g9qjgIcXVkFQqjX/SIU5W6kT21Iei5ow48kxk
bJPm86cGTDPhoB0lTlG3XVaWEorIlw62D4V/DIpN1pHXXVGdDsaWNMxfqJTqVDTyu4xmeSftOfxj
rGW3DHiMlfZ4zf+qB/k0lNZEktFA50qf06+Qk1YeuCnas5OaVwdq6EhpBnPKENYd1r0kosr2+fr5
avHt7NvZf68NDhZlbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCjE5MDQKZW5kb2JqCjggMCBvYmoK
PDwKL1R5cGUgL1BhZ2UKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1BhcmVudCAyIDAgUgovUmVz
b3VyY2VzIDw8IC9Qcm9jU2V0IFsvUERGIC9UZXh0XQovRm9udCA8PAovUjYgNiAwIFIKPj4KPj4K
L0NvbnRlbnRzIDkgMCBSCj4+CmVuZG9iagoxMiAwIG9iago8PC9MZW5ndGggMTMgMCBSL0ZpbHRl
ciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy1WVmTm0gSjpjH/hV6256whYGiKJg3dfue9roPxU5s
hCMmaKC7GUsgAxqP99dvHVlUFgWSPEf4wXapjjy+/PLA94KFL/7A3/n27MvZl0Ug1/Rf+XZxsT57
cRuLhfXDmdoaLIIw9MJkwfzUCxfr7Xnl/bj+7Szw+f/4vuI8b8usr5parC6D0Etpmi6WAfES8WsF
22FdnsjyvOw6uZ9QcfcyiL1Ybv90Xn/6UR7gK0wfeFc/lW3VZ3Veit8SL/J9n8ljNJavjGTa7dtd
05Wni2QrQb2E2CfgCPwgj8jbI48EacrUyh/ZdrcplWKUeUS+GgaeFDHWj0aJVqov2wexyA3MLxmM
U9WPcpU/Pligb0BBAhr2T/L9IEKbrsWKcGAi/BerxY9iMfZCLnekVu6U4Cl/k6qVtVihHt+iV944
p27VHsaVCtTKK/2cwos6T9AbIMGN+DeT7oSVK+VFITnsf5n12X02eIwJ6YztPp1nAyr8Qd1LsZJ6
AdcDjHKV1Y/77FF5JpCyqh9W1+/kcY6c4finc8tcxOO70wQJaCkkzxP5GChxYQwSIvtbhr2xTaQM
CmhRGi0DDiqu00KgDpS9nwiBV9v7sijKQj5BpRyWFQTYohnFEuPFV45il45fXTXeHFcjjT0W8FeE
GixUYuRTTnv2TIKbh+phT1DHE4njCep4IvouT8DuZwrsCEhohVpqskQctNUsBjXTwSvvJ1wABlsp
aQM6hPx/nJWVLW3iUcMyh3D7XtkGrbx0AvnCcfjlOJDRb6B3TARZUkvvcsK9H19eXAKHWnsfYC+V
khygKwRQOkc8V7a8zGMGzofAPwNsC84uOd44Frwa2wuF06/W81Q6jjrPsz+trPUYVbupISVNKj4V
/rJc8DgB07XtAhx4iBdOUPuFAh4y0tTVsPnnMbrZEfJiJ7ByOIfug17Hwh6hxUPqaxIU2Sixzf40
YfZJ5P/3kFQg+Vtnj5ve//0nrYvsFDoShd9ZFrjFwFxMsRnrBkhqDepQnMCZsgLjRvI5tfsXVVwg
xizvVek1rj55mWHKuUlaJXMQch1xbSsQ4XoHFEhknaeJ0Q/Us79N6HBXtr9DwWL4smxVIUXpcPGy
qwpZ7fBKiQ3w2rXNY5ttt1BILoksktx6eVCW15WRTcsWTV05OPyHmHQZyQI7lpV3KgOoGotKUK08
I+o4SCniKOTgvxb/y8j3pIedLsHIijOjaw5X+neuOXhdl4DjNGA+n8oobrRC7SEK72ROT3fllIi+
G4nOeAAQgXVdwzPd/7DDQn88AUjf2a/g2vdv6ldWBY+uqutb0zXSWGyIpMYRNLOTbYtsNVVoElk1
gyv2XdkqXiKeP4RjVhdwBRtwX0C3pFrNVEI5trLOVAtxkeWf9zv5bIi6RvOAgVNbdn3Tqm4slnhh
Ryv7a97NNu1WN+lL/fZ0qWzEWhtHgbnbZn/P++inptF2EjaFlvxw/Xm554Jvq//hZn66EAU/DsmA
+AiZeVP/8LhHzuUtOglGkTgeOnSatGNJ0Zi0+SYjIx5/pCLNJIdnEwXqjTlgTMpCF9FQWDQ5MrLg
92x0upi+holMkaBMgetGPJDpy7aW5sk2yNp4MqMGOmMj6UNSmUgYCtCfP2VtlvfKXkRbr86bgmNA
SZfEIqvHR62lJiMpMrkEZq9uYSHoqJkpGU9mVkVRGSlVtw0/3ZZds2/zcnAfj7zkaMi/bssv+7Lu
N9/gQjrw76r7DG7S6Fc9fsA9BFtu9jwauTjyzSj0TJt4qNl5rViTGNZcjXpgXRD9a/6SEatb1aGu
yuJAMP1R9vmQVRvNegT5a8NZFOofM6/p9rtd0/aKfyLBfMf5546f2VTKekQOkMB+RZPvt9z6A0qD
JPKiaBH7TIzTRsRkQvey2W7LNq8UDGiAqNqSj+nQEz7USbocGl6j6geO5YdvYAQLVmaaFw9hqYAm
ozVBUvGA0FMyHvMq3aQSx6mD492urIvqj5/Me0P8dn222Rh+w0hOIhvJWIU3ZT/krhAJ+3eMHslc
JXnC6BHf76ZxgtL4kjGRz4jkKKgxD1TDrw9JnEyW/kuev0X3wV+IPD+aI6qvqi2RsA5g2qxr3rFE
2AVuY+7OeG6dAsn1xYeR1DQVVQdDdsGBbIXFbghlSfiBY0v0dUDuVqwuR/EnF/duAecWzGMdOMgj
FYtMlVAWW2Arvqs5xVu5a6m1lPP/aJ4X7vqsHYIgEgx0KIrni4JlEpjCLY3neWNUMSZEP5gpp6am
dMK1wjIhootmiCK4X+TtvIkE/6zquuHMCINlgmrAi+p+U4lGcvf0TXFEImyaoOsGjnhxG0Q6q2DJ
12ARhnrba6l8ikcPPO9XuaLZMEXGu7uRIRv6chqg1t7yevW+aT4/H6UmbN+LBlIoAOcrr0rlRbyI
1lm2V1Iwk9CyjfdcAYEFAkbcLzIJQ0XQKZiQGLXkE7OGTlVY3AwEnlLWY6gcNmni3rUfVuQXxWEo
iduzjJclKKrd+Xu5aXYi2YE7yeDOr1X/BHWRScrXb6/dchD6AaZIzEQelSN7gF7T9Y+t45wSPGb8
wpOUIVMwb+KL57glJAl4Kqojw0xoJXRWInSVxXAn+Ige8VFKBcJVQCZj+pjD+ErdH6Mp2V5PZWJU
0zif8ExwRA7c44Fq6iJTJXGADFk8d9B76cnhP6dQgo0mNRoSBdTGqAZMXffEeswW/iPQt4h1Dvir
GpShiLH7FuhVo70p9rmmb8IQ2B1b4++LkY8i4O5b15fbbsQmXFPzoZBb1oNMLftmbRlhTXmO53v0
qdGyF6Gn2WvYBkBMBcCYlYrKwzA04DEf1l4bBMCbTQuEYTbdbUU6Kx0TpIgT3jdaUrN2WW5U65Kg
xrkBYKKU9AHeZIgnHrMawMaTShAMJv052z9wrlb5OEqF+5ZhnEAvSsTyq/Xi5uzm7P/8nsWxZW5k
c3RyZWFtCmVuZG9iagoxMyAwIG9iagoyMTk2CmVuZG9iagoxMSAwIG9iago8PAovVHlwZSAvUGFn
ZQovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUGFyZW50IDIgMCBSCi9SZXNvdXJjZXMgPDwgL1By
b2NTZXQgWy9QREYgL1RleHRdCi9Gb250IDw8Ci9SMTQgMTQgMCBSCi9SNiA2IDAgUgo+Pgo+Pgov
Q29udGVudHMgMTIgMCBSCj4+CmVuZG9iagoxNCAwIG9iago8PC9UeXBlL0ZvbnQvTmFtZS9SMTQv
U3VidHlwZS9UeXBlMS9CYXNlRm9udC9UaW1lcy1JdGFsaWM+PgplbmRvYmoKNiAwIG9iago8PC9U
eXBlL0ZvbnQvTmFtZS9SNi9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L1RpbWVzLVJvbWFuL0VuY29k
aW5nIDcgMCBSPj4KZW5kb2JqCjcgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9EaWZmZXJlbmNlc1sK
Mi9maV0+PgplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwozIDAgUgo4IDAg
UgoxMSAwIFIKXSAvQ291bnQgMwo+PgplbmRvYmoKMSAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAv
UGFnZXMgMiAwIFIKPj4KZW5kb2JqCjE1IDAgb2JqCjw8IC9DcmVhdGlvbkRhdGUgKEQ6MTk5OTEw
MTMwNzM5MDMpCi9Qcm9kdWNlciAoQWxhZGRpbiBHaG9zdHNjcmlwdCA1LjUwKQo+PgplbmRvYmoK
eHJlZgowIDE2CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAwNzQ0MCAwMDAwMCBuIAowMDAwMDA3
MzY4IDAwMDAwIG4gCjAwMDAwMDI0MDggMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAw
MDAyMzg4IDAwMDAwIG4gCjAwMDAwMDcyMjcgMDAwMDAgbiAKMDAwMDAwNzMxNSAwMDAwMCBuIAow
MDAwMDA0NTUyIDAwMDAwIG4gCjAwMDAwMDI1NTYgMDAwMDAgbiAKMDAwMDAwNDUzMSAwMDAwMCBu
IAowMDAwMDA2OTg5IDAwMDAwIG4gCjAwMDAwMDQ3MDAgMDAwMDAgbiAKMDAwMDAwNjk2OCAwMDAw
MCBuIAowMDAwMDA3MTUxIDAwMDAwIG4gCjAwMDAwMDc0ODkgMDAwMDAgbiAKdHJhaWxlcgo8PCAv
U2l6ZSAxNiAvUm9vdCAxIDAgUiAvSW5mbyAxNSAwIFIKPj4Kc3RhcnR4cmVmCjc1ODEKJSVFT0YK

--ELM939814822-4332-0_

--ELM939814822-4332-0_--

From bouncefilter Wed Oct 13 07:50:49 1999
Received: from meryl.csd.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA02307;
Wed, 13 Oct 1999 07:50:22 -0400 (EDT)
(envelope-from e99re41@csd.uu.se)
Received: from enequist.csd.uu.se (e99re41@enequist.csd.uu.se [130.238.15.83])
by meryl.csd.uu.se (8.8.5/8.8.5) with SMTP id NAA28216;
Wed, 13 Oct 1999 13:49:31 +0200 (MET DST)
Date: Wed, 13 Oct 1999 13:49:30 +0200 (MET DST)
From: Peter Eisentraut <e99re41@csd.uu.se>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Dmitry Samersoff <dms@wplus.net>, Vince Vielhaber <vev@michvhf.com>,
PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <199910131109.HAA02403@candle.pha.pa.us>
Message-ID: <Pine.GSO.3.96.991013134118.18359E-100000@enequist.csd.uu.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

2BOOK Authors:
Please, try to keep rights for translating this book into another
languages by you self, not by publisher.

I may ask some St.Pitersburg's publishing company
to make russian translation of this book, but some publishers
like O'Reilly have too hard license policy
and too long reaction time.

Actually, I want to make sure the book is accessible on the web. I will
keep your translation idea in mind. Good point.

What about translating the regular docs first? Are you planning on using a
lot of the existing documentation for the book? Perhaps one could organize
the distributed documentation as a sort of abridged version of the
official book, similar to what is being done with Perl. Just an idea.

And what kind of timespan did you have in mind?

I had the insane plan of providing a German documentation (at least the
User's Guide) in time for 7.0. (big market) On the other hand, I have lots
of insane plans ...

-Peter

From bouncefilter Wed Oct 13 07:51:49 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA02462
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 07:51:01 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id IAA01993;
Wed, 13 Oct 1999 08:51:08 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 13 Oct 1999 08:51:08 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Chairudin Sentosa Harjo <chai@prima.net.id>
cc: Andy Duncan <andy_j_duncan@yahoo.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <38045709.543BC497@prima.net.id>
Message-ID: <Pine.BSF.4.10.9910130850280.30583-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 13 Oct 1999, Chairudin Sentosa Harjo wrote:

Can you imagine the "PostgreSQL" book written by people from different
countries that never each other's face?
Let's imagine, 20 chapters book written by 20 people.
Each chapter is written by the person who knows best his/her part of
PostgreSQL.
Wow this is amazing!!!

I think this is like Linux to Microsoft,
but this one is PostgreSQL to Oracle.

Linux + PostgreSQL is going to beat Microsoft + Oracle.

Gag me with a spoon...please don't let it be Linux+PostgreSQL :( What a
taint on the world *that* would be...like, come on...Linux? Use a real
operating system :)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Wed Oct 13 07:54:50 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA03035;
Wed, 13 Oct 1999 07:54:32 -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 HAA05309;
Wed, 13 Oct 1999 07:54:02 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131154.HAA05309@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <Pine.GSO.3.96.991013134118.18359E-100000@enequist.csd.uu.se>
from
Peter Eisentraut at "Oct 13, 1999 01:49:30 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Wed, 13 Oct 1999 07:54:02 -0400 (EDT)
CC: Dmitry Samersoff <dms@wplus.net>, Vince Vielhaber <vev@michvhf.com>,
PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Actually, I want to make sure the book is accessible on the web. I will
keep your translation idea in mind. Good point.

What about translating the regular docs first? Are you planning on using a
lot of the existing documentation for the book? Perhaps one could organize
the distributed documentation as a sort of abridged version of the
official book, similar to what is being done with Perl. Just an idea.

And what kind of timespan did you have in mind?

I had the insane plan of providing a German documentation (at least the
User's Guide) in time for 7.0. (big market) On the other hand, I have lots
of insane plans ...

Not sure on a timespan. I think I could do most if it in one month if I
did nothing else. My wife seems supportive of the idea.

Not sure how to merge current documentation into it. I would like to
point them to URL locations as much as possible. I thought if I give
them enough to get started, and to understand how the current docs fit
together, that would be good.

-- 
  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 Wed Oct 13 08:04:49 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id IAA05133
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 08:04:47 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 7702 invoked by uid 1001); 13 Oct 1999 12:04:48 -0000
Date: Wed, 13 Oct 1999 08:04:48 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: The Hermit Hacker <scrappy@hub.org>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <Pine.BSF.4.10.9910130850280.30583-100000@thelab.hub.org>
Message-ID: <Pine.BSF.4.05.9910130804130.7254-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 13 Oct 1999, The Hermit Hacker wrote:

On Wed, 13 Oct 1999, Chairudin Sentosa Harjo wrote:

Can you imagine the "PostgreSQL" book written by people from different
countries that never each other's face?
Let's imagine, 20 chapters book written by 20 people.
Each chapter is written by the person who knows best his/her part of
PostgreSQL.
Wow this is amazing!!!

I think this is like Linux to Microsoft,
but this one is PostgreSQL to Oracle.

Linux + PostgreSQL is going to beat Microsoft + Oracle.

Gag me with a spoon...please don't let it be Linux+PostgreSQL :( What a
taint on the world *that* would be...like, come on...Linux? Use a real
operating system :)

*rofl*

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

From bouncefilter Wed Oct 13 08:08:49 1999
Received: from meryl.csd.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA06415;
Wed, 13 Oct 1999 08:08:11 -0400 (EDT)
(envelope-from e99re41@csd.uu.se)
Received: from enequist.csd.uu.se (e99re41@enequist.csd.uu.se [130.238.15.83])
by meryl.csd.uu.se (8.8.5/8.8.5) with SMTP id OAA29486;
Wed, 13 Oct 1999 14:08:02 +0200 (MET DST)
Date: Wed, 13 Oct 1999 14:08:01 +0200 (MET DST)
From: Peter Eisentraut <e99re41@csd.uu.se>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <199910131154.HAA05309@candle.pha.pa.us>
Message-ID: <Pine.GSO.3.96.991013140113.18359F-100000@enequist.csd.uu.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 13 Oct 1999, Bruce Momjian wrote:

Not sure how to merge current documentation into it. I would like to
point them to URL locations as much as possible. I thought if I give
them enough to get started, and to understand how the current docs fit
together, that would be good.

Personally, I always think that computer books that point you to URLs to
get the complete information are less than desirable. The very point of
reading the book is that you don't have to get up to your computer all the
time. Books should be self-contained and add to the existing documentation
since otherwise I won't need it.

Also, think about the fact that the online documentation might change more
quickly than a book is published. In a magazine you can do that, but in a
book that's questionable. I have a few books that are only about two years
old and the information in them is still very valid, but the URLs with all
the examples and all don't work anymore. Who knows why, I don't have the
time to find out.

But the publishers are probably a lot smarter in that area than I am.

-Peter

From bouncefilter Wed Oct 13 08:11:50 1999
Received: from meryl.csd.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA07685
for <pgsql-hackers@postgresql.org>;
Wed, 13 Oct 1999 08:10:49 -0400 (EDT)
(envelope-from e99re41@csd.uu.se)
Received: from enequist.csd.uu.se (e99re41@enequist.csd.uu.se [130.238.15.83])
by meryl.csd.uu.se (8.8.5/8.8.5) with SMTP id OAA29844
for <pgsql-hackers@postgresql.org>;
Wed, 13 Oct 1999 14:10:46 +0200 (MET DST)
Date: Wed, 13 Oct 1999 14:10:46 +0200 (MET DST)
From: Peter Eisentraut <e99re41@csd.uu.se>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgresql.org
Subject: Scripts again
Message-ID: <Pine.GSO.3.96.991013140919.18359G-100000@enequist.csd.uu.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Okay, I have the following voting results:

Well, since this is not on the immediate agenda I'll leave it open for a
while, but you see the leading vote getter.

In addition I'll add a configure option --with-pragmatic-scrappy which
will prevent the installation of the scripts altogether.

-Peter

From bouncefilter Wed Oct 13 08:51:49 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA19226;
Wed, 13 Oct 1999 08:51:30 -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 IAA06628;
Wed, 13 Oct 1999 08:51:12 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131251.IAA06628@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <Pine.GSO.3.96.991013140113.18359F-100000@enequist.csd.uu.se>
from
Peter Eisentraut at "Oct 13, 1999 02:08:01 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Wed, 13 Oct 1999 08:51:12 -0400 (EDT)
CC: PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 13 Oct 1999, Bruce Momjian wrote:

Not sure how to merge current documentation into it. I would like to
point them to URL locations as much as possible. I thought if I give
them enough to get started, and to understand how the current docs fit
together, that would be good.

Personally, I always think that computer books that point you to URLs to
get the complete information are less than desirable. The very point of
reading the book is that you don't have to get up to your computer all the
time. Books should be self-contained and add to the existing documentation
since otherwise I won't need it.

Also, think about the fact that the online documentation might change more
quickly than a book is published. In a magazine you can do that, but in a
book that's questionable. I have a few books that are only about two years
old and the information in them is still very valid, but the URLs with all
the examples and all don't work anymore. Who knows why, I don't have the
time to find out.

I just don't want to produce a 500 page book to cover these topics.

-- 
  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 Wed Oct 13 08:52:49 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA19308
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 08:52:32 -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 IAA06639;
Wed, 13 Oct 1999 08:52:16 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131252.IAA06639@candle.pha.pa.us>
Subject: Re: [HACKERS] Scripts again
In-Reply-To: <Pine.GSO.3.96.991013140919.18359G-100000@enequist.csd.uu.se>
from
Peter Eisentraut at "Oct 13, 1999 02:10:46 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Wed, 13 Oct 1999 08:52:16 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Okay, I have the following voting results:

2 for pgcreatedb, pgdropdb, pgcreateuser, pgdropuser (Bruce, me)
1 for pg_createdb, pg_dropdb, etc. (Sergio K.)
1/2 for pgadduser, etc., or sth. like that (Marc)
1/2 for leave as is (Thomas)
1 for drop altogether (Marc)

I can go for pg_createdb too.

Well, since this is not on the immediate agenda I'll leave it open for a
while, but you see the leading vote getter.

In addition I'll add a configure option --with-pragmatic-scrappy which
will prevent the installation of the scripts altogether.

I like that.

-- 
  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 Wed Oct 13 09:11:26 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA21690;
Wed, 13 Oct 1999 09:09:50 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11bOA5-0001zc-0K; Wed, 13 Oct 1999 13:09:45 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id PAA00995;
Wed, 13 Oct 1999 15:14:15 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5KMC>; Wed, 13 Oct 1999 14:07:45 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E6D8@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Bruce Momjian'" <maillist@candle.pha.pa.us>, Peter Eisentraut
<peter_e@gmx.net>
Cc: PostgreSQL-documentation <docs@postgresql.org>, PostgreSQL-development
<pgsql-hackers@postgresql.org>
Subject: RE: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
Date: Wed, 13 Oct 1999 14:07:34 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

500 pages isn't that much once you start rambling... I have an internal
document here that's already passed the 100 page mark, and it has hardly
anything in it - well it's about NT so it's not worth much any how ;-)

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: 13 October 1999 13:51
To: Peter Eisentraut
Cc: PostgreSQL-documentation; PostgreSQL-development
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book

On Wed, 13 Oct 1999, Bruce Momjian wrote:

Not sure how to merge current documentation into it. I would like

point them to URL locations as much as possible. I thought if I

give

them enough to get started, and to understand how the current docs

fit

together, that would be good.

Personally, I always think that computer books that point you to URLs

get the complete information are less than desirable. The very point

reading the book is that you don't have to get up to your computer all

the

time. Books should be self-contained and add to the existing

documentation

since otherwise I won't need it.

Also, think about the fact that the online documentation might change

quickly than a book is published. In a magazine you can do that, but

in a

book that's questionable. I have a few books that are only about two

years

old and the information in them is still very valid, but the URLs with

all

the examples and all don't work anymore. Who knows why, I don't have

the

time to find out.

I just don't want to produce a 500 page book to cover these topics.

-- 
  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 Wed Oct 13 09:18:51 1999
Received: from ritchie.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA22942
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 09:17:57 -0400 (EDT)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by ritchie.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id RAA01321;
Wed, 13 Oct 1999 17:17:56 +0400 (MSK/MSD)
X-Real-To: pgsql-hackers@postgreSQL.org
Received: (from dms@localhost)
by woland.wplus.net (8.9.2/8.9.1/wplus.2) id RAA00253;
Wed, 13 Oct 1999 17:17:56 +0400 (MSD)
Message-ID: <XFMail.991013171756.dms@wplus.net>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.GSO.3.96.991013140919.18359G-100000@enequist.csd.uu.se>
Date: Wed, 13 Oct 1999 17:17:56 +0400 (MSD)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: Peter Eisentraut <peter_e@gmx.net>
Subject: RE: [HACKERS] Scripts again
Cc: pgsql-hackers@postgreSQL.org

On 13-Oct-99 Peter Eisentraut wrote:

Okay, I have the following voting results:

2 for pgcreatedb, pgdropdb, pgcreateuser, pgdropuser (Bruce, me)
1 for pg_createdb, pg_dropdb, etc. (Sergio K.)

Me too ...
Another method is
pgadm createdb ....

1/2 for pgadduser, etc., or sth. like that (Marc)
1/2 for leave as is (Thomas)
1 for drop altogether (Marc)

Well, since this is not on the immediate agenda I'll leave it open for a
while, but you see the leading vote getter.

In addition I'll add a configure option --with-pragmatic-scrappy which
will prevent the installation of the scripts altogether.

-Peter

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

---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

From bouncefilter Wed Oct 13 09:36:50 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA25971
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 09:36:42 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id KAA02572;
Wed, 13 Oct 1999 10:36:53 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 13 Oct 1999 10:36:52 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Scripts again
In-Reply-To: <199910131252.IAA06639@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910131035200.30583-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 13 Oct 1999, Bruce Momjian wrote:

Okay, I have the following voting results:

2 for pgcreatedb, pgdropdb, pgcreateuser, pgdropuser (Bruce, me)
1 for pg_createdb, pg_dropdb, etc. (Sergio K.)
1/2 for pgadduser, etc., or sth. like that (Marc)
1/2 for leave as is (Thomas)
1 for drop altogether (Marc)

I can go for pg_createdb too.

Well, since this is not on the immediate agenda I'll leave it open for a
while, but you see the leading vote getter.

In addition I'll add a configure option --with-pragmatic-scrappy which
will prevent the installation of the scripts altogether.

I like that.

Okay, who invited this guy? :) How about drop'ng them unlessthe configure
with a --with-hand-holding option? or even --disable-sql? :)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Wed Oct 13 09:51:50 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id JAA28356
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 09:51:41 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 7900 invoked by uid 1001); 13 Oct 1999 13:51:42 -0000
Date: Wed, 13 Oct 1999 09:51:42 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Scripts again
In-Reply-To: <Pine.GSO.3.96.991013140919.18359G-100000@enequist.csd.uu.se>
Message-ID: <Pine.BSF.4.05.9910130950140.7895-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 13 Oct 1999, Peter Eisentraut wrote:

Okay, I have the following voting results:

2 for pgcreatedb, pgdropdb, pgcreateuser, pgdropuser (Bruce, me)
1 for pg_createdb, pg_dropdb, etc. (Sergio K.)
1/2 for pgadduser, etc., or sth. like that (Marc)
1/2 for leave as is (Thomas)
1 for drop altogether (Marc)

I vote with Thomas - leave as is. But I don't understand the tallying.
Did Thomas shrink so as to only get a halfa vote? :)

From bouncefilter Wed Oct 13 10:08:50 1999
Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA31688
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 10:08:38 -0400 (EDT) (envelope-from geek+@cmu.edu)
Received: from export.andrew.cmu.edu (EXPORT.ANDREW.CMU.EDU [128.2.23.2])
by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id KAA12053
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 10:08:37 -0400 (EDT)
Date: 13 Oct 1999 10:08:36 -0400
Message-ID: <emacs-smtp-24855-14340-37476-702327@export.andrew.cmu.edu>
From: Brian E Gallew <geek+@cmu.edu>
X-Mailer: BatIMail version 3.2
To: "PostgreSQL-development" <pgsql-hackers@postgreSQL.org>
In-reply-to: <199910121535.LAA21501@candle.pha.pa.us>
Subject: Re: [HACKERS] Dead CVS directoriesh
References: <199910121535.LAA21501@candle.pha.pa.us>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/signed; protocol="application/pgp-signature";
boundary="pgp-sign-Multipart_Wed_Oct_13_10:08:35_1999-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit

--pgp-sign-Multipart_Wed_Oct_13_10:08:35_1999-1
Content-Type: text/plain; charset=US-ASCII

Then <maillist@candle.pha.pa.us> spoke up and said:

Why would we want to remove it in the first place? If its been 'deleted',
it won't show up unless you want it to (cvs update -APd removed old
files/directories)...

Oops, careful in the above, it also removed any 'sticky/branch' tags...

I just thought we could fiddle with CVS to remove the stuff totally. No
real need to, though. I just thought it would be confusing for people
who didn't do -P, or people managing CVSROOT directly.

There is only one good reason for "really" pruning those old
directories out of the source tree: revision purging. If you purge
all revisions of the files that live in those directories (so that
they really *are* empty), then removing the directories is a good idea.

--
=====================================================================
| JAVA must have been developed in the wilds of West Virginia. |
| After all, why else would it support only single inheritance?? |
=====================================================================
| Finger geek@cmu.edu for my public key. |
=====================================================================

--pgp-sign-Multipart_Wed_Oct_13_10:08:35_1999-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface

iQBVAwUBOASSZIdzVnzma+gdAQE0egH9FuZ0qnyfz7mqmnDdo1ml87UE8gGsa4kb
W5Dmuqgp+2FomQh3Bg1lu3U3dJLPXeidvaksDGoMBn4SYdmES/Cqbw==
=mjgX
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Wed_Oct_13_10:08:35_1999-1--

From bouncefilter Wed Oct 13 10:18:50 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 KAA33405
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 10:18:46 -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 KAA20418;
Wed, 13 Oct 1999 10:18:00 -0400 (EDT)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sort on huge table
In-reply-to: Your message of Wed, 13 Oct 1999 19:03:20 +0900
<199910131003.TAA06423@srapc451.sra.co.jp>
Date: Wed, 13 Oct 1999 10:18:00 -0400
Message-ID: <20416.939824280@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

I came across problems with sorting a huge (2.4GB) table.

The current sorting code will fail if the data volume exceeds whatever
the maximum file size is on your OS. (Actually, if long is 32 bits,
it might fail at 2gig even if your OS can handle 4gig; not sure, but
it is doing signed-long arithmetic with byte offsets...)

I am just about to commit code that fixes this by allowing temp files
to have multiple segments like tables can.

o it took 46 minutes to complete following query:

What -S setting are you using? Increasing it should reduce the time
to sort, so long as you don't make it so large that the backend starts
to swap. The current default seems to be 512 (Kb) which is probably
on the conservative side for modern machines.

o it produced 7 sort temp files each having size of 1.4GB (total 10GB)

Yes, I've been seeing space consumption of about 4x the actual data
volume. Next step is to revise the merge algorithm to reduce that.

regards, tom lane

From bouncefilter Wed Oct 13 09:26:50 1999
Received: from ns0.metica.com (ns0.metica.com [194.200.69.178])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA24194
for <pgsql-hackers@postgresql.org>;
Wed, 13 Oct 1999 09:25:51 -0400 (EDT)
(envelope-from nigel@metica.com)
Received: from metica.com (jupiter.metica.com [192.168.2.20])
by ns0.metica.com (8.9.3/8.9.3) with ESMTP id OAA08563
for <pgsql-hackers@postgresql.org>; Wed, 13 Oct 1999 14:26:21 GMT
Sender: nigel@metica.com
Message-ID: <3804964C.741BC978@metica.com>
Date: Wed, 13 Oct 1999 15:25:16 +0100
From: Nigel Tamplin <nigel@metica.com>
Organization: Metica Limited
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: psql history buffer.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

I have compiled postgres on a few different Linux boxes (all Red Hat
i386).

My question is regarding the psql program, on some of the machines
up/down cursor lets me scroll back and forth through the history buffer,
on other machines this luxury is gone and an up cursor results in.

template1=> select date('now');
date
----------
01-01-2000
(1 row)

template1=> ^[[A

Why is this?

Are there any libraries required by pgsql that maybe are present on some
machines and not others hence the different behaviour?

Thanks,

Nigel Tamplin.

From bouncefilter Wed Oct 13 10:38:51 1999
Received: from ext16.sra.co.jp (IDENT:root@ykh28DS41.kng.mesh.ad.jp
[133.205.214.41]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA36377;
Wed, 13 Oct 1999 10:38:27 -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 XAA09782;
Wed, 13 Oct 1999 23:37:56 +0900
Message-Id: <199910131437.XAA09782@ext16.sra.co.jp>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
Subject: Re: [HACKERS] Outline for PostgreSQL book
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Wed, 13 Oct 1999 07:20:13 -0400.
<199910131120.HAA02994@candle.pha.pa.us>
Date: Wed, 13 Oct 1999 23:37:56 +0900
Sender: t-ishii@ext04.sra.co.jp

Here is my proposal for an outline for a PostgreSQL book. Many of us
have been asked by publishers about writing a book. Here is what I
think would be a good outline for the book.

I am interested in whether this is a good outline for a PostgreSQL book,
how our existing documentation matches this outline, where our existing
documentation can be managed into a published book, etc.

Any comments would be welcome.

FYI, here is the table of contents from my PostgreSQL book published
in Japan at the beginning of this year (I do not guarantee the
accuracy of translation to English, however).

Note that the second edition about to be released will contain many more
topics including MVCC, transactions, views, rules, triggers...
---
Tatsuo Ishii

-----------------------------------------------------------
Chapter 1

Introduction to PostgreSQL

1.1 History of PostgreSQL
1.2 Advantages of PostgreSQL

Chapter 2

Installation

2.1 Before installation
2.2 Preparing for installation
2.3 Compiling and installation
2.4 Setting your environment
2.5 Initialization
2.6 Adding users and creating database
2.7 Using psql
2.8 Security

Chapter 3

Learning PostgreSQL

3.1 Processes and modules
3.2 Source tree
3.3 Data types
3.4 User defined functions
3.5 User defined operators
3.6 User defined types

Chapter 4

Make applications

4.1 Tcl/Tk
4.2 C
4.3 PHP
4.4 Perl
4.5 Java

Chapter 5

Tips for PostgreSQL

5.1 Backuping database
5.2 Benchmark tests
5.3 Performance tuning
5.4 Troubles shooting
5.5 New functionalities (while writing this book 6.4 was about to release)
5.6 Developers and future plans
5.7 Resources on the Internet

Appendix

Total pages: 309

From bouncefilter Wed Oct 13 10:52:51 1999
Received: from jupiter.netgroup.de (schulz@[212.46.111.26])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA38930;
Wed, 13 Oct 1999 10:52:32 -0400 (EDT)
(envelope-from schulz@Linux-Systemhaus.de)
Received: from localhost (schulz@localhost)
by jupiter.netgroup.de (8.9.1a/8.9.1) with SMTP id QAA15285;
Wed, 13 Oct 1999 16:52:11 +0200
Date: Wed, 13 Oct 1999 16:52:11 +0200 (CEST)
From: Karsten Schulz <schulz@Linux-Systemhaus.de>
X-Sender: schulz@jupiter.netgroup.de
To: Peter Eisentraut <peter_e@gmx.net>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
Dmitry Samersoff <dms@wplus.net>, Vince Vielhaber <vev@michvhf.com>,
PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <Pine.GSO.3.96.991013134118.18359E-100000@enequist.csd.uu.se>
Message-ID: <Pine.LNX.3.95.991013164757.15201A-100000@jupiter.netgroup.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 13 Oct 1999, Peter Eisentraut wrote:

I had the insane plan of providing a German documentation (at least the
User's Guide) in time for 7.0. (big market) On the other hand, I have lots
of insane plans ...

Hi Peter,

I translated the FAQ and Linux-FAQ to german recently. I consider to
translate the online doc, too. But it is so much for one person, so I
didn't started yet. What about a cooperation?
(Warning: I really need some advices to set up my sgml system ;))

have fun!
Karsten

From bouncefilter Wed Oct 13 10:42:51 1999
Received: from penguin.hub.org (root@nat206.219.mpoweredpc.net
[142.177.206.219]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA37073
for <pgsql-hackers@postgresql.org>;
Wed, 13 Oct 1999 10:42:07 -0400 (EDT) (envelope-from jeff@hub.org)
Received: from localhost (jeff@localhost)
by penguin.hub.org (8.9.3/8.9.3) with ESMTP id LAA05561
for <pgsql-hackers@postgresql.org>; Wed, 13 Oct 1999 11:57:56 -0300
X-Authentication-Warning: penguin.hub.org: jeff owned process doing -bs
Date: Wed, 13 Oct 1999 11:57:55 -0300 (ADT)
From: Jeff MacDonald <jeff@hub.org>
Reply-To: Jeff MacDonald <jeff@hub.org>
To: pgsql-hackers@postgresql.org
Subject: Bood Idea
Message-ID: <Pine.LNX.4.10.9910131156050.28983-100000@penguin.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Marc threw this idea at me one day, thougth i'd bring it up.

Apparently Oracle has a fold out poster type deal. It shows file
structure of teh server, flowcharts etc. It's the kind of thing
that geeks put up on their(our) walls. I think it would be a simple
/good addition to an publication.

Jeff MacDonald
jeff@hub.org

===================================================================
So long as the Universe had a beginning, we can suppose it had a
creator, but if the Universe is completly self contained , having
no boundry or edge, it would neither be created nor destroyed
It would simply be.
===================================================================

From bouncefilter Wed Oct 13 11:11:51 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 LAA42485
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 11:11:01 -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 LAA20870;
Wed, 13 Oct 1999 11:10:21 -0400 (EDT)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sort on huge table
In-reply-to: Your message of Wed, 13 Oct 1999 10:18:00 -0400
<20416.939824280@sss.pgh.pa.us>
Date: Wed, 13 Oct 1999 11:10:21 -0400
Message-ID: <20868.939827421@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I wrote:

The current sorting code will fail if the data volume exceeds whatever
the maximum file size is on your OS. (Actually, if long is 32 bits,
it might fail at 2gig even if your OS can handle 4gig; not sure, but
it is doing signed-long arithmetic with byte offsets...)

I am just about to commit code that fixes this by allowing temp files
to have multiple segments like tables can.

OK, committed. I have tested this code using a small RELSEG_SIZE,
and it seems to work, but I don't have the spare disk space to try
a full-scale test with > 4Gb of data. Anyone care to try it?

I have not yet done anything about the excessive space consumption
(4x data volume), so plan on using 16+Gb of diskspace to sort a 4+Gb
table --- and that's not counting where you put the output ;-)

regards, tom lane

From bouncefilter Wed Oct 13 11:15:51 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 LAA42813
for <pgsql-hackers@postgreSQL.org>;
Wed, 13 Oct 1999 11:14:50 -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 LAA20896;
Wed, 13 Oct 1999 11:13:42 -0400 (EDT)
To: Nigel Tamplin <nigel@metica.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql history buffer.
In-reply-to: Your message of Wed, 13 Oct 1999 15:25:16 +0100
<3804964C.741BC978@metica.com>
Date: Wed, 13 Oct 1999 11:13:42 -0400
Message-ID: <20894.939827622@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Nigel Tamplin <nigel@metica.com> writes:

Are there any libraries required by pgsql that maybe are present on some
machines and not others hence the different behaviour?

Precisely. If the GNU readline library is not present when psql is
configured/built, you don't get history.

IIRC, some people have been burnt because they have installed
libreadline.a (or .so), but not readline.h. You need both, or
configure will decide to omit the feature.

regards, tom lane

From bouncefilter Wed Oct 13 11:31:53 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA45923;
Wed, 13 Oct 1999 11:31:44 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA03466;
Wed, 13 Oct 1999 12:31:09 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 13 Oct 1999 12:31:09 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Hannu Krosing <hannu@trust.ee>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
Subject: Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <199910131120.HAA02994@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910131229460.30583-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 13 Oct 1999, Bruce Momjian wrote:

Maybe "Advanced SQL Commands" could also contain:

* Outer Joins

But we don't have them yet.

As someone else mentioned previously, due to time required to write,
publish and get this out on the shelf, shouldn't we be revolving this
around the upcoming v7 release, which I believe Thomas has Outer Joins
target'd for?

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Wed Oct 13 11:52:23 1999
Received: from mail.texoma.net (mail.texoma.net [209.151.96.3])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA49412;
Wed, 13 Oct 1999 11:51:20 -0400 (EDT)
(envelope-from jhouchin@texoma.net)
Received: from texoma.net (ppp-151-100-119.texoma.net [209.151.100.119])
by mail.texoma.net (Postfix) with ESMTP
id A36E515EC63; Wed, 13 Oct 1999 10:51:18 -0500 (CDT)
Message-ID: <3804AA53.BAE48B13@texoma.net>
Date: Wed, 13 Oct 1999 10:50:43 -0500
From: Jimmie Houchin <jhouchin@texoma.net>
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
Cc: PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
References: <199910131111.HAA02615@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

I just joined this list and am getting into the middle of this thread,
but I did go back and read the archives.

Just a few comments.

To answer a previous question, I like PDFs.

I like the approach that Bruce Eckel has taken to writing his last
couple of books. It was somewhat of an opensource approach. He wrote the
book and kept it on his site in PDF format and released regular updates
based on either his additions to the book or corrections of errors and
such by readers. It helped him to develop a good rapport with his
audience. I do not believe the book being available on the web really
impacted the sales of the published book that much. I know I printed one
copy and purchased one copy.
http://www.BruceEckel.com/

One thing to consider when writing the book is keeping it on target
about PostgreSQL. I was browsing Amazon and SQL books and was reading
about the MySQL book by O'Reilly. It got some really bad reviews based
it being to general on databases and not specific about MySQL. Many said
great db book, poor MySQL book.
Read about it at, http://www.amazon.com/exec/obidos/ASIN/1565924347 .

Their are many books which cover the basics of databases and database
design and you list a few below. What is needed is a PostgreSQL book.
Their will be overlap, but the emphasis should be on database
development with PostgreSQL. That is what will differentiate it from
others.

Addison Wesley is an excellent publisher as is O'Reilly. I would
recommend trying the above approach when writing the book and find a
publisher friendly to the idea. Bruce's Thinking in Java was published
by Prentice Hall. I don't know about any of the other publishers.

Jimmie Houchin

Bruce Momjian wrote:
[snip]

FYI, I just did bibliography, and got:

(a) The Practical SQL Handbook, Bowman et al., Addison Wesley
(b) Web Development with PHP and PostgreSQL, \ldots{}, Addison Wesley
(c) A Guide to The SQL Standard, C.J. Date, Addison Wesley
(d) An Introduction to Database Systems, C.J. Date, Addison Wesley
(e) SQL For Smarties, Joe Celko, Morgan, Kaufmann

Looks like Addision Wesley is the winner.
--
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 Wed Oct 13 11:53:52 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA49666;
Wed, 13 Oct 1999 11:53:39 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id LAA04012;
Wed, 13 Oct 1999 11:52:47 -0400
Message-ID: <3804AAC9.FE9FEF75@wgcr.org>
Date: Wed, 13 Oct 1999 11:52:41 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Dmitry Samersoff <dms@wplus.net>, Vince Vielhaber <vev@michvhf.com>,
Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
References: <199910131109.HAA02403@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Actually, I want to make sure the book is accessible on the web. I will
keep your translation idea in mind. Good point.

Talk to Philip Greenspun. Morgan-Kaufman cut him a deal where his book,
"Philip and Alex's Guide to Web Publishing" is also available free on
the web (http://photo.net/wtr/thebook). His e-mail is philg@mit.edu.

And you gotta see the quality of his book! Amazon carries it.
(although, I must say, some of his choices for pictures were a little
over the top....)

--
Lamar Owen
WGCR Internet Radio
Pisgah Forest, North Carolina
1 Peter 4:11

From bouncefilter Wed Oct 13 12:47:54 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 MAA57657;
Wed, 13 Oct 1999 12:46:49 -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 MAA12870;
Wed, 13 Oct 1999 12:43:45 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131643.MAA12870@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <Pine.LNX.3.95.991013164757.15201A-100000@jupiter.netgroup.de>
from Karsten Schulz at "Oct 13, 1999 04:52:11 pm"
To: Karsten Schulz <schulz@Linux-Systemhaus.de>
Date: Wed, 13 Oct 1999 12:43:45 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>, Dmitry Samersoff <dms@wplus.net>,
Vince Vielhaber <vev@michvhf.com>,
PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 13 Oct 1999, Peter Eisentraut wrote:

I had the insane plan of providing a German documentation (at least the
User's Guide) in time for 7.0. (big market) On the other hand, I have lots
of insane plans ...

Hi Peter,

I translated the FAQ and Linux-FAQ to german recently. I consider to
translate the online doc, too. But it is so much for one person, so I
didn't started yet. What about a cooperation?
(Warning: I really need some advices to set up my sgml system ;))

I got sgmltools 2.0.1 and installed it on BSDI with no problems. Only
issue was that I needed install GNU m4. See SGML docs for sgmltools
install notes.

-- 
  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 Wed Oct 13 12:47:53 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA57682;
Wed, 13 Oct 1999 12:46:54 -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 MAA13097;
Wed, 13 Oct 1999 12:46:17 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131646.MAA13097@candle.pha.pa.us>
Subject: Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <Pine.BSF.4.10.9910131229460.30583-100000@thelab.hub.org> from
The
Hermit Hacker at "Oct 13, 1999 12:31:09 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Wed, 13 Oct 1999 12:46:17 -0400 (EDT)
CC: Hannu Krosing <hannu@trust.ee>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-documentation <docs@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 13 Oct 1999, Bruce Momjian wrote:

Maybe "Advanced SQL Commands" could also contain:

* Outer Joins

But we don't have them yet.

As someone else mentioned previously, due to time required to write,
publish and get this out on the shelf, shouldn't we be revolving this
around the upcoming v7 release, which I believe Thomas has Outer Joins
target'd for?

Yes, for 7.0, but no sense in writing stuff until it is completed. I
don't even have WAL mentioned.

-- 
  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 Wed Oct 13 12:48:58 1999
Received: from mail.texoma.net (mail.texoma.net [209.151.96.3])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA57866;
Wed, 13 Oct 1999 12:48:41 -0400 (EDT)
(envelope-from jhouchin@texoma.net)
Received: from [209.151.100.51] (ppp-151-100-146.texoma.net [209.151.100.146])
by mail.texoma.net (Postfix) with ESMTP
id 1BD9D15ECBE; Wed, 13 Oct 1999 11:48:39 -0500 (CDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: jhouchin@texoma.net (Unverified)
Message-Id: <v04020a11b42a65c44231@[209.151.100.51]>
In-Reply-To: <3804AAC9.FE9FEF75@wgcr.org>
References: <199910131109.HAA02403@candle.pha.pa.us>
Date: Wed, 13 Oct 1999 11:48:24 -0500
To: Lamar Owen <lamar.owen@wgcr.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
From: Jimmie Houchin <jhouchin@texoma.net>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
Cc: PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>

Hello,

I agree with your comments here. When I posted my message I had forgotten
about Philip's book. Excellent book and website, photos, many are great and
many are as you say "a little over the top".

Based on his book which I learned about from his articles on LinuxWorld I
have decided to deploy my website with AOLserver. I currently am planning
to use PostgreSQL for the database.

He does a great job of discussing how to develop excellent websites.

Jimmie Houchin

At 11:52 AM -0400 10/13/99, Lamar Owen wrote:

Bruce Momjian wrote:

Actually, I want to make sure the book is accessible on the web. I will
keep your translation idea in mind. Good point.

Talk to Philip Greenspun. Morgan-Kaufman cut him a deal where his book,
"Philip and Alex's Guide to Web Publishing" is also available free on
the web (http://photo.net/wtr/thebook). His e-mail is philg@mit.edu.

And you gotta see the quality of his book! Amazon carries it.
(although, I must say, some of his choices for pictures were a little
over the top....)

--
Lamar Owen
WGCR Internet Radio
Pisgah Forest, North Carolina
1 Peter 4:11

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

From bouncefilter Wed Oct 13 13:02: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 NAA60329;
Wed, 13 Oct 1999 13:01:52 -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 MAA13573;
Wed, 13 Oct 1999 12:52:23 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131652.MAA13573@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <3804AA53.BAE48B13@texoma.net> from Jimmie Houchin at "Oct 13,
1999 10:50:43 am"
To: Jimmie Houchin <jhouchin@texoma.net>
Date: Wed, 13 Oct 1999 12:52:23 -0400 (EDT)
CC: PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello,

I just joined this list and am getting into the middle of this thread,
but I did go back and read the archives.

Just a few comments.

To answer a previous question, I like PDFs.

I like the approach that Bruce Eckel has taken to writing his last
couple of books. It was somewhat of an opensource approach. He wrote the
book and kept it on his site in PDF format and released regular updates
based on either his additions to the book or corrections of errors and
such by readers. It helped him to develop a good rapport with his
audience. I do not believe the book being available on the web really
impacted the sales of the published book that much. I know I printed one
copy and purchased one copy.
http://www.BruceEckel.com/

Yes, I would like to do that, and the publisher I was talking to today
seemed to think it was fine. He said it helps sell books. I would be
very unhappy if the book could not be put on the web. In fact, he is
subscribed to the hackers list, so he may be reading this.

One thing to consider when writing the book is keeping it on target
about PostgreSQL. I was browsing Amazon and SQL books and was reading
about the MySQL book by O'Reilly. It got some really bad reviews based
it being to general on databases and not specific about MySQL. Many said
great db book, poor MySQL book.
Read about it at, http://www.amazon.com/exec/obidos/ASIN/1565924347 .

Good point. I will keep it in mind.

Their are many books which cover the basics of databases and database
design and you list a few below. What is needed is a PostgreSQL book.
Their will be overlap, but the emphasis should be on database
development with PostgreSQL. That is what will differentiate it from
others.

Good. And I will show actual PostgreSQL examples in the book, with
PostgreSQL output from psql, etc.

Addison Wesley is an excellent publisher as is O'Reilly. I would
recommend trying the above approach when writing the book and find a
publisher friendly to the idea. Bruce's Thinking in Java was published
by Prentice Hall. I don't know about any of the other publishers.

Yes, I am a big Addison Wesley fan. I realized this when I found most
of the books I like were from them. I am not a big O'Reilly fan, though
I have a few of their books.

-- 
  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 Wed Oct 13 13: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 NAA60511;
Wed, 13 Oct 1999 13:02:52 -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 MAA13583;
Wed, 13 Oct 1999 12:53:33 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910131653.MAA13583@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <3804AAC9.FE9FEF75@wgcr.org> from Lamar Owen at "Oct 13,
1999 11:52:41 am"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Wed, 13 Oct 1999 12:53:33 -0400 (EDT)
CC: Dmitry Samersoff <dms@wplus.net>, Vince Vielhaber <vev@michvhf.com>,
Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Actually, I want to make sure the book is accessible on the web. I will
keep your translation idea in mind. Good point.

Talk to Philip Greenspun. Morgan-Kaufman cut him a deal where his book,
"Philip and Alex's Guide to Web Publishing" is also available free on
the web (http://photo.net/wtr/thebook). His e-mail is philg@mit.edu.

And you gotta see the quality of his book! Amazon carries it.
(although, I must say, some of his choices for pictures were a little
over the top....)

Again, having it on the web will be done. No better way to have it
available to everyone, and it helps sell books, and the publisher thinks
that is fine.

Morgan-Kaufmann is good, but I don't have many of their books.

-- 
  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 Wed Oct 13 13:01:53 1999
Received: from aixrs1.hrz.uni-essen.de (spa113.power.uni-essen.de
[132.252.181.13]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA60211
for <pgsql-hackers@postgresql.org>;
Wed, 13 Oct 1999 13:01:10 -0400 (EDT)
(envelope-from joerg.rudnick@uni-essen.de)
Received: from pool-dc (pool-dc.pul.uni-essen.de [132.252.54.200]) by
aixrs1.hrz.uni-essen.de (8.8.8/8.7) with SMTP id SAA35374 for
<pgsql-hackers@postgresql.org>; Wed, 13 Oct 1999 18:00:55 +0100
Date: Wed, 13 Oct 1999 18:00:55 +0100
Message-Id: <199910131700.SAA35374@aixrs1.hrz.uni-essen.de>
X-Sender: sw0631@aixrs1.hrz.uni-essen.de
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
To: pgsql-hackers@postgresql.org
From: =?iso-8859-1?Q?J=F6rg?= Rudnick <joerg.rudnick@uni-essen.de>
Subject: SQL Functions on Composite Types - what's the purpose??
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id NAA60331

ORIGINALLY: pgsql-sql@postgresql.org, Tue 21 Sep 1999 16:48:57 +0200

ADDENDUM: The problem seems to remain in PostgreSQL 6.5.2. I have found
related comments here at pgsql-hackers since about a year ago; is there any
general advice??

[Chapter 39, Programmer's Guide / PostgreSQL 6.4]
WHAT DO I MAKE WRONG??

Did I try to abuse PostgreSQL dread or was there just a mistake??
How do you realize nested relations if not by OIDs??
Did I misunderstand the purpose of SQL functions on composite types??

Who has an answer??

You offer SQL functions that return tuples as composite types, but once
I try to use it by another SQL function with the same class as
parameter, I receive the error message:

Function '...' has bad return type 18826

/* Example:

CREATE TABLE class (attribute text);

CREATE FUNCTION tuple() RETURNS class
AS 'SELECT \'content\'::text AS attribute;'
LANGUAGE 'sql';

CREATE FUNCTION get_attribute(class) RETURNS text
AS 'SELECT $1.attribute AS result;'
LANGUAGE 'sql';

SELECT get_attribute(tuple());

If the composite type producer is put into an attribute, whilst trying
to read from a table containing the composite attribute I will receive:

Functions on sets are not yet supported

/* Example:

CREATE TABLE container (composite_attribute class);

INSERT INTO container VALUES (tuple());

SELECT get_attribute(composite_attribute) FROM container;

It seems that SQL functions with composite parameters do only work on
'raw' tuples of a relational table, don't they??

On the other hand, the attribute(class) function works quite well on
composite returns of SQL functions*.
But the interesting thing, reading from composite attributes, fails with
message:

init_fcache: cache lookup failed for procedure 136280528

/* Example:

SELECT attribute(composite_attribute) FROM container;

* There are seemingly some fatal exceptions, which lead to:

pqReadData() -- backend closed the channel unexpectedly
This probably means the backend terminated
abnormally before or while processing the request.
We have lost the connection to the backend, so
further processing is impossible. Terminated.
nick@weg:~> ~( >;->)

/* Example:

CREATE FUNCTION get_class(class) RETURNS class
AS 'SELECT $1.attribute AS attribute;'
LANGUAGE 'sql';

SELECT attribute(get_class(composite_attribute)) FROM container;

@your service@your service@your service@your service@your service@your service@
Jï¿½rg R. Rudnick
Software Developer
EMail: Joerg.Rudnick@uni-essen.de

From bouncefilter Wed Oct 13 16:39:57 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA93210
for <pgsql-hackers@postgresql.org>;
Wed, 13 Oct 1999 16:39:30 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:1048 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s/Cri135459>;
Wed, 13 Oct 1999 22:39:10 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11bRvh-0000fX-00; Wed, 13 Oct 1999 19:11:09 +0200
Date: Wed, 13 Oct 1999 19:11:09 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: The Hermit Hacker <scrappy@hub.org>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Scripts again
In-Reply-To: <Pine.BSF.4.10.9910131035200.30583-100000@thelab.hub.org>
Message-ID: <Pine.LNX.4.10.9910131908020.2573-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 13, The Hermit Hacker mentioned:

On Wed, 13 Oct 1999, Bruce Momjian wrote:

Okay, I have the following voting results:

2 for pgcreatedb, pgdropdb, pgcreateuser, pgdropuser (Bruce, me)
1 for pg_createdb, pg_dropdb, etc. (Sergio K.)
1/2 for pgadduser, etc., or sth. like that (Marc)
1/2 for leave as is (Thomas)
1 for drop altogether (Marc)

I can go for pg_createdb too.

Well, since this is not on the immediate agenda I'll leave it open for a
while, but you see the leading vote getter.

In addition I'll add a configure option --with-pragmatic-scrappy which
will prevent the installation of the scripts altogether.

I like that.

Okay, who invited this guy? :) How about drop'ng them unlessthe configure
with a --with-hand-holding option? or even --disable-sql? :)

I like that even better. Watch out, it might become a standard option in
autoconf soon.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Wed Oct 13 16:40:03 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA93183
for <pgsql-hackers@postgresql.org>;
Wed, 13 Oct 1999 16:39:10 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:1044 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s/CrZ119075>;
Wed, 13 Oct 1999 22:39:01 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11bSBq-0000fd-00; Wed, 13 Oct 1999 19:27:50 +0200
Date: Wed, 13 Oct 1999 19:27:50 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Vince Vielhaber <vev@michvhf.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Scripts again
In-Reply-To: <Pine.BSF.4.05.9910130950140.7895-100000@paprika.michvhf.com>
Message-ID: <Pine.LNX.4.10.9910131911130.2573-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 13, Vince Vielhaber mentioned:

On Wed, 13 Oct 1999, Peter Eisentraut wrote:

Okay, I have the following voting results:

2 for pgcreatedb, pgdropdb, pgcreateuser, pgdropuser (Bruce, me)
1 for pg_createdb, pg_dropdb, etc. (Sergio K.)
1/2 for pgadduser, etc., or sth. like that (Marc)
1/2 for leave as is (Thomas)
1 for drop altogether (Marc)

I vote with Thomas - leave as is. But I don't understand the tallying.
Did Thomas shrink so as to only get a halfa vote? :)

He didn't make his opinion exactly clear, except that the underscores are
a sign of the coming apocalypse. (If you ask Marc, he can probably give
you an alternate theory here...)

I suppose that would subtract another half vote from the underscore
option. With Bruce's defection and my own change of mind we now stand at

0 pgblah
3 1/2 pg_blah (Bruce, Sergio K, Dmitry S, -1/2 Thomas, myself)
1/2 pgadddb (Marc)
1 1/2 as is (Thomas, Vince)
1 none (Marc)

Hmm, I guess that does it. pg_createdb and symlinks for one release with
warnings for deprecated forms.

Perhaps we should really change the installation instructions to not make
mention of the scripts, though, to enforce proper learning. But you were
working on that anyway, right?

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Wed Oct 13 16:39:55 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA93209
for <pgsql-hackers@postgresql.org>;
Wed, 13 Oct 1999 16:39:30 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:1052 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s/Crp71982>;
Wed, 13 Oct 1999 22:39:17 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11bSGY-0000ff-00; Wed, 13 Oct 1999 19:32:42 +0200
Date: Wed, 13 Oct 1999 19:32:42 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql Week 2
In-Reply-To: <199910120055.JAA01440@ext16.sra.co.jp>
Message-ID: <Pine.LNX.4.10.9910131929030.2573-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 12, Tatsuo Ishii mentioned:

Will the new psql replace the old one in 7.0? If so, I need to work on
it to incomporate the multi-byte capability. Peter, can you tell me
when you will finish the work?

If I don't terminally mess it up I thunk that was the plan.

I was initially planning on 4 weeks, but this week is really tight, so I
might need to finish with less. I don't want to occupy this thing forever
either.

Meanwhile I (think I) have been careful about multibyte stuff but it's
probably good if you take a look. Perhaps you can start with the tarball I
posted. It should be working.

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Wed Oct 13 16:40:55 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA93332
for <pgsql-hackers@postgresql.org>;
Wed, 13 Oct 1999 16:40:02 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:1058 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s/CsE94510>;
Wed, 13 Oct 1999 22:39:44 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11bSKs-0000fk-00; Wed, 13 Oct 1999 19:37:10 +0200
Date: Wed, 13 Oct 1999 19:37:10 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql Week 2
In-Reply-To: <10299.939691695@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.10.9910131933090.2573-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 11, Tom Lane mentioned:

Peter Eisentraut <peter_e@gmx.net> writes:

2. What about including an snprintf() into the source tree similar what is
done with strdup()?

There is one in the backend/port/ directory, along with some other
important library routines that are missing on certain platforms.
Up to now we haven't worried about including these into anything but
the backend, but I see no reason not to include them into psql if
you need 'em. (Probably would not be a good idea to put them into
libpq though, since that could cause conflicts with user apps that
supply their own versions.) See backend/port/Makefile.in for the
tests that determine whether individual routines need to be included.

Okay, I'm sorry, I guess I never dug that far into the backend for that.
All those things seem kind of useful, so for good measure they could
perhaps be moved into the src/utils dir or a src/port dir.

I was not talking about putting them into libpq as public functions but if
someone working on libpq needed them there a way could surely be found.
Not me though right now.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden