pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedOpen 6.4 items
141+ messages / 19 participants
[nested] [flat]
* Open 6.4 items
@ 1998-08-24 02:08 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 3 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-08-24 02:08 UTC (permalink / raw)
To: hackers@postgreSQL.org
With the 6.4 beta just over a week away, here are the open items I see
for 6.4. We actually have fewer than usual, so that is a good thing.
Many of the latter ones are fairly rare bugs.
---------------------------------------------------------------------------
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
permissions on indexes: what do they do? should it be prevented?
man pages/sgml synchronization (dump out man pages as postscript?)
cidr/IP address type
low level locking - status?
improve reporting of syntax errors by showing location of error in query
clean up username and indentifier length problems
large object improvements
use index with constants on functions
allow chainging of pages to allow >8k tuples
SERIAL type auto-creates sequence
fix problem when DEFAULT string for CHAR() is not same as column
remove PARSEDEBUG defines if not longer needed
SELECT oid @ oid @ oid FROM pg_user fails with parser error, not function error
CONSTRAINT does not pg_dump properly, paren problem
double-quotes from pg_dump of field names
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects issues
improve group handling
re-assign resno's for rewrite system
order by mis-ordering result(Tom Lane/HPUX)
have psql dump out rules text with new function
Allow IN in DEFAULT section
make identifiers 31 in scanner
cnf-ify still can exhaust memory
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-24 07:34 Peter T Mount <peter@retep.org.uk>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
2 siblings, 0 replies; 141+ messages in thread
From: Peter T Mount @ 1998-08-24 07:34 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: PostgreSQL-development <hackers@postgresql.org>
On Sun, 23 Aug 1998, Bruce Momjian wrote:
> With the 6.4 beta just over a week away, here are the open items I see
> for 6.4. We actually have fewer than usual, so that is a good thing.
> Many of the latter ones are fairly rare bugs.
>
> ---------------------------------------------------------------------------
>
>
> large object improvements
> large objects issues
+ Some JDBC Stuff
I've been held up over the last 4 weeks with other things, but I'm putting
most of this week aside to get these ready for the beta
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-24 15:27 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
2 siblings, 3 replies; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-08-24 15:27 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: PostgreSQL-development <hackers@postgreSQL.org>
> man pages/sgml synchronization (dump out man pages as postscript?)
I'll need the sgml docs to firm up two weeks before release (Sept 15?)
to give time to generate hardcopy. The admin guide will be the last
converted, and it has the release notes and installation procedure which
need to be updated. Can we think about how to do the release notes and
installation for this release? I would suggest having a short readme on
how to install and read the docs, and have the detailed installation
procedure in sgml->html/hardcopy.
> improve reporting syntax errors by showing location of error in query
We haven't had this in previous releases. Not required for v6.4, right?
> use index with constants on functions
We haven't had this in previous releases. I know how to do it, I think,
but am not seeing when I could get to it. How important is it??
> allow chainging of pages to allow >8k tuples
One week before beta freeze. Won't be in v6.4, right?
> SERIAL type auto-creates sequence
I won't have time to do this for v6.4. It's not quite the same as the
PRIMARY KEY parser solution, since the sequence must be created _before_
the main portion of the CREATE TABLE command is executed, rather than
after. We should go through the high-level parser routines and allow all
of them to return multiple parse trees; at the moment I've got a
special-case workaround implemented for the PRIMARY KEY code which
doesn't generalize very well.
> fix problem when DEFAULT string for CHAR() is not same as column
Who is pursuing this? Where does the problem come from?
> remove PARSEDEBUG defines if not longer needed
Yeah, yeah :)
> double-quotes from pg_dump of field names
I have some patches for this, but have not had time to test yet.
> Allow IN in DEFAULT section
Already done and in the cvs tree:
postgres=> create table t (i int, check (i in (1, 2, 3)));
CREATE
I fixed NOT LIKE and NOT IN at the same time...
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-24 16:04 Brook Milligan <brook@trillium.NMSU.Edu>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
2 siblings, 0 replies; 141+ messages in thread
From: Brook Milligan @ 1998-08-24 16:04 UTC (permalink / raw)
To: lockhart@alumni.caltech.edu; +Cc: maillist@candle.pha.pa.us; hackers@postgreSQL.org
> SERIAL type auto-creates sequence
I won't have time to do this for v6.4. It's not quite the same as the
PRIMARY KEY parser solution, since the sequence must be created _before_
the main portion of the CREATE TABLE command is executed, rather than
after. We should go through the high-level parser routines and allow all
of them to return multiple parse trees; at the moment I've got a
special-case workaround implemented for the PRIMARY KEY code which
doesn't generalize very well.
Actually, sequences can be defined _either_ before or after the
table. See below.
Cheers,
Brook
===========================================================================
-- create id sequence before table
drop sequence id_sequence_before;
create sequence id_sequence_before start 1;
-- create table
drop table id_table;
create table id_table
(
id_before int4 default nextval ('id_sequence_before'),
id_after int4 default nextval ('id_sequence_after'),
name text
);
-- create id sequence after table
drop sequence id_sequence_after;
create sequence id_sequence_after start 1;
-- populate table
insert into id_table (name) values ('one');
insert into id_table (name) values ('two');
insert into id_table (name) values ('three');
select * from id_table;
===========================================================================
id_before|id_after|name
---------+--------+-----
1| 1|one
2| 2|two
3| 3|three
(3 rows)
===========================================================================
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 01:01 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
2 siblings, 1 reply; 141+ messages in thread
From: Tom Lane @ 1998-08-25 01:01 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: hackers@postgreSQL.org
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> With the 6.4 beta just over a week away, here are the open items I see
> for 6.4. We actually have fewer than usual, so that is a good thing.
I had a few other things on my list:
* make PGconn,PGresult truly opaque to applications (per recent discussion)
* libpgtcl is missing any way to access PQerrorMessage!?
* remove writable fields in static PQconninfoOptions for thread safety
* bring libpq.sgml documentation fully up to speed
(I'm willing to do the above four, but am not promising that the doco
will get done before Sept 1. I think Thomas indicated that Sept 15
is OK for docs?)
* put UNLISTEN in standard backend, fix libpgtcl listen support to use it
I would really like to see this in 6.4, because I need UNLISTEN in my
applications. Thomas had volunteered to add the needed parser support
for UNLISTEN (the execution function already exists, it just needs a
statement that can call it). As far as I've heard he hasn't gotten to
it yet. I can fix libpgtcl but do not want to touch it unless the
underlying backend support is there.
* psql: control-c ought to stop lengthy output
* psql's \z output truncates table names at 16 chars
* psql and libpgtcl insert unexpected backslashes in output data
I was going to work on these but it's looking like they will not make
the Sept 1 cut. Anyone else want to do them?
> change pg args for platforms that don't support argv changes
> (setproctitle()?, sendmail hack?)
I'd like to see this in there too, and will work on it if no one else
does, but I rather doubt I can get to it by Sept 1. Maybe this will
have to wait for 6.5, or 6.4.1, or something.
regards, tom lane
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 02:58 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
2 siblings, 3 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-08-25 02:58 UTC (permalink / raw)
To: lockhart@alumni.caltech.edu; +Cc: hackers@postgreSQL.org
> > man pages/sgml synchronization (dump out man pages as postscript?)
>
> I'll need the sgml docs to firm up two weeks before release (Sept 15?)
> to give time to generate hardcopy. The admin guide will be the last
> converted, and it has the release notes and installation procedure which
> need to be updated. Can we think about how to do the release notes and
> installation for this release? I would suggest having a short readme on
> how to install and read the docs, and have the detailed installation
> procedure in sgml->html/hardcopy.
Yep. Remember Marc's rule that you can't add features after beta
starts, but you can be fixing things. That buys us a lot of time.
>
> > improve reporting syntax errors by showing location of error in query
>
> We haven't had this in previous releases. Not required for v6.4, right?
Not required. Again, there are NEW items. If they don't get fixed,
they are moved to the TODO list.
>
> > use index with constants on functions
>
> We haven't had this in previous releases. I know how to do it, I think,
> but am not seeing when I could get to it. How important is it??
Probably too large for 6.4 at this point.
>
> > allow chainging of pages to allow >8k tuples
>
> One week before beta freeze. Won't be in v6.4, right?
Right.
>
> > SERIAL type auto-creates sequence
>
> I won't have time to do this for v6.4. It's not quite the same as the
> PRIMARY KEY parser solution, since the sequence must be created _before_
> the main portion of the CREATE TABLE command is executed, rather than
> after. We should go through the high-level parser routines and allow all
> of them to return multiple parse trees; at the moment I've got a
> special-case workaround implemented for the PRIMARY KEY code which
> doesn't generalize very well.
This would be nice to have for 6.4. Someone mentioned you can create
the sequence before the table, so maybe we can jam it in. If it is not
100% correct, we have a month to make it correct, right?
>
> > fix problem when DEFAULT string for CHAR() is not same as column
>
> Who is pursuing this? Where does the problem come from?
I am attaching the posting describing the problem. If anyone wants to
see the actual problem reports for any item, let me know. I can send
you my entire mailbox of 70 items if you wish.
>
> > remove PARSEDEBUG defines if not longer needed
>
> Yeah, yeah :)
Remember, I suggested a way you could keep them with more eligant
defines. Any comments?
>
> > double-quotes from pg_dump of field names
>
> I have some patches for this, but have not had time to test yet.
Cool. Let the beta testers test it!
>
> > Allow IN in DEFAULT section
>
> Already done and in the cvs tree:
> postgres=> create table t (i int, check (i in (1, 2, 3)));
> CREATE
>
> I fixed NOT LIKE and NOT IN at the same time...
Great.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
Attachments:
/tmp/i (text/plain, 0B) download
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 03:56 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-08-25 03:56 UTC (permalink / raw)
To: tgl@sss.pgh.pa.us; +Cc: hackers@postgreSQL.org
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > With the 6.4 beta just over a week away, here are the open items I see
> > for 6.4. We actually have fewer than usual, so that is a good thing.
>
> I had a few other things on my list:
>
> * make PGconn,PGresult truly opaque to applications (per recent discussion)
> * libpgtcl is missing any way to access PQerrorMessage!?
> * remove writable fields in static PQconninfoOptions for thread safety
> * bring libpq.sgml documentation fully up to speed
>
> (I'm willing to do the above four, but am not promising that the doco
> will get done before Sept 1. I think Thomas indicated that Sept 15
> is OK for docs?)
Sounds good to me.
>
> * put UNLISTEN in standard backend, fix libpgtcl listen support to use it
>
> I would really like to see this in 6.4, because I need UNLISTEN in my
> applications. Thomas had volunteered to add the needed parser support
> for UNLISTEN (the execution function already exists, it just needs a
> statement that can call it). As far as I've heard he hasn't gotten to
> it yet. I can fix libpgtcl but do not want to touch it unless the
> underlying backend support is there.
>
> * psql: control-c ought to stop lengthy output
> * psql's \z output truncates table names at 16 chars
> * psql and libpgtcl insert unexpected backslashes in output data
>
> I was going to work on these but it's looking like they will not make
> the Sept 1 cut. Anyone else want to do them?
Not really sure anyone else knows those areas. I am surprised by the
psql \z. Of course, if you add the "features" now, you can fix the bugs
during beta.
>
>
> > change pg args for platforms that don't support argv changes
> > (setproctitle()?, sendmail hack?)
>
> I'd like to see this in there too, and will work on it if no one else
> does, but I rather doubt I can get to it by Sept 1. Maybe this will
> have to wait for 6.5, or 6.4.1, or something.
Again, can be done later. Will be a problem without the fix.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 03:59 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
2 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-08-25 03:59 UTC (permalink / raw)
To: lockhart@alumni.caltech.edu; +Cc: hackers@postgreSQL.org
> > man pages/sgml synchronization (dump out man pages as postscript?)
>
> I'll need the sgml docs to firm up two weeks before release (Sept 15?)
> to give time to generate hardcopy. The admin guide will be the last
> converted, and it has the release notes and installation procedure which
> need to be updated. Can we think about how to do the release notes and
> installation for this release? I would suggest having a short readme on
> how to install and read the docs, and have the detailed installation
> procedure in sgml->html/hardcopy.
I wanted to comment on this. Are you going sgml crazy? :-) (We need
more humor here.)
Do we have to sgml everything? Perhaps we can add an sgml mode to psql
like the html mode we have?
I think some things that are referenced only occasionally or on screen
are better left as flat text files. Why not just let them pull it up
with more or vi?
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 06:13 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 2 replies; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-08-25 06:13 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: hackers@postgreSQL.org
> Do we have to sgml everything? Perhaps we can add an sgml mode to
> psql like the html mode we have?
No, we don't have to sgml everything. But, it makes the difference
between flat text files and true documentation. Not everyone wants to
bother writing it, but it really makes the difference between hacker
code and a usable system imho.
> I think some things that are referenced only occasionally or on screen
> are better left as flat text files. Why not just let them pull it up
> with more or vi?
That is possible. But why are fundamental things like installation
instructions or release notes better left as flat files? Can't quite see
why a user would think so. We can choose what docs we write and maintain
for the system, and we can choose how we make them look. It maybe isn't
too suprising how little interest people have in writing documentation,
but I'm the wrong person to ask whether sgml is the right way to go.
I'm currently listing 326 source and product files of documentation
resources in the Postgres system (a few files are obsolete with
conversion to sgml). This does not including html output files. There
are 50 README files. There are over 88 man pages. These are all
unstructured docs, with no clear organization. How should someone
remember which README to look in? Or what man page to try?? It's a
volume of information which needs organizing and structuring into a
predictable presentation for a user. I'm using as my model for
documentation those I've found useful over the years. None of them
struck me as something better left as a flat text file.
Anyway, that's my $0.02...
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 06:26 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1 sibling, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-08-25 06:26 UTC (permalink / raw)
To: lockhart@alumni.caltech.edu; +Cc: hackers@postgreSQL.org
> > Do we have to sgml everything? Perhaps we can add an sgml mode to
> > psql like the html mode we have?
>
> No, we don't have to sgml everything. But, it makes the difference
> between flat text files and true documentation. Not everyone wants to
> bother writing it, but it really makes the difference between hacker
> code and a usable system imho.
I am concerned about people installing on systems that don't have
graphic monitors or can print postscript. What do we tell them?
>
> > I think some things that are referenced only occasionally or on screen
> > are better left as flat text files. Why not just let them pull it up
> > with more or vi?
>
> That is possible. But why are fundamental things like installation
> instructions or release notes better left as flat files? Can't quite see
> why a user would think so. We can choose what docs we write and maintain
> for the system, and we can choose how we make them look. It maybe isn't
> too suprising how little interest people have in writing documentation,
> but I'm the wrong person to ask whether sgml is the right way to go.
>
> I'm currently listing 326 source and product files of documentation
> resources in the Postgres system (a few files are obsolete with
> conversion to sgml). This does not including html output files. There
> are 50 README files. There are over 88 man pages. These are all
> unstructured docs, with no clear organization. How should someone
> remember which README to look in? Or what man page to try?? It's a
> volume of information which needs organizing and structuring into a
> predictable presentation for a user. I'm using as my model for
> documentation those I've found useful over the years. None of them
> struck me as something better left as a flat text file.
>
> Anyway, that's my $0.02...
OK. As long as we can generate flat too for those that can't use fancy
stuff. Certainly it is better than flat files if both are available for
novices trying to get started.
I agree we have TONS of stuff that needs serious organization. But I
also like to have the stuff availble in quick format like man pages and
ascii files that I can grep and pull up quickly.
psql has the \h help command because it gives people information in a
handy way. Man pages are the same. 'more INSTALL' may be the same?
Right now, we have great docs that someone can sit down and read as a
book, chapter by chapter. For people who are in the middle of
something, psql \h or man or 'more INSTALL' may be easier, and no one is
really going to sit down and study those, I think. Maybe I am wrong.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 06:28 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
2 siblings, 2 replies; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-08-25 06:28 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; Tatsuo Ishii <t-ishii@sra.co.jp>; +Cc: hackers@postgreSQL.org
> > > SERIAL type auto-creates sequence
> This would be nice to have for 6.4. Someone mentioned you can create
> the sequence before the table, so maybe we can jam it in. If it is not
> 100% correct, we have a month to make it correct, right?
postgres=> create table s (x text, i serial);
NOTICE: CREATE TABLE will create implicit sequence s_i_seq for SERIAL
column s.i
CREATE
postgres=> insert into s values ('one');
INSERT 894455 1
postgres=> insert into s values ('two');
INSERT 894456 1
postgres=> insert into s values ('three');
INSERT 894457 1
postgres=> select * from s;
x |i
-----+-
one |1
two |2
three|3
(3 rows)
> > > remove PARSEDEBUG defines if not longer needed
> Remember, I suggested a way you could keep them with more eligant
> defines. Any comments?
Well, I think that at least most of them should come out of the code
altogether. The more elegant solution probably leads to code clutter
also, just a bit more readable since it indents with the rest of the
code.
> > > double-quotes from pg_dump of field names
> > I have some patches for this, but have not had time to test yet.
> Cool. Let the beta testers test it!
Hmm. So that would make them alpha testers, right? :) Might be OK for
this one, if someone is willing to try it. I'd hate to make a change and
then forget about it though. Tatsuo?
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 07:05 Tatsuo Ishii <t-ishii@sra.co.jp>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1 sibling, 1 reply; 141+ messages in thread
From: Tatsuo Ishii @ 1998-08-25 07:05 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; Tatsuo Ishii <t-ishii@sra.co.jp>; hackers@postgreSQL.org
>> > > double-quotes from pg_dump of field names
>> > I have some patches for this, but have not had time to test yet.
>> Cool. Let the beta testers test it!
>
>Hmm. So that would make them alpha testers, right? :) Might be OK for
>this one, if someone is willing to try it. I'd hate to make a change and
>then forget about it though. Tatsuo?
You could send me the patch. I also have another problem with 6.3.2
pg_dump regarding 8bit or Upper case letters handling and some fixes
for that. I would like to merge the fixes into 6.4.
--
Tatsuo Ishii
t-ishii@sra.co.jp
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 15:19 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Tatsuo Ishii <t-ishii@sra.co.jp>
0 siblings, 0 replies; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-08-25 15:19 UTC (permalink / raw)
To: t-ishii@sra.co.jp; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; hackers@postgreSQL.org
> You could send me the patch. I also have another problem with 6.3.2
> pg_dump regarding 8bit or Upper case letters handling and some fixes
> for that. I would like to merge the fixes into 6.4.
OK, here is the patch. However, I've also already committed the patch to
the CVS source tree; hope that doesn't make it more difficult for you.
Thanks.
- Tom
Attachments:
pg_dump.c.patch (text/plain, 10.5K) download
*** ../src/bin/pg_dump/pg_dump.c.orig Thu Aug 6 05:12:51 1998
--- ../src/bin/pg_dump/pg_dump.c Tue Aug 18 05:57:44 1998
***************
*** 221,235 ****
if (oids)
{
! fprintf(fout, "COPY \"%s\" WITH OIDS FROM stdin;\n",
fmtId(classname));
! sprintf(query, "COPY \"%s\" WITH OIDS TO stdout;\n",
fmtId(classname));
}
else
{
! fprintf(fout, "COPY \"%s\" FROM stdin;\n", fmtId(classname));
! sprintf(query, "COPY \"%s\" TO stdout;\n", fmtId(classname));
}
res = PQexec(g_conn, query);
if (!res ||
--- 221,235 ----
if (oids)
{
! fprintf(fout, "COPY %s WITH OIDS FROM stdin;\n",
fmtId(classname));
! sprintf(query, "COPY %s WITH OIDS TO stdout;\n",
fmtId(classname));
}
else
{
! fprintf(fout, "COPY %s FROM stdin;\n", fmtId(classname));
! sprintf(query, "COPY %s TO stdout;\n", fmtId(classname));
}
res = PQexec(g_conn, query);
if (!res ||
***************
*** 316,322 ****
int tuple;
int field;
! sprintf(query, "SELECT * FROM \"%s\"", classname);
res = PQexec(g_conn, query);
if (!res ||
PQresultStatus(res) != PGRES_TUPLES_OK)
--- 316,322 ----
int tuple;
int field;
! sprintf(query, "SELECT * FROM %s", fmtId(classname));
res = PQexec(g_conn, query);
if (!res ||
PQresultStatus(res) != PGRES_TUPLES_OK)
***************
*** 327,333 ****
tuple = 0;
while (tuple < PQntuples(res))
{
! fprintf(fout, "INSERT INTO \"%s\" ", fmtId(classname));
if (attrNames)
{
int j;
--- 327,333 ----
tuple = 0;
while (tuple < PQntuples(res))
{
! fprintf(fout, "INSERT INTO %s ", fmtId(classname));
if (attrNames)
{
int j;
***************
*** 338,344 ****
{
if (tblinfo.inhAttrs[j] == 0)
{
! sprintf(q, "%s%s\"%s\"",
q,
(actual_atts > 0) ? "," : "",
fmtId(tblinfo.attnames[j]));
--- 338,344 ----
{
if (tblinfo.inhAttrs[j] == 0)
{
! sprintf(q, "%s%s%s",
q,
(actual_atts > 0) ? "," : "",
fmtId(tblinfo.attnames[j]));
***************
*** 1570,1576 ****
exit_nicely(g_conn);
}
tgfunc = finfo[findx].proname;
! sprintf(query, "CREATE TRIGGER \"%s\" ", PQgetvalue(res2, i2, i_tgname));
/* Trigger type */
findx = 0;
if (TRIGGER_FOR_BEFORE(tgtype))
--- 1570,1576 ----
exit_nicely(g_conn);
}
tgfunc = finfo[findx].proname;
! sprintf(query, "CREATE TRIGGER %s ", fmtId(PQgetvalue(res2, i2, i_tgname)));
/* Trigger type */
findx = 0;
if (TRIGGER_FOR_BEFORE(tgtype))
***************
*** 1597,1604 ****
else
strcat(query, " UPDATE");
}
! sprintf(query, "%s ON \"%s\" FOR EACH ROW EXECUTE PROCEDURE %s (",
! query, tblinfo[i].relname, tgfunc);
for (findx = 0; findx < tgnargs; findx++)
{
char *s,
--- 1597,1604 ----
else
strcat(query, " UPDATE");
}
! sprintf(query, "%s ON %s FOR EACH ROW EXECUTE PROCEDURE %s (",
! query, fmtId(tblinfo[i].relname), tgfunc);
for (findx = 0; findx < tgnargs; findx++)
{
char *s,
***************
*** 1967,1976 ****
becomeUser(fout, tinfo[i].usename);
sprintf(q,
! "CREATE TYPE \"%s\" "
"( internallength = %s, externallength = %s, input = %s, "
"output = %s, send = %s, receive = %s, default = '%s'",
! tinfo[i].typname,
tinfo[i].typlen,
tinfo[i].typprtlen,
tinfo[i].typinput,
--- 1967,1976 ----
becomeUser(fout, tinfo[i].usename);
sprintf(q,
! "CREATE TYPE %s "
"( internallength = %s, externallength = %s, input = %s, "
"output = %s, send = %s, receive = %s, default = '%s'",
! fmtId(tinfo[i].typname),
tinfo[i].typlen,
tinfo[i].typprtlen,
tinfo[i].typinput,
***************
*** 2033,2045 ****
becomeUser(fout, finfo[i].usename);
! sprintf(q, "CREATE FUNCTION \"%s\" (", finfo[i].proname);
for (j = 0; j < finfo[i].nargs; j++)
{
char *typname;
typname = findTypeByOid(tinfo, numTypes, finfo[i].argtypes[j]);
! sprintf(q, "%s%s\"%s\"",
q,
(j > 0) ? "," : "",
fmtId(typname));
--- 2033,2045 ----
becomeUser(fout, finfo[i].usename);
! sprintf(q, "CREATE FUNCTION %s (", fmtId(finfo[i].proname));
for (j = 0; j < finfo[i].nargs; j++)
{
char *typname;
typname = findTypeByOid(tinfo, numTypes, finfo[i].argtypes[j]);
! sprintf(q, "%s%s%s",
q,
(j > 0) ? "," : "",
fmtId(typname));
***************
*** 2400,2407 ****
/* Revoke Default permissions for PUBLIC */
fprintf(fout,
! "REVOKE ALL on \"%s\" from PUBLIC;\n",
! tbinfo.relname);
for (k = 0; k < l; k++)
{
--- 2400,2407 ----
/* Revoke Default permissions for PUBLIC */
fprintf(fout,
! "REVOKE ALL on %s from PUBLIC;\n",
! fmtId(tbinfo.relname));
for (k = 0; k < l; k++)
{
***************
*** 2409,2421 ****
{
if (ACLlist[k].user == (char *) NULL)
fprintf(fout,
! "GRANT %s on \"%s\" to PUBLIC;\n",
! ACLlist[k].privledges, tbinfo.relname);
else
fprintf(fout,
! "GRANT %s on \"%s\" to \"%s\";\n",
! ACLlist[k].privledges, tbinfo.relname,
! ACLlist[k].user);
}
}
}
--- 2409,2421 ----
{
if (ACLlist[k].user == (char *) NULL)
fprintf(fout,
! "GRANT %s on %s to PUBLIC;\n",
! ACLlist[k].privledges, fmtId(tbinfo.relname));
else
fprintf(fout,
! "GRANT %s on %s to %s;\n",
! ACLlist[k].privledges, fmtId(tbinfo.relname),
! fmtId(ACLlist[k].user));
}
}
}
***************
*** 2471,2477 ****
becomeUser(fout, tblinfo[i].usename);
! sprintf(q, "CREATE TABLE \"%s\" (", fmtId(tblinfo[i].relname));
actual_atts = 0;
for (j = 0; j < tblinfo[i].numatts; j++)
{
--- 2471,2477 ----
becomeUser(fout, tblinfo[i].usename);
! sprintf(q, "CREATE TABLE %s (", fmtId(tblinfo[i].relname));
actual_atts = 0;
for (j = 0; j < tblinfo[i].numatts; j++)
{
***************
*** 2481,2487 ****
/* Show lengths on bpchar and varchar */
if (!strcmp(tblinfo[i].typnames[j], "bpchar"))
{
! sprintf(q, "%s%s\"%s\" char",
q,
(actual_atts > 0) ? ", " : "",
fmtId(tblinfo[i].attnames[j]));
--- 2481,2487 ----
/* Show lengths on bpchar and varchar */
if (!strcmp(tblinfo[i].typnames[j], "bpchar"))
{
! sprintf(q, "%s%s%s char",
q,
(actual_atts > 0) ? ", " : "",
fmtId(tblinfo[i].attnames[j]));
***************
*** 2493,2499 ****
}
else if (!strcmp(tblinfo[i].typnames[j], "varchar"))
{
! sprintf(q, "%s%s\"%s\" %s",
q,
(actual_atts > 0) ? ", " : "",
fmtId(tblinfo[i].attnames[j]),
--- 2493,2499 ----
}
else if (!strcmp(tblinfo[i].typnames[j], "varchar"))
{
! sprintf(q, "%s%s%s %s",
q,
(actual_atts > 0) ? ", " : "",
fmtId(tblinfo[i].attnames[j]),
***************
*** 2506,2512 ****
}
else
{
! sprintf(q, "%s%s\"%s\" %s",
q,
(actual_atts > 0) ? ", " : "",
fmtId(tblinfo[i].attnames[j]),
--- 2506,2512 ----
}
else
{
! sprintf(q, "%s%s%s %s",
q,
(actual_atts > 0) ? ", " : "",
fmtId(tblinfo[i].attnames[j]),
***************
*** 2539,2545 ****
sprintf(q, "%s%s%s",
q,
(k > 0) ? ", " : "",
! parentRels[k]);
}
strcat(q, ")");
}
--- 2539,2545 ----
sprintf(q, "%s%s%s",
q,
(k > 0) ? ", " : "",
! fmtId(parentRels[k]));
}
strcat(q, ")");
}
***************
*** 2648,2654 ****
else
attname = tblinfo[tableInd].attnames[indkey];
if (funcname)
! sprintf(attlist + strlen(attlist), "%s\"%s\"",
(k == 0) ? "" : ", ", fmtId(attname));
else
{
--- 2648,2654 ----
else
attname = tblinfo[tableInd].attnames[indkey];
if (funcname)
! sprintf(attlist + strlen(attlist), "%s%s",
(k == 0) ? "" : ", ", fmtId(attname));
else
{
***************
*** 2659,2665 ****
attname, indinfo[i].indexrelname);
exit_nicely(g_conn);
}
! sprintf(attlist + strlen(attlist), "%s\"%s\" \"%s\"",
(k == 0) ? "" : ", ", fmtId(attname), fmtId(classname[k]));
free(classname[k]);
}
--- 2659,2665 ----
attname, indinfo[i].indexrelname);
exit_nicely(g_conn);
}
! sprintf(attlist + strlen(attlist), "%s%s %s",
(k == 0) ? "" : ", ", fmtId(attname), fmtId(classname[k]));
free(classname[k]);
}
***************
*** 2668,2681 ****
if (!tablename || (!strcmp(indinfo[i].indrelname, tablename)))
{
! sprintf(q, "CREATE %s INDEX \"%s\" on \"%s\" using %s (",
(strcmp(indinfo[i].indisunique, "t") == 0) ? "UNIQUE" : "",
fmtId(indinfo[i].indexrelname),
fmtId(indinfo[i].indrelname),
indinfo[i].indamname);
if (funcname)
{
! sprintf(q, "%s %s (%s) \"%s\" );\n",
q, funcname, attlist, fmtId(classname[0]));
free(funcname);
free(classname[0]);
--- 2668,2681 ----
if (!tablename || (!strcmp(indinfo[i].indrelname, tablename)))
{
! sprintf(q, "CREATE %s INDEX %s on %s using %s (",
(strcmp(indinfo[i].indisunique, "t") == 0) ? "UNIQUE" : "",
fmtId(indinfo[i].indexrelname),
fmtId(indinfo[i].indrelname),
indinfo[i].indamname);
if (funcname)
{
! sprintf(q, "%s %s (%s) %s );\n",
q, funcname, attlist, fmtId(classname[0]));
free(funcname);
free(classname[0]);
***************
*** 2892,2898 ****
sprintf(query,
"SELECT sequence_name, last_value, increment_by, max_value, "
! "min_value, cache_value, is_cycled, is_called from \"%s\"",
fmtId(tbinfo.relname));
res = PQexec(g_conn, query);
--- 2892,2898 ----
sprintf(query,
"SELECT sequence_name, last_value, increment_by, max_value, "
! "min_value, cache_value, is_cycled, is_called from %s",
fmtId(tbinfo.relname));
res = PQexec(g_conn, query);
***************
*** 2931,2937 ****
PQclear(res);
sprintf(query,
! "CREATE SEQUENCE \"%s\" start %d increment %d maxvalue %d "
"minvalue %d cache %d %s;\n",
fmtId(tbinfo.relname), last, incby, maxv, minv, cache,
(cycled == 't') ? "cycle" : "");
--- 2931,2937 ----
PQclear(res);
sprintf(query,
! "CREATE SEQUENCE %s start %d increment %d maxvalue %d "
"minvalue %d cache %d %s;\n",
fmtId(tbinfo.relname), last, incby, maxv, minv, cache,
(cycled == 't') ? "cycle" : "");
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 15:32 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
2 siblings, 2 replies; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-08-25 15:32 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: hackers@postgreSQL.org
> > > SERIAL type auto-creates sequence
> > I won't have time to do this for v6.4.
> This would be nice to have, so maybe we can jam it in. If it is not
> 100% correct, we have a month to make it correct, right?
OK, I've committed the SERIAL type support to the CVS tree:
postgres=> create table test (x text, s serial);
NOTICE: CREATE TABLE will create implicit sequence test_s_seq for
SERIAL column test.s
NOTICE: CREATE TABLE/UNIQUE will create implicit index test_s_key for
table test
CREATE
postgres=> insert into test values ('one');
INSERT 894781 1
postgres=> insert into test values ('two');
INSERT 894782 1
postgres=> insert into test values ('three');
INSERT 894783 1
postgres=> select * from test;
x |s
-----+-
one |1
two |2
three|3
(3 rows)
postgres=> \d
Database = postgres
+------------------+----------------------------------+----------+
| Owner | Relation | Type |
+------------------+----------------------------------+----------+
| postgres | test | table |
| postgres | test_s_key | index |
| postgres | test_s_seq | sequence |
+------------------+----------------------------------+----------+
postgres=> select * from test;
x |s
-----+-
one |1
two |2
three|3
(3 rows)
postgres=> \d
pqReadData() -- backend closed the channel unexpectedly.
Whoops! Don't know why this is causing trouble, but it seems to be
reproducible. Will look at it some more...
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 17:31 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1 sibling, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-08-25 17:31 UTC (permalink / raw)
To: lockhart@alumni.caltech.edu; +Cc: t-ishii@sra.co.jp; hackers@postgreSQL.org
> > > > SERIAL type auto-creates sequence
> > This would be nice to have for 6.4. Someone mentioned you can create
> > the sequence before the table, so maybe we can jam it in. If it is not
> > 100% correct, we have a month to make it correct, right?
>
> postgres=> create table s (x text, i serial);
> NOTICE: CREATE TABLE will create implicit sequence s_i_seq for SERIAL
> column s.i
> CREATE
> postgres=> insert into s values ('one');
> INSERT 894455 1
> postgres=> insert into s values ('two');
> INSERT 894456 1
> postgres=> insert into s values ('three');
> INSERT 894457 1
> postgres=> select * from s;
> x |i
> -----+-
> one |1
> two |2
> three|3
> (3 rows)
Great.
>
> > > > remove PARSEDEBUG defines if not longer needed
> > Remember, I suggested a way you could keep them with more eligant
> > defines. Any comments?
>
> Well, I think that at least most of them should come out of the code
> altogether. The more elegant solution probably leads to code clutter
> also, just a bit more readable since it indents with the rest of the
> code.
OK. I just redid parse_target.c, so I hope you can merge in your stuff.
>
> > > > double-quotes from pg_dump of field names
> > > I have some patches for this, but have not had time to test yet.
> > Cool. Let the beta testers test it!
>
> Hmm. So that would make them alpha testers, right? :) Might be OK for
> this one, if someone is willing to try it. I'd hate to make a change and
> then forget about it though. Tatsuo?
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 17:55 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1 sibling, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-08-25 17:55 UTC (permalink / raw)
To: lockhart@alumni.caltech.edu; +Cc: hackers@postgreSQL.org
> postgres=> select * from test;
> x |s
> -----+-
> one |1
> two |2
> three|3
> (3 rows)
>
> postgres=> \d
> pqReadData() -- backend closed the channel unexpectedly.
>
> Whoops! Don't know why this is causing trouble, but it seems to be
> reproducible. Will look at it some more...
While you are in there, how does \d show sequences. I have \d table
showing the indexes. Can it show sequences too?
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 19:50 Nick Bastin <nbastin@rbbsystems.com>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
2 siblings, 1 reply; 141+ messages in thread
From: Nick Bastin @ 1998-08-25 19:50 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; hackers@postgreSQL.org
Bruce Momjian wrote:
>
> > > man pages/sgml synchronization (dump out man pages as postscript?)
> >
> > I'll need the sgml docs to firm up two weeks before release (Sept 15?)
> > to give time to generate hardcopy. The admin guide will be the last
> > converted, and it has the release notes and installation procedure which
> > need to be updated. Can we think about how to do the release notes and
> > installation for this release? I would suggest having a short readme on
> > how to install and read the docs, and have the detailed installation
> > procedure in sgml->html/hardcopy.
>
> Yep. Remember Marc's rule that you can't add features after beta
> starts, but you can be fixing things. That buys us a lot of time.
Not to point out the obvious, but that's what beta traditionally *means*...
'feature complete'.
Nick
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-25 21:41 The Hermit Hacker <scrappy@hub.org>
parent: Nick Bastin <nbastin@rbbsystems.com>
0 siblings, 1 reply; 141+ messages in thread
From: The Hermit Hacker @ 1998-08-25 21:41 UTC (permalink / raw)
To: Nick Bastin <nbastin@rbbsystems.com>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; Thomas G. Lockhart <lockhart@alumni.caltech.edu>; hackers@postgreSQL.org
On Tue, 25 Aug 1998, Nick Bastin wrote:
> Bruce Momjian wrote:
> >
> > > > man pages/sgml synchronization (dump out man pages as postscript?)
> > >
> > > I'll need the sgml docs to firm up two weeks before release (Sept 15?)
> > > to give time to generate hardcopy. The admin guide will be the last
> > > converted, and it has the release notes and installation procedure which
> > > need to be updated. Can we think about how to do the release notes and
> > > installation for this release? I would suggest having a short readme on
> > > how to install and read the docs, and have the detailed installation
> > > procedure in sgml->html/hardcopy.
> >
> > Yep. Remember Marc's rule that you can't add features after beta
> > starts, but you can be fixing things. That buys us a lot of time.
>
> Not to point out the obvious, but that's what beta traditionally *means*...
> 'feature complete'.
Ya, we know that...:) Bruce is trying make fun of me *sniffle*
*grin* Once we go beta, I tend to be quite...anal(?) about adding
anything unless 100% absolutely necessary, so the idea is to sneak as many
new features as possible in before it goes beta, even if they are buggy,
cause then "the feature is there, just has a few bugs to fix" *grin*
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-26 00:13 Henry B. Hotz <hotz@jpl.nasa.gov>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1 sibling, 0 replies; 141+ messages in thread
From: Henry B. Hotz @ 1998-08-26 00:13 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; lockhart@alumni.caltech.edu; +Cc: hackers@postgreSQL.org
At 11:26 PM -0700 8/24/98, Bruce Momjian wrote:
>> That is possible. But why are fundamental things like installation
>> instructions or release notes better left as flat files? Can't quite see
>
>OK. As long as we can generate flat too for those that can't use fancy
>stuff. Certainly it is better than flat files if both are available for
>novices trying to get started.
>
My $.02. Having just built a new server I like the fact that most packages
(gcc, apache, perl) have a top-level INSTALL and README file. They are
flat files so you can look at them before you have installed anything. I
like the convention.
More specifically you shouldn't have to install anything to read the
INSTALL file.
Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-26 03:03 Bruce Momjian <maillist@candle.pha.pa.us>
parent: The Hermit Hacker <scrappy@hub.org>
0 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-08-26 03:03 UTC (permalink / raw)
To: scrappy@hub.org; +Cc: nbastin@rbbsystems.com; lockhart@alumni.caltech.edu; hackers@postgreSQL.org
> > > Yep. Remember Marc's rule that you can't add features after beta
> > > starts, but you can be fixing things. That buys us a lot of time.
> >
> > Not to point out the obvious, but that's what beta traditionally *means*...
> > 'feature complete'.
>
> Ya, we know that...:) Bruce is trying make fun of me *sniffle*
> *grin* Once we go beta, I tend to be quite...anal(?) about adding
> anything unless 100% absolutely necessary, so the idea is to sneak as many
> new features as possible in before it goes beta, even if they are buggy,
> cause then "the feature is there, just has a few bugs to fix" *grin*
Good analysis.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-26 03:44 The Hermit Hacker <scrappy@hub.org>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 141+ messages in thread
From: The Hermit Hacker @ 1998-08-26 03:44 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: nbastin@rbbsystems.com; lockhart@alumni.caltech.edu; hackers@postgreSQL.org
On Tue, 25 Aug 1998, Bruce Momjian wrote:
> > > > Yep. Remember Marc's rule that you can't add features after beta
> > > > starts, but you can be fixing things. That buys us a lot of time.
> > >
> > > Not to point out the obvious, but that's what beta traditionally *means*...
> > > 'feature complete'.
> >
> > Ya, we know that...:) Bruce is trying make fun of me *sniffle*
> > *grin* Once we go beta, I tend to be quite...anal(?) about adding
> > anything unless 100% absolutely necessary, so the idea is to sneak as many
> > new features as possible in before it goes beta, even if they are buggy,
> > cause then "the feature is there, just has a few bugs to fix" *grin*
>
> Good analysis.
We've worked together for much much to long for us not to have a
pretty good "feel" for each other :) Produce some good work, no? :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items]
@ 1998-08-26 04:47 Bruce Momjian <maillist@candle.pha.pa.us>
parent: The Hermit Hacker <scrappy@hub.org>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-08-26 04:47 UTC (permalink / raw)
To: scrappy@hub.org; +Cc: nbastin@rbbsystems.com; lockhart@alumni.caltech.edu; hackers@postgreSQL.org
> > > Ya, we know that...:) Bruce is trying make fun of me *sniffle*
> > > *grin* Once we go beta, I tend to be quite...anal(?) about adding
> > > anything unless 100% absolutely necessary, so the idea is to sneak as many
> > > new features as possible in before it goes beta, even if they are buggy,
> > > cause then "the feature is there, just has a few bugs to fix" *grin*
> >
> > Good analysis.
>
> We've worked together for much much to long for us not to have a
> pretty good "feel" for each other :) Produce some good work, no? :)
>
You bet. Very good work, and getting better every day.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Open 6.4 items
@ 1998-08-29 04:40 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 2 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-08-29 04:40 UTC (permalink / raw)
To: hackers@postgreSQL.org
Here they are. I know people want the 6.4 feature list.
---------------------------------------------------------------------------
cidr/IP address type
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
fix problem when DEFAULT string for CHAR() is not same as column
have psql dump out rules text with new function
cnf-ify still can exhaust memory
permissions on indexes: what do they do? should it be prevented?
man pages/sgml synchronization (dump out man pages as postscript?)
remove PARSEDEBUG defines if not longer needed
low level locking - status?
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chainging of pages to allow >8k tuples
SELECT oid @ oid @ oid FROM pg_user fails with parser error, not function error
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-30 10:53 Peter T Mount <peter@retep.org.uk>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 0 replies; 141+ messages in thread
From: Peter T Mount @ 1998-08-30 10:53 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: PostgreSQL-development <hackers@postgresql.org>
On Sat, 29 Aug 1998, Bruce Momjian wrote:
> Here they are. I know people want the 6.4 feature list.
>
> ---------------------------------------------------------------------------
>
> cidr/IP address type
> change pg args for platforms that don't support argv changes
> (setproctitle()?, sendmail hack?)
> fix problem when DEFAULT string for CHAR() is not same as column
> have psql dump out rules text with new function
> cnf-ify still can exhaust memory
> permissions on indexes: what do they do? should it be prevented?
> man pages/sgml synchronization (dump out man pages as postscript?)
> remove PARSEDEBUG defines if not longer needed
> low level locking - status?
> improve reporting of syntax errors by showing location of error in query
> use index with constants on functions
> allow chainging of pages to allow >8k tuples
> SELECT oid @ oid @ oid FROM pg_user fails with parser error, not function error
> document/trigger/rule so changes to pg_shadow create pg_pwd
> large objects orphanage
I'm working on orphans at the moment, should have something to commit
later today...
> improve group handling
>
> --
> Bruce Momjian | 830 Blythe Avenue
> maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
> + If your life is a hard drive, | (610) 353-9879(w)
> + Christ can be your backup. | (610) 853-3000(h)
>
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-30 10:55 Peter T Mount <peter@retep.org.uk>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1 sibling, 1 reply; 141+ messages in thread
From: Peter T Mount @ 1998-08-30 10:55 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; hackers@postgresql.org
On Tue, 25 Aug 1998, Thomas G. Lockhart wrote:
> > > > SERIAL type auto-creates sequence
> > > I won't have time to do this for v6.4.
> > This would be nice to have, so maybe we can jam it in. If it is not
> > 100% correct, we have a month to make it correct, right?
>
> OK, I've committed the SERIAL type support to the CVS tree:
>
> postgres=> create table test (x text, s serial);
> NOTICE: CREATE TABLE will create implicit sequence test_s_seq for
> SERIAL column test.s
> NOTICE: CREATE TABLE/UNIQUE will create implicit index test_s_key for
> table test
> CREATE
I've just tried this (using a CVS tree from Friday), and got this:
peter=> create table test (x text, s serial);
NOTICE: CREATE TABLE will create implicit sequence test_s_seq for SERIAL
column test.s
NOTICE: CREATE TABLE/UNIQUE will create implicit index test_s_key for
table test
ERROR: pg_aclcheck: class "test_s_seq" not found
\d shows that nothing is created. Any ideas?
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-30 18:40 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Peter T Mount <peter@retep.org.uk>
0 siblings, 1 reply; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-08-30 18:40 UTC (permalink / raw)
To: Peter T Mount <peter@retep.org.uk>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; hackers@postgreSQL.org
Works fine _if_ the user has database creation privileges:
tgl=> create table test (x text, s serial);
NOTICE: CREATE TABLE will create implicit sequence test_s_seq for SERIAL
column test.s
NOTICE: CREATE TABLE/UNIQUE will create implicit index test_s_key for
table test
CREATE
This statement internally expands to roughly the following:
create table test (x text, s int4 default nextval('test_s_seq'));
create unique index test_s_key on test (s);
create sequence test_s_seq;
If the user has no database creation privileges, then apparently there
is some checking which insists that the sequence referenced in the
implicit default clause actually exists:
tgl=> create table test (x text, i int default nextval('test_s_seq'));
ERROR: pg_aclcheck: class "test_s_seq" not found
So, it looks like the sequence should internally be created before the
table, though in some cases it doesn't matter. I was concerned that this
might be the case, and the parser is not at the moment configured to
allow this. Should be able to fix it up, or have just limited SERIAL
support for the v6.4 release :(
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-30 21:11 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-08-30 21:11 UTC (permalink / raw)
To: lockhart@alumni.caltech.edu; +Cc: peter@retep.org.uk; hackers@postgreSQL.org
> Works fine _if_ the user has database creation privileges:
Can I ask why sequence creation is related to database CREATION. Seems
very strange to me.
>
> tgl=> create table test (x text, s serial);
> NOTICE: CREATE TABLE will create implicit sequence test_s_seq for SERIAL
> column test.s
> NOTICE: CREATE TABLE/UNIQUE will create implicit index test_s_key for
> table test
> CREATE
>
> This statement internally expands to roughly the following:
> create table test (x text, s int4 default nextval('test_s_seq'));
> create unique index test_s_key on test (s);
> create sequence test_s_seq;
>
> If the user has no database creation privileges, then apparently there
> is some checking which insists that the sequence referenced in the
> implicit default clause actually exists:
>
> tgl=> create table test (x text, i int default nextval('test_s_seq'));
> ERROR: pg_aclcheck: class "test_s_seq" not found
>
> So, it looks like the sequence should internally be created before the
> table, though in some cases it doesn't matter. I was concerned that this
> might be the case, and the parser is not at the moment configured to
> allow this. Should be able to fix it up, or have just limited SERIAL
> support for the v6.4 release :(
>
> - Tom
>
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-08-30 23:07 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-08-30 23:07 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: peter@retep.org.uk; hackers@postgreSQL.org
> > Works fine _if_ the user has database creation privileges:
> Can I ask why sequence creation is related to database CREATION.
> Seems very strange to me.
I'd guess that it is related to being allowed to put entries into
whatever supports sequences (a view or table?). If you created the
database you get some other privileges too??
> > tgl=> create table test (x text,
> > tgl-> i int default nextval('test_s_seq'));
> > ERROR: pg_aclcheck: class "test_s_seq" not found
> > it looks like the sequence should internally be created before the
> > table, though in some cases it doesn't matter. I was concerned that
> > this might be the case, and the parser is not at the moment
> > configured to allow this.
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-09-04 00:53 David Hartwig <daybee@bellatlantic.net>
parent: Vadim Mikheev <vadim@krs.ru>
1 sibling, 1 reply; 141+ messages in thread
From: David Hartwig @ 1998-09-04 00:53 UTC (permalink / raw)
To: Vadim Mikheev <vadim@krs.ru>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; PostgreSQL-development <hackers@postgreSQL.org>
Vadim Mikheev wrote:
> >
> > example:
> > select upper(usename), count(usename) from pg_shadow group by 1;
> > OK
> > select upper(usename), count(oid) from pg_shadow group by 1;
> > CRASH
> >
> > It did work in 6.3.
>
> As I remember, someone re-implemented GroupBy node in 6.4...
You may be referring to me. I made some changes to the SortGroupBy parse
node to allow espressions. I didn't touch the GroupClause node. Also,
I think this bug arrived before I made my changes in 6.4
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-09-04 03:40 David Hartwig <daybee@bellatlantic.net>
parent: Vadim Mikheev <vadim@krs.ru>
0 siblings, 1 reply; 141+ messages in thread
From: David Hartwig @ 1998-09-04 03:40 UTC (permalink / raw)
To: Vadim Mikheev <vadim@krs.ru>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; PostgreSQL-development <hackers@postgreSQL.org>
Vadim Mikheev wrote:
> Bruce Momjian wrote:
> >
> > low level locking - status?
>
> Work in progress -:))
> This is 6.5 item...
>
> But this is 6.4 item from TODO:
> * select upper(usename), count(usesysid) from pg_shadow group by 1;
> --> CRASH
>
> - group by function is BROKEN!!!
>
> Is anybody working on fix ?
>
Not I, but I can give you some background. The crash seems to only
occur when the argument of the GROUPed by function is not used elsewhere
in the target list.
example:
select upper(usename), count(usename) from pg_shadow group by 1;
OK
select upper(usename), count(oid) from pg_shadow group by 1;
CRASH
It did work in 6.3.
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-09-04 03:42 Vadim Mikheev <vadim@krs.ru>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 1 reply; 141+ messages in thread
From: Vadim Mikheev @ 1998-09-04 03:42 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: PostgreSQL-development <hackers@postgreSQL.org>
Bruce Momjian wrote:
>
> low level locking - status?
Work in progress -:))
This is 6.5 item...
But this is 6.4 item from TODO:
* select upper(usename), count(usesysid) from pg_shadow group by 1;
--> CRASH
- group by function is BROKEN!!!
Is anybody working on fix ?
Vadim
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-09-04 04:19 Vadim Mikheev <vadim@krs.ru>
parent: David Hartwig <daybee@bellatlantic.net>
0 siblings, 2 replies; 141+ messages in thread
From: Vadim Mikheev @ 1998-09-04 04:19 UTC (permalink / raw)
To: David Hartwig <daybee@bellatlantic.net>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; PostgreSQL-development <hackers@postgreSQL.org>
David Hartwig wrote:
>
> >
> > Is anybody working on fix ?
> >
>
> Not I, but I can give you some background. The crash seems to only
> occur when the argument of the GROUPed by function is not used elsewhere
> in the target list.
Yes, I see that it comes from replace_agg_clause() after
match_varid() call: for some reasons varoattno of
target list var is changed and so var is not matched...
>
> example:
> select upper(usename), count(usename) from pg_shadow group by 1;
> OK
> select upper(usename), count(oid) from pg_shadow group by 1;
> CRASH
>
> It did work in 6.3.
As I remember, someone re-implemented GroupBy node in 6.4...
Vadim
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-09-04 04:54 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Vadim Mikheev <vadim@krs.ru>
1 sibling, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-09-04 04:54 UTC (permalink / raw)
To: vadim@krs.ru; +Cc: daybee@bellatlantic.net; hackers@postgreSQL.org
> >
> > It did work in 6.3.
>
> As I remember, someone re-implemented GroupBy node in 6.4...
I don't think I did.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-09-04 05:21 Vadim Mikheev <vadim@krs.ru>
parent: David Hartwig <daybee@bellatlantic.net>
0 siblings, 0 replies; 141+ messages in thread
From: Vadim Mikheev @ 1998-09-04 05:21 UTC (permalink / raw)
To: David Hartwig <daybee@bellatlantic.net>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; PostgreSQL-development <hackers@postgreSQL.org>
David Hartwig wrote:
>
> Vadim Mikheev wrote:
>
> > >
> > > example:
> > > select upper(usename), count(usename) from pg_shadow group by 1;
> > > OK
> > > select upper(usename), count(oid) from pg_shadow group by 1;
> > > CRASH
> > >
> > > It did work in 6.3.
> >
> > As I remember, someone re-implemented GroupBy node in 6.4...
>
> You may be referring to me. I made some changes to the SortGroupBy parse
> node to allow espressions. I didn't touch the GroupClause node. Also,
> I think this bug arrived before I made my changes in 6.4
Ok, I'll take care...
Vadim
^ permalink raw reply [nested|flat] 141+ messages in thread
* open 6.4 items
@ 1998-09-10 05:04 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 2 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-09-10 05:04 UTC (permalink / raw)
To: hackers@postgreSQL.org
cidr/IP address type(Tom Helbekkmo)
rewrite system(Jan)
foreign key?(Vadim)
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
fix problem when DEFAULT string for CHAR() is not same as column
have psql dump out rules text with new function
cnf-ify still can exhaust memory
permissions on indexes: what do they do? should it be prevented?
man pages/sgml synchronization (dump out man pages as postscript?)
remove PARSEDEBUG defines if not longer needed
low level locking - status?
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chainging of pages to allow >8k tuples
SELECT oid @ oid @ oid FROM pg_user fails with parser error, not function error
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
no min/max for oid type
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] open 6.4 items
@ 1998-09-10 05:53 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 1 reply; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-09-10 05:53 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: PostgreSQL-development <hackers@postgreSQL.org>
> fix problem when DEFAULT string for CHAR() is not same as column
I think I fixed that a while ago. I've forgotten which file was
involved, but I no longer see the symptom on my system.
> man pages/sgml synchronization (dump out man pages as postscript?)
We should synchronize the man pages and sgml for this release, if
possible, and then commit to using the sgml sources for man pages for
v6.5. After v6.4 is released, man pages (but not sgml) are frozen until
they can be generated from the sgml.
> remove PARSEDEBUG defines if not longer needed
OK. You really want those gone, don't you!
> use index with constants on functions
Not likely for v6.4. On my list for v6.5.
> SELECT oid @ oid @ oid FROM pg_user fails with parser error, not
> function error
What is the issue with this? The parser doesn't know how to group the
arguments and operators, so barfs. The only operators which have
explicit precedence are the plain standard ones (+,-,*,/ for math and
=,<,> for comparisons, and |,: for who-knows-what). Everything else
falls into the same precedence, higher than the comparison operators and
lower than the math ones. This includes, for example, "<=" which should
be the same precedence as the other comparison ops, but has higher
precedence at the moment.
> no min/max for oid type
Does this still need to be on the list? The guy who asked for it
actually needed something else...
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] open 6.4 items
@ 1998-09-10 06:15 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-09-10 06:15 UTC (permalink / raw)
To: lockhart@alumni.caltech.edu; +Cc: hackers@postgreSQL.org
> > fix problem when DEFAULT string for CHAR() is not same as column
>
> I think I fixed that a while ago. I've forgotten which file was
> involved, but I no longer see the symptom on my system.
Removed.
>
> > man pages/sgml synchronization (dump out man pages as postscript?)
>
> We should synchronize the man pages and sgml for this release, if
> possible, and then commit to using the sgml sources for man pages for
> v6.5. After v6.4 is released, man pages (but not sgml) are frozen until
> they can be generated from the sgml.
OK.
>
> > remove PARSEDEBUG defines if not longer needed
>
> OK. You really want those gone, don't you!
I can move it to the TODO list, OK? :-)
>
> > use index with constants on functions
>
> Not likely for v6.4. On my list for v6.5.
OK.
>
> > SELECT oid @ oid @ oid FROM pg_user fails with parser error, not
> > function error
>
> What is the issue with this? The parser doesn't know how to group the
> arguments and operators, so barfs. The only operators which have
> explicit precedence are the plain standard ones (+,-,*,/ for math and
> =,<,> for comparisons, and |,: for who-knows-what). Everything else
> falls into the same precedence, higher than the comparison operators and
> lower than the math ones. This includes, for example, "<=" which should
> be the same precedence as the other comparison ops, but has higher
> precedence at the moment.
Should I move this to the TODO list now?
>
> > no min/max for oid type
>
> Does this still need to be on the list? The guy who asked for it
> actually needed something else...
I can move some of the items off now, rather than wait until just before
6.4 to be released to move them. OK?
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] open 6.4 items
@ 1998-09-10 06:23 Peter T Mount <peter@retep.org.uk>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 0 replies; 141+ messages in thread
From: Peter T Mount @ 1998-09-10 06:23 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: PostgreSQL-development <hackers@postgresql.org>
On Thu, 10 Sep 1998, Bruce Momjian wrote:
> large objects orphanage
I thought we were in beta?
I didn't have this ready in time for the beta, so I thought it wasn't
going to get in to 6.4.
There isn't much more to do for it though. I'm just finishing off the
documentation for JDBC at the moment, so I can return to it shortly.
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] open 6.4 items
@ 1998-09-10 13:38 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-09-10 13:38 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: hackers@postgreSQL.org
> > > remove PARSEDEBUG defines if not longer needed
> > OK. You really want those gone, don't you!
> I can move it to the TODO list, OK? :-)
No, leave it on the v6.4 FixIt list. This is the start of that list,
right?
> > > SELECT oid @ oid @ oid FROM pg_user fails with parser error, not
> > > function error
> Should I move this to the TODO list now?
Well, I don't know how you would fix it without rewriting the parser or
changing the associativity of generic operators. I would suggest leaving
it off the ToDo list altogether, unless someone can suggest a viable
solution. The example suggests it is a problem with OIDs or with the "@"
operator, not a fundamental feature of the yacc/bison parser.
> > > no min/max for oid type
> I can move some of the items off now, rather than wait until just
> before 6.4 to be released to move them. OK?
Yeah. Let's turn this list into the v6.4 FixIt list; you've done one for
every release I can remember and it has been very helpful.
Be sure to add the views problem to this list ;)
Also, add the html/hardcopy documentation since we will re-release the
User's Guide, Admin Guide, and Programmer's Guide.
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] open 6.4 items
@ 1998-09-10 14:25 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 2 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-09-10 14:25 UTC (permalink / raw)
To: lockhart@alumni.caltech.edu; +Cc: hackers@postgreSQL.org
> Yeah. Let's turn this list into the v6.4 FixIt list; you've done one for
> every release I can remember and it has been very helpful.
The new one.
---------------------------------------------------------------------------
cidr/IP address type(Tom Helbekkmo)
rewrite system(Jan)
foreign key?(Vadim)
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
pg_user dumps core on some platforms
have psql dump out rules text with new function
man pages/sgml synchronization
generate html/postscript documentation
generate postmaster pid file and remove flock/fcntl lock code
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes: what do they do? should it be prevented?
remove PARSEDEBUG defines if not longer needed
low level locking - work-in-progress for 6.5
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chaining of pages to allow >8k tuples
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
no min/max for oid type
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] open 6.4 items
@ 1998-09-10 15:32 Vadim Mikheev <vadim@krs.ru>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 1 reply; 141+ messages in thread
From: Vadim Mikheev @ 1998-09-10 15:32 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; hackers@postgreSQL.org
> foreign key?(Vadim)
I just added attributes for primary/unique/foreign keys
to pg_index & pg_class => dump/reload (or pg_upgrade)...
Nothing more yet, just catalog changes...
regression tests ... as usual -:)
>
> pg_user dumps core on some platforms
Please, please - could someone run Purify ?
Vadim
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] open 6.4 items
@ 1998-09-10 16:38 D'Arcy J.M. Cain <darcy@druid.net>
parent: Vadim Mikheev <vadim@krs.ru>
0 siblings, 1 reply; 141+ messages in thread
From: darcy@druid.net @ 1998-09-10 16:38 UTC (permalink / raw)
To: vadim@krs.ru; +Cc: hackers@PostgreSQL.org
Thus spake Vadim Mikheev
> > foreign key?(Vadim)
>
> I just added attributes for primary/unique/foreign keys
> to pg_index & pg_class => dump/reload (or pg_upgrade)...
Hooray!
> Nothing more yet, just catalog changes...
Do you think there would be any problem if I just manually updated those
fields so that I can start testing my Python access stuff? Do they get
set to some default value at least?
--
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 424 2871 (DoD#0082) (eNTP) | what's for dinner.
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] open 6.4 items
@ 1998-09-10 17:06 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 1 reply; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-09-10 17:06 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: hackers@postgreSQL.org
> allow multiple generic operators in expressions without the use of
> parentheses
I could just let this one go until it dies a quiet death, but...
To parse "multiple generic operators", per the example
select oid @ oid @ oid from table;
one would have to change the associativity of many operators from
non-associative (the correct assumption) to left- or right associative
(the wrong thing to do). If we are going to allow operator extensibility
we cannot make assumptions about the precedence order of operators, and
should require parentheses to break the ambiguity.
Unless someone has a good proposal on how to change the standard rules
of arithmetic, or on how to change the parser to allow
operator-dependent precedence in an extensible way, then we shouldn't
bother tracking this as a problem statement imho.
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] open 6.4 items
@ 1998-09-10 17:44 Vadim Mikheev <vadim@krs.ru>
parent: D'Arcy J.M. Cain <darcy@druid.net>
0 siblings, 0 replies; 141+ messages in thread
From: Vadim Mikheev @ 1998-09-10 17:44 UTC (permalink / raw)
To: D'Arcy J.M. Cain <darcy@druid.net>; +Cc: hackers@PostgreSQL.org
D'Arcy J.M. Cain wrote:
>
> Thus spake Vadim Mikheev
> > > foreign key?(Vadim)
> >
> > I just added attributes for primary/unique/foreign keys
> > to pg_index & pg_class => dump/reload (or pg_upgrade)...
>
> Hooray!
>
> > Nothing more yet, just catalog changes...
>
> Do you think there would be any problem if I just manually updated those
> fields so that I can start testing my Python access stuff? Do they get
> set to some default value at least?
No problem. Default is: no keys.
Vadim
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] open 6.4 items
@ 1998-09-10 17:59 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-09-10 17:59 UTC (permalink / raw)
To: lockhart@alumni.caltech.edu; +Cc: hackers@postgreSQL.org
> > allow multiple generic operators in expressions without the use of
> > parentheses
>
> I could just let this one go until it dies a quiet death, but...
>
> To parse "multiple generic operators", per the example
>
> select oid @ oid @ oid from table;
>
> one would have to change the associativity of many operators from
> non-associative (the correct assumption) to left- or right associative
> (the wrong thing to do). If we are going to allow operator extensibility
> we cannot make assumptions about the precedence order of operators, and
> should require parentheses to break the ambiguity.
>
> Unless someone has a good proposal on how to change the standard rules
> of arithmetic, or on how to change the parser to allow
> operator-dependent precedence in an extensible way, then we shouldn't
> bother tracking this as a problem statement imho.
I agree, except the error message returned from the parser is quite
confusing, just stating 'parse error'. In fact, it took me 10 minutes
to figure out what would and wouldn't work, and I had no idea that
parentheses would fix it.
If we can't give a better error message, we have to keep it on the
todo/bugs list until we can tell people what they are doing wrong, and
how to fix it.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 141+ messages in thread
* Open 6.4 Items
@ 1998-09-21 02:28 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-09-21 02:28 UTC (permalink / raw)
To: hackers@postgreSQL.org
Possible additions
------------------
cidr/IP address type(Tom Helbekkmo)
rewrite system(Jan)
foreign key?(Vadim)
Serious Bugs
------------
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
pg_user dumps core on some platforms
have psql dump out rules text with new function
man pages/sgml synchronization
generate html/postscript documentation
generate postmaster pid file and remove flock/fcntl lock code
regproc dumps name_oid, which fails on CREATE TYPE
CREATE TABLE test (x text, s serial) fails if no database creation permission
SELECT * FROM pg_rules WHERE pg_rules.oid = pg_class.oid crashes
handle oid's on views by either disallowing it or meaningful results
certain AND/OR WHERE clauses crash backend
select not bool_field from t1 crashes
CREATE TABLE bar (id serial, name varchar(32)) fails
New Bugs
--------
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes: what do they do? should it be prevented?
remove PARSEDEBUG defines if not longer needed
low level locking - work-in-progress for 6.5
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chaining of pages to allow >8k tuples
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
no min/max for oid type
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
http://www.op.net/~candle | (610) 353-9879(w)
+ If your life is a hard drive, | (610) 853-3000(h)
+ Christ can be your backup. |
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 Items
@ 1998-09-23 02:32 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Nick Bastin <nbastin@rbbsystems.com>
0 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-09-23 02:32 UTC (permalink / raw)
To: nbastin@rbbsystems.com; +Cc: hackers@postgresql.org
> Bruce Momjian wrote:
> > allow chaining of pages to allow >8k tuples
>
> How transparent is this going to be? Am I going to need to specify that a
> table needs to be 'chainable', or is it just going to do it when I create
> tables that can have records containing >8k of data? I have several databases
> that I would like to move over to a postgres backend from 4th Dimension, but
> many tables have the potential of creating tuples greater than 8k.
>
> Thanks,
> Nick
>
Automatically. We have had no one offer to do it, yet.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
http://www.op.net/~candle | (610) 353-9879(w)
+ If your life is a hard drive, | (610) 853-3000(h)
+ Christ can be your backup. |
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 Items
@ 1998-09-23 04:23 Nick Bastin <nbastin@rbbsystems.com>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 141+ messages in thread
From: Nick Bastin @ 1998-09-23 04:23 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; hackers@postgresql.org
Bruce Momjian wrote:
> allow chaining of pages to allow >8k tuples
How transparent is this going to be? Am I going to need to specify that a
table needs to be 'chainable', or is it just going to do it when I create
tables that can have records containing >8k of data? I have several databases
that I would like to move over to a postgres backend from 4th Dimension, but
many tables have the potential of creating tuples greater than 8k.
Thanks,
Nick
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 Items
@ 1998-09-23 05:08 Nick Bastin <nbastin@rbbsystems.com>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Nick Bastin @ 1998-09-23 05:08 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: hackers@postgresql.org
Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> > > allow chaining of pages to allow >8k tuples
> >
> > How transparent is this going to be? Am I going to need to specify that a
> > table needs to be 'chainable', or is it just going to do it when I create
> > tables that can have records containing >8k of data? I have several databases
> > that I would like to move over to a postgres backend from 4th Dimension, but
> > many tables have the potential of creating tuples greater than 8k.
> >
> > Thanks,
> > Nick
> >
>
> Automatically. We have had no one offer to do it, yet.
Ahh, well...bummer, then.. ;-)
Nick
^ permalink raw reply [nested|flat] 141+ messages in thread
* Open 6.4 items
@ 1998-10-02 06:18 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 4 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-02 06:18 UTC (permalink / raw)
To: hackers@postgreSQL.org
We still have some release-stoppper items on this list.
I need to integrate the cidr type into the system.
---------------------------------------------------------------------------
Possible additions
------------------
cidr/IP address type(Tom Helbekkmo)
rewrite system(Jan)
notify fixes(Tom)
Serious Bugs
------------
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
have psql dump out rules text with new function
man pages/sgml synchronization
generate html/postscript documentation
generate postmaster pid file and remove flock/fcntl lock code
CREATE TABLE test (x text, s serial) fails if no database creation permission
SELECT * FROM pg_rules WHERE pg_rules.oid = pg_class.oid crashes
handle oid's on views by either disallowing it or meaningful results
CREATE INDEX i_test ON pg_class (upper(relname)) fails
New Bugs
--------
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes: what do they do? should it be prevented?
low level locking - work-in-progress for 6.5
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chaining of pages to allow >8k tuples
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
no min/max for oid 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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-02 10:21 Jan Wieck <jwieck@debis.com>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
3 siblings, 1 reply; 141+ messages in thread
From: jwieck@debis.com @ 1998-10-02 10:21 UTC (permalink / raw)
To: maillist@candle.pha.pa.us; +Cc: hackers@postgreSQL.org
>
> We still have some release-stoppper items on this list.
>
> I need to integrate the cidr type into the system.
>
> ---------------------------------------------------------------------------
>
> Possible additions
> ------------------
> cidr/IP address type(Tom Helbekkmo)
> rewrite system(Jan)
I'm still waiting for 2 patches I sent to you to get applied.
Subjects where:
rewrite rules patch
Fix for pg_views/pg_rules and new system views
Do you need them again?
Still must tidy up the rewrite stuff and add the checks for
rules on select. But I would like the two patches applied
first to get in sync with CVS.
> notify fixes(Tom)
>
> Serious Bugs
> ------------
> change pg args for platforms that don't support argv changes
> (setproctitle()?, sendmail hack?)
> have psql dump out rules text with new function
This requires the second patch, because it covers subselect
backparsing for pg_get_ruledef.
> man pages/sgml synchronization
> generate html/postscript documentation
> generate postmaster pid file and remove flock/fcntl lock code
> CREATE TABLE test (x text, s serial) fails if no database creation permission
> SELECT * FROM pg_rules WHERE pg_rules.oid = pg_class.oid crashes
Will take a look at it.
> handle oid's on views by either disallowing it or meaningful results
> CREATE INDEX i_test ON pg_class (upper(relname)) fails
Don't functional indices need an operator class too?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-02 11:29 D'Arcy J.M. Cain <darcy@druid.net>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
3 siblings, 0 replies; 141+ messages in thread
From: darcy@druid.net @ 1998-10-02 11:29 UTC (permalink / raw)
To: maillist@candle.pha.pa.us; +Cc: hackers@postgreSQL.org
Thus spake Bruce Momjian
> Possible additions
> ------------------
> cidr/IP address type(Tom Helbekkmo)
> rewrite system(Jan)
> notify fixes(Tom)
What about the completion of PRIMARY KEY? I know that we are putting
FOREIGN KEY support off for a later version. Does that mean full PRIMARY
KEY hs been put off too? All that is left is to actually set the
relevant indisprimary bool in pg_index. I guess it also needs to be
added to pg_dump output as well as suppressing the related CREATE INDEX.
--
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 424 2871 (DoD#0082) (eNTP) | what's for dinner.
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-02 14:09 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
3 siblings, 1 reply; 141+ messages in thread
From: Tom Lane @ 1998-10-02 14:09 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: hackers@postgreSQL.org
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> We still have some release-stoppper items on this list.
I'm a little confused by this list. Some of these are things we clearly
have gotta do before 6.4 release, but some others are things I thought
were being put off for another day. Wouldn't it help to mark the list
items with priorities? Perhaps distinguish "must fix for 6.4", "would
like to have in 6.4", "future work".
regards, tom lane
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-02 14:43 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-02 14:43 UTC (permalink / raw)
To: tgl@sss.pgh.pa.us; +Cc: hackers@postgreSQL.org
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > We still have some release-stoppper items on this list.
>
> I'm a little confused by this list. Some of these are things we clearly
> have gotta do before 6.4 release, but some others are things I thought
> were being put off for another day. Wouldn't it help to mark the list
> items with priorities? Perhaps distinguish "must fix for 6.4", "would
> like to have in 6.4", "future work".
OK, but I normally don't make those decisions myself as to which are
which.
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-02 14:47 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Jan Wieck <jwieck@debis.com>
0 siblings, 2 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-02 14:47 UTC (permalink / raw)
To: jwieck@debis.com; +Cc: hackers@postgreSQL.org
> >
> > We still have some release-stoppper items on this list.
> >
> > I need to integrate the cidr type into the system.
> >
> > ---------------------------------------------------------------------------
> >
> > Possible additions
> > ------------------
> > cidr/IP address type(Tom Helbekkmo)
> > rewrite system(Jan)
>
> I'm still waiting for 2 patches I sent to you to get applied.
> Subjects where:
>
> rewrite rules patch
>
> Fix for pg_views/pg_rules and new system views
>
> Do you need them again?
I am afraid I do. I don't have them.
>
> Still must tidy up the rewrite stuff and add the checks for
> rules on select. But I would like the two patches applied
> first to get in sync with CVS.
>
> > notify fixes(Tom)
> >
> > Serious Bugs
> > ------------
> > change pg args for platforms that don't support argv changes
> > (setproctitle()?, sendmail hack?)
> > have psql dump out rules text with new function
>
> This requires the second patch, because it covers subselect
> backparsing for pg_get_ruledef.
>
> > man pages/sgml synchronization
> > generate html/postscript documentation
> > generate postmaster pid file and remove flock/fcntl lock code
> > CREATE TABLE test (x text, s serial) fails if no database creation permission
> > SELECT * FROM pg_rules WHERE pg_rules.oid = pg_class.oid crashes
>
> Will take a look at it.
>
> > handle oid's on views by either disallowing it or meaningful results
> > CREATE INDEX i_test ON pg_class (upper(relname)) fails
>
> Don't functional indices need an operator class too?
yes.
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-02 15:45 Jan Wieck <jwieck@debis.com>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 1 reply; 141+ messages in thread
From: jwieck@debis.com @ 1998-10-02 15:45 UTC (permalink / raw)
To: maillist@candle.pha.pa.us; +Cc: jwieck@debis.com; hackers@postgreSQL.org
>
> > >
> > > We still have some release-stoppper items on this list.
> > >
> > > I need to integrate the cidr type into the system.
> > >
> > > ---------------------------------------------------------------------------
> > >
> > > Possible additions
> > > ------------------
> > > cidr/IP address type(Tom Helbekkmo)
> > > rewrite system(Jan)
> >
> > I'm still waiting for 2 patches I sent to you to get applied.
> > Subjects where:
> >
> > rewrite rules patch
> >
> > Fix for pg_views/pg_rules and new system views
> >
> > Do you need them again?
>
> I am afraid I do. I don't have them.
>
Here's a combination of all the patches I'm currently waiting
for against a just updated CVS tree. It contains
Partial new rewrite system that handles subselects, view
aggregate columns, insert into select from view, updates
with set col = view-value and select rules restriction to
view definition.
Updates for rule/view backparsing utility functions to
handle subselects correct.
Little changes to system views pg_rules and pg_views.
New system views pg_tables and pg_indexes (where you can
see the complete index definition in the latter one).
Enabling array references on query parameters.
Bugfix for functional index.
The rule system isn't a release-stopper any longer.
But another stopper is that I don't know if the latest
changes to PL/pgSQL (not already in CVS) made it compile on
AIX. Still wait for some response from Dave.
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
begin 644 combined.diff.gz
M'XL("*WQ%#8"`V-O;6)I;F5D+F1I9F8`U#QK<]O&KI_57['*:1.]9=G.P_:)
M.Q[':7TGM5/'33]T.AI:7$EL*%+ADG9\TOSW"V`?W"6IARVW:3,9R2*Q6`"+
MQ6M!^L%XS+JCA(EDU(N38-*_\D8?>.3WO=&("]$/(I]_DI_>K#="N!4@W[1:
MK771U5XG`3L?I8QML\'S_>W=_=T7;+"W]^*;;K>[QES%\<_W=Y[+\2WW'Q&U
M\VR[L_/L!:,+C-5J-<:NXCAD+2]-S[(P;,+5SWCGE9=FLUHMX6F61.^]\.";
M.JLA:*T6"(0\`"@$#,:L\38.HI0GIP(``[\Q/HW&<9,]?LQ>GTYX^C:)1^?Y
MY?I+=AI=(R!<Q/EJGXE731O\W=V0-O:2O3YZ\^[D06FLE.?SIYV=%\\M><I_
MC`'-R5DV$[\%OW?<.]/+;/Z*BU&G-("8/*#+7^C3<`@,-8CK)AO/)LG02Q+O
M%CXGHE%!OH.Y5B.(Z`B!*^\W1E,O`1::2`/,XA7N/Y9"593-QPGG#079)-'7
M]`K9<I<L\%#P$BM3[LV'0!/*J)%F\Y!W<GG!'^?C\>^=7$Z6:$A/2.9[EIX\
M@,S;>!G5)%<VNI0KU.7%+R?_\K7)-^Y?LCC^0DLZ]Q+!D_XD`8MUZQ@UYTZU
MW71`RN;RZ=-J<[ETV//]P1(KN?MT[T5G]]F6LZ_EJI-%J;.W'J`]B_<9>WMT
M<?23`OFLU^;;;T&0,^\#/XM]WE#`:HWH=O<PRF97/`&P;P<'Y1F0&4V%;1&7
M4L'B>3H$QQ`D?)0&<;0I5>W\NH45;VY7D+QR]>EKR#_-DX(3K;B_5!-LP#OK
MP[+!R[5BL+W=&6S;OK,V1QEV#^DKO9US-`7H,%@:!_Y!!=`P#0.1(M@;_(9M
M??;+FS=J.1$XX2(+"0`7"0%HG,9UE7#O@_HA93_R!&>7PZ/A";"T3UP3H<^V
M;+5Y>$+15LZCV%4-<)MGIV^:"N2S^JXA"K"VK!7XGP!E<1C:*0UZ,PU"SAH(
MZ"++L=6.AJ<P&((AP.@%2&-^!0@-QT$B4D2A+"#^0VD2"2$N/8Q!=CKF=HWN
M97C/IJ:6*>@T\2(QCI,92KDQ%V`=T2P&W<,,YNFP.;#"?1Z->/.@UF^Q609"
MXY^`;R"I;]"AT!#C)2Q!@W#+4./L<O?\]%4S)X>'\:1Q<G%Q?M%AC\BA,(KX
M&(Z!*!"D)N0D5QSNI+M/Q".+6YP'B0NU'('9''LNR5JXDK^PQ%\^VF$G7,+.
MIOQ\,7\9KEZR4*]6?B>3=\KKV&^9/UF+17'*V0UG"<]@\Z13SDC9XS$2A6K4
M(3/)1)8@G#W4CZ,G*4,WB^-F=78.7\E-(+@:X[&(WQ`^>QC`V&@LC9"L1/Q3
M06,-RV6+@/.H*"/AXX:^3ONV4]I=!J7&2%Y_(?*[F9O%1C_A-TF0\GX8CSZ(
M@L$OW*LV]@6@HJU^NK^U56WH5PQ\MK_U8K&1W][M[&QI$_^?(!J%&<CE498&
MH>A?94&8!I'H31\Y=T<0;8&"]^>3H9AZ?GPC`;X!NF`C!2-V#5:6C:9\].$-
M$/66)S.A["H1V6$_9SRY92UR3BDH5P<W`4O(G?-/397'])$HT*;+:2`0T:^>
MN`2134"Y?!(#4+^M`N-*#_9\JS-X_DRS]T5B!5VPR(0+&Q"J,[0+'GJH?#5^
M#3H:RL!]\&P/IG^J_5(^_5\X[VH%5=^O^#B(^`)%+<`L5]@"\-T5=P4"U.$E
M4<K>7F=[:\]$*>",NN8?7B#]X6R4)0E'$<K)V-2+_!!"OT"P#U%\$T%DP&[B
MY`,#MYXHJ8+)O>:A0I)D(?C;.`IO>^PH\AEX#_;NY,W)\24#J"B%10O0!\[!
M#"$<![,;=<'T3H-H@O8'<'@R;$BG7HH3P]9*N>?WV#O86F2A@1*BC,59RJX#
M?B,8_J*Y%0Z@,^&3+(0T":QY`M/".'(EX*]N`?R69F1H]GIRC!IY2IS*V4_E
M$"D+:<.+DADG\8R)4>*EHZG"@#P_ZSUE(L9)1QZ*:A9?DV\`.TD*+2GVPA"F
M@D]R-T1_3PI2?F+\\7]>I&1KK1AM'%K39R:@^Q>NJ5PV2C,%(`"@$-:&47Z)
MCA>DHL9+XE.>D]@C@P<_19H$.+$B25(+/)%BK"?.2IL_>-[9WMZ66X;,Z&"7
M+FCQFCR9BS!.AT@&*-3+/"1NXYK@)TQV%A-A2@Y""F(6@R&Z9>=O7C$0Z=G)
MKQ*XKXM3GAL_XUP@>^Z-IHVPHU`M*4-M[^QTMB'Q,:G)%YWCZPEH^88R]'_)
MCG]Z-91"5$AQ#(*%/)JD4T5.$T&W)#4JB:0X[NS\\O3X!`(YO;9*`8SZ,,%#
MT!"MC[#2``'1U'P>)RGW'^F<TXD*<?>J+:[P/G)J817D';)!LP+3#$*:8&Z6
MX*YD?217`R&1\CDFH_!T/*7)J0=BJ&7PYY^,!G8/1_%L!MJ.03$N:$'6!5IQ
MKVE^NXH^26].I:$PYT'1JE>XKTV:W"BH?H&-@:P/C._";HG-1H(+R@1VV178
MUYMXQB.]BR,,6(+0!PR,V,_W4U_-*G7*&!)5.HKG/$J4OL57?W0/`2#R9EQ5
M[U!5=P9632-757L779`,SL_T7O<2;M.M-CV8>/"1`6VTPHY:H?!8V[CTD@E/
M3Z(TN:W56FG(9<GC@@L_GL%"M1+Z2UY]#<G1$`(\+(4%("U>P[_D/:S1U62E
M#3F5%R$^P?@>?]!OR1KR]BY&<Y>0PT`-A)3G].S=Y<G1*P9;Z\?3LQ\ZK-?K
M*?#^/WUSEO@#VDL,%O:D6(O#A]_?E822(U.X=`[J*<4KT_EO,0]M187<"!\S
M+\PK`>W21`3%$"H8!R-/NBY'?!0,%$0MYUD@U92VE\ZL\8K>R[FH]1@=$<PP
MN")829`Q+O8JX/>=;8\KCGS@8I%<!TF*4M.P17G<<IO_,FZ8W4=ST3V,X%.@
M])5^*TV0`L(TIUDUO[/<$E;6*4A'I:1<*0E(Y))L!$$6MRC#=6M@F6QPP`+V
MWY=L*9D`TVXWF;20-3"*J.J6I02%CX"%`'S&H,/*G*BRL32=6%D*.2Y#;DC)
M;K+%5.!M\1OA_ST?@:L(@_`+4H'&8SSD2`B8UC?GEA8"Q#":S1MR6IH>H>BL
M@L!Q+;;T"<]*H7/B^SL?XFG!,*'D%&6/XC";1422S`V^$X\@/LYG<6DR!(-/
M"GRDP"(/_=2F])"O(T*,CS(DK4$3A*AEHN#BIF2)X'_KD;70EV`L`F[>"Y57
M(?U7?L5#]P8ICHD4]$`9@X<00_NWKNE8L%,E+]I$Z@U@-L\6;1ZV:"`=G6#M
MHK"!()J@7`SC&0@H,AEDJ'M$X\LE..GKMT#O`R(=KW4/Y<8O1#;JP,99J>\$
MAH)*$.#6T(F#\/.-5#4[#W/3V=1;^HN[1F1P1V$L>`'%.J%I'I"B<\.T.$A[
M&T:7:Y=Z?I1I\?):CP%:J]ACH.]=[5F(X=G^UM[B<L^SSF!;IWW,^F"GKT[.
M+D]?GQX?79Z>G\$:4%+\[8^@!CS99_U,)%@A]<+^Z%HD<9SVYQ/Q,>RO0V+G
MF@UZVP.BJK^UU]\:L*W=_9W!_LX.9+JS/P(O8B>?YNS;G)[N0_TC;'V2)O%N
MKOVMO&\IWE_TMW?9%C#^?/_IWM_%>V79[T5G>R>O8.#/72V;8AD;MDRQ@AW%
M/A=8O\8`8\'-))C17WB[7;IMBC6R]&V/MT]>L78+(%C"0M-JKD$\$P7S3&UV
M,@+5"(;V1)4M.8/.TXH*O@J[17\$EC`-HFF12]5>A5;&FU5P(64G;L7(&TUY
M<;2\ZXW"^YT-',WGX>T%2"(`TX:^HE$N>%N>A)$GZ0`2>71IU\)595Q):4CE
MO1Q2%\@-@`1O48$JX#YFZ9HR68"'Y(;F%(WE-?@..Y[)K(:LLYQ2=W"I%&8X
M#KU)ASF5??FCA:G'<)[$/L2OPJ:"Y$-3*P&\RZ[>!-$'=6*%VE<FVH8_C\K2
M+(_P.9^K`02\=`C1I*#?)AS(1MU9/4[=TR-CD:JA9W'TCD*JJN'.V<_$PWA'
M8?B)IQZ3->*=[4Y^M+*AVK=+BATNU_N'V17M:@",:^5M\U^)4TD!^Z98JR28
MLKZJ`(GI=<!--)39:'Y/JA7=0IW,;SC*;JX6E%Y?+JL]A5&*<+J;>-&$7WI7
M(:?$:I@)[EM*W:G8U2*[HOTLAMF\A,^$U^M@PL`[7HZ4E#P>CT%XPVLO(3-?
MPBKOKX%H-$5V%R-RR8OXS3I\$V996S^:3!(^^65.<*YM6`Q^3$2]=VFB86_3
MY"'I>I7$\Y]!FTI3R-\86DI1X+$Z:U$KA85/F3QEIA7.G[P/:`M#M(5R&**!
MH>73TJ6T5=)5B6'-_ZZQ(_]Q>I%4NA!MW588N,J(!V*<W9T=<^8A#Y=@6<;Q
M@3Y=+MAX^'T^3X,99*1`D71JEB]JPOW/Z+9,OQ)N*>E!&9W,*#]*K4P'#J3K
M;R4T0B"0/LF!A-?,4Z.):B6?/D0([`A134Q-C<3D?@0ARR11C!E@=]"49)5H
M"+TYI$M^HQ`,,(.&L*N.D*ZNS92&YQ=+0[_@AY)\-(JC46FN?#"-^&(6&Z-R
M%OC<PWPPC?&0@9N37)F,DPPZF/5'NC0).:,RJA*!!,0*01:50-3=T(.8EAU%
MMRSDLQG6PO%P),XB5=7LJ;BZ7M"6.HL32!@J]`2[#>K.ZDNRU;+;M[0+D*0L
M`<BIKP+2G7=E7:HSU="U4)<:SIVFK5NJG:^@6X$XE43)%B[5+U8`HHKR2[>W
MK,BLUB#GNJM$=>:V)%6)HXC&W"NCDDU..;Y\9?+-0%=*0VED#JZU60&7II:#
M"JI?`"9V"?"+TV<#K@-^'(6ACOB5=JFS$92FJU]1<?DC?2AL*P`95X*?I[D)
MB?)E5EUPN.\B>?`1^FP.42BX`=P1Z(!N5-L"NYERJJRI"%(>I6'I1N,`GL4<
M2_M/&D]:3WK6N4:S)\\3^9-K#B[S&K"8LKD>31V'01H`!!:1,J"@QW[$#D/5
M0^'76)=YMVRPU=_;[:EA?:.N\W3I48I:?%J=L0?J8*\Q74V3C)>7QFS]U^BV
MK(1,'*75\7W>1%J($,WE<LZ5WZM(CPKX4$LI?BQI1:!`J:V52H_X&XG%0B39
MI71(55E2<V$Z%FPDU`^B+(Y4$Y1NHS2R7)YLNKM?B=5"I(?240751AOY$G68
M.T7'BK0*X4&=.E[&@6RCP2X26A5CY:56_'66L;[8--9@$T!6)36I5E/"U*8&
M?U;;&41+P%:3\V<;12E.D3S):2Q6$=RQTNM$%-*<T_FTZZZ=6[HDD#_4HQMJ
M2X'&PL#DH-)UZ-:8EW:'M^Y*=C:#>>Y&=\?G.E9G>4]KODHTZ/%C!:_.V\I3
M-]GA2[:=`]JVN`+Z[B26D;@4EPL^5EG%#+8W12F(*QD3V,^/K3J.D8RYMCX7
MKX-/L@T";:O(:2L<]3DLA^@0;#9P;4WS<#UO]<AML#(6>2<H[/-3%1*&P0?L
MHPO$/D5Z*MQ3$NOJ,W%C#&3(,?7@3^OLB8-_`+-.75@1R^:^EV+/FD_=@]B*
MP;'?&:[!/M-!)QY5T:&2Z-7>>D*H'QBCOM:UL)X<?H[QH346XU!5T>E95`L(
M<QD'HD;I?F[<G@A874S_P;1Q<,2S8#*E,RV9*OO%J)2Z9.OKE`K5NK"JDF&]
MLIKA7"V4#NL+2X?.L+R$J,/C/!ZQ"BVV$S(/99AJB^N;I'@L+Y>D!"#MDVIL
MT50`,W*[6R!7GB\^ND^#HO+IV="MT6F:F3H_8"N'5U:#B@M"?2KHHK[__GM8
MOY&'S3(01\EG!603IO4L1"WOM+P)TBGDX@F7^AE')3@YQ_>L"Y&0/!HC`/T\
M`T#\>G1Q=GKV0[U>9Z=CG%;$,P[.@W8#3KUB+C,))5JRK<H;A;IY56HEGN]>
M)?$''O7,*(0\&H7G$-XEJ.!B&F>A3]VC*`6@@F(LUKCB87S39,&8MC/L[7SB
MDE53^[JC>WEDMTV7FL_4J+X=W$D;Y.K7*)[?GE_]@=54Y?3<]5*&2S=&6>Y-
M&B>3/>00^N%/4A^Y:9UY+`,I;\LYM*-.TH[:ZW940O6_JU"U54!PG'OI)*V*
MVI7XT!+-$WD"[/G^<!8(`61B;4T,TWAXY<EC$M%HJH-WWU?]N5+H5_$D$^J\
M/J5F-&IXMGI,W'@;2,-'2EX#KF/<-,6`6N\\9CI<C!`*(E.)DMS7M@"M%30B
ME#(LB19W+?WA[&=WK`4#`.=4I'SO)6=4YG/@J<;+#`O-J@'FX1AG9.X)5XW/
MB\D.H*1^K;DF29S-CT.T+/<C%APCJ,#/"V@P==!%`C*6GKV]>+<]//[EXN+D
M['+X'FS/.6OG&.V`94N25\"]4I8/-Y4E]KNAJA3*ZH7YJX5DK>%]I\HS/-?P
M6F9)GG2_!^->"DO5MEVV"]S<%^AS`U+'OMKS00QUI,\O[CJO'0#;`;,T^I2.
M=`P='?981@6%;,R$+_A*B+H"R:D\\GVJDQ>C='N75)ELZGJY"2!M);](V5T@
MNR&E:YMYL-+*".<MS4#&U6UN]B%$C+%C!IV1I7'R;P&@!".P$\V<`@E\TL"/
MY7,RZJE'9@8!'";3]7)=)3>W]DQNH6\1T,*]<:"%^*/1X86BS-5<.6IKMJDG
MCB8385+.?(R\_N>?K`Q=B48=J52B,O=*Z/2=7'D6E(_>RBQ`Q^DK2D=JG!/O
M+B\.J2/$3$84A6ITZH;1ZE1]B`H7.$5H50-06X:ZW$PJ=L?@1=9R"A&,++ZH
M1_),O<?JZ3*I@%U+5X^D6I4D0V*[?:!_EW!9_6'ZMMT>IL^9\L.4(HZ*-D`"
M_JR/5R1AJI=B88'06MZN'<SGUK%XV26C<-]=?G=H%G)UA$,',79/7@FM`B1;
MYYQ+:^YDW8*85!U\W3PADE#E&E])=[K5BI.?>*VE.-WU%(?`5M<[NXOUR[EE
M1I7N^-EL=FO:4\R9G*V6W?NII3/,%%L7J^;!.@MM]K"KZ'E=5!>!U(3*JFQ8
MJ-5E'DJ4";']/-MGG;8I\>=]18ZK-\U$.0&.?W<[B11%C]WUL8M?!5UW*U:J
M3HLGNTKSG8JE)-5]#T79F,J<IG#=PL>J*E\%<*L*YIZ>PX5CR)*.(E]'(&4G
MHMZ5Q9Q#I([L`]S=P2<936-0Y2FY<R);U97"NK*'$A_(Y?+I*U7E@F3RXO*$
M6OGR*IA\:&6,CXH&LLX&TU)%;@2#L3QQ0WW<0<0@997E./V("`5%I0-9=';P
M:]..&5V8PL7%`94'&$ZI2-P$*1ZW`?"E-Z'O9E,BT:]"L)Z-V'<+K/;S9:WJ
M)RD`G_/R%VF#J]@TFT#G!@UZLH(Z1?(=4CY]*K2HV#5H\W8'FQW9$U+@1%ZL
MM;S)A%ZW0C\WI1^0Z3#^03GX(0\["VQ8=VJM23)'7JQKFS($&&%!$.)!^9%O
MVG`8P4LU[!)"#F3OSV:D`RI(E1*(E1^2\M.4%RG'2[56D-)+IAKX:U/2$5?W
M$#_ONA=8F?ZZNQ?P'2L7?%S<#>HR/B`ZIOV@+AA6ZO9;DM;D`W!A7##.P"<E
M1/A=N&GF;W0AX=F'.?>G!1_2^*?0\D^@P1-B$CTX(:[CJ:_2RO=><5/!E5KK
MFMI6&N^]I%H-X7[W$#XD:=D<G9_K'5U"-;P\R]5<'E2^1.A.]-.+Y_:=#@WW
M?%G!'4,4DZX!AV%/02`4M[="2P(J)V'X.@7]2C/RYLR\#6NU/AB%4*E*:*E!
MA1XL4(0J3?AR/U50Y8@"]^IJK07SHTJ8[M$-K!.@ZAZ&?(QG1_[FVG]/`N!#
MG@NM30%KL\$J*NXH=`K`"R*71YVMC^Z3X?<7]\?"4[5?0>!$`I4UO];D5B'P
M:Y%@E3`?C(9UU<T'?P,9Y+YND;1?[I!%\H4^E,6DW@0?NPT6A$Q-?-S326`.
MJE`2WX'8EP_GTH#X';WIQAUE$ZFS6BNQ->F3W=0A4TOW`06=5!Y3MR$LC,?$
MG(_P]0/6D\+JA:3Q6&6:@<`:MFS^K3FII,D>%R2/#_)XQ+\D@RSP>M_<44KA
M:Z:2*QE9-XG<D)6'SRE7<K9F-KDA8QLEERMY6"^MW)"%S;+,E3S<(;_<=+_<
M-]UT7LJ[DJ$[)YK+V%K#WZY-T-K9YM]%T#^&D/7RSKM3P\R;*!S/9;WNH5I3
MUT]!V3\D!56<NBEHFU6P;L.I%'0EG$Q!VU(@;3<%-6_[6):"MO,4M*@4[27)
M9[N<?)I+2AO:"Y+1=E4RVE;)Z)I*X0K!)*..'%8EHT8\RWA?F(:VV2+^"^Q7
M<U]@_LZ4V/GHO4A1Z>E2<NZX#"H]=19A67IZ-[;+B>G76P([0_W*5#BIZE>F
MQ<U9_Q)BUE5)D\*VUTYA"SQ6):_M>R6O!6_&F'E+42EYK9ODM<WH5520O!8>
MA(?L%2_7?E5'HOH]5-<\P9?98\):Z,MLXA-UD3XXQ7Y<0F".3>EGWWU.&W[=
M^P%\&$O;OYRJMEG>/?TW)JDF]"FRM%YZJAB]0W1=WS0;O0/%_U_>M[^U<2R)
M_JS]*QIVCRU9`^C],"<^GV/CA.\XX`-XC[,GN7Q"&D`;H5'TL,,FOG_[[:KJ
M]_2,9O0`LI<X(,WTH[JZNKM>7>670]>%>7VQ,\<0O`+GNB/()5_F`-8G6:X+
M:SY!,@>PB2+DVC2]MH%R.?!+Q,4L0\C12X(,N.%>MMNZ3UI;=Z:W9?33YB]#
MV"I_(XZ5P_A+N#(>>_\UG]7/6\`T]WD+K&?GDR-)G,94XYX[?;GG;TU+W7+B
M2S+0+26\?#WX+'!I7:"`LTVCVG*XDVUIF\.-SUBVX=:]UK`-]^$W=ZV\=ZU@
MP7(!W:;Q2GGPRZ_24.7$JI*6*LSC(?A\Y\(.)%*+L%3\PN[F(E])3_\TZY-$
M_L.R].X85[4XZ=$_"I^_?!A9[4T;&,@&F?_EX\IH;=K`L%:3"):/()NM:0,#
M6%%,6#Z"'):F3:R3M66'Y2/*;6K*.*X<76<V*FV^ZT?H,INA:`/4LR5Y1$=D
ML002P_KCEUB^T>=F@LSB*?$GDEH2*2"O2Z)GZA]:EEE.S=F=#;-0<KYNL[D8
M+NEWZU+/\L'D\2#<*!:S^0UNOLN,WH*;[SBKC^`ZN^X*DI0+_:-(4I[8O%*:
M.A[+P".C>X;1J>%R&,6SQ0MEO3'K846(SR22K:#CX'!,+9#'GY&Q2*=^[`W^
M&_[@I7KCM`'[$J5@I!;4];/]!-EM26SAIRN0^0!/$\JV+5EE@\>4KK8G2V2#
M1<L36Q0*LH'B"`8/P]UG`\W+X2O&-5\;%JN^8AOKU-7,\Y8X8)?[E=$,_A0L
M:"HNXVSH`S"2V6;79B9+J]6/.'6O6E=SE%ME";-!Y+*%I=5:0/YNQ;H&H[9B
M"R;'M6FVR0?&H[-.=IX"?7,"GDHF1]RC!Q9'L5&2K4I@IZ@9P5.Q&#NE<CCS
MYB!(F[RCKYJA^M>+L4CY'+%)!$IK$<ZH'TVG4`U3+<'MC2Q<UD93,DC^#`--
MOB`.C<G&))4\;>;-P8>[(OB2>&:R<4]8N9YW5!8S^.?1M><=IJ%Y?YJJ][P#
M,ACGIZF)SSL@E_U^\HKYO`/T,_&;T%RO"HDM"CPF)(\/@2&6_/^AU+=#Z_('
MI<--J?P+<5@A;ID:3D$R!S!@P7/RTG]"BT$6:C/)30MN3]Z`D'<A.1+@AK3#
M*T%!<N1C0F!(HT_9P)%W;#&Y]I%P;$C'CPF!*6,_)AR6I/Z$C",I@WET85_F
M"I1B/J5#0HEZLIA*\9OU1[#$*+Z[+;=GD+)7R4?XD,*TYD0V)X::92*WD!QQ
M`L$K?.615)72*O)[C8DLCP_`4L3%VWSR(20>N`1P/5*B+@4X=$MY\`HD8A3]
MAB$>-`>(HRF\Z,L$769\)BC*,7D_"4^'`XC,^>WIZ?O3X[<ZN!*NTJ.SL],S
M@T'9U9HO:`'N7T40!-/1=PUGD+`#M%R040SBANQJUA/AP6Q6OX0PL46$TWD/
M.<GX4ZRO@/,6&840'+;J?<?A6(Q&5F(*M\CGW@BA*;[MS1=W)3.6E%7NZOXS
MYCEQ;I_[^%R%<#,@E7G).ON"4/025P3H12%)(.:UEW5=Y!7_=8'(*;'6ZD]6
M#^BQ)KKV91WK&DH!NUP4+[C6Z)?I#HSY3G<&-#&Q0O])&H-X_PD>@6OVO[S?
MS?;GU0K$._4Y!&:EN71!5'^-,`6<$$)-8BJ(7'*CH2-F9XC&EXX1"R5:=#5E
M5XF+\?RV.!H&++)<XRSL<P"5*3:+C+^J_&J5BF+%UEJ'R<*=)HI$![>L%)%?
MG#-*1$Z1M8;KE;/T2'U.:&J0JW7F%ZF<+KU.:$NQNZ8`HX!_=-'%2$FNC)1H
M@C1LDC@0-$@ZW)?!F8'A41DG9UY/,(P(!PE37&E'K2='Y,F3+EV*.G*QXIJ&
MFH<ZKQT^PX!S.I>=>":2R5FI#@J0X`L?"QD$!17^`9^!GI6SV2@AX`/79D@-
M8DK&`ASV\`&?(>LM+3B&VE0,KN0*9D@;?$NL!,PPU``;+L6JD@KB;Y:O+BEO
M,MYL=TJ)!U]"]F".UJ&,B5"+3>0,\]*H],"2X=9\I[]='SU@^AQT_[N"/#B,
M8V!^2\D7!:N_J]`AA&A+3G1'B9#0G!24_KM(-94X1VF@YR&4<');8(M43"JM
M]U@U8`G)XO@L%PSQPJ``F6L:9]\H0O3@C&GO%5\S(#_,'+:?Z@-7,!M'!2E[
M&$]!:H%A%$\GR!63)8]4EO"7,AI`*4]-OM08I'QU7T&:"_YB,IM/!XM)<?>O
MXP@>O=HMN25_">\+@DUP'D=*36^^^&^^-18,O@*MX`I)QA)1YO&"%G;TVD.-
M!*W:Q)Q^OZID1-Y]5YT5ST1#@>K':82S(<ZZE-NB,:UBUZ$.Q7L\M^'I!4W2
MT:</9Y?G'[]]?WSR=[L<G_V([PBF\*C>225XX1L[]T4\8Z*QUATX@!X**0W`
MX.*@$\M1T!E_%-IQ+S5&C[MK2@,2L^;N:S9FI06'EG4FD4.[W&(^'`WG]^?S
MNWG!@,PH012O$M%((M0%.'<;%1(J#V<?^);6&\7F0KW_=CCNT>A][Q=CWF=O
M-$IYSS^]&_5N$@"8\>Z%YT+"\'#WB4TFW\U*3DFM68^5GH]BI8'2$2OF::A?
M&TIA!.S8A4MS40F`B\1>\%9I/JRW,D]7*F[CN!&DY/,!,\AN)!>G6];1).MM
MH1A;@:6`62>#X!:KUF-II(QO/1EZPGU[Z[T8TD3>KHRX2P9WE<Y@FGKQ\[`W
MY3(DL)))C.2,7-@@27MO.$YR7*.\S3"2^7"^P`2YX1TDU1-@S?;9Q6TX,W6'
M(JT-;.9#6*/W#//=HC;>`D9``)Y",<Y'M"$9V2S><5Z=?2+[^@0T]=O076_$
M-2M9VO,[9)FIKC;M:.5J#XRMJ&#EG=:G,NB^:PGJDN2A>5VS8B,S!B45(@8H
M*4+$CA8*#)^/%"G"J$!C>=CAD`8F24@$T3"A5?'8HT07LU<HI.2;-)3U6_9N
M6T5IG8O0-^NKMKJ6.3[I^=I-TAZOV^ZFV_-J?7/-V.:]BW)K9G/!NT%?H964
MIU);^6AW.7+J0+T;58[V_&K.;%.VIA[SX768@M$B'/#O[_@6\`,DP>3M7+Q'
MW8L@__D(,USW;T$)%%Y"[%3(WQG+O3N4R)!)4(<@(8%'DLZ=:_G^TWT`L5"&
M`FSH1B8KA7X4AK5"Q=!V*#W+H=+<[<SFT_[=I*@@Q7R4"'+)RJADW!W0^;!E
MFE<A%27C"X3V2]`U%<$<#YHAA1&RXL,8^GZC.13JV_9RI5KJ6T9RCJQ+_HI_
M*6(75A%I"/\`-T_"Z7?A'"WB161IK9+*JJ[LW'W'2"XZPJ]&5Q)5,BE[WXL4
MP:UST7AT?WEV?'8)//V2^RNQ9+A\GBQZ@^(O=.KR_RT77!PDK7.I!7"FOA#6
MU%>%N$>Y[Y)ED)GON&QWF!N4L;*,.NN5E^T.>K7;,%G&E_$&S':'MZ+XD&5\
M>2[$;'E]KBU_9!EO_OLQZX\Z%V#9K\L\,&!/#J",EVFV2[5/X9Z-L%=S5)AN
M@;3U^=A@+;XYZ"@`UR2XS"+'&R:W'QK8T<!@Q@'KTK=TZE2LB0;0U*YH/E,V
MI;DS(TV!^O[5Z2&&N5>L8F)+Z:C`>$6V;3X+)C`Q^[JTX0E2$[,&3]W[16[G
M%I3N2,5\T&-):;;.Z,]T"REI:6;0$GCN'EFK,D:'\77YT!>3LFQ$.2XCK;D)
MY04JX\V@U:':^J6A+$/-=5'HX68@X[VA!P8HZS6B!P8K\ZVB+1WC*^BYG+$]
MAI9+*"A>`R1G(6^%C_5L,0J+KOU08H2Q,W*W@E+L!62IT:\L18;]5+A+7"(R
MS<;HN2I@5U.GG5)JT)I'-1CO^K)'448,AP#D8=1[Y6F@E''DWR"ZH0=8`'R2
MX<R?`X,CH>"#(2N;4>2J-YC]:EW$0'V0[(V_@,^T<`^EJH4>$;0S0^UGV/'L
M(IP;J98*!R_8W_[V-W85]E&P_A*R00374>"<&(4&-\6'\H)2!K$OP_DMNXO0
M9-T;LV@<*T=]_(WM]>[)MFQJ_XAZ;.3&78%L8`7)">19=U1PK2C'/5W"<D+#
M*4ETM#+]X:0&=3H'EQ1\KI$9UYQI+>I4*Q@+Z$2`F(`[*1#,!J+43#EE0I;?
MP>#R;HC)F"!.XNQR'EU>\3/HDE,HQ'2GRW6#`21K$JWTV%5TLY@QU%[(0#?C
M\(OP<F"PQ^R+P@>$7F")A^-WO*TW0#'7/8XA0]<JR0[@%]2AD6"A;-R/QGWQ
MUG*Y,F90H9!P&$,MD"Q^L(C9KFN5B:4.4&I0M0P"OK34,`)6*66H1ST&\7JH
MEW5"5_JZ5'L'^W!V7KM\\_'L[.B$L^VOSTY..:-AM*O5K0*R].8%9*NWK_8!
M:Q_4M,O<PT"=;^R9WH.-9JD2/P=]_J6R&+F6BLD7T%MSJWF>@&F-LD!)&DSN
M?#T<5-:&(G#W/6Z'',[7,E$<GF$6XFB!)/4C9U8/1>QPO$%(^JW!>$;[OP$,
MS*L6RYX]8SNB"!/@O1X,T(QEPF/"H3U)&>,[_@5L2E^&HQ'?NT?W[$LTQ53H
M*I<YEWR!C:!M!OV;.>\Q'/.^K^[QV74T&D5?Q`8%1QPSF"/Z/)-E9V`Y4OGU
M9BR:\B,F)`=L51H<IWNCT8[8OAB`8^[09O.F/8'WS?S%OK$08+PX5"C[7O&9
MB8@S6%%1S_:O`']`$`V<2O3\CS\\I?WM&'X:L;;4.]Y>0C5!*X44!HP?4D"_
MT?A<"EQ_CI"R'K@?,Z)L)G#R!I3=H"$D$WRF)61K)HM,D#Q(N-M,D#Q*M-M,
MD*4'N\W5A#_6;:XFUJBZ:J3;)ZUK3,.`1H&A;#S<[DU/K;+*2V?)(6M)_R4:
M01FPF.ZAE*/;7\6U"^T<:;1FN#@R,:)M:?$RH2@MCFWV!F)A;+-738ABF[V!
M;0:Q]4#Q*'=#34*5;ONH?\(P_"KU,0.G?5C;4Q`E2`8E`1NCV2(G[#K'"^+1
M_!2MAD1?>%3H2)8_[7JFNNW#Y3>M3N)[4=3_948E>$_O^;<"ZIW$,ZTIH\>Q
MIS@?HWNM79)BA'XRM/K3\K^0I>3UHR^WPU&H1:R_2KU!7(\BF<%RV1RY]A)#
M?%]`440"I=R.75VS15RQW\*=BN%8!@R1F@[04L3$OP3]#B"8E[\->Y/+:!*.
MI\IZB'YJVIF-/^&/!Y=$*ZZE$.OW1]$LA(*2/FWPE#U0-,&L)JD,SB]3UY$<
M[=$;+F?!-@ARE*9;O-NA<DX`85NJ'[B:4J38!VS(YPDK[;T:+^[>(S&Q8;FL
MQ@$OA4*1E\$__QK^+(:C]8JDN=HQK[7)$]`><\&M2?*M8_K<<?*MQR<_W2)G
M2<Z*."Q0Z)%$K[P[AM])QBLYDV1@_3;L_\(XLX5:.KIVH]';A[>`R0^\P$RV
MZ"%;GSKP)/I",X:W?=QI4YP&-NK.D>(A]/#$ZM['Z2E(O3!^.[1+$+)4$?KJ
ME,$+=#'ELM$&*6-U(_1=@Q-7\L<G])EH33V(S:\-,JR\O:HNK77[A6=*=P\9
MY8VI]"U.^=)S2"D6P_$WCGD)&^JIV#W=@,5]H(4+IWKAOVDV'(0]H2(&X/@N
M<;,8]:9BL>.D!T`N*FX4!DZ?S</>@!J@@G";;#&.%1%O1[W9?)^]'M_S;?ON
M#C3DO,=^M!B+0.VQ:V#$Z_+OT7003L_PF*-G1)PQ'V0)MKY:J=V3"12YE287
MT-#["GF<G!4L4D'OFHXNH02P?=:;DNWZK/=\60/NR1X34"6DK=_M?4T4(G.,
MJ2J!T#/V8.768ST7:B9H17-$*N:5#QUN,^J=W12M@[*,95`FLXN<&=F(>!*K
M*ORP97&A^I>%8UU;CLH)A7&XV/I7_C\'"/XQEY]B_*B;W+\>#Z0F,VX=9,*<
M1D0H]I[@WU[8/_"=-5JUH-%J,WRPM[?':K5F(ZC56A7&O^U)6)B`Y0#ZAYN9
ML#4(IA$?\%^@48#+D_-;SCC?W"+"B.IH'X>5A$/<]T/2Z03-2H4@X2,X@#2_
M$=^8J"&YY-'D`T8<""A!A,/7(B-]G#C#<$4@,1(M?IA&_7`VD]LM(JSH.T#C
MG)#Y4L[3]:AW$Z#1S."!7IAO;1=^ZS:V>U%#T[)TZH?%C`2&>%?GLK&YT%(^
M!!3QY3WR[%^`$YK-3I7/9J<M9W.3:-TTP#ZJ:%::0;-:550A[,1X;@N#,CQ5
M.Y\Z:*VGT\-_V^/?(6!@`>\$7YJS!1[YYO=#,9#"`77)SXUC"^"^SNMA!R"0
M"3A0(-IGYV@6$!/1K?&)Z(J)\`VUU6@&K6;-6(J-.I^\1D,M1;08[^7^D34/
MZ,-P?!T1_QHW*XIWG"7"[5`@P+^`8NT$JKK8@FC9/(LA7"T>[`3AH@H':XR.
MG<_#"6OX4=NN!.UN6U&1H%R:O)G:<??`XF.TO`<L@S@-/TS#"6&!]EMZ6Q!Y
M[`9<*!Z.9C)+B\'B(I'`2IO=<P3<4:U!"!L"B-74A],G7[N626(O`0B/,+W'
M68T]7.56FX`?RVQUV^.[LD.]<`6IQ]GXFS&1+=:B(FP0W<$%?2X97873F31X
M*=E$O1B:=87)7=I9]]F[X6\GX%S#-`+8D`MHP+'QH8UZ?3"44>47X_`+='\=
M3L-Q7R;.050*7PAA-3,O_5-5W,QH=0+:YL@/PHH4[UW4`+X+CAG-6=A<*`/D
M%A"['N<&VF"T:F)`#]0.-!_1`_=J&3TE9Q:Z+`:RQA[#QR2OQ^RW*,$G@PHB
M/59W;W,:TCVV/D@5[@4,DH.<CRP]@:'9PV*$EX+73"4YR/E(]*Q&RLL*Q^37
M\_G)XJXX'03>BW.R8NQ=Q&0D(<(;L'0"<E.T&5`#\$Z\3U_LT6PN%MH)%W](
MP2I7/,JD\@03RE>E)1/*,#Q44=-W=4_5-#E:6T'*TI<,WUX:5,E;@.%DA6,7
M-&;IJO9,'RZ^WJ"!!-<?11&FUT^<M%+6R"5I#&TO('O5B#*7<L=0OF183&CU
M:$RBI%(*J6)JW):^R'HCSZ+D$O!&`N>(2<;J)%1"9$KQ/0:]M;SHM;W&C&H2
MFE@[IB),](W"E5716H8TUW#N]N\&XNZFF%XK^I)JK^![R^S03'N&EDCL+W=P
M!P%5945=,F`V9*9V4G0CEW-"KP;@>DT7#%9T1["BQI`E64(!)>SND6V#@!6Z
MH03Q5DAV>^HR!REN#-E6;*DN\9`P9SVE_F5K7YTAV`TL'8I5W!F2/#=,/Z9#
MZYUQ0Z&B9SL/+NS6I=>%TE:BS@F%5E$^KMD2LVP>2HR1LZKU1&FWK*>.LZI3
MPUXI]FM3Z>7,1.R`<%O2YP7\E7([#>003Q%FR.9"`Z3\<?W<68`1RVU90UXG
M?@&RS"7?W0>+_GP&0M;OP*B^N1-1TK2B4NU1HO`E'#A#2UFDV`G.%IB[445*
M-J]GLW!J;.Y(A70?FPJ0$OL;<X.WM@TJA7>#J"1M%1\OCM\?7_Q(>B!;/!02
M3;/#)9I.5TDT"9RX_/>(^"TL0[`7OSZS%9&68[M*/.IL^Y7_G-O<+)9!5H#?
M($#A]BUUI--0>#8/N(`.SB+(I7^!IY]#E:6;:DH,H;EE=ALM1@.XJ\]9\[#/
MI8,!%3N`/S&:D2:2LD,R91NXCQ@+<$B0@=NUYNW)(8[SO5]N[U$[##Y[MUQL
M^)OL-R^M^F3(3J4>=#I*$T'$ZU)`(E>.S>Z88,0M1+_[?*)#7`/A'5098J3=
MQ630@S@$G,SY]*.3(&<%YZ%E(DG@O@Z%ZC<+%69AN*353C-W_.-U"$YO#G)2
MK(SY^::=W'S3SO+]WE1NVVWOF&IKH=YVV4QZ:C!$.,L>7B@1+8:Q*K;SF,X+
MJ%'S:"]9K&WC%4%C/+`V2>,Y@6D\L#?.F"70%&`$T0["<&)NU-J)E384HNKA
M?"&3X6"M+[!B'?F)2_A"Y,<PTW)@,QE_&BOB?N25QZ0K;A$<<\GL`UV/AK^$
M)7D'`)1T?%/KPWX'YF`,+0B@J`*Q`1XH.G'G23)S/CJ9_"JL%UKBFM_)NZ2J
M%*19DLAV;-V*+YS\RJG&[KEDN_'PADW_'<G737Y5WFA4(DVPY"54:0<JJ=`V
M'W.Y_<Z]E!4_0,T:KN5?6`#M.D*SO"?<S(5TB>S;P0O\X]TE!1V(`JC?,?`>
M\0I3N2,;NVV,=16:WADIDTCIBYK23Y\^L8]C"DTYA7B1$\YFJBLH-[WAV+YC
M@CTF2]:">284$*_J5;EB,X'/2F'PO3;[@[=_)#>KN"MAQP$]7@]4C*"Y'8Y!
M-S'E)_9TACO3%U1O\_Z%6P7I^%#'/;R#@U@X_F!+?7XR71D:MWWVEI])_3E8
M??KW?5B.?&+`9TXN,]`V#GA[/3S5PM_ZX;0_G/%U1YQBMQG4FK6.Y!17/&]I
M<G.>I)R5(/,R["*B/FHJ]^G+@?#Z6?G,6^W(RWWB93KPEIQWM*5X3[O-''8)
M9UW:49=\TKD'7<(YYQYS\5-.VK,,UX3XQF18:I_XDO(RM)UVT.6BF&!HA:@%
MH@V'"O<;<3P<CS]'OT@5@MP^4'EIEI+Z4:;4G-%86AL^#WMV6=*`<GJ(9K/A
MU>B>$9)A9!4(P<ZXD'(OVQ,85_I1(0WN64TF*T(3;"=QS:;9G/`8]L287U[0
MN@EC*1#,BJ?CT('AJU1+T\`]O>`+>HL7DP2FZ7R23LXBB/90>\0,(D`LLC[1
MEQ!LO&/Y<I]:^R=(=$`\]\1.]2/*R0!UT/`CYW0411-Q11-QR4M.<16&`VKI
M<V\ZA(UN1E88],2WY</P-YB_X=@`=#_![.5#M'D51\QP_"K.GG$5AV:`KN(P
MYRZ.5E?[KN/L&8ZT>_%+,0FOZ0Z(I:?#.R!HM[:3[S'RK%9J.=]XE<N5D8K-
MTF=Y0,`+`0GOR)??`D_O[@8L2@NIO?F9Q'HA"5CMO+\,1.6X;T$B:1B`T8D7
M#/]]A;&"Q4G3-F.RO/$`Z(?N:*?AW!BO8"?)]Q`6R0#\MFF1,/9/N.U-FH59
M!*;4GEH2O<&`;[>ZL@1671"72V4XAXV9KWE*80AMP7+:5U4/LI"!$<*_E)5T
M8F'[S9H<#1QS[M;TJ\CRH!7B.[R@FOPX>BTC#/FUX-7$T3C\;5Z$NLJ#)*T-
M:1P*YR6S*5G'2C;S%M$+#O;LEO]O[$HRD0#M.'J;C-@=YQN&DU$H]Z3]W612
M58[]>^2<P"`?%H6?9\B*S]2<Z5I?]7X?W]0)S1R_RP]-=TOTGGHP4XD'7]HQ
M3K-/-(^6^E]`]@;)G<%0YK<H+??450#3?"EN"[#>O6$^%R><*_LG'G'(X<0T
M!<J;S#K9:"HU0-*G8D:B%HO&JM@PG&F&"1L3CE#->H/+$_5NLO]-M=*H!/R7
MZ8'3[%:"6JM;MZ40H;(6O9#2NBP<]E!AZ9WH<M)$EQGI1NV)+F>8Z#*?Z'+Z
M1#MJU%4G6BMPLTQTV4*(J4$II[K4E%=RJ2D[+C5EQZ[NX!=YBW)VEQJ!9'<<
MJ[C4E-=PJ2FOXU)37MVEIKS$I:;LNM38NOXE+C5EX+_*"2XU9=>EINRZU)2]
M+C5ECTL-K8-U7&K*Z2XUY>4N-0*&#"XU950@EK.YU)17=:DI9W"I*0LO:?S@
MNM24&;Y+V/V6;WTH&-*G:0;)4+8CY$,E&,H%[MTYDU>TN,>%_8/KZZ'Q4!@D
MI0JV;-[Z*NL,@R+!E;/)HB=BE;Z(1Q>HW9[-(9+$+`SO@(V\"RD`S]64;]=C
MBA4D?$HY\N7Z%PW,(E(>Z-WD3DIP>L%E$'5]H-8L4/7]OW$TWK.,@FI2."FB
M&J+BF0L)C,*KA[M<!E$]`2+[=I>\E2B/4=FS>3](05&B22_$1`7CLA#9(.7,
MZRL`^"2P+S(2@ZP7@7$V*FNV7AJ#X?4UV^M/V6S:WP?_EH.K7I_/^N!`$+[\
M^T-O/)SL]Z'<DB+(M&1LKO!N.F2GG,%F-59MOZPU7U8JK-KM=I#-6=Z76[_U
MLM*E^CY.JET/VAW-1?&OW:;APUPXQ<A#7$@]L</[:`DW8!2=2%S30%V<YK++
M;IR#,LF091WG`-V\[%`'0G046UDR%'9X`P.2,D%2]D.B0QQ8T*@0!R1QNE$.
ML@+EBVS@@K:TLAG3('?EE2JI.`;I:&2.ZH(1!ID*O8O8L\+O"L1Y&?EF.ZBV
M##:^VFX$U6[+)$&5.2V-!$<#BD&%?FORHQ.$<&ODF01AC#RS0/D0I)L$<`+I
M9@9[:<,.66^NX8TW:"Z'%:=MLTNEWJP']::Q5]<[[:!1,9?*63B+1I]#$#+@
M>H=,%TCI+_0US^*S8M%2:Y9TA'TFK2S>Q9.Z:O+T;BZDDAW^OIP$0;85D0<*
M=X64O)'ITP%:OS\WX/RV^WNH?JSP\)EF-77!D)0(JMA+$8L=_',YKU@TUTY)
M1&KWKZ%&LQ$TFEV]AIJ56J`T3<P,]\D>[/2`KPF1^"P\QS)%R.A\IK@+'9HS
MI?VY05MQR0656'$=HX_B[\4*/,(!E14G"=DD'A,SN6%WUO^?"O8_(\SFOO1T
MEE#NO2_[KM?L-H)FU]CU6IS);EN<PS*SI[SU:2#[/X?AESB2#<MGR<0"AK6E
M6*(&;MT"$M$:G[GVGHULPOYQQ=/T//#8-KVO^H>9E)UG.X/-#$X"B_18X#P1
M,"P&BRV#A>6$1?`[R=JPQ7PXFAWT!O,#T++A-T<9YBWAUX5YBWI4836_*BQ3
M];;2I'EWR5K0JAJ<82UH-^0.^>_#<7^TX#.P2QV-9O>S?J]_&^[?[EJO^[UY
M;Q3='$QN+OLC/C\I[^'*'+PN^U_/;GN#Z$M*`9R_E/?1Q`O!]=W-E)Y)_["8
MS>]]U.^-V(`WA5DD9XE6.G@[X/O,;#Y=<#3_8WK__9#OKK@WV<\*!5#JX[T=
MK9(W=/)?9<'#!&,DVJ"_&T57`C)ZX!0X2`C6$+2,PZ_=#CKJZ!-V1DI%BM!<
M\@4CKMSM"H7Z"_;N[/0'QG$J+1___/[H[`@UVR*#Z']4=P]U<^A3^&(RZHVA
M-0PUK:\#^;L4A7)U"0I]\T%M]]`VG6H8>G<*@G("!%@DWC]_3%U#>V*@"9T(
MBEO:DRX7[TZ^B_7IIU>O2INO7"-*3J<;:'TBW3":A[\)1_\;@`?=<#D=%T\X
M(M\"V;^8"K-;O"Q,E+]L&<LR^I'%<95"^5-T,^5?,*,7%E=-Z.*+63B]NA]"
M0*1Y@RV&@U*>D7<J0;<AG41IJ-8,8.HO.=COP][D8@'N-?!DOI@$#+^^#6=]
M>C3OEPZ]34@<9&QBQVX"QDFT`&T(TX[T8?*4)7^C7%7(2SQ7%7(PSU6%/-!S
M5<$0+'!D"S\]>5#;J6RUWZ2X)\F9^PD_\(>_^5N]7HS[RULECIY4FEE:G6<!
MU;7H>YIF\:8Q4S`UC@&-V0N9?]A?7MTLQL1XL)3D*O(4UE$8[=((>@U-[HL[
MLRI"C`$0+X?7EU,9OC%Y3BAU,#!)L,%TNT&UVK!WF#_5L@O4R2T.Z5]O5UB)
M1BM)]5.798;ZJ6LT0_W4!9NAOEZ]1M'-+=Z41E=>NREM;F'IECTT0YZCZZ'M
MS[0E^`[F&F=":O)H1MM-I1LT.Q7#5]'/BAL<!^>7]]@/O>%X9&0@H:Q;C`^-
M?0G)YP8%/,R`(EP<\,(!\5G2H;F'^4^2^7J#C^%?E[`RTD<'.:7""UD,.7VU
M515N>0.#W[P/,3AT[/EX$'\^FPPOYY#UDS]56QX]G??Q*6K*X,&U\(AZ%TWO
M+J6X5,#>^M8+Y#?IQ2CA'8(BWW&.;7%'?8":ZU_5G_$Q$!L]A=RJLW_5?K;@
MF1K@C<`157[Y);P7D%(+5XOK?W6JW9K9*B_C>_QB%DZT3T[<Y9&OSS'&68[8
M^8=C\/WIW83395Z`O"@L\C$&.H?[9?#@].^7;TY/3M3M?\NWVR2.EW`5"NX/
M][V=[Y;2`#XE8D4G'][.:`39Q>!((K=2+F:@[^4HBGY93$@X$37!,=:0>9=Z
M.AIBD;R'HMP;.7E#`L7I#0J_<GX+(.N0(,`K*Y6:*E;YF4LJI\=O^3\J#\48
M84^,HFC(6@$$\Y:5A>9'0F;!Y.#:;*[$KGO#$46Z93_M_F7VT^ZN\**B3DH:
M$B7A00.SWF=P-QUC;Z4UQR)P_@`#$CTYH]+2I']HRN/+1W'OX"XH49?8(M@<
M.2OA70M;G0@4B6_3"(LV,X`C[$W[M^?WLS>@(L)]JGA\\O;HT]G1^^.W0BM(
M5XN/!]^%<]Q1BL:.&L#-N@JE[A(4NZ,VP>/9?_9XH2)U5_*L1ZF<D@L%L$EC
M^\M`8'@W<(51L36"_MC:,DO?'5V<7YQ]?',A>SS,BD^:%\*GB43E$KT<FQ36
MWH=0CLO3%&3B8"!7X"I(A?#:&?&*;=MXC7>M\3MR4$P$[:*8PGNOB>5PD!G/
M>+ZMB^><6,8*&\&RB6-Y4B_#,?6>AF,^1'+ROV.H7Y/7=K-3L.(0:#OUHFZ$
M@X#6Q&:M&0BL]9P]=QY7\?%/%?5\VA=;'T3PF1A'6\`D!/0)ZP>8-EK,#-76
M1[P9W\>:$[$M\[,7;C205I`HSMA;,,D)1U6TF(/!S!H>JLA*NF?:]='OF;?+
M(:ANNU?!.@I<\4^HS@"[*>):EYGW8V7XIP%G-%69:[3`0IEK\OPNBIH<Z-X=
M])K.YYS/@0_7U(3!3X;+Z6G*.<;K(F<%>3]OSHY>7QSQ\>/)PO^RTQ/X_?'\
M^.0[^%#<I45KK)3A;#$>\N.4_8WM?CPY_L?'([;+7K)=43(=C;$R<JW%R@!B
M0*7=&RW"HL`[D2"B2&"P).U=R>RK3A,B=S2=<3$54R',\RYJJB7S7+'6#683
M0=:;,HK0Q[\R1.;E#Z\_7?[]Z,=S\;Q<-KA##`NH4<H+_`L+_0Q,SO'X,VQP
MX(1P@H11<LRY^'4VG_9[\R(!QO$12M.?@)O/KBH;0PPZV0\&%E:NA^%H@*M`
MEHC5.5@.O-RAE`L%#0%NU(AA.(#O<HYX5X"NX_([A3SBM[MW:SNI%[92*1T;
MQ]<8L*C'0),"BPBCEI/#AD!4-(%X]WS.Z;#,CRG8JXP)/B6Q5YGALVSUU!`"
M(`=VJ&M[]OQ"XJY?2-GW%3N>MOD7EF[_R[9BR773?OP7YTCVC3)MV]]\;UFV
M^T*F#;^P=,OGT.D]W[-,6-*;?!OEUZ7"#"=P=PVP6>^>/8>GK`C+<%9B`IG/
MEPG)+OGOQ,B?J%^K9Z"85,\H'0H\Q#?G:!%6:UD43F`[/YR=:K83?])6%;3E
MLIX)O*?HMN2316-\)XX[@>W$/JW1T`!-UA/+,,UZRLX/S7,`24&?J[JEO5?\
ML\G#6#5V^0GO>4RTY2M?8IHKR;UC5>3*2MJL$O>J=;>JI3O5^EN'&ESJ'K7!
M?C+M3IDVIYQ[DTD0N78?W'SD(9^T^1C!%G#;@0U';C?L7P';W]__.77;^3V5
MG%/W/LY`SVY3F4)K+:0SZ&_@NKV9-02N7U-\'(J3"E<IP[M(7F7T]S@*06G&
M^^4?H-\2*[/_?'WV_=NS\_^2XBHJ3:5JK3<:1?TB+TWCY67/C__KJ"B+E>"B
MH]`=\][[D_LB+_+V]<5K701L`7R`T/6>ZBQUK&^',ZFKQ9OC.57%UXAX2U/\
M[OCD^/S[!$6QL&:\9%9EL<$J0(7IPK0EI(8I,'TGT%`"XGL/0E%.27R_NL>X
ME/>SX0"4Q8:IY)IC'=S(8"T_ESE`BQ^/WWXS+CU/-)&8OAO:1!)WWY#&$7U(
M0AEY2,IS@IR]\-6EM#/('N0%Y[0Y?`V$`Q0[F_3ZH1%B#"JFS:*@;DA(J_Q9
M(&,<$N+)ZQ^.@+K>'YV4)-'-PKFX9+OW"ORP\,1U"R[3J:@1B\RDJ+T'X38C
MU`*%":S#Q_.C\Q_/DW56"[^:*L8IB%Y*!JLC)\@\XVDDAGY)UJ,=EQ_E)V_X
M2K61QL]YV=;>*_Z)3GGY-H9X:_<5FZ30!A3)REFB]HTTMDC"?QE`KMK%<)!R
M^3EM<:&7G>F_@(N+0PTV7^1V8,:$+N+LX_LC)J)64W`86F"<&GOL9OB9[TF&
M0QL>E#$W/N_-MWHUJ#=:9CCG^)$G_!XX`L+/F&UJEWQ8Q3=16IUWRG-"U8.S
M[E"&*!O.@`NA\$>Z!3.B]Q((*$B'AD$$[5@+"M6&A$.$J)8O5"Q(<-T5V;6`
M4F5(L!GF'KZ(P&ZMJZD0Y.[,P_+[=C$<#8P@/EI3A49B4<I,C`+7"ZKMH%7K
MFH%XMC9?#S`9&\5S>7.H]BZ5;C5H5&HJ>Q9=(`%`1.PUF87-B<>F;G@(W+M#
M$"',F"\H@PQP(C"A)L615LBC<U?$'3;?V:XU(@":=#>K!!CP4^0A*UGIZ^P.
MWIYBZ_*"2ZNC`M+F0`-LK=)+A?_\>KM9S&!4B]M]<K,R'&7Q*=7G3^TI60V-
MS\#%)C?RO)<FJ\V@43/R^LF@.#*5G!R>2"F*%P>6X$)&GW;AUZY9*F8'<\OM
M'K)=E1,TAJ#2H22"=J4:M"LZG>(#PAW0!K$J]-Y9X(=@H]XVLBLF+>$L=+@&
M\BWHOQ*F^8;?KM6-^V3;ABT5P0Z$_@RFM:"A?:4?CZ78W?U?RE`@7;0Z0;O=
M2H[CUZQ4@F9%<7:R>TR#Q3M_7GW._OB#0<N@27CU#:O`]YWA3.:HA*\P^7<3
MN1=S;.V6K$PANR=H'0#!<U?&&H<ZG"E7Y!7S;#57@(^ZXJ<X#IB35=LX=QYM
M/&G+)=MPO--5[03-1E7?,(A?P'&<+SEL*>[^,K6/#/@KCGXC\4U)G]YT$5+G
M87EII>)-F40[=H78B%1C'S]P2>LHWEC,USA+8\<GYT=G'LABCL]9&GO+A^F#
M+.;%G*6QD].+[X]/OGM)5V+XLNOH>/WKSJ//?QRG%JYZR?M?P$F1\&GR/[+\
MH7CALD#$+F^5/@+V#/V]-T<D65K,1RE96LQ'+EE:5#3CW0N:[:#9JN??"]*O
M\\@M(>8,*Y]AN&GP>T5";C2"3K.2GY!SW&3(#I'W\F&]&;0:!O-L[KYD^6>.
MY5_D.G$YH'FR@(3.^Y`9@C,.X*?.7K%JJ50RDF.S-^#+#D%0OX3L#F*V@H+^
M]3FHY&6V:1F:'4*N8Z1)O%H,YQ:&)"C199=:+>CJK6,CX[E]R$%X)ZE3Y>*B
MR5LG#,L=F%O2"2*ZHS-4VL,2565X!T<6VU6]^1J_E@E)838X@]75UY2W`+A@
M1LSW#B2`V\I&1N2=FBZ$JJA8'*(15MUB47_?L-9!]9)$ETJ6/M`^.=^=G7[\
MP+[]D;UY__KC^9$,:MWE)-;MM"W.<"OCN-TP\-X;MI56T*YJ+9.<]@3:,TG/
M*]RE38,*^9DX#BGG":&CVZT'W:X1TFESP-WFA\A_0;G.Q>5N_J,S_5IKOJ.S
M6JE""/5J*__AF>,:WWJ'9Z<*?*J5QW'U>5SM_/1K:7;U"B*SC&]1ILF424K@
M-]'DWHA33@(V7"Z+6$_8^`;"R`=&,VDFG8LI[;:#:K5B)>+:!,)NMXBE&%_*
MJ68[*/)26)U36+V5?RFF7Q?/N12K59@WK4#;$!@;78I-")M1-_A8AY\PYS4A
MAGG\5/LF\41+6JWRJQVZWPQN@V3JZKL)S5Q:J%:UN/"`@[A=&7+O9+2:0:==
M?6BF:/D(;+[#/PG-&DQ"YT$XH74A]N=BJP6=3B?_EI$>+B)M>?H2+A`R6Q![
MH-W,OW'DN`J?%S(OTKK=H%MI/C8;3QDV8^ROH\6M5CLMCM9N[5&X]>4P^A#<
MK3:Y7+Z":G;MB"0IY$'8K%7XBJ]55E`WKAMO(0TT+Q+KK:#;,.0:)<^ZL1(\
M:3Y4H,0=F:I+:N#T,"1R%?1FS%FF8E`;FHO`B8,0BT%+*.82!?]EQK'=,.2`
M]PU"[<5^HQUTFW6;V[<63^_F9N\5_V4<Q<[**^XJ[47RJLLZ"]@=A="S1N3O
MNJ25'#(-*7\_6$R*Y,!*$U7G+$BM4;$Y]&T,,LN$;7:`WCEM=H)NJ^%94=]-
MH\7DS:C')0GVXF:*2;"M9YM=4;P'3IM`\5F75*/)9ZI9]2RI#8&>98;R@.W%
M?[L1=#LM2[,IC"D4J36:*#.*J;Y#&\#IA\NC3Q_.7JH,\RLN*8PXJ<8$%2$1
M;C0ITEYA%^5E/828HE",015-\)99L7@ZH5"O<J3AM`1_R*<]N=T-C-8:['1X
M<YMWM"D[2*O*Z;)=MW2^VYC21/+\7S>=J2/=SE1ZUVJ'[Y7=CG/^B7D[$_/F
M'6=Q0V2[V5DM<:A9\:FLJ/A11LNI#=M\I^D<R!O$^@.NHSP8WR[1Q['M3^-9
MJ8(.NNJE^=<G;_^,1,_!?OI4S[>::JW;\5+]9O#^H&2?`^=/@^ZK7`RHU"I>
MNC\YO4C#/W_-GBCM*_JJP[JN:]_;+8WO(6DL>2YK-9C+CLECNRXU<NCO/IZ\
M<1@P0S30D2"739R5G<%]&1,3',D&8@]6Z]6FG?1F/8#39F)58/W8KK<A\;-A
MB%@MPQ:-)JZ^3,PXRQL1238PQ2Q3R605QO"^N>TO<4W^$KLO3H[^^4*Z<;JD
M-0Z_[.N54^,[0[UN>*UO=GS*MX/B5?)Z<F`4^Q\N)NY(L?7+[7`4%ODS#AFD
M`&:_WH)KWNW>*QG,78BW.?`&M2TM;<GH$/6LJGD9-HX]>Q:#DE(2"YK,V'\Y
MJ?^-36%"KG(@V6;=WB"L^OW%%`:\;\A!:#`5GW]7BP\`5$O&Q`L?WLXW:@DJ
M*+7XE^IYXRVS:U!E`_;S1MO>,E8?0DZOH@T,PS\S8#ZI."*76&_GBZOWP_$O
M:LT1^.(I1D85D6V!\N1C9_DYMR"L:P]%47WO%?]`K@+JS%-YLT?RB6V@M=:+
M:@>.N%LP>2OKQ`ZS4)_(QNEX2>*!O"DSHJP@5O-JU?WN/:')PT"]<9T,<O(K
M.\Y!;?C>6&>V*/?5.]02.SXQ5`%?-?ZRJE4]/AP["0K2'4?G9\O]'K6=-)/4
M6W6^QEK6M<ET8C1=F\THR]9A3*?N,MUA@D&D6JV"):Q6RV]76CLF?9K9T1-R
MAG#8X5MMO;N"(\6Z4;AS0NM'=J,.D>2[^J`PSR,1"P9.F\5HA-=]Y'%D>+C)
M2R`&->=8;W)]&5F\;,VTAU-VE]HY[#WJ%$A69#9`!FK4#&^,+8_67A8/,U+_
M/#>KX`+17CK/T?A)3S67U++.-<A(#=-M?/LCWO1T9QJM?[ZEEX9]*WNYYWRZ
M\T#BE(X\QKROL9M?PIPG)JA1X1/4:#DWIM<%T3L'^<#S8[0+9E3M%IY]G]],
M4A.YVWMV=L:LR&?,C'Q&J&XU.:K;U?QGU$:2.JP(NG<::A50(U;U@<7B_IH'
MTG_&]:>;WT_NH@'[JY3CLIEWF7(RB/$T:5<_X.3>4#=N@DRC+WV%UC#$`0!*
MC;(9&/"Z,(3T@S`T\!?`,,QBQKIN\ZVGT=6'[,9GR%[B6YF=K%UL:V8R]I]I
M5OSKJ`Y&J$8STSJ*Q0?DAQF,I+;!9>3TP=N45YB=-T;*@.UU;Z1BP""4)Q>-
MT^.WFUM*/B_S=\-Q;S2ZYS04L:N0S:,Y?IWUKL,2I5^!&$@#R'BPN`-=%=Y'
MXR5[M/":%2XX-?7MBHU/:9YUM^'I7*/KW%.98^UM>!K]*[4!)UZK9JQ4G$5J
M!H)8PNH7B9%(`5D-F,%UQO9"9:7038A=$5O9X*K"H'2@>%(=P55JRMVT((V;
M_P38[DK[YVWTA>VQFVC.AO-]=L*_04C-J<Z\,>D-!G#'0\:V35Q..RPKE!YQ
MP`%7N-Z*U5SEQVBS7F?.XGV,:<^S^K8QY6NNR`>8[J627\)4^U=\&T2-MI%`
MMMH$U\"FX1JHM+/A;X!91#^PW5S,Q8`KG#C0J_O0JR%2^9Q`"(;GK<;/$H,P
MB7+"Q-3)&"Y61!`03).8]$X7;/V:N2`@@6!%Z$!6?`%9@2^O.>*GQ6?7P_%U
M=!DMYI/%O%2*]8^DXYI0"\\(K(#M54LJ*(F5L.#Y7V;/7[[$?`T$@1GT&`X%
M>4SPSRKH,6-)>E1]HZ0)'G&MAEZ<#SY`,7%\D&*`RP>VPTQ#B-F`B-^X6P+S
ME^"\)64820R\^(UAE["UDX#%'29TX?R?O59W9%!54[&,L1\_]*:SD&'`U)XT
M#E!QI_J!FY=0AEY8/R$@;PEUX#FL,2N98E"0$'GP`%Q\Z!AG7,L,/A"5C$5.
M9H'8'"HZ2#7BD,(?RHW"\0T_7.)&&0HK$%.)24T9Z6DL,\]R&\_O\?8,ZT[.
MB]->FTZZ04<9:E8:>4F9?-3=4[]WJ.Q&>M&:U`!TA-ZT1'!DCSGZ='Q^<7YY
M_O';]\<G?W_I:9I*:)N3L+*(X0@OJQ^=%ASQ56!&02-D2"^J8SZRIMQI>,EZ
MD,#A2(?S_?NG`>?[]ZEP@@S_)`!-`'(07O<6H[D$S0R+O1@O)I-HBO>6Q2Z&
M\AD$D5<&31]1NAUI4O;9-3/>O-YA?JOFDJ-X,+R^9GO]*9M-^_O1='AS<#4<
M'T`$T\&5^+,_NX6WWA?(JZ16+;R;#MEI?\Y8C57;+VO-EY4VJW:['>0"DMIU
M:[5?5BI4RQ]DL1DT&A7-Z]&#JF&3#?NW$=O%`/'`I$(4-HQJ##%;=_5[BHA\
M\?K;]T?L-_F>%0N%GS".-?]!F02H#$_W`-XP>@-EO2]T2%A,MEHZW&5_L$DT
MF]]PQIW]QX?OSO_Q_O+TPP6;AW>346\>5OGF>#`(/Q\`Z\);^?>[Z'/(^6ZZ
M+B_!\J.",[F-IKHY<O<9VH>@U`=7?+D=J!X.].@2"JAN3/P9$:-_VKT\.[J0
MI7[:A8@^IR<R9>W%J8(3@I0>GYQ?'+U^RW&R0S@1Q23.`AF*7>;;EB]*T*R!
M0-4`8^_.3G\P(E/GQFHR5<#?-*K`]T058HKAR0/-/7:N8*,09SJAX/G1!1.N
M.<"OR/+/Q=U6XY4:R'.`Z2=:-XU6T&@IEORI4\^;?3D>7ELMS``V7H-.\.=L
M7U(4E%5DIXI"68<$=167"%.HD)T%>C+>,!\H-!,&0#O_ESW_/X".YQ8XX!W]
M9C_B$O8WO'3XF1I%`L(R3X?6R_H%%X'"Z9]X%7CW5"ZI-EJ&*J'1Z@3-6BU^
MO/@('%OW$SCAUB)P9F^/FKPEU@-!4V6+9E4&"UX#IZ`DZ^`W<R[$CZ@H\GH4
M91"Q.*4SE]()Q0J3M[T9+51.KX7L_4!<51T1];D@ZW(>LL:XE`EDC;L!I^MR
M$EU3@65'N_G&(6WQB@^?\OG-4'?DO$+,^%[,.;]T$T[I7=[U4(ZO!QJ.&N[R
M!4$5$E:$>$E+(N><N``@3PS]"SV*MW_CW;K]IQ]:8MJ33RV%2)=T[%5-Q?S+
M6O1AK>MRTKK6QU:.A:WI,3"JT&*D_'&\D*;,P&K96K/GBDKM0M"?I%%R(J>B
MBFX-<D[<&G[A_8,39_'Y]'G`GL^>E^QJ^`/'7-(FL=T]0F`G99,0)?@ND6&3
MP,+);R`+RRJ'GV>Q"[!RK'91(V&YR[?;7.\.!,Z"7PN"]!4OYS!YR6MTIJ]Y
M4<Z_Z&4W*:L^@5VUU_VQ64B15.#;&R19%3_M&UG+53U,^^-9I+1!?#+Y5./S
ML;U$"XIAE:PH=H9=%1)6\[%94H`EUBY;D6U]'_70N,3!A"1ZT^$$P^I[U!?#
M<7^T&(0'_=Z\-XIN#H17U#[I,!+?VHJ,Q&)Q;4:U:FLS,E=-5VG4*HU*P'\U
M-=<I'RE7\[='YV_.BKNS:#'MAYAM!FQQ/91NR`U/))F#N(_L]/@MGY,J1#4N
MNFP9S."'[S[R$GPXUVS._X>_M2;;K79WX<(O@__@+[N.(G;5FS*R\T@84/V.
MAH,0#?((",:ZQ_0I7D!J!B`J"YP?DFJ7[=;J*9"4)216[CAHI_AE.+]5Z>)*
M*?#4#7C4"DK&3*V5!1Z9*EP3K;2S'@@72$X>\PC=*S#GEK2?SI@DG7X*F8.E
M9'8P`>L.?G3H//[:3^CQ<AY*K_DI?7G=]LMJ)YG46ZUVT&K7-*'3`VT8/"'C
M>Z$`2"(C^7C.]Q[*MW%8P"#38(*F!]H@/>5D,`=%,%K]0?<*Z?(`Z=`2$,FA
MJ@M/^CUP!,!<=<I<!/G7IR'.R"&4[4VGO7M^@%Z'TW#<YW.&C7\%`UOO[B32
M<YL\9T)5<#"*^K^X$^:\\\^64\@S50W_5"VIV'I9Z2;/4[4;U.J&/9U_;9@B
M\&\<U6-&#KIWO7G_]CWT4GQSAR'_6?B9[PL!.^.;$[Q@+V";0D#(A(BWX<A^
MR_$NK'Q(5?-I&.*2$EU\AN.E#T'%H:$/X?1N)OR"17-N9=M&*=??OX=\:OD"
MYY/Z_O3-W\\OOX>YC$_;/)S-.>;@S)H=A+]Q,IF'@P/DF?>CQ1P1O*2,/8U+
M"L>GD^],UG3F;"!]6EOM*JXVO?SX@XYVDZA5*G^<_IU_*-;8-/J">9?X7/SC
MX]'9CR]97Z1<!6X&[O7-Z$SA9TP/D-X(V!6>3`'[S$C475JW)NMF*%MW^\E0
MIQ&'K9_4'XH*HBJ-JS=CXK#K07W,O6J.^Q/L'E]N^>[`CX6_@@\/%NY'B_&\
M^*+D5JBQ'QF5_G&_ASQ3+P,8M:5@4)N?ES=53VN*^GJ0(34,.'B-@/^Z"D0?
MO)T2O.:[+CX`>.*(#VP8--"?$`S>"#RZ@8A?P!O(3N*@R1/8:`\>585;%IG3
M9D@R'"IH]/E2E!`D`,=_5#&7\J@WOEGT;D(N%O\Z>KX</TUGGH(8=,MQ9/0B
M>!^4*$TLHA<-%WBK7%[G)\4=JX+D/G]>RE&W)NO6\M>MR[KU_'4;LFX#ZE[G
MJMN4=9OY^VW)NJW\_;9EW7;^?CNR;B=KW9J>HZT5;N0IW,Q3N/T$"XL5^2*V
M;>)BZ_UQA5(Q_[A75OF0:W_0ZN`?&_2QP3\VZ6.3?VS3QS;_6&R(0[?,,G1:
M2^ZT2FU6[?[K]+&>V'^'/G8`E%8>4.J9QI\PZ'J>GAIF3W\8^Y_LLFSDHI9]
M_R'T%>8DR&=5`S#SF810/FODGI]F'E#EC,GN*@G@RSDTRV4=4HN>M<RZOF%*
M,C#+%3N>H?L73SUEG:BC\:^LO6QA9:8K_[KRTA6%U/9VL^J8]'&_\PUK8CZ#
M*[3RUIZO-T)C$1LK-V&Y-AYFL/6-35J.S6#5<312MA$Q:77V2C%1&89F[SY]
M:RV;"];::*SE6,TWR,8Z@VPJRGS%A4-*M$%#Y9QI9?WAJKVH8FXN%7,'J:P^
M7(]`UX_N)JR(%H/>=(X&E@"^+<;#.?KT<GX$'\R&_Q,6KD=1#[;;)5(B5+[N
M\>$7O4W!JVB:UIC)O".$)"8H\09@#5CQTSY`Q9'\XSZUB1P\/+L<CB_[=ZCO
M-[EX;$L).@K,'ZF@E';@.0H\\"&56E0+DK=Y?L=9R6JELE\IY:S8QYKYZPW'
M_5M>L[;?7,(XXMA5M0G*)=!G<UF?3L6:K%C/61$EDOXJ7394S6K>JBB."!RU
M<]9M&74;^XVE;"M6CZ:#<`KR,=`HU("_?U@T:3$JN(E/JGPS$*Q!LP(K?%+3
M3^KTI*Z?,-SD)PWC216?-.63:GN_#:?8I"6>5*O[U78K%QN*XZ%%H>$'OW-.
MWGJ<QJO%#&Q,KS8ZZOB(XJ..C[&IQ[A$(3G[=20T?_Q37#MHO4Y10UKE/!K(
M5HH&,K5NZV4US7.WT@@:,I,TNE;Q!\V*TOW[YG4<S6_'M<.TM_5#4E*NI)W,
MI);,I8]<21&YN@:2;49?MPG=XZ,K'9^BMO%QU8Q;UB_R?ROI%E=2*JZD35Q)
MC;B2_G`EQ>%*&L.55(6)]5S-WV9*-3*5:F8JU7ZD4OQ?NL8O7367+D2G:[C2
ME4J)(\BC>DD5WU-$[E4Z7Z(C>4A0ZEOI<`550ZK0G2(>KP+#<DW`JM`@;\Q9
MN0O^%#U:@`]?S'ODU#(<,_+=%P4W*]/3O\V(]/ZS4HCS[#'E^:0I7R;.YY;C
K5Q'@O=66">_YI?85Q/55Y/25!/25)/.D%>>7RE-+KR3S_C^-YP;Y!>P!````
`
end
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-02 16:26 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Jan Wieck <jwieck@debis.com>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-02 16:26 UTC (permalink / raw)
To: jwieck@debis.com; +Cc: jwieck@debis.com; hackers@postgreSQL.org
> Here's a combination of all the patches I'm currently waiting
> for against a just updated CVS tree. It contains
>
> Partial new rewrite system that handles subselects, view
> aggregate columns, insert into select from view, updates
> with set col = view-value and select rules restriction to
> view definition.
>
> Updates for rule/view backparsing utility functions to
> handle subselects correct.
>
> Little changes to system views pg_rules and pg_views.
>
> New system views pg_tables and pg_indexes (where you can
> see the complete index definition in the latter one).
>
> Enabling array references on query parameters.
>
> Bugfix for functional index.
>
> The rule system isn't a release-stopper any longer.
>
> But another stopper is that I don't know if the latest
> changes to PL/pgSQL (not already in CVS) made it compile on
> AIX. Still wait for some response from Dave.
>
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-02 19:05 Jan Wieck <jwieck@debis.com>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 1 reply; 141+ messages in thread
From: jwieck@debis.com @ 1998-10-02 19:05 UTC (permalink / raw)
To: maillist@candle.pha.pa.us; +Cc: jwieck@debis.com; hackers@postgreSQL.org
> > > SELECT * FROM pg_rules WHERE pg_rules.oid = pg_class.oid crashes
> >
> > Will take a look at it.
> >
Please apply the patch at the end. Disables use of system
columns of views at all (not only oid, cmin etc. too).
pgsql=> select cmin from pg_rules;
ERROR: system column cmin not available - pg_rules is a view
pgsql=> select * from pg_rules where pg_rules.oid = pg_class.oid;
ERROR: system column oid not available - pg_rules is a view
pgsql=>
initdb and regression tests still O.K.
> > > handle oid's on views by either disallowing it or meaningful results
> > > CREATE INDEX i_test ON pg_class (upper(relname)) fails
Fixed by earlier applied patch.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
inline patch 1: src/backend/rewrite/rewriteHandler.c (+2/-0 lines) download inline-1.patch
diff -cr src.orig/backend/rewrite/rewriteHandler.c src/backend/rewrite/rewriteHandler.c
*** src.orig/backend/rewrite/rewriteHandler.c Fri Oct 2 19:32:27 1998
--- src/backend/rewrite/rewriteHandler.c Fri Oct 2 19:43:15 1998
***************
*** 1777,1782 ****
--- 1777,1784 ----
var->varno == rt_index) {
Node *exp;
+ if (var->varattno < 0)
+ elog(ERROR, "system column %s not available - %s is a view", get_attname(rte->relid, var->varattno), rte->relname);
exp = FindMatchingTLEntry(
tlist,
get_attname(rte->relid,
* Re: [HACKERS] Open 6.4 items
@ 1998-10-02 21:34 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Jan Wieck <jwieck@debis.com>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-02 21:34 UTC (permalink / raw)
To: jwieck@debis.com; +Cc: jwieck@debis.com; hackers@postgreSQL.org
Applied.
> > > > SELECT * FROM pg_rules WHERE pg_rules.oid = pg_class.oid crashes
> > >
> > > Will take a look at it.
> > >
>
> Please apply the patch at the end. Disables use of system
> columns of views at all (not only oid, cmin etc. too).
>
> pgsql=> select cmin from pg_rules;
> ERROR: system column cmin not available - pg_rules is a view
> pgsql=> select * from pg_rules where pg_rules.oid = pg_class.oid;
> ERROR: system column oid not available - pg_rules is a view
> pgsql=>
>
> initdb and regression tests still O.K.
>
> > > > handle oid's on views by either disallowing it or meaningful results
> > > > CREATE INDEX i_test ON pg_class (upper(relname)) fails
>
> Fixed by earlier applied patch.
>
>
> Jan
>
> --
>
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me. #
> #======================================== jwieck@debis.com (Jan Wieck) #
>
> diff -cr src.orig/backend/rewrite/rewriteHandler.c src/backend/rewrite/rewriteHandler.c
> *** src.orig/backend/rewrite/rewriteHandler.c Fri Oct 2 19:32:27 1998
> --- src/backend/rewrite/rewriteHandler.c Fri Oct 2 19:43:15 1998
> ***************
> *** 1777,1782 ****
> --- 1777,1784 ----
> var->varno == rt_index) {
> Node *exp;
>
> + if (var->varattno < 0)
> + elog(ERROR, "system column %s not available - %s is a view", get_attname(rte->relid, var->varattno), rte->relname);
> exp = FindMatchingTLEntry(
> tlist,
> get_attname(rte->relid,
>
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Open 6.4 items
@ 1998-10-02 21:58 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-02 21:58 UTC (permalink / raw)
To: hackers@postgreSQL.org
Possible additions
------------------
cidr/IP address type(Tom Helbekkmo, Bruce Momjian)
rewrite system(Jan)
notify fixes(Tom)
Serious Items
------------
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
have psql dump out rules text with new function
man pages/sgml synchronization
generate html/postscript documentation
generate postmaster pid file and remove flock/fcntl lock code
CREATE TABLE test (x text, s serial) fails if no database creation permission
regression test all platforms
Minor items
-----------
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes: what do they do? should it be prevented?
multi-verion concurrency control - work-in-progress for 6.5
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chaining of pages to allow >8k tuples
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
no min/max for oid type
improve PRIMARY KEY handling
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 Items
@ 1998-10-03 05:50 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-03 05:50 UTC (permalink / raw)
To: tih@nhh.no; +Cc: hackers@postgreSQL.org
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
>
> > Possible additions
> > ------------------
> > cidr/IP address type(Tom Helbekkmo)
>
> It looks like the code I sent you is working fine -- if you want to
> integrate it into the backend, I'd say go ahead. Also, if you at the
> same time could make notes explaining how this is done, that would
> make it possible for the rest of us to do such things ourselves...
It is very hard to do this. If you look at how I integrated this type,
you can see what is involved. There are things pointing everywhere, so
it is really hard to describe without understanding all the tables and
their interaction.
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Open 6.4 items
@ 1998-10-03 06:05 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 2 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-03 06:05 UTC (permalink / raw)
To: hackers@postgreSQL.org
Additions
------------------
test new cidr/IP address type(Tom Helbekkmo)
complete rewrite system changes(Jan)
notify fixes(Tom)
Serious Items
------------
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
have psql dump out rules text with new function
man pages/sgml synchronization
generate html/postscript documentation
generate postmaster pid file and remove flock/fcntl lock code
CREATE TABLE test (x text, s serial) fails if no database creation permission
regression test all platforms
make sure all changes are documented properly
Minor items
-----------
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes: what do they do? should it be prevented?
multi-verion concurrency control - work-in-progress for 6.5
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chaining of pages to allow >8k tuples
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
no min/max for oid type
improve PRIMARY KEY handling
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-05 02:04 Tatsuo Ishii <t-ishii@sra.co.jp>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 1 reply; 141+ messages in thread
From: Tatsuo Ishii @ 1998-10-05 02:04 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: hackers@postgreSQL.org
I'm working on the multi-byte support for win32 env. with help from
Hiroshi Inoue who appears in the discussion on some win32 issues.
In one or two days, I will post new patches that should make
the multi-byte support usable on win32.
Note that only Japanese(Shift-JIS) will be supported in the first
version.
I hope this is not too late for the 6.4 release.
--
Tatsuo Ishii
t-ishii@sra.co.jp
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-05 05:05 Marc G. Fournier <scrappy@hub.org>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
3 siblings, 1 reply; 141+ messages in thread
From: Marc G. Fournier @ 1998-10-05 05:05 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: PostgreSQL-development <hackers@postgreSQL.org>
On Fri, 2 Oct 1998, Bruce Momjian wrote:
> Serious Bugs
> ------------
> change pg args for platforms that don't support argv changes
> (setproctitle()?, sendmail hack?)
I'll try and dive into this on Tuesday night...maybe even
afternoon...will use sendmail as a basis for it, which *should* hit most
of the operating systems out there...
Marc G. Fournier scrappy@hub.org
Systems Administrator @ hub.org
scrappy@{postgresql|isc}.org ICQ#7615664
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-05 05:28 Marc G. Fournier <scrappy@hub.org>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 1 reply; 141+ messages in thread
From: Marc G. Fournier @ 1998-10-05 05:28 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: PostgreSQL-development <hackers@postgreSQL.org>
On Sat, 3 Oct 1998, Bruce Momjian wrote:
> Additions
Rename as 'release stopper'...
> ------------------
> test new cidr/IP address type(Tom Helbekkmo)
> complete rewrite system changes(Jan)
> notify fixes(Tom)
These have obviously become show stoppers, since they are now half
implemented, and have to be completed before release. Do we have ETAs on
this stuff? As things stand right now, we are looking at November 1st
for a release date on v6.4...a month late, but not much worse then other
releases :) Unfortunately, because of the lateness for some of this, we
haven't done a solid freeze yet, which means that the testing cycle is
going to be a little bit shorter then we like :(
At this time, I'd like to say that the source tree is now
*absolutely* frozen...no more "just one more thing"...the above three
issues will still need work, as they haven't been fully tested, nor do I
believe them to be fully implemented...but, as a result, they can still be
considered to be "bugs", and, as such, code changes can still be
made/submitted to fix those bugs...
> Serious Items
> ------------
> change pg args for platforms that don't support argv changes
> (setproctitle()?, sendmail hack?)
> have psql dump out rules text with new function
> man pages/sgml synchronization
> generate html/postscript documentation
> generate postmaster pid file and remove flock/fcntl lock code
None of these, IMHO, are release stoppers...documentation related
issues don't truly apply to the beta freeze anyway, but unless there is a
real reason that the above coding issues interfere with the ability for
the backend to run on a particular platform, then let's leave them as they
are. I'm going to look at the setproctitle stuff this week, but will not
be committing any changes until *after* the release, at which time I will
create a seperate patch...
As for the flock/fcntl lock code...my understanding of it is that
it is only 'startup' related, and doesn't really affect anything...leave
it there for now, create a patch shortly after release that can be used to
remove it if it is causing problems for some...
> CREATE TABLE test (x text, s serial) fails if no database creation permission
release stopper...please move it up with the other three...
> regression test all platforms
same as the CREATE TABLE...
> make sure all changes are documented properly
not included as part of beta freeze, changes here can be made at
any time up till the release date, since it does not affect the running of
the backend...
> Minor items
> -----------
> cnf-ify still can exhaust memory, make SET KSQO more generic
> permissions on indexes: what do they do? should it be prevented?
> multi-verion concurrency control - work-in-progress for 6.5
> improve reporting of syntax errors by showing location of error in query
> use index with constants on functions
> allow chaining of pages to allow >8k tuples
> allow multiple generic operators in expressions without the use of parentheses
> document/trigger/rule so changes to pg_shadow create pg_pwd
> large objects orphanage
> improve group handling
> no min/max for oid type
> improve PRIMARY KEY handling
actually, I'd pretty much say that none of the 'minor' ones are
release stoppers...and, as such, should be moved over to "todo for
v6.5"...
For v6.4, can we just concentrate on, and remove from the list
everything else, the following:
> test new cidr/IP address type(Tom Helbekkmo)
> complete rewrite system changes(Jan)
> notify fixes(Tom)
> CREATE TABLE test (x text, s serial) fails if no database creation permission
> regression test all platforms
Everything else appears to be a "ya, be nice if we could, but it can
wait" sort of issue...
If we can get those 5 cleaned up/out, then I think we have a good
release candidate to snapshot and test...
Marc G. Fournier scrappy@hub.org
Systems Administrator @ hub.org
scrappy@{postgresql|isc}.org ICQ#7615664
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-05 14:36 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marc G. Fournier <scrappy@hub.org>
0 siblings, 1 reply; 141+ messages in thread
From: Tom Lane @ 1998-10-05 14:36 UTC (permalink / raw)
To: Marc G. Fournier <scrappy@hub.org>; +Cc: PostgreSQL-development <hackers@postgreSQL.org>
"Marc G. Fournier" <scrappy@hub.org> writes:
> Rename as 'release stopper'...
>> notify fixes(Tom)
>> [other items snipped]
> These have obviously become show stoppers, since they are now half
> implemented, and have to be completed before release. Do we have ETAs on
> this stuff?
My notify rewrite is not in the tree at all right now. I thought we had
agreed (off-list) not to put that change into 6.4, but to postpone it
to the next release.
> As things stand right now, we are looking at November 1st
> for a release date on v6.4...a month late, but not much worse then other
> releases :)
On the other hand, if release is going to be 11/1 not 10/1, my personal
vote is to put the notify changes in. If there are any bugs, that ought
to be time enough to shake them out.
I can commit those changes tonight if I have the go-ahead. Or I can
wait till post-6.4. Your call.
>> Serious Items
>> ------------
>> [snippage]
>> generate postmaster pid file and remove flock/fcntl lock code
> None of these, IMHO, are release stoppers...
flock is a release stopper as far as I'm concerned, because the backend
*does not compile* on my platform without diking out that code. I agree
that it is too late to try to rewrite the feature correctly for 6.4.
What say we put in an autoconf test for whether flock exists, and make
the new code conditional on that? People without flock would see the
same old behavior, which is good enough for now. I will volunteer to
make the necessary changes if that strategy is agreed on.
regards, tom lane
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-05 18:29 Marc G. Fournier <scrappy@hub.org>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 141+ messages in thread
From: Marc G. Fournier @ 1998-10-05 18:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL-development <hackers@postgreSQL.org>
On Mon, 5 Oct 1998, Tom Lane wrote:
> "Marc G. Fournier" <scrappy@hub.org> writes:
> > Rename as 'release stopper'...
> >> notify fixes(Tom)
> >> [other items snipped]
> > These have obviously become show stoppers, since they are now half
> > implemented, and have to be completed before release. Do we have ETAs on
> > this stuff?
>
> My notify rewrite is not in the tree at all right now. I thought we had
> agreed (off-list) not to put that change into 6.4, but to postpone it
> to the next release.
*slap forehead*
> > As things stand right now, we are looking at November 1st
> > for a release date on v6.4...a month late, but not much worse then other
> > releases :)
>
> On the other hand, if release is going to be 11/1 not 10/1, my personal
> vote is to put the notify changes in. If there are any bugs, that ought
> to be time enough to shake them out.
>
> I can commit those changes tonight if I have the go-ahead. Or I can
> wait till post-6.4. Your call.
Go for it...that will at least get them off the list...
> flock is a release stopper as far as I'm concerned, because the backend
> *does not compile* on my platform without diking out that code. I agree
> that it is too late to try to rewrite the feature correctly for 6.4.
> What say we put in an autoconf test for whether flock exists, and make
> the new code conditional on that? People without flock would see the
> same old behavior, which is good enough for now. I will volunteer to
> make the necessary changes if that strategy is agreed on.
Make it so...
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-06 01:56 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Marc G. Fournier <scrappy@hub.org>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-06 01:56 UTC (permalink / raw)
To: scrappy@hub.org; +Cc: hackers@postgreSQL.org
> On Fri, 2 Oct 1998, Bruce Momjian wrote:
>
> > Serious Bugs
> > ------------
> > change pg args for platforms that don't support argv changes
> > (setproctitle()?, sendmail hack?)
>
> I'll try and dive into this on Tuesday night...maybe even
> afternoon...will use sendmail as a basis for it, which *should* hit most
> of the operating systems out there...
Let me remind you what has to be done.
We need to use set_proctitle() for those platforms that have it. I
don't have it here, but Linux does.
Second, we need to determine if set_proctitle is a cheap function by
looking at the library source code.
Third, we need a 'configure' test to see if the modification of argv[0]
displays in the ps output.
If modification of argv[0] works, use it, as the current code does.
If not, then if set_proctitle() is available, use to change the backend
'ps' display on backend startup, and if it is cheap, use it to change
status for every command.
If a platform has neither, use the sendmail code to change the ps
display on backend startup only. The sendmail code it so slow to use
for every command, I 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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-06 02:05 Tatsuo Ishii <t-ishii@sra.co.jp>
parent: Tatsuo Ishii <t-ishii@sra.co.jp>
0 siblings, 1 reply; 141+ messages in thread
From: Tatsuo Ishii @ 1998-10-06 02:05 UTC (permalink / raw)
To: hackers@postgreSQL.org; +Cc: t-ishii@srapc451.sra.co.jp
>I'm working on the multi-byte support for win32 env. with help from
>Hiroshi Inoue who appears in the discussion on some win32 issues.
>In one or two days, I will post new patches that should make
>the multi-byte support usable on win32.
>Note that only Japanese(Shift-JIS) will be supported in the first
>version.
Here are the patches against the current source tree. I have run the
regression test on a FreeBSD box with both non-MULTIBYTE and
MULTIBYTE-enabled, and confirmed that the results are same.
However I do not tested on PCs(I don't have access to win). Please let
me know if the patches break anything on PCs.
Also please note that the patch for varchar.c is a fix for a nasty bug
of char(n) types that I introduced and I believe at least this should
be applied.
Affected files are:
src/win32.mak
src/bin/psql/win32.mak
src/interfaces/libpq/win32.mak
src/interfaces/libpq/libpqdll.def
src/interfaces/libpq/fe-print.c
src/backend/utils/mb/common.c
src/backend/utils/adt/varchar.c
inline patch 1: src/win32.mak, win32.mak, src/bin/psql/win32.mak and 9 more (+55/-7 lines) download inline-1.patch
Index: src/win32.mak
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/win32.mak,v
retrieving revision 1.2
diff -c -r1.2 win32.mak
*** win32.mak 1998/08/27 13:25:11 1.2
--- win32.mak 1998/10/05 06:33:48
***************
*** 10,19 ****
NULL=nul
!ENDIF
ALL:
cd interfaces\libpq
! nmake /f win32.mak
cd ..\..\bin\psql
! nmake /f win32.mak
cd ..\..
echo All Win32 parts have been built!
--- 10,23 ----
NULL=nul
!ENDIF
+ !IFDEF MULTIBYTE
+ MAKEMACRO = "MULTIBYTE=$(MULTIBYTE)"
+ !ENDIF
+
ALL:
cd interfaces\libpq
! nmake /f win32.mak $(MAKEMACRO)
cd ..\..\bin\psql
! nmake /f win32.mak $(MAKEMACRO)
cd ..\..
echo All Win32 parts have been built!
Index: src/bin/psql/win32.mak
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/bin/psql/win32.mak,v
retrieving revision 1.2
diff -c -r1.2 win32.mak
*** win32.mak 1998/09/03 02:16:27 1.2
--- win32.mak 1998/10/05 06:33:48
***************
*** 29,34 ****
--- 29,42 ----
CPP_PROJ=/nologo /ML /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D\
"_MBCS" /Fp"$(INTDIR)\psql.pch" /YX /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\\" /FD /c \
/I ..\..\include /I ..\..\interfaces\libpq
+
+ !IFDEF MULTIBYTE
+ !IFNDEF MBFLAGS
+ MBFLAGS="-DMULTIBYTE=$(MULTIBYTE)"
+ !ENDIF
+ CPP_PROJ=$(MBFLAGS) $(CPP_PROJ)
+ !ENDIF
+
CPP_OBJS=.\Release/
CPP_SBRS=.
Index: src/interfaces/libpq/win32.mak
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/interfaces/libpq/win32.mak,v
retrieving revision 1.3
diff -c -r1.3 win32.mak
*** win32.mak 1998/09/18 16:46:07 1.3
--- win32.mak 1998/10/05 06:33:48
***************
*** 33,39 ****
-@erase "$(OUTDIR)\libpq.lib"
-@erase "$(OUTDIR)\libpq.dll"
-@erase "$(OUTDIR)\libpq.res"
! -@erase "$(OUTDIR)\vc*.*"
-@erase "$(OUTDIR)\libpq.pch"
-@erase "$(OUTDIR)\libpqdll.exp"
-@erase "$(OUTDIR)\libpqdll.lib"
--- 33,39 ----
-@erase "$(OUTDIR)\libpq.lib"
-@erase "$(OUTDIR)\libpq.dll"
-@erase "$(OUTDIR)\libpq.res"
! -@erase "vc50.pch"
-@erase "$(OUTDIR)\libpq.pch"
-@erase "$(OUTDIR)\libpqdll.exp"
-@erase "$(OUTDIR)\libpqdll.lib"
***************
*** 44,49 ****
--- 44,57 ----
CPP_PROJ=/nologo /ML /W3 /GX /O2 /I "..\..\include" /D "NDEBUG" /D\
"WIN32" /D "_WINDOWS" /Fp"$(INTDIR)\libpq.pch" /YX\
/Fo"$(INTDIR)\\" /Fd"$(INTDIR)\\" /FD /c
+
+ !IFDEF MULTIBYTE
+ !IFNDEF MBFLAGS
+ MBFLAGS="-DMULTIBYTE=$(MULTIBYTE)"
+ !ENDIF
+ CPP_PROJ = $(CPP_PROJ) $(MBFLAGS)
+ !ENDIF
+
CPP_OBJS=.\Release/
CPP_SBRS=.
***************
*** 57,62 ****
--- 65,74 ----
"$(INTDIR)\fe-lobj.obj" \
"$(INTDIR)\fe-misc.obj" \
"$(INTDIR)\fe-print.obj"
+
+ !IFDEF MULTIBYTE
+ LIB32_OBJS = $(LIB32_OBJS) $(INTDIR)\common.obj $(INTDIR)\wchar.obj $(INTDIR)\conv.obj
+ !ENDIF
RSC_PROJ=/l 0x409 /fo"$(INTDIR)\libpq.res"
Index: src/interfaces/libpq/libpqdll.def
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/interfaces/libpq/libpqdll.def,v
retrieving revision 1.4
diff -c -r1.4 libpqdll.def
*** libpqdll.def 1998/10/01 01:40:26 1.4
--- libpqdll.def 1998/10/05 06:33:48
***************
*** 63,66 ****
lo_unlink @ 60
lo_import @ 61
lo_export @ 62
! PQresultErrorMessage @ 63
--- 63,67 ----
lo_unlink @ 60
lo_import @ 61
lo_export @ 62
! pgresStatus @ 63
! PQmblen @ 64
Index: src/interfaces/libpq/fe-print.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/interfaces/libpq/fe-print.c,v
retrieving revision 1.13
diff -c -r1.13 fe-print.c
*** fe-print.c 1998/10/04 20:46:39 1.13
--- fe-print.c 1998/10/05 06:33:49
***************
*** 513,519 ****
return (pg_encoding_mblen(encoding, s));
}
! #endif
static void
do_field(PQprintOpt *po, PGresult *res,
--- 513,529 ----
return (pg_encoding_mblen(encoding, s));
}
! #else
!
! #ifdef WIN32
! int
! PQmblen(unsigned char *s)
! {
! }
! #endif /* WIN32 */
!
!
! #endif /* MULTIBYTE */
static void
do_field(PQprintOpt *po, PGresult *res,
Index: src/backend/utils/mb/common.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/utils/mb/common.c,v
retrieving revision 1.2
diff -c -r1.2 common.c
*** common.c 1998/09/01 04:33:19 1.2
--- common.c 1998/10/05 06:33:49
***************
*** 4,10 ****
* Tatsuo Ishii
* $Id: common.c,v 1.2 1998/09/01 04:33:19 momjian Exp $ */
! #include <stdio.h>
#include <string.h>
#include "mb/pg_wchar.h"
--- 4,19 ----
* Tatsuo Ishii
* $Id: common.c,v 1.2 1998/09/01 04:33:19 momjian Exp $ */
! #include <stdlib.h>
!
! #ifdef WIN32
! #include "win32.h"
! #else
! #if !defined(NO_UNISTD_H)
! #include <unistd.h>
! #endif
! #endif
!
#include <string.h>
#include "mb/pg_wchar.h"
Index: src/backend/utils/adt/varchar.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/utils/adt/varchar.c,v
retrieving revision 1.41
diff -c -r1.41 varchar.c
*** varchar.c 1998/09/25 15:51:02 1.41
--- varchar.c 1998/10/05 06:33:50
***************
*** 163,169 ****
#ifdef MULTIBYTE
/* truncate multi-byte string in a way not to break
multi-byte boundary */
! slen = pg_mbcliplen(VARDATA(s), rlen, rlen);
#else
slen = VARSIZE(s) - VARHDRSZ;
#endif
--- 163,173 ----
#ifdef MULTIBYTE
/* truncate multi-byte string in a way not to break
multi-byte boundary */
! if (VARSIZE(s) > len) {
! slen = pg_mbcliplen(VARDATA(s), VARSIZE(s)-VARHDRSZ, rlen);
! } else {
! slen = VARSIZE(s) - VARHDRSZ;
! }
#else
slen = VARSIZE(s) - VARHDRSZ;
#endif
* Re: [HACKERS] Open 6.4 items
@ 1998-10-06 02:49 Tom Lane <tgl@sss.pgh.pa.us>
parent: Marc G. Fournier <scrappy@hub.org>
0 siblings, 0 replies; 141+ messages in thread
From: Tom Lane @ 1998-10-06 02:49 UTC (permalink / raw)
To: Marc G. Fournier <scrappy@hub.org>; +Cc: PostgreSQL-development <hackers@postgreSQL.org>
"Marc G. Fournier" <scrappy@hub.org> writes:
>> I can commit those changes tonight if I have the go-ahead. Or I can
>> wait till post-6.4. Your call.
> Go for it...that will at least get them off the list...
OK, the NOTIFY rewrite is checked in. We'll see what breaks, if
anything.
>> flock is a release stopper as far as I'm concerned, because the backend
>> *does not compile* on my platform without diking out that code.
Actually, it looks like Vadim replaced the flock() call with fcntl() a
few weeks ago, and I'd not noticed because I had a locally modified copy
of pqcomm.c. I don't know if fcntl(F_SETLK) is any more portable than
flock() --- it compiles on my platform, where flock() didn't, but that
proves little. So I went ahead and put in an autoconf test, only
checking for fcntl(F_SETLK) rather than flock(). I still think the
process-pid-in-a-textfile approach to locking is safer, but we can
leave that for the next release.
That's two items off the must-fix list and onto the are-there-bugs?
list...
regards, tom lane
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-06 03:03 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Tatsuo Ishii <t-ishii@sra.co.jp>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-06 03:03 UTC (permalink / raw)
To: t-ishii@sra.co.jp; +Cc: hackers@postgreSQL.org; t-ishii@srapc451.sra.co.jp
Applied.
> >I'm working on the multi-byte support for win32 env. with help from
> >Hiroshi Inoue who appears in the discussion on some win32 issues.
> >In one or two days, I will post new patches that should make
> >the multi-byte support usable on win32.
> >Note that only Japanese(Shift-JIS) will be supported in the first
> >version.
>
> Here are the patches against the current source tree. I have run the
> regression test on a FreeBSD box with both non-MULTIBYTE and
> MULTIBYTE-enabled, and confirmed that the results are same.
>
> However I do not tested on PCs(I don't have access to win). Please let
> me know if the patches break anything on PCs.
>
> Also please note that the patch for varchar.c is a fix for a nasty bug
> of char(n) types that I introduced and I believe at least this should
> be applied.
>
> Affected files are:
> src/win32.mak
> src/bin/psql/win32.mak
> src/interfaces/libpq/win32.mak
> src/interfaces/libpq/libpqdll.def
> src/interfaces/libpq/fe-print.c
> src/backend/utils/mb/common.c
> src/backend/utils/adt/varchar.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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Open 6.4 items
@ 1998-10-06 04:33 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-06 04:33 UTC (permalink / raw)
To: hackers@postgreSQL.org
Additions
---------
test new cidr/IP address type(Tom Helbekkmo)
complete rewrite system changes(Jan)
CREATE TABLE test (x text, s serial) fails if no database creation permission
regression test all platforms
Serious Items
------------
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
Docs
----
man pages/sgml synchronization
generate html/postscript documentation
make sure all changes are documented properly
Minor items
-----------
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes: what do they do? should it be prevented?
multi-verion concurrency control - work-in-progress for 6.5
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chaining of pages to allow >8k tuples
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
no min/max for oid type
improve PRIMARY KEY handling
have psql dump out rules text with new function
generate postmaster pid file and remove flock/fcntl lock 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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Open 6.4 items
@ 1998-10-07 03:20 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-10-07 03:20 UTC (permalink / raw)
To: hackers@postgreSQL.org
Additions
---------
test new cidr/IP address type(Tom Helbekkmo)
complete rewrite system changes(Jan)
CREATE TABLE test (x text, s serial) fails if no database creation permission
regression test all platforms
vacuum crash
Serious Items
------------
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
Docs
----
man pages/sgml synchronization
generate html/postscript documentation
make sure all changes are documented properly
Minor items
-----------
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes: what do they do? should it be prevented?
multi-verion concurrency control - work-in-progress for 6.5
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chaining of pages to allow >8k tuples
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
no min/max for oid type
improve PRIMARY KEY handling
generate postmaster pid file and remove flock/fcntl lock 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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-07 09:26 Tom Ivar Helbekkmo <tih@nhh.no>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 141+ messages in thread
From: Tom Ivar Helbekkmo @ 1998-10-07 09:26 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: hackers@postgreSQL.org
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> test new cidr/IP address type(Tom Helbekkmo)
Looks good to me. I haven't done really heavy testing yet, and I'd
also like to update the regression test -- what I included was just a
very quick sequence to see that it basically worked, but we should
have a more comprehensive test. No great hurry there, though: for
now, I'd say it's ready for shipping, modulo the renaming of IPADDR to
INET, for which I'm sending a separate patch kit.
One problem though, seemingly lately introduced: It's nice to be able
to input IP addresses in various formats, for compatibility with other
software. One of the common formats is a network byte order hex
string, like 0x12345678. Until very recently, I could check what the
heck the actual address behind such a representation was, by going
"select '0x12345678'::ipaddr;". This no longer works, because the
system now helpfully transforms the hex into a long int or something
and then tries to treat the result as an ipaddr. Uh-oh.
The intuitively correct thing would be for the hex string to be read
and converted as a numeric value only if the type it is being cast to
is, indeed, numeric in nature. In the given case, it should be up to
ipaddr_in() to make sense of the character string. Or what do you say?
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-08 00:12 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Tom Ivar Helbekkmo <tih@nhh.no>
0 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-10-08 00:12 UTC (permalink / raw)
To: tih@nhh.no; +Cc: hackers@postgreSQL.org
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
>
> > test new cidr/IP address type(Tom Helbekkmo)
>
> Looks good to me. I haven't done really heavy testing yet, and I'd
> also like to update the regression test -- what I included was just a
> very quick sequence to see that it basically worked, but we should
> have a more comprehensive test. No great hurry there, though: for
> now, I'd say it's ready for shipping, modulo the renaming of IPADDR to
> INET, for which I'm sending a separate patch kit.
OK. I think Thomas is adding it to the regression tests, particularly
so people can see how it works. Your readme is now in the manual.
> One problem though, seemingly lately introduced: It's nice to be able
> to input IP addresses in various formats, for compatibility with other
> software. One of the common formats is a network byte order hex
> string, like 0x12345678. Until very recently, I could check what the
> heck the actual address behind such a representation was, by going
> "select '0x12345678'::ipaddr;". This no longer works, because the
> system now helpfully transforms the hex into a long int or something
> and then tries to treat the result as an ipaddr. Uh-oh.
>
> The intuitively correct thing would be for the hex string to be read
> and converted as a numeric value only if the type it is being cast to
> is, indeed, numeric in nature. In the given case, it should be up to
> ipaddr_in() to make sense of the character string. Or what do you say?
Thomas?
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-08 07:13 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-10-08 07:13 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; Tom Ivar Helbekkmo <tih@nhh.no>; +Cc: hackers@postgreSQL.org
> > Looks good to me. I haven't done really heavy testing yet, and I'd
> > also like to update the regression test
> OK. I think Thomas is adding it to the regression tests, particularly
> so people can see how it works. Your readme is now in the manual.
It would be great if you could gin up a real regression test, since I'm
up to my eyeballs in other Postgres projects. But if you can't, or want
some help, let me know. I'd be happy to help with integration of the
test...
> > One problem though, seemingly lately introduced: It's nice
> > to input IP addresses in various formats...
> > One of the common formats is a network byte order hex
> > string, like 0x12345678. Until very recently, I could check what
> > the heck the actual address behind such a representation was, by
> > going "select '0x12345678'::ipaddr;". This no longer works, because
> > the system now helpfully transforms the hex into a long int or
> > something and then tries to treat the result as an ipaddr. Uh-oh.
There is a problem, but this is not the explanation. See below...
> > The intuitively correct thing would be for the hex string to be read
> > and converted as a numeric value only if the type it is being cast
> > to is, indeed, numeric in nature. In the given case, it should be
> > up to ipaddr_in() to make sense of the character string.
What you describe as "no longer works" is actually a core dump on my
machine:
postgres=> select 'x12345678'::ipaddr;
ERROR: could not parse "x12345678"
postgres=> select '0x12345678'::ipaddr;
pqReadData() -- backend closed the channel unexpectedly.
Any single-quote-delimited string is passed to the corresponding _in()
routine without change. So the system is not changing anything before
ipaddr_in() sees it for input. It appears that the _in() code tries to
handle strings starting with "X", but fails to do so (though I'm not
exactly sure what a correct value would look like; I would have guessed
that something like 'x12121212' might be legal, but it fails). It also
appears that the code crashes if there is a leading zero and an
otherwise hex-looking value following, even though it at least sometimes
is checking that each character is valid.
I haven't looked at it further, but the core dump feature should be a
"must-fix" and I would put the "hex input" in the same category since
the code claims to handle it but doesn't. Volunteers?
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Open 6.4 items
@ 1998-10-09 04:29 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-09 04:29 UTC (permalink / raw)
To: hackers@postgreSQL.org
Additions
---------
test new cidr/IP address type(Tom Helbekkmo)
complete rewrite system changes(Jan)
CREATE TABLE test (x text, s serial) fails if no database creation permission
regression test all platforms
vacuum crash
Serious Items
------------
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
Docs
----
man pages/sgml synchronization
generate html/postscript documentation
make sure all changes are documented properly
Minor items
-----------
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes: what do they do? should it be prevented?
multi-verion concurrency control - work-in-progress for 6.5
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chaining of pages to allow >8k tuples
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
no min/max for oid type
improve PRIMARY KEY handling
generate postmaster pid file and remove flock/fcntl lock 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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-09 08:50 Tom Ivar Helbekkmo <tih@nhh.no>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 1 reply; 141+ messages in thread
From: Tom Ivar Helbekkmo @ 1998-10-09 08:50 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; Tom Ivar Helbekkmo <tih@nhh.no>; hackers@postgreSQL.org
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
(Oh, and "::ipaddr" is now "::inet", of course...)
> postgres=> select 'x12345678'::ipaddr;
> ERROR: could not parse "x12345678"
This is as it should be -- it demands the leading 0 to work, as in:
> postgres=> select '0x12345678'::ipaddr;
...which should return:
?column?
---------------
18.52.86.120/32
(1 row)
but in your case gives:
> pqReadData() -- backend closed the channel unexpectedly.
...or a number of other, weird errors, with or without crashes, but
mostly with. It also changes with time, so it looks very much like
a memory corruption. Now, I've read and re-read my code, and I'm
pretty damn sure that I don't write outside the palloc()ed area at
all, and I do palloc() the sum of VARHDRSZ and the size of the data
structure I'm storing. I also set VARSIZE(dst) to the right number
(the same as the number of bytes I palloc()).
Looking at debug output from the backend, it is obvious that inet_in()
does the right thing: the expected 12 byte data structure looks the
way it ought to, and since all written data ends up inside it (that
is, it's filled with what I expect to see there), it's hard to imagine
what might end up outside. It's also very strange that this happens
only when the '0x12345678'::inet format is used. It would be natural
from this to suspect that inet_net_pton() is at fault, but my tests of
that function don't show up any problems.
Weirdly, this patch fixes the problem:
Index: inet.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/utils/adt/inet.c,v
retrieving revision 1.2
diff -r1.2 inet.c
52c52
< dst = palloc(VARHDRSZ + sizeof(inet_struct));
---
> dst = palloc(VARHDRSZ + sizeof(inet_struct) + 1);
Now I'm explicitly asking for at least one byte more than I need, and
I'm pretty damn sure that I never touch that extra byte, but something
seems to, since the problem goes away. It's arrogant of me, I know,
but barring a complete misunderstanding on my part of how variable
size records work (or a stupid bug that I've been staring at for hours
without seeing, of course), I'd say that something outside my code is
at fault. Any ideas as to how to try to find out?
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-09 15:01 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Ivar Helbekkmo <tih@nhh.no>
0 siblings, 1 reply; 141+ messages in thread
From: Tom Lane @ 1998-10-09 15:01 UTC (permalink / raw)
To: Tom Ivar Helbekkmo <tih@nhh.no>; +Cc: hackers@postgreSQL.org
Tom Ivar Helbekkmo <tih@nhh.no> writes:
> Now I'm explicitly asking for at least one byte more than I need, and
> I'm pretty damn sure that I never touch that extra byte, but something
> seems to, since the problem goes away. It's arrogant of me, I know,
> but barring a complete misunderstanding on my part of how variable
> size records work (or a stupid bug that I've been staring at for hours
> without seeing, of course), I'd say that something outside my code is
> at fault. Any ideas as to how to try to find out?
Well, I hate to ruin your day, but coming pre-armed with the knowledge
that the code is writing one byte too many, it's pretty obvious that the
first loop in inet_net_pton_ipv4 does indeed do that. Specifically at
else if (size-- > 0)
*++dst = 0, dirty = 0;
where, when size (the number of remaining destination bytes) is reduced
to 0, the code nonetheless advances dst and clears the next byte.
The loop logic is fundamentally faulty: you can't check for emsgsize
overflow until you get a digit that is supposed to go into another byte.
I'd try something like
tmp = 0;
ndigits = 0; // ndigits is # of hex digits seen for cur byte
while (ch = next hex digit)
{
n = numeric equivalent of ch;
assert(n >= 0 && n <= 15);
tmp = (tmp << 4) | n;
if (++ndigits == 2)
{
if (size-- <= 0)
goto emsgsize;
*dst++ = (u_char) tmp;
tmp = 0, ndigits = 0;
}
}
if (ndigits)
goto enoent; // odd number of hex digits is bogus
BTW, shouldn't this routine clear out all "size" bytes of the
destination, even if the given data doesn't fill it all? A memset
at the top might be worthwhile.
regards, tom lane
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-09 20:38 Tom Ivar Helbekkmo <tih@nhh.no>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 4 replies; 141+ messages in thread
From: Tom Ivar Helbekkmo @ 1998-10-09 20:38 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Paul A Vixie <vixie@vix.com>; hackers@postgreSQL.org
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Well, I hate to ruin your day,
You sure didn't! You made my day! :-)
> but coming pre-armed with the knowledge
> that the code is writing one byte too many, it's pretty obvious that the
> first loop in inet_net_pton_ipv4 does indeed do that. Specifically at
> else if (size-- > 0)
> *++dst = 0, dirty = 0;
> where, when size (the number of remaining destination bytes) is reduced
> to 0, the code nonetheless advances dst and clears the next byte.
You're quite right, and I should have caught this one myself, only I
must have goofed when I tested the function. (It is written in a
style that's just obscure enough that I chose testing it instead of
studying it until I understood in detail what it did.) As far as I
can tell, the only actual error in Paul Vixie's code is that the two
lines you quote above should be:
else if (--size > 0)
*++dst = 0, dirty = 0;
That is, size should be predecremented instead of postdecremented.
I'm cc-ing Paul on this, as I assume he wants to get the fix into
BIND, which is where inet_net_ntop() and inet_net_pton() came from.
> BTW, shouldn't this routine clear out all "size" bytes of the
> destination, even if the given data doesn't fill it all? A memset
> at the top might be worthwhile.
It does: there is code further down that handles that. Another
example of the obscure programming style: this function really shows
what a low-level language C is! :-)
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-09 21:20 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Ivar Helbekkmo <tih@nhh.no>
3 siblings, 3 replies; 141+ messages in thread
From: Tom Lane @ 1998-10-09 21:20 UTC (permalink / raw)
To: Tom Ivar Helbekkmo <tih@nhh.no>; +Cc: Paul A Vixie <vixie@vix.com>; hackers@postgreSQL.org
Tom Ivar Helbekkmo <tih@nhh.no> writes:
> As far as I
> can tell, the only actual error in Paul Vixie's code is that the two
> lines you quote above should be:
> else if (--size > 0)
> *++dst = 0, dirty = 0;
No, that's still wrong, because it will error out (jump to emsgsize)
one byte sooner than it should. The loop is fundamentally broken
because it wants to grab and zero a byte before it knows whether there
are any digits for the byte.
I think its behavior for an odd number of digits is wrong too, or at
least pretty nonintuitive. I like my code a lot better ;-)
regards, tom lane
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-10 05:34 Paul A Vixie <paul@vix.com>
parent: Tom Ivar Helbekkmo <tih@nhh.no>
3 siblings, 0 replies; 141+ messages in thread
From: Paul A Vixie @ 1998-10-10 05:34 UTC (permalink / raw)
To: hackers@postgreSQL.org
i'll take a tiny exception to the declaration that the code is obscure --
since that just means you have not looked at the rest of bind :-). but
thanks for the bug report, i'll fix this in bind 8.1.3.
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-10 10:28 Tom Ivar Helbekkmo <tih@nhh.no>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 141+ messages in thread
From: Tom Ivar Helbekkmo @ 1998-10-10 10:28 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Paul A Vixie <vixie@vix.com>; hackers@postgreSQL.org
Tom Lane <tgl@sss.pgh.pa.us> writes:
> No, that's still wrong, [...]
I'll leave that to you and Paul. Right now, the code works as I
expect it to, and that's enough for me. :-)
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-10 12:12 Tom Ivar Helbekkmo <tih@nhh.no>
parent: Tom Ivar Helbekkmo <tih@nhh.no>
3 siblings, 1 reply; 141+ messages in thread
From: Tom Ivar Helbekkmo @ 1998-10-10 12:12 UTC (permalink / raw)
To: hackers@postgreSQL.org
I wrote:
> As far as I can tell, the only actual error in Paul Vixie's code is
> that the two lines you quote above should be:
>
> else if (--size > 0)
> *++dst = 0, dirty = 0;
That is, the patch to apply to fix the INET type is:
Index: inet_net_pton.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/utils/adt/inet_net_pton.c,v
retrieving revision 1.2
diff -r1.2 inet_net_pton.c
120c120
< else if (size-- > 0)
---
> else if (--size > 0)
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-10 12:38 Tom Ivar Helbekkmo <tih@nhh.no>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 141+ messages in thread
From: Tom Ivar Helbekkmo @ 1998-10-10 12:38 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Tom Ivar Helbekkmo <tih@nhh.no>; Paul A Vixie <vixie@vix.com>; hackers@postgreSQL.org
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Tom Ivar Helbekkmo <tih@nhh.no> writes:
> > As far as I
> > can tell, the only actual error in Paul Vixie's code is that the two
> > lines you quote above should be:
> > else if (--size > 0)
> > *++dst = 0, dirty = 0;
>
> No, that's still wrong, because it will error out (jump to emsgsize)
> one byte sooner than it should. The loop is fundamentally broken
> because it wants to grab and zero a byte before it knows whether there
> are any digits for the byte.
Damn! You're right! I swear I tested that change at home, and found
it to do what I wanted -- but now that I've put it into my production
system at work, it doesn't work here. Heck, I even read the code very
carefully to verify that it was all that was needed! I think I really
need the holiday I'm taking next week!
To keep this in sync with BIND, maybe Paul could take a look, and fix
the code the way he wants it there?
Whoops. It just hit me. When I tested my "quick fix" last night, I
just looked at what happened to the data, and ignored the return
value. Silly of me...
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-10 18:14 Tom Ivar Helbekkmo <tih@nhh.no>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 141+ messages in thread
From: Tom Ivar Helbekkmo @ 1998-10-10 18:14 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Paul A Vixie <vixie@vix.com>; hackers@postgreSQL.org
Tom Lane <tgl@sss.pgh.pa.us> writes:
> I think its behavior for an odd number of digits is wrong too, or at
> least pretty nonintuitive. I like my code a lot better ;-)
Well, I like your code better too on closer inspection. I changed it
a bit, though, because I don't feel that an odd number of digits in
the hex string is wrong at all -- it's just a representation of a bit
string, with the representation padded to an even multiple of four
bits.
Anyway, here's what I ended up with for the code in question:
if (ch == '0'&& (src[0] == 'x'|| src[0] == 'X')
&& isascii(src[1]) && isxdigit(src[1]))
{
/* Hexadecimal: Eat nybble string. */
if (size <= 0)
goto emsgsize;
tmp = 0;
dirty = 0;
src++; /* skip x or X. */
while ((ch = *src++) != '\0'&&
isascii(ch) && isxdigit(ch))
{
if (isupper(ch))
ch = tolower(ch);
n = strchr(xdigits, ch) - xdigits;
assert(n >= 0 && n <= 15);
tmp = (tmp << 4) | n;
if (++dirty == 2) {
if (size-- <= 0)
goto emsgsize;
*dst++ = (u_char) tmp;
tmp = 0, dirty = 0;
}
}
if (dirty) {
if (size-- <= 0)
goto emsgsize;
tmp <<= 4;
*dst++ = (u_char) tmp;
}
}
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-12 01:31 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Tom Ivar Helbekkmo <tih@nhh.no>
0 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-10-12 01:31 UTC (permalink / raw)
To: tih@nhh.no; +Cc: hackers@postgreSQL.org
Applied
> I wrote:
>
> > As far as I can tell, the only actual error in Paul Vixie's code is
> > that the two lines you quote above should be:
> >
> > else if (--size > 0)
> > *++dst = 0, dirty = 0;
>
>
> That is, the patch to apply to fix the INET type is:
>
> Index: inet_net_pton.c
> ===================================================================
> RCS file: /usr/local/cvsroot/pgsql/src/backend/utils/adt/inet_net_pton.c,v
> retrieving revision 1.2
> diff -r1.2 inet_net_pton.c
> 120c120
> < else if (size-- > 0)
> ---
> > else if (--size > 0)
>
> -tih
> --
> Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
>
>
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* RE: [HACKERS] Open 6.4 items
@ 1998-10-12 02:16 Taral <taral@mail.utexas.edu>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 141+ messages in thread
From: Taral @ 1998-10-12 02:16 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; Tom Ivar Helbekkmo <tih@nhh.no>; +Cc: hackers@postgreSQL.org
> Applied
>
> > I wrote:
> >
> > > As far as I can tell, the only actual error in Paul Vixie's code is
> > > that the two lines you quote above should be:
> > >
> > > else if (--size > 0)
> > > *++dst = 0, dirty = 0;
[snip]
> > < else if (size-- > 0)
> > ---
> > > else if (--size > 0)
Didn't we agree this WASN'T the fix for the problem? Something about return
values? I seem to remember that this piece of code needed to be rewritten...
Taral
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-12 06:03 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Taral <taral@mail.utexas.edu>
0 siblings, 1 reply; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-10-12 06:03 UTC (permalink / raw)
To: Taral <taral@mail.utexas.edu>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; Tom Ivar Helbekkmo <tih@nhh.no>; hackers@postgreSQL.org
> Didn't we agree this WASN'T the fix for the problem? Something about
> return values? I seem to remember that this piece of code needed to be
> rewritten...
Yup. Bruce, Tom has another patch he posted which will behave better...
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-12 13:47 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-10-12 13:47 UTC (permalink / raw)
To: lockhart@alumni.caltech.edu; +Cc: taral@mail.utexas.edu; tih@nhh.no; hackers@postgreSQL.org
> > Didn't we agree this WASN'T the fix for the problem? Something about
> > return values? I seem to remember that this piece of code needed to be
> > rewritten...
>
> Yup. Bruce, Tom has another patch he posted which will behave better...
>
> - Tom
>
I have lost it. Could someone resend it, and the patch to reverse too.
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-12 15:16 Tom Ivar Helbekkmo <tih@nhh.no>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 141+ messages in thread
From: Tom Ivar Helbekkmo @ 1998-10-12 15:16 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: lockhart@alumni.caltech.edu; taral@mail.utexas.edu; hackers@postgreSQL.org
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> I have lost it. Could someone resend it, and the patch to reverse too.
This is the one that shouldn't have been applied:
Index: inet_net_pton.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/utils/adt/inet_net_pton.c,v
retrieving revision 1.2
diff -r1.2 inet_net_pton.c
120c120
< else if (size-- > 0)
---
> else if (--size > 0)
This is the one that works:
Index: inet_net_pton.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/utils/adt/inet_net_pton.c,v
retrieving revision 1.2
diff -r1.2 inet_net_pton.c
108c108,109
< *dst = 0, dirty = 0;
---
> tmp = 0;
> dirty = 0;
117,122c118,127
< *dst |= n;
< if (!dirty++)
< *dst <<= 4;
< else if (size-- > 0)
< *++dst = 0, dirty = 0;
< else
---
> tmp = (tmp << 4) | n;
> if (++dirty == 2) {
> if (size-- <= 0)
> goto emsgsize;
> *dst++ = (u_char) tmp;
> tmp = 0, dirty = 0;
> }
> }
> if (dirty) {
> if (size-- <= 0)
123a129,130
> tmp <<= 4;
> *dst++ = (u_char) tmp;
125,126d131
< if (dirty)
< size--;
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-12 15:57 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Tom Ivar Helbekkmo <tih@nhh.no>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-12 15:57 UTC (permalink / raw)
To: tih@nhh.no; +Cc: lockhart@alumni.caltech.edu; taral@mail.utexas.edu; hackers@postgreSQL.org
Both applied, with the first one reverse applied. Thanks.
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
>
> > I have lost it. Could someone resend it, and the patch to reverse too.
>
> This is the one that shouldn't have been applied:
>
> Index: inet_net_pton.c
> ===================================================================
> RCS file: /usr/local/cvsroot/pgsql/src/backend/utils/adt/inet_net_pton.c,v
> retrieving revision 1.2
> diff -r1.2 inet_net_pton.c
> 120c120
> < else if (size-- > 0)
> ---
> > else if (--size > 0)
>
> This is the one that works:
>
> Index: inet_net_pton.c
> ===================================================================
> RCS file: /usr/local/cvsroot/pgsql/src/backend/utils/adt/inet_net_pton.c,v
> retrieving revision 1.2
> diff -r1.2 inet_net_pton.c
> 108c108,109
> < *dst = 0, dirty = 0;
> ---
> > tmp = 0;
> > dirty = 0;
> 117,122c118,127
> < *dst |= n;
> < if (!dirty++)
> < *dst <<= 4;
> < else if (size-- > 0)
> < *++dst = 0, dirty = 0;
> < else
> ---
> > tmp = (tmp << 4) | n;
> > if (++dirty == 2) {
> > if (size-- <= 0)
> > goto emsgsize;
> > *dst++ = (u_char) tmp;
> > tmp = 0, dirty = 0;
> > }
> > }
> > if (dirty) {
> > if (size-- <= 0)
> 123a129,130
> > tmp <<= 4;
> > *dst++ = (u_char) tmp;
> 125,126d131
> < if (dirty)
> < size--;
>
> -tih
> --
> Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
>
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-13 07:37 Paul A Vixie <paul@vix.com>
parent: Tom Ivar Helbekkmo <tih@nhh.no>
3 siblings, 0 replies; 141+ messages in thread
From: Paul A Vixie @ 1998-10-13 07:37 UTC (permalink / raw)
To: hackers@postgreSQL.org
Wow. Tough room! I've got to admit that I don't have any test cases
with hex strings in them, and had the hex portion of inet_net_pton_ipv4()
ever been tested here it would have shown every error you folks found:
> From: Tom Ivar Helbekkmo <tih@nhh.no>
> Date: 09 Oct 1998 22:38:37 +0200
>
> As far as I can tell, the only actual error in Paul Vixie's code is that
> the two lines you quote above should be:
>
> else if (--size > 0)
> *++dst = 0, dirty = 0;
>
> That is, size should be predecremented instead of postdecremented.
> I'm cc-ing Paul on this, as I assume he wants to get the fix into
> BIND, which is where inet_net_ntop() and inet_net_pton() came from.
As later bespoken by someone else, this is not yet the right answer.
> > BTW, shouldn't this routine clear out all "size" bytes of the
> > destination, even if the given data doesn't fill it all? A memset
> > at the top might be worthwhile.
No. "size" is the maximum I'm allowed to fill -- but I only touch the
bits I need, and I return the number of bits I touched.
> It does: there is code further down that handles that. Another
> example of the obscure programming style: this function really shows
> what a low-level language C is! :-)
C is not a language, it is a very smart macro assembler. Modula-3 is a
language. I'm told that Eiffel is a language. Scheme is definitely a
language. But C is not a language. It's just what we all use :-).
More seriously, this function is called in the inner loop and speed was
important enough to trade off some simplicity for. The amazing thing is,
because I was blasting the same byte of *dst twice per loop iteration, it
was actually sped up considerably by the patches suggested here. I've got
egg on my face this time fershure man.
And as I said, if you think this routine is obscure, that just shows that
you've not looked at the rest of BIND. This routine is at least self
contained and its bugs don't lean on other bugs.
> Date: Fri, 09 Oct 1998 17:20:22 -0400
> From: Tom Lane <tgl@sss.pgh.pa.us>
>
> > As far as I can tell, the only actual error in Paul Vixie's code is
> > that the two lines you quote above should be:
> >
> > else if (--size > 0)
> > *++dst = 0, dirty = 0;
>
> No, that's still wrong, because it will error out (jump to emsgsize)
> one byte sooner than it should. The loop is fundamentally broken
> because it wants to grab and zero a byte before it knows whether there
> are any digits for the byte.
Yes.
> From: Tom Ivar Helbekkmo <tih@nhh.no>
> Date: 10 Oct 1998 20:14:51 +0200
>
> > I think its behavior for an odd number of digits is wrong too, or at
> > least pretty nonintuitive. I like my code a lot better ;-)
>
> Well, I like your code better too on closer inspection. I changed it
> a bit, though, because I don't feel that an odd number of digits in
> the hex string is wrong at all -- it's just a representation of a bit
> string, with the representation padded to an even multiple of four
> bits.
I agree with this interpretation. I'm now wracking my brain trying to
remember what other source file I got this code from, in what other
package, in what year, done for what project, because it's possible that
the bug was inherited.
> Anyway, here's what I ended up with for the code in question:
>
> if (ch == '0'&& (src[0] == 'x'|| src[0] == 'X')
> && isascii(src[1]) && isxdigit(src[1]))
> {
> /* Hexadecimal: Eat nybble string. */
> if (size <= 0)
> goto emsgsize;
> tmp = 0;
> dirty = 0;
> src++; /* skip x or X. */
> while ((ch = *src++) != '\0'&&
> isascii(ch) && isxdigit(ch))
> {
> if (isupper(ch))
> ch = tolower(ch);
> n = strchr(xdigits, ch) - xdigits;
> assert(n >= 0 && n <= 15);
> tmp = (tmp << 4) | n;
> if (++dirty == 2) {
> if (size-- <= 0)
> goto emsgsize;
> *dst++ = (u_char) tmp;
> tmp = 0, dirty = 0;
> }
> }
> if (dirty) {
> if (size-- <= 0)
> goto emsgsize;
> tmp <<= 4;
> *dst++ = (u_char) tmp;
> }
> }
Since that made some stylistic changes that had nothing to do with the
algorythm, it caught my eye (that's a hint.) In keeping with its spirit,
I came up with the following. Comments please?
if (ch == '0' && (src[0] == 'x' || src[0] == 'X')
&& isascii(src[1]) && isxdigit(src[1])) {
/* Hexadecimal: Eat nybble string. */
if (size <= 0)
goto emsgsize;
dirty = 0;
src++; /* skip x or X. */
while ((ch = *src++) != '\0' && isascii(ch) && isxdigit(ch)) {
if (isupper(ch))
ch = tolower(ch);
n = strchr(xdigits, ch) - xdigits;
assert(n >= 0 && n <= 15);
if (dirty == 0)
tmp = n;
else
tmp = (tmp << 4) | n;
if (++dirty == 2) {
if (size-- <= 0)
goto emsgsize;
*dst++ = (u_char) tmp;
dirty = 0;
}
}
if (dirty) { /* Odd trailing nybble? */
if (size-- <= 0)
goto emsgsize;
*dst++ = (u_char) (tmp << 4);
}
}
For the record, I found my original code completely impenetrable, and I'd
like to both thank those of you who slogged through it, and apologize for
not testing every code path before I released it. I oughta know better,
and you find folks deserve better.
^ permalink raw reply [nested|flat] 141+ messages in thread
* Open 6.4 items
@ 1998-10-13 15:40 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-13 15:40 UTC (permalink / raw)
To: hackers@postgreSQL.org
Getting smaller. I moved some stuff to the TODO list:
Additions
---------
new functoins and test INET address type(Tom Helbekkmo)
CREATE TABLE test (x text, s serial) fails if no database creation permission
regression test all platforms
Serious Items
------------
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
Docs
----
man pages/sgml synchronization
generate html/postscript documentation
make sure all changes are documented properly
Minor items
-----------
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes: what do they do? should it be prevented?
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
improve PRIMARY KEY handling
generate postmaster pid file and remove flock/fcntl lock code
add ability to specifiy location of lock/socket files
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Open 6.4 items
@ 1998-10-15 05:59 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-15 05:59 UTC (permalink / raw)
To: hackers@postgreSQL.org
Additions
---------
new functoins and test INET address type(Tom Helbekkmo)
CREATE TABLE test (x text, s serial) fails if no database creation permission
regression test all platforms
fix perl/tcl compile/library issues
Serious Items
------------
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
Docs
----
generate html/postscript documentation
make sure all changes are documented properly
Minor items
-----------
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes: what do they do? should it be prevented?
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
improve PRIMARY KEY handling
generate postmaster pid file and remove flock/fcntl lock code
add ability to specifiy location of lock/socket files
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Open 6.4 items
@ 1998-10-28 05:17 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-10-28 05:17 UTC (permalink / raw)
To: hackers@postgreSQL.org
Additions
---------
CREATE TABLE test (x text, s serial) fails if no database creation permission
regression test all platforms
Serious Items
------------
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
Docs
----
generate html/postscript documentation
(User's Guide, Administrator's Guide, Programmer's Guide) (Thomas)
make sure all changes are documented properly
markup and merge JDBC docs from Peter (Thomas, others??)
merge the release notes into doc/src/sgml/release.sgml (Bruce, Thomas)
generate new text-format INSTALL and README from sgml sources (Thomas)
markup of Jan's PL docs
Minor items
-----------
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes: what do they do? should it be prevented?
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
improve PRIMARY KEY handling
generate postmaster pid file and remove flock/fcntl lock code
add ability to specifiy location of lock/socket files
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 14:19 Jan Wieck <jwieck@debis.com>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 2 replies; 141+ messages in thread
From: jwieck@debis.com @ 1998-10-28 14:19 UTC (permalink / raw)
To: maillist@candle.pha.pa.us; +Cc: hackers@postgreSQL.org
Bruce Momjian wrote:
>
> Additions
> ---------
> CREATE TABLE test (x text, s serial) fails if no database creation permission
> regression test all platforms
The patch below arranges that the sequence(s) get created
first. Unprivileged user now can create table with serial
columns.
Regression tested.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
inline patch 1: analyze.c (+31/-10 lines) download inline-1.patch
*** analyze.c.orig Wed Oct 28 14:50:47 1998
--- analyze.c Wed Oct 28 14:59:12 1998
***************
*** 42,48 ****
static Query *transformCursorStmt(ParseState *pstate, SelectStmt *stmt);
static Query *transformCreateStmt(ParseState *pstate, CreateStmt *stmt);
! List *extras = NIL;
/*
* parse_analyze -
--- 42,49 ----
static Query *transformCursorStmt(ParseState *pstate, SelectStmt *stmt);
static Query *transformCreateStmt(ParseState *pstate, CreateStmt *stmt);
! List *extras_before = NIL;
! List *extras_after = NIL;
/*
* parse_analyze -
***************
*** 57,62 ****
--- 58,64 ----
{
QueryTreeList *result;
ParseState *pstate;
+ Query *parsetree;
int i = 0;
result = malloc(sizeof(QueryTreeList));
***************
*** 66,88 ****
while (pl != NIL)
{
pstate = make_parsestate(parentParseState);
! result->qtrees[i++] = transformStmt(pstate, lfirst(pl));
if (pstate->p_target_relation != NULL)
heap_close(pstate->p_target_relation);
! if (extras != NIL)
{
! result->len += length(extras);
result->qtrees = (Query **) realloc(result->qtrees, result->len * sizeof(Query *));
! while (extras != NIL)
{
! result->qtrees[i++] = transformStmt(pstate, lfirst(extras));
if (pstate->p_target_relation != NULL)
heap_close(pstate->p_target_relation);
! extras = lnext(extras);
}
}
! extras = NIL;
pl = lnext(pl);
pfree(pstate);
}
--- 68,107 ----
while (pl != NIL)
{
pstate = make_parsestate(parentParseState);
! parsetree = transformStmt(pstate, lfirst(pl));
if (pstate->p_target_relation != NULL)
heap_close(pstate->p_target_relation);
! if (extras_before != NIL)
{
! result->len += length(extras_before);
result->qtrees = (Query **) realloc(result->qtrees, result->len * sizeof(Query *));
! while (extras_before != NIL)
{
! result->qtrees[i++] = transformStmt(pstate, lfirst(extras_before));
if (pstate->p_target_relation != NULL)
heap_close(pstate->p_target_relation);
! extras_before = lnext(extras_before);
}
}
! extras_before = NIL;
!
! result->qtrees[i++] = parsetree;
!
! if (extras_after != NIL)
! {
! result->len += length(extras_after);
! result->qtrees = (Query **) realloc(result->qtrees, result->len * sizeof(Query *));
! while (extras_after != NIL)
! {
! result->qtrees[i++] = transformStmt(pstate, lfirst(extras_after));
! if (pstate->p_target_relation != NULL)
! heap_close(pstate->p_target_relation);
! extras_after = lnext(extras_after);
! }
! }
! extras_after = NIL;
!
pl = lnext(pl);
pfree(pstate);
}
***************
*** 487,492 ****
--- 506,512 ----
Constraint *constraint;
List *keys;
Ident *key;
+ List *blist = NIL;
List *ilist = NIL;
IndexStmt *index;
IndexElem *iparam;
***************
*** 553,559 ****
elog(NOTICE, "CREATE TABLE will create implicit sequence %s for SERIAL column %s.%s",
sequence->seqname, stmt->relname, column->colname);
! ilist = lcons(sequence, NIL);
}
if (column->constraints != NIL)
--- 573,579 ----
elog(NOTICE, "CREATE TABLE will create implicit sequence %s for SERIAL column %s.%s",
sequence->seqname, stmt->relname, column->colname);
! blist = lcons(sequence, NIL);
}
if (column->constraints != NIL)
***************
*** 745,751 ****
}
q->utilityStmt = (Node *) stmt;
! extras = ilist;
return q;
}
--- 765,772 ----
}
q->utilityStmt = (Node *) stmt;
! extras_before = blist;
! extras_after = ilist;
return q;
}
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 15:14 The Hermit Hacker <scrappy@hub.org>
parent: Jan Wieck <jwieck@debis.com>
1 sibling, 1 reply; 141+ messages in thread
From: The Hermit Hacker @ 1998-10-28 15:14 UTC (permalink / raw)
To: Jan Wieck <jwieck@debis.com>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; hackers@postgreSQL.org
On Wed, 28 Oct 1998, Jan Wieck wrote:
> Bruce Momjian wrote:
> >
> > Additions
> > ---------
> > CREATE TABLE test (x text, s serial) fails if no database creation permission
> > regression test all platforms
>
> The patch below arranges that the sequence(s) get created
> first. Unprivileged user now can create table with serial
> columns.
Is this safe to leave until post-v6.4 released?
>
> Regression tested.
>
>
> Jan
>
> --
>
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me. #
> #======================================== jwieck@debis.com (Jan Wieck) #
>
>
> *** analyze.c.orig Wed Oct 28 14:50:47 1998
> --- analyze.c Wed Oct 28 14:59:12 1998
> ***************
> *** 42,48 ****
> static Query *transformCursorStmt(ParseState *pstate, SelectStmt *stmt);
> static Query *transformCreateStmt(ParseState *pstate, CreateStmt *stmt);
>
> ! List *extras = NIL;
>
> /*
> * parse_analyze -
> --- 42,49 ----
> static Query *transformCursorStmt(ParseState *pstate, SelectStmt *stmt);
> static Query *transformCreateStmt(ParseState *pstate, CreateStmt *stmt);
>
> ! List *extras_before = NIL;
> ! List *extras_after = NIL;
>
> /*
> * parse_analyze -
> ***************
> *** 57,62 ****
> --- 58,64 ----
> {
> QueryTreeList *result;
> ParseState *pstate;
> + Query *parsetree;
> int i = 0;
>
> result = malloc(sizeof(QueryTreeList));
> ***************
> *** 66,88 ****
> while (pl != NIL)
> {
> pstate = make_parsestate(parentParseState);
> ! result->qtrees[i++] = transformStmt(pstate, lfirst(pl));
> if (pstate->p_target_relation != NULL)
> heap_close(pstate->p_target_relation);
>
> ! if (extras != NIL)
> {
> ! result->len += length(extras);
> result->qtrees = (Query **) realloc(result->qtrees, result->len * sizeof(Query *));
> ! while (extras != NIL)
> {
> ! result->qtrees[i++] = transformStmt(pstate, lfirst(extras));
> if (pstate->p_target_relation != NULL)
> heap_close(pstate->p_target_relation);
> ! extras = lnext(extras);
> }
> }
> ! extras = NIL;
> pl = lnext(pl);
> pfree(pstate);
> }
> --- 68,107 ----
> while (pl != NIL)
> {
> pstate = make_parsestate(parentParseState);
> ! parsetree = transformStmt(pstate, lfirst(pl));
> if (pstate->p_target_relation != NULL)
> heap_close(pstate->p_target_relation);
>
> ! if (extras_before != NIL)
> {
> ! result->len += length(extras_before);
> result->qtrees = (Query **) realloc(result->qtrees, result->len * sizeof(Query *));
> ! while (extras_before != NIL)
> {
> ! result->qtrees[i++] = transformStmt(pstate, lfirst(extras_before));
> if (pstate->p_target_relation != NULL)
> heap_close(pstate->p_target_relation);
> ! extras_before = lnext(extras_before);
> }
> }
> ! extras_before = NIL;
> !
> ! result->qtrees[i++] = parsetree;
> !
> ! if (extras_after != NIL)
> ! {
> ! result->len += length(extras_after);
> ! result->qtrees = (Query **) realloc(result->qtrees, result->len * sizeof(Query *));
> ! while (extras_after != NIL)
> ! {
> ! result->qtrees[i++] = transformStmt(pstate, lfirst(extras_after));
> ! if (pstate->p_target_relation != NULL)
> ! heap_close(pstate->p_target_relation);
> ! extras_after = lnext(extras_after);
> ! }
> ! }
> ! extras_after = NIL;
> !
> pl = lnext(pl);
> pfree(pstate);
> }
> ***************
> *** 487,492 ****
> --- 506,512 ----
> Constraint *constraint;
> List *keys;
> Ident *key;
> + List *blist = NIL;
> List *ilist = NIL;
> IndexStmt *index;
> IndexElem *iparam;
> ***************
> *** 553,559 ****
> elog(NOTICE, "CREATE TABLE will create implicit sequence %s for SERIAL column %s.%s",
> sequence->seqname, stmt->relname, column->colname);
>
> ! ilist = lcons(sequence, NIL);
> }
>
> if (column->constraints != NIL)
> --- 573,579 ----
> elog(NOTICE, "CREATE TABLE will create implicit sequence %s for SERIAL column %s.%s",
> sequence->seqname, stmt->relname, column->colname);
>
> ! blist = lcons(sequence, NIL);
> }
>
> if (column->constraints != NIL)
> ***************
> *** 745,751 ****
> }
>
> q->utilityStmt = (Node *) stmt;
> ! extras = ilist;
>
> return q;
> }
> --- 765,772 ----
> }
>
> q->utilityStmt = (Node *) stmt;
> ! extras_before = blist;
> ! extras_after = ilist;
>
> return q;
> }
>
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 16:06 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Jan Wieck <jwieck@debis.com>
1 sibling, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-10-28 16:06 UTC (permalink / raw)
To: jwieck@debis.com; +Cc: hackers@postgreSQL.org
Thanks. Applied.
> Bruce Momjian wrote:
> >
> > Additions
> > ---------
> > CREATE TABLE test (x text, s serial) fails if no database creation permission
> > regression test all platforms
>
> The patch below arranges that the sequence(s) get created
> first. Unprivileged user now can create table with serial
> columns.
>
> Regression tested.
>
>
> Jan
>
> --
>
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me. #
> #======================================== jwieck@debis.com (Jan Wieck) #
>
>
> *** analyze.c.orig Wed Oct 28 14:50:47 1998
> --- analyze.c Wed Oct 28 14:59:12 1998
> ***************
> *** 42,48 ****
> static Query *transformCursorStmt(ParseState *pstate, SelectStmt *stmt);
> static Query *transformCreateStmt(ParseState *pstate, CreateStmt *stmt);
>
> ! List *extras = NIL;
>
> /*
> * parse_analyze -
> --- 42,49 ----
> static Query *transformCursorStmt(ParseState *pstate, SelectStmt *stmt);
> static Query *transformCreateStmt(ParseState *pstate, CreateStmt *stmt);
>
> ! List *extras_before = NIL;
> ! List *extras_after = NIL;
>
> /*
> * parse_analyze -
> ***************
> *** 57,62 ****
> --- 58,64 ----
> {
> QueryTreeList *result;
> ParseState *pstate;
> + Query *parsetree;
> int i = 0;
>
> result = malloc(sizeof(QueryTreeList));
> ***************
> *** 66,88 ****
> while (pl != NIL)
> {
> pstate = make_parsestate(parentParseState);
> ! result->qtrees[i++] = transformStmt(pstate, lfirst(pl));
> if (pstate->p_target_relation != NULL)
> heap_close(pstate->p_target_relation);
>
> ! if (extras != NIL)
> {
> ! result->len += length(extras);
> result->qtrees = (Query **) realloc(result->qtrees, result->len * sizeof(Query *));
> ! while (extras != NIL)
> {
> ! result->qtrees[i++] = transformStmt(pstate, lfirst(extras));
> if (pstate->p_target_relation != NULL)
> heap_close(pstate->p_target_relation);
> ! extras = lnext(extras);
> }
> }
> ! extras = NIL;
> pl = lnext(pl);
> pfree(pstate);
> }
> --- 68,107 ----
> while (pl != NIL)
> {
> pstate = make_parsestate(parentParseState);
> ! parsetree = transformStmt(pstate, lfirst(pl));
> if (pstate->p_target_relation != NULL)
> heap_close(pstate->p_target_relation);
>
> ! if (extras_before != NIL)
> {
> ! result->len += length(extras_before);
> result->qtrees = (Query **) realloc(result->qtrees, result->len * sizeof(Query *));
> ! while (extras_before != NIL)
> {
> ! result->qtrees[i++] = transformStmt(pstate, lfirst(extras_before));
> if (pstate->p_target_relation != NULL)
> heap_close(pstate->p_target_relation);
> ! extras_before = lnext(extras_before);
> }
> }
> ! extras_before = NIL;
> !
> ! result->qtrees[i++] = parsetree;
> !
> ! if (extras_after != NIL)
> ! {
> ! result->len += length(extras_after);
> ! result->qtrees = (Query **) realloc(result->qtrees, result->len * sizeof(Query *));
> ! while (extras_after != NIL)
> ! {
> ! result->qtrees[i++] = transformStmt(pstate, lfirst(extras_after));
> ! if (pstate->p_target_relation != NULL)
> ! heap_close(pstate->p_target_relation);
> ! extras_after = lnext(extras_after);
> ! }
> ! }
> ! extras_after = NIL;
> !
> pl = lnext(pl);
> pfree(pstate);
> }
> ***************
> *** 487,492 ****
> --- 506,512 ----
> Constraint *constraint;
> List *keys;
> Ident *key;
> + List *blist = NIL;
> List *ilist = NIL;
> IndexStmt *index;
> IndexElem *iparam;
> ***************
> *** 553,559 ****
> elog(NOTICE, "CREATE TABLE will create implicit sequence %s for SERIAL column %s.%s",
> sequence->seqname, stmt->relname, column->colname);
>
> ! ilist = lcons(sequence, NIL);
> }
>
> if (column->constraints != NIL)
> --- 573,579 ----
> elog(NOTICE, "CREATE TABLE will create implicit sequence %s for SERIAL column %s.%s",
> sequence->seqname, stmt->relname, column->colname);
>
> ! blist = lcons(sequence, NIL);
> }
>
> if (column->constraints != NIL)
> ***************
> *** 745,751 ****
> }
>
> q->utilityStmt = (Node *) stmt;
> ! extras = ilist;
>
> return q;
> }
> --- 765,772 ----
> }
>
> q->utilityStmt = (Node *) stmt;
> ! extras_before = blist;
> ! extras_after = ilist;
>
> return q;
> }
>
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 16:12 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Jan Wieck <jwieck@debis.com>
0 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-10-28 16:12 UTC (permalink / raw)
To: jwieck@debis.com; +Cc: scrappy@hub.org; jwieck@debis.com; hackers@postgreSQL.org
> Marc wrote:
>
> >
> > On Wed, 28 Oct 1998, Jan Wieck wrote:
> >
> > > Bruce Momjian wrote:
> > > >
> > > > Additions
> > > > ---------
> > > > CREATE TABLE test (x text, s serial) fails if no database creation permission
> > > > regression test all platforms
> > >
> > > The patch below arranges that the sequence(s) get created
> > > first. Unprivileged user now can create table with serial
> > > columns.
> >
> > Is this safe to leave until post-v6.4 released?
>
> I just did it now to let Bruce get rid of the open item. If
> it shouldn't be in 6.4, why is it on it's open item list
> then?
It has been on the open items. In fact, it is the only hot item, except
for the 'pg args' thing, which is not as hot.
It is serious breakage, in the sense that if we don't fix it, we must
remove reference to the new SERIAL type.
As to why no one fixed it earlier, ...? Must be the same reason 'ps
args' is not fixed. :-)
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 16:16 Jan Wieck <jwieck@debis.com>
parent: The Hermit Hacker <scrappy@hub.org>
0 siblings, 1 reply; 141+ messages in thread
From: jwieck@debis.com @ 1998-10-28 16:16 UTC (permalink / raw)
To: scrappy@hub.org; +Cc: jwieck@debis.com; maillist@candle.pha.pa.us; hackers@postgreSQL.org
Marc wrote:
>
> On Wed, 28 Oct 1998, Jan Wieck wrote:
>
> > Bruce Momjian wrote:
> > >
> > > Additions
> > > ---------
> > > CREATE TABLE test (x text, s serial) fails if no database creation permission
> > > regression test all platforms
> >
> > The patch below arranges that the sequence(s) get created
> > first. Unprivileged user now can create table with serial
> > columns.
>
> Is this safe to leave until post-v6.4 released?
I just did it now to let Bruce get rid of the open item. If
it shouldn't be in 6.4, why is it on it's open item list
then?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
^ permalink raw reply [nested|flat] 141+ messages in thread
* Open 6.4 items
@ 1998-10-28 16:16 Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 4 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-28 16:16 UTC (permalink / raw)
To: hackers@postgreSQL.org
Here are the open items. Thanks to Jan, the only 'hot' item left is the
ps args issue. People on non-BSD platforms will see all their backends
called 'postmaster', because argv[0] changes do not reflect in ps arg
displays.
I have asked that at least we get set_proctitle() working for Linux, but
no one wants to do it, and we can't remove the it because we would have
to add the exec() back into backend creation, which is impossible at
this point.
At this point, I am not even sure if Marc will allow a fix so late in
the game. Perhaps we can put it into a minor 6.4 release.
As long as you don't think we are going to get tons of complaints, I am
not worried about it.
Everything else is minor, so we are ready for 6.4 on November 1.
---------------------------------------------------------------------------
Additions
---------
regression test all platforms
Serious Items
------------
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
Docs
----
generate html/postscript documentation
(User's Guide, Administrator's Guide, Programmer's Guide) (Thomas)
make sure all changes are documented properly
markup and merge JDBC docs from Peter (Thomas, others??)
merge the release notes into doc/src/sgml/release.sgml (Bruce, Thomas)
generate new text-format INSTALL and README from sgml sources (Thomas)
markup of Jan's PL docs
Minor items
-----------
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes: what do they do? should it be prevented?
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
improve PRIMARY KEY handling
generate postmaster pid file and remove flock/fcntl lock code
add ability to specifiy location of lock/socket files
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 16:18 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Jan Wieck <jwieck@debis.com>
2 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-10-28 16:18 UTC (permalink / raw)
To: jwieck@debis.com; +Cc: jwieck@debis.com; hackers@postgreSQL.org
> >
> > Thanks. Applied.
> >
> > > Bruce Momjian wrote:
> > > >
> > > > Additions
> > > > ---------
> > > > CREATE TABLE test (x text, s serial) fails if no database creation permission
> > > > regression test all platforms
> > >
> > > The patch below arranges that the sequence(s) get created
> > > first. Unprivileged user now can create table with serial
> > > columns.
> > >
> > > Regression tested.
>
> So Marc's assumption that his BETA3 is what we release was
> false. We really know how to trigger his hot buttons - eh?
> :-)
You want even worse. I fixed a problem in the system table just now
with the lseg_eq <> problem. That requires an initdb for people to see
the fix.
But we might as well fix it now, because we can't ask for initdb after
the final release.
Can someone check that that fix does not affect the regression test
results? I doubt we do lseg not-equal tests in the regression suite.
You will have to do an initdb to see the change.
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 16:31 Jan Wieck <jwieck@debis.com>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 3 replies; 141+ messages in thread
From: jwieck@debis.com @ 1998-10-28 16:31 UTC (permalink / raw)
To: maillist@candle.pha.pa.us; +Cc: jwieck@debis.com; hackers@postgreSQL.org
>
> Thanks. Applied.
>
> > Bruce Momjian wrote:
> > >
> > > Additions
> > > ---------
> > > CREATE TABLE test (x text, s serial) fails if no database creation permission
> > > regression test all platforms
> >
> > The patch below arranges that the sequence(s) get created
> > first. Unprivileged user now can create table with serial
> > columns.
> >
> > Regression tested.
So Marc's assumption that his BETA3 is what we release was
false. We really know how to trigger his hot buttons - eh?
:-)
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 16:46 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-10-28 16:46 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: jwieck@debis.com; scrappy@hub.org; hackers@postgreSQL.org
> It is serious breakage, in the sense that if we don't fix it, we must
> remove reference to the new SERIAL type.
> As to why no one fixed it earlier, ...? Must be the same reason 'ps
> args' is not fixed. :-)
I'm comfortable with Jan's patches, and it's my code he's mucking with
:) For the transformation from serial to int4 with index and sequence,
the only time that code gets traversed is for the serial type. So it
shouldn't have hidden side effects (yeah, sure...)
'Course, I see Bruce has already committed it anyway...
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 16:49 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Jan Wieck <jwieck@debis.com>
0 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-10-28 16:49 UTC (permalink / raw)
To: jwieck@debis.com; +Cc: hackers@postgreSQL.org
> >
> > Here are the open items. Thanks to Jan, the only 'hot' item left is the
> > ps args issue. People on non-BSD platforms will see all their backends
> > called 'postmaster', because argv[0] changes do not reflect in ps arg
> > displays.
> >
> > I have asked that at least we get set_proctitle() working for Linux, but
> > no one wants to do it, and we can't remove the it because we would have
> > to add the exec() back into backend creation, which is impossible at
> > this point.
>
> I'm running Linux 2.1.88 and get
>
> 15572 p2 S 0:01 /usr/local/pgsql/bin/postmaster -o -F
> 16121 p2 S 0:01 /usr/local/pgsql/bin/postgres localhost twieck twieck idle
>
> from ps. So what isn't working?
Whoh, this is a shock. I thought this trick did not work under Linux.
If it does, and no one has complained, we can consider the issue closed.
Massimo did a nice job of moving my ps status stuff into pg_status.h,
but it looks like the same code that modifies argv[0]. Perhaps it is
the Linux version you are using.
It give us a cheap 'db monitor' capability, wrapped into the 'ps'
command.
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 16:53 Jan Wieck <jwieck@debis.com>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
3 siblings, 1 reply; 141+ messages in thread
From: jwieck@debis.com @ 1998-10-28 16:53 UTC (permalink / raw)
To: maillist@candle.pha.pa.us; +Cc: hackers@postgreSQL.org
>
> Here are the open items. Thanks to Jan, the only 'hot' item left is the
> ps args issue. People on non-BSD platforms will see all their backends
> called 'postmaster', because argv[0] changes do not reflect in ps arg
> displays.
>
> I have asked that at least we get set_proctitle() working for Linux, but
> no one wants to do it, and we can't remove the it because we would have
> to add the exec() back into backend creation, which is impossible at
> this point.
I'm running Linux 2.1.88 and get
15572 p2 S 0:01 /usr/local/pgsql/bin/postmaster -o -F
16121 p2 S 0:01 /usr/local/pgsql/bin/postgres localhost twieck twieck idle
from ps. So what isn't working?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 17:06 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Jan Wieck <jwieck@debis.com>
2 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-10-28 17:06 UTC (permalink / raw)
To: jwieck@debis.com; +Cc: hackers@postgreSQL.org
> >
> > Here are the open items. Thanks to Jan, the only 'hot' item left is the
> > ps args issue. People on non-BSD platforms will see all their backends
> > called 'postmaster', because argv[0] changes do not reflect in ps arg
> > displays.
> >
>
> Bruce,
>
> I asked for it a while ago but forgot about it. Anyway - I
> think it is better to have precreated gram.c, y.tab.h and
> scan.c files in src/pl/plpgsql/src too. Otherwise ppl not
> having bison/flex might have a build problem.
>
> The only thing required is to take them out of the 'clean' rm
> in Makefile.in and add the bison/flex created files to CVS.
> If gram.c, y.tab.h and scan.l are present and newer than
> gram.y and scan.l the Makefile will already skip the steps to
> create them.
Do they fail for people who have standard BSD yacc? Too large? No one
has complained about it, but it may be true.
Done. Removed from Makefile.in, and added via cvs.
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 17:06 Jan Wieck <jwieck@debis.com>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
3 siblings, 3 replies; 141+ messages in thread
From: jwieck@debis.com @ 1998-10-28 17:06 UTC (permalink / raw)
To: maillist@candle.pha.pa.us; +Cc: hackers@postgreSQL.org
>
> Here are the open items. Thanks to Jan, the only 'hot' item left is the
> ps args issue. People on non-BSD platforms will see all their backends
> called 'postmaster', because argv[0] changes do not reflect in ps arg
> displays.
>
Bruce,
I asked for it a while ago but forgot about it. Anyway - I
think it is better to have precreated gram.c, y.tab.h and
scan.c files in src/pl/plpgsql/src too. Otherwise ppl not
having bison/flex might have a build problem.
The only thing required is to take them out of the 'clean' rm
in Makefile.in and add the bison/flex created files to CVS.
If gram.c, y.tab.h and scan.l are present and newer than
gram.y and scan.l the Makefile will already skip the steps to
create them.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 17:08 Brook Milligan <brook@trillium.NMSU.Edu>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 141+ messages in thread
From: Brook Milligan @ 1998-10-28 17:08 UTC (permalink / raw)
To: maillist@candle.pha.pa.us; +Cc: jwieck@debis.com; hackers@postgreSQL.org
> I'm running Linux 2.1.88 and get
>
> 15572 p2 S 0:01 /usr/local/pgsql/bin/postmaster -o -F
> 16121 p2 S 0:01 /usr/local/pgsql/bin/postgres localhost twieck twieck idle
>
> from ps. So what isn't working?
Whoh, this is a shock. I thought this trick did not work under Linux.
If it does, and no one has complained, we can consider the issue closed.
For whatever it's worth, I see the same status stuff changing under
NetBSD 1.3.2. Seems to work fine.
Cheers,
Brook
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 17:18 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Jan Wieck <jwieck@debis.com>
2 siblings, 0 replies; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-10-28 17:18 UTC (permalink / raw)
To: Jan Wieck <jwieck@debis.com>; Marc G. Fournier <scrappy@hub.org>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; hackers@postgreSQL.org
> So Marc's assumption that his BETA3 is what we release was
> false. We really know how to trigger his hot buttons - eh?
> :-)
Good point. I just committed a _very_ small bit of code in the ODBC
interface which is non-essential, but potentially useful.
Also, he will have to rebuild a tarball one more time anyway to get the
new docs, which won't be finished until the last minute.
Just to get his blood pressure up, I'll mention that there is a chance
I'll ask for a couple of extra days to finish docs, but I'm hoping to
have them done on time :)
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 17:20 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Jan Wieck <jwieck@debis.com>
2 siblings, 0 replies; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-10-28 17:20 UTC (permalink / raw)
To: Jan Wieck <jwieck@debis.com>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; hackers@postgreSQL.org
> The only thing required is to take them out of the 'clean' rm
> in Makefile.in and add the bison/flex created files to CVS.
> If gram.c, y.tab.h and scan.l are present and newer than
> gram.y and scan.l the Makefile will already skip the steps to
> create them.
We should do that for the ecpg pre-processor also.
- Tom
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 17:20 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
3 siblings, 0 replies; 141+ messages in thread
From: Tom Lane @ 1998-10-28 17:20 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: hackers@postgreSQL.org
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Here are the open items. Thanks to Jan, the only 'hot' item left is the
> ps args issue. People on non-BSD platforms will see all their backends
> called 'postmaster', because argv[0] changes do not reflect in ps arg
> displays.
> I have asked that at least we get set_proctitle() working for Linux, but
> no one wants to do it, and we can't remove the it because we would have
> to add the exec() back into backend creation, which is impossible at
> this point.
I think I was one of the louder complainers about the lack of proctitle
information, but even I don't think it's worth holding up the release
for --- and it's certainly not worth taking a strong risk of breakage
at this stage. Let's put it on the to-do-for-6.4.1 list.
regards, tom lane
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 17:30 Tom Lane <tgl@sss.pgh.pa.us>
parent: Jan Wieck <jwieck@debis.com>
2 siblings, 1 reply; 141+ messages in thread
From: Tom Lane @ 1998-10-28 17:30 UTC (permalink / raw)
To: jwieck@debis.com; +Cc: hackers@postgreSQL.org
jwieck@debis.com (Jan Wieck) writes:
> I asked for it a while ago but forgot about it. Anyway - I
> think it is better to have precreated gram.c, y.tab.h and
> scan.c files in src/pl/plpgsql/src too. Otherwise ppl not
> having bison/flex might have a build problem.
There are quite a few places that need lex/yacc capability; plpgsql
is not creating any new build requirement that did not exist before.
(ecpg and bootparse are two examples I can think of offhand.)
We ship the main gram.c file not to avoid requiring lex/yacc, but
because it is too big for some older yaccs.
It might be nice to eliminate the need for lex/yacc capability,
but post-beta3 is NOT the time to be doing "might be nice" stuff.
Leave it be for now.
regards, tom lane
PS: BTW, I was able to build all the Postgres yacc files on a rather
ancient HPUX yacc, once I added enough -N switches. According to my
notes,
YACC:/usr/bin/yacc
YFLAGS:-d -Np2000 -Ns3000 -Nm100000 -Nl2000 -Na30000 -Nc10000
worked with a pretty recent fileset. So I'm not sure we even really
need to distribute the main parser's gram.c. We could have configure
plug in these switches if it fails to find bison...
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 17:35 Jan Wieck <jwieck@debis.com>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: jwieck@debis.com @ 1998-10-28 17:35 UTC (permalink / raw)
To: maillist@candle.pha.pa.us; +Cc: jwieck@debis.com; hackers@postgreSQL.org
> > Bruce,
> >
> > I asked for it a while ago but forgot about it. Anyway - I
> > think it is better to have precreated gram.c, y.tab.h and
> > scan.c files in src/pl/plpgsql/src too. Otherwise ppl not
> > having bison/flex might have a build problem.
> >
> > The only thing required is to take them out of the 'clean' rm
> > in Makefile.in and add the bison/flex created files to CVS.
> > If gram.c, y.tab.h and scan.l are present and newer than
> > gram.y and scan.l the Makefile will already skip the steps to
> > create them.
>
> Do they fail for people who have standard BSD yacc? Too large? No one
> has complained about it, but it may be true.
They shouldn't be too large. But they get modified with
sed(1) since this is a second independend scanner/parser
inside the backend (after loading). I'm not 100% sure if the
code generated by ANY other lex/yacc accepts the
substitutions or if the resulting code is really that
independet as it should be.
>
> Done. Removed from Makefile.in, and added via cvs.
Thanks.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 19:16 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Tom Lane @ 1998-10-28 19:16 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: hackers@postgreSQL.org
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> But we might as well fix it now, because we can't ask for initdb after
> the final release.
> Can someone check that that fix does not affect the regression test
> results? I doubt we do lseg not-equal tests in the regression suite.
> You will have to do an initdb to see the change.
I just rebuilt and initdb'd. Regression test state is the same
as before, except that the new inet test fails:
inline patch 1: results/inet.out (+8/-8 lines) download inline-1.patch
*** expected/inet.out Tue Oct 27 14:34:02 1998
--- results/inet.out Wed Oct 28 14:02:45 1998
***************
*** 53,66 ****
i as inet, network(i) as "network(inet)" FROM INET_TBL;
eight|cidr |network(cidr)|inet |network(inet)
-----+------------+-------------+----------------+-------------
! |192.168.1/24| 0.1.168.192|192.168.1.226/24| 0.1.168.192
! |192.168.1/24| 0.1.168.192|192.168.1.226 |226.1.168.192
! |10/8 | 0.0.0.10|10.1.2.3/8 | 0.0.0.10
! |10.0.0.0/32 | 0.0.0.10|10.1.2.3/8 | 0.0.0.10
! |10.1.2.3/32 | 3.2.1.10|10.1.2.3 | 3.2.1.10
! |10.1.2/24 | 0.2.1.10|10.1.2.3/24 | 0.2.1.10
! |10.1/16 | 0.0.1.10|10.1.2.3/16 | 0.0.1.10
! |10/8 | 0.0.0.10|10.1.2.3/8 | 0.0.0.10
(8 rows)
QUERY: SELECT '' as eight, c as cidr, masklen(c) as "masklen(cidr)",
--- 53,66 ----
i as inet, network(i) as "network(inet)" FROM INET_TBL;
eight|cidr |network(cidr)|inet |network(inet)
-----+------------+-------------+----------------+-------------
! |192.168.1/24| 192.168.1.0|192.168.1.226/24| 192.168.1.0
! |192.168.1/24| 192.168.1.0|192.168.1.226 |192.168.1.226
! |10/8 | 10.0.0.0|10.1.2.3/8 | 10.0.0.0
! |10.0.0.0/32 | 10.0.0.0|10.1.2.3/8 | 10.0.0.0
! |10.1.2.3/32 | 10.1.2.3|10.1.2.3 | 10.1.2.3
! |10.1.2/24 | 10.1.2.0|10.1.2.3/24 | 10.1.2.0
! |10.1/16 | 10.1.0.0|10.1.2.3/16 | 10.1.0.0
! |10/8 | 10.0.0.0|10.1.2.3/8 | 10.0.0.0
(8 rows)
QUERY: SELECT '' as eight, c as cidr, masklen(c) as "masklen(cidr)",
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 19:17 The Hermit Hacker <scrappy@hub.org>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
3 siblings, 1 reply; 141+ messages in thread
From: The Hermit Hacker @ 1998-10-28 19:17 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: PostgreSQL-development <hackers@postgreSQL.org>
On Wed, 28 Oct 1998, Bruce Momjian wrote:
> Here are the open items. Thanks to Jan, the only 'hot' item left is the
> ps args issue. People on non-BSD platforms will see all their backends
> called 'postmaster', because argv[0] changes do not reflect in ps arg
> displays.
Since there were no problem reports for this, I assumed that it
was an 'asthetic change' more then anything. Once v6.4 is released, I'll
dive into it with the Linux guys here at the University...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 19:19 The Hermit Hacker <scrappy@hub.org>
parent: Jan Wieck <jwieck@debis.com>
2 siblings, 0 replies; 141+ messages in thread
From: The Hermit Hacker @ 1998-10-28 19:19 UTC (permalink / raw)
To: Jan Wieck <jwieck@debis.com>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; hackers@postgreSQL.org
On Wed, 28 Oct 1998, Jan Wieck wrote:
> >
> > Thanks. Applied.
> >
> > > Bruce Momjian wrote:
> > > >
> > > > Additions
> > > > ---------
> > > > CREATE TABLE test (x text, s serial) fails if no database creation permission
> > > > regression test all platforms
> > >
> > > The patch below arranges that the sequence(s) get created
> > > first. Unprivileged user now can create table with serial
> > > columns.
> > >
> > > Regression tested.
>
> So Marc's assumption that his BETA3 is what we release was
> false. We really know how to trigger his hot buttons - eh?
> :-)
If it was 'the release', it wouldn't have been named BETA :) I'll
build a BETA4 tomorrow...release set for Monday...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-28 19:22 The Hermit Hacker <scrappy@hub.org>
parent: Brook Milligan <brook@trillium.NMSU.Edu>
0 siblings, 2 replies; 141+ messages in thread
From: The Hermit Hacker @ 1998-10-28 19:22 UTC (permalink / raw)
To: Brook Milligan <brook@trillium.NMSU.Edu>; +Cc: maillist@candle.pha.pa.us; jwieck@debis.com; hackers@postgreSQL.org
Doesn't work under Solaris, but, then again, neither does sendamil's, so
that isn't a shock :)
On Wed, 28 Oct 1998, Brook Milligan wrote:
> > I'm running Linux 2.1.88 and get
> >
> > 15572 p2 S 0:01 /usr/local/pgsql/bin/postmaster -o -F
> > 16121 p2 S 0:01 /usr/local/pgsql/bin/postgres localhost twieck twieck idle
> >
> > from ps. So what isn't working?
>
> Whoh, this is a shock. I thought this trick did not work under Linux.
> If it does, and no one has complained, we can consider the issue closed.
>
> For whatever it's worth, I see the same status stuff changing under
> NetBSD 1.3.2. Seems to work fine.
>
> Cheers,
> Brook
>
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 02:35 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-29 02:35 UTC (permalink / raw)
To: tgl@sss.pgh.pa.us; +Cc: jwieck@debis.com; hackers@postgreSQL.org
> jwieck@debis.com (Jan Wieck) writes:
> > I asked for it a while ago but forgot about it. Anyway - I
> > think it is better to have precreated gram.c, y.tab.h and
> > scan.c files in src/pl/plpgsql/src too. Otherwise ppl not
> > having bison/flex might have a build problem.
>
> There are quite a few places that need lex/yacc capability; plpgsql
> is not creating any new build requirement that did not exist before.
> (ecpg and bootparse are two examples I can think of offhand.)
> We ship the main gram.c file not to avoid requiring lex/yacc, but
> because it is too big for some older yaccs.
>
> It might be nice to eliminate the need for lex/yacc capability,
> but post-beta3 is NOT the time to be doing "might be nice" stuff.
> Leave it be for now.
>
> regards, tom lane
>
> PS: BTW, I was able to build all the Postgres yacc files on a rather
> ancient HPUX yacc, once I added enough -N switches. According to my
> notes,
> YACC:/usr/bin/yacc
> YFLAGS:-d -Np2000 -Ns3000 -Nm100000 -Nl2000 -Na30000 -Nc10000
> worked with a pretty recent fileset. So I'm not sure we even really
> need to distribute the main parser's gram.c. We could have configure
> plug in these switches if it fails to find bison...
Again, too late to play with. BSD yacc doesn't have switches that
enable larger tables, so you have to have gram.c. Does plpgsql have
tables too large for BSD yacc? Can someone test 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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 03:36 Bruce Momjian <maillist@candle.pha.pa.us>
parent: The Hermit Hacker <scrappy@hub.org>
0 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-29 03:36 UTC (permalink / raw)
To: scrappy@hub.org; +Cc: hackers@postgreSQL.org
> On Wed, 28 Oct 1998, Bruce Momjian wrote:
>
> > Here are the open items. Thanks to Jan, the only 'hot' item left is the
> > ps args issue. People on non-BSD platforms will see all their backends
> > called 'postmaster', because argv[0] changes do not reflect in ps arg
> > displays.
>
> Since there were no problem reports for this, I assumed that it
> was an 'asthetic change' more then anything. Once v6.4 is released, I'll
> dive into it with the Linux guys here at the University...
Looks like it works for most people. I will remove it from the list,
and see if someone complains.
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 03:37 Bruce Momjian <maillist@candle.pha.pa.us>
parent: The Hermit Hacker <scrappy@hub.org>
1 sibling, 2 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-29 03:37 UTC (permalink / raw)
To: scrappy@hub.org; +Cc: brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
> Doesn't work under Solaris, but, then again, neither does sendamil's, so
> that isn't a shock :)
Man, if sendmail's doesn't work, that is really broken.
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 04:32 The Hermit Hacker <scrappy@hub.org>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 1 reply; 141+ messages in thread
From: The Hermit Hacker @ 1998-10-29 04:32 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
On Wed, 28 Oct 1998, Bruce Momjian wrote:
> > Doesn't work under Solaris, but, then again, neither does sendamil's, so
> > that isn't a shock :)
>
> Man, if sendmail's doesn't work, that is really broken.
Solaris just doesn't have any mechanisms to work around the
limitation, I guess *shrug* It really sucks when you want to SIGHUP the
"parent process", which, under FreeBSD at least, is the one that states:
-accepting connections, but under Solaris they are *all* the same :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 06:41 Billy G. Allie <Bill.Allie@mug.org>
parent: The Hermit Hacker <scrappy@hub.org>
1 sibling, 1 reply; 141+ messages in thread
From: Billy G. Allie @ 1998-10-29 06:41 UTC (permalink / raw)
To: The Hermit Hacker <scrappy@hub.org>; +Cc: Brook Milligan <brook@trillium.NMSU.Edu>; maillist@candle.pha.pa.us; jwieck@debis.com; hackers@postgreSQL.org
Doesn't work under UnixWare, either.
The Hermit Hacker wrote:
> Doesn't work under Solaris, but, then again, neither does sendamil's, so
> that isn't a shock :)
>
>
>
> On Wed, 28 Oct 1998, Brook Milligan wrote:
>
> > > I'm running Linux 2.1.88 and get
> > >
> > > 15572 p2 S 0:01 /usr/local/pgsql/bin/postmaster -o -F
> > > 16121 p2 S 0:01 /usr/local/pgsql/bin/postgres localhost twieck twieck idle
> > >
> > > from ps. So what isn't working?
> >
> > Whoh, this is a shock. I thought this trick did not work under Linux.
> > If it does, and no one has complained, we can consider the issue closed.
> >
> > For whatever it's worth, I see the same status stuff changing under
> > NetBSD 1.3.2. Seems to work fine.
> >
> > Cheers,
> > Brook
> >
>
> Marc G. Fournier
> Systems Administrator @ hub.org
> primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
>
>
--
____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/ |LLIE | (313) 582-1540 |
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 06:48 Billy G. Allie <Bill.Allie@mug.org>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 3 replies; 141+ messages in thread
From: Billy G. Allie @ 1998-10-29 06:48 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: scrappy@hub.org; brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
Bruce Momjian wrote:
> > Doesn't work under Solaris, but, then again, neither does sendamil's, so
> > that isn't a shock :)
>
> Man, if sendmail's doesn't work, that is really broken.
If you want strange, here is the output from the UnixWare 7 ps command with
some different options:
$ ps -ef | fgrep post
pgsql 10775 1 TS 80 0 01:34:12 ? 0:00 postmaster -S -i -o -F
pgsql 10869 10775 TS 80 0 01:45:30 ? 0:00 postmaster -S -i -o -F
$ ps -e | fgrep post
10775 TS 80 ? 0:00 postgres
10869 TS 80 ? 0:00 postgres
Notice that the PIDs are the same even if the program name is different
depending on the use of the 'f' option.
--
____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/ |LLIE | (313) 582-1540 |
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 07:07 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Billy G. Allie <Bill.Allie@mug.org>
2 siblings, 1 reply; 141+ messages in thread
From: Bruce Momjian @ 1998-10-29 07:07 UTC (permalink / raw)
To: Bill.Allie@mug.org; +Cc: scrappy@hub.org; brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
> Bruce Momjian wrote:
> > > Doesn't work under Solaris, but, then again, neither does sendamil's, so
> > > that isn't a shock :)
> >
> > Man, if sendmail's doesn't work, that is really broken.
>
> If you want strange, here is the output from the UnixWare 7 ps command with
> some different options:
>
> $ ps -ef | fgrep post
> pgsql 10775 1 TS 80 0 01:34:12 ? 0:00 postmaster -S -i -o -F
> pgsql 10869 10775 TS 80 0 01:45:30 ? 0:00 postmaster -S -i -o -F
>
> $ ps -e | fgrep post
> 10775 TS 80 ? 0:00 postgres
> 10869 TS 80 ? 0:00 postgres
>
> Notice that the PIDs are the same even if the program name is different
> depending on the use of the 'f' option.
Wow, that really is strange. Seems like with the -f, it looks in one
place, as though it knows the child did not exec, so they params must be
the same, while with no -f, it looks in the proper area. The really
weird thing is that even the postmaster is called postgres. That is
bizarre.
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 07:31 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Billy G. Allie <Bill.Allie@mug.org>
2 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-29 07:31 UTC (permalink / raw)
To: Bill.Allie@mug.org; +Cc: scrappy@hub.org; brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org; dz@cs.unitn.it
> Bruce Momjian wrote:
> > > Doesn't work under Solaris, but, then again, neither does sendamil's, so
> > > that isn't a shock :)
> >
> > Man, if sendmail's doesn't work, that is really broken.
>
> If you want strange, here is the output from the UnixWare 7 ps command with
> some different options:
>
> $ ps -ef | fgrep post
> pgsql 10775 1 TS 80 0 01:34:12 ? 0:00 postmaster -S -i -o -F
> pgsql 10869 10775 TS 80 0 01:45:30 ? 0:00 postmaster -S -i -o -F
>
> $ ps -e | fgrep post
> 10775 TS 80 ? 0:00 postgres
> 10869 TS 80 ? 0:00 postgres
>
> Notice that the PIDs are the same even if the program name is different
> depending on the use of the 'f' option.
That is really bizarre. The postmaster name is changed to postgres too!
Ah, I now know why things work on Linux. Massimo did more than just
parameterize my argv code. In include/utils/ps_status.h, he put in
Linux-specific code to handle the ps args. Seems under Linux, only
argv[0] can be modified for ps display, for some reason. He erases the
other args, and puts everything in argv[0].
Under non-linux, he uses the argv[0-4] for various displays, like my
orignal code. The major issue is that for Linux, he writes directly
into argv[0] memory. He sets the normal i/o static parameters in the
start of the string, then marks the next position, and writes status
information into there.
In non-Linux, we don't write into argv[0], but change argv[0..4] to
point to our own alloc'ed strings, where the memory sits in our own
address space, not in the proc 'environment' address space. Getting
'ps' to display process address space strings is a real trick, so it is
not surprising some O/S's don't support it.
He may have done it all in argv[0] because he is expanding the size of
argv[0], and if they are layed out sequentially in environment memory,
the changes would over-write each other. What I don't understand is why
ps when it goes to look at argv[1], does not see garbage because it may
be pointing into the middle of the argv[0] string.) Can a Linux user
use ps to display all the params, like 'ps -ef' and see if it is showing
argv[1] as part of the argv[0] string? You may have to get a wide
display to see it all.
The great news is that it seems it is working to write directly into the
environment address space under Linux, so we don't need set_proctitle,
and it is very fast.
Non-linux platforms are not writing directly to environment memory, but
are using the argv[0..4] trick.
FYI, I have re-exec'ed the postmaster in postmaster.h so it has 4 args.
argc is passed as a value to the program, so you can't change it, and if
you don't do the re-exec, ps only looks at the argv[0], and under
non-linux, that is bad because we use argv[0...4].
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 15:24 Matthew N. Dodd <winter@jurai.net>
parent: The Hermit Hacker <scrappy@hub.org>
0 siblings, 2 replies; 141+ messages in thread
From: Matthew N. Dodd @ 1998-10-29 15:24 UTC (permalink / raw)
To: The Hermit Hacker <scrappy@hub.org>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
On Thu, 29 Oct 1998, The Hermit Hacker wrote:
> Solaris just doesn't have any mechanisms to work around the
> limitation, I guess *shrug* It really sucks when you want to SIGHUP
> the "parent process", which, under FreeBSD at least, is the one that
> states: -accepting connections, but under Solaris they are *all* the
> same :)
$ ps -eaf
UID PID PPID C STIME TTY TIME CMD
root 0 0 0 Oct 12 ? 0:01 sched
root 1 0 0 Oct 12 ? 0:15 /etc/init -
...
You'll note the 'PPID' field.
3 guesses what that stands for.
--
| Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? |
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 16:31 Jan Wieck <jwieck@debis.com>
parent: Matthew N. Dodd <winter@jurai.net>
1 sibling, 2 replies; 141+ messages in thread
From: jwieck@debis.com @ 1998-10-29 16:31 UTC (permalink / raw)
To: winter@jurai.net; +Cc: scrappy@hub.org; maillist@candle.pha.pa.us; brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
>
> On Thu, 29 Oct 1998, The Hermit Hacker wrote:
> > Solaris just doesn't have any mechanisms to work around the
> > limitation, I guess *shrug* It really sucks when you want to SIGHUP
> > the "parent process", which, under FreeBSD at least, is the one that
> > states: -accepting connections, but under Solaris they are *all* the
> > same :)
>
> $ ps -eaf
> UID PID PPID C STIME TTY TIME CMD
> root 0 0 0 Oct 12 ? 0:01 sched
> root 1 0 0 Oct 12 ? 0:15 /etc/init -
> ...
>
> You'll note the 'PPID' field.
>
> 3 guesses what that stands for.
>
Don't see how this is related to the topic - sorry.
PPID is the parent process ID. sched has no parent (it's a
kernel pseudo process) and init has sched as father. For all
other processes the PPID is set to init's PID at the time
their father dies (you'll see lot's of PPID=1).
But this all has nothing to do with changing the CMD column
of the ps output from inside a running process.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 16:43 Matthew N. Dodd <winter@jurai.net>
parent: Jan Wieck <jwieck@debis.com>
1 sibling, 1 reply; 141+ messages in thread
From: Matthew N. Dodd @ 1998-10-29 16:43 UTC (permalink / raw)
To: Jan Wieck <jwieck@debis.com>; +Cc: scrappy@hub.org; maillist@candle.pha.pa.us; brook@trillium.NMSU.Edu; hackers@postgreSQL.org
On Thu, 29 Oct 1998, Jan Wieck wrote:
> > On Thu, 29 Oct 1998, The Hermit Hacker wrote:
> > > Solaris just doesn't have any mechanisms to work around the
> > > limitation, I guess *shrug* It really sucks when you want to SIGHUP
> > > the "parent process", which, under FreeBSD at least, is the one that
> > > states: -accepting connections, but under Solaris they are *all* the
> > > same :)
> >
> > $ ps -eaf
> > UID PID PPID C STIME TTY TIME CMD
> > root 0 0 0 Oct 12 ? 0:01 sched
> > root 1 0 0 Oct 12 ? 0:15 /etc/init -
> > ...
> >
> > You'll note the 'PPID' field.
> >
> > 3 guesses what that stands for.
> >
>
> Don't see how this is related to the topic - sorry.
I really have to start explaining things using more words don't I.
> PPID is the parent process ID. sched has no parent (it's a
> kernel pseudo process) and init has sched as father. For all
> other processes the PPID is set to init's PID at the time
> their father dies (you'll see lot's of PPID=1).
Reread the bit of text I quoted. Read my reply. How does my reply
address the problem scrappy had?
The bits of ps output I quoted were only serving to demonstrate actual
data produced by the ps command I used. The actual commands weren't
important, only the PID and PPID fields were.
> But this all has nothing to do with changing the CMD column
> of the ps output from inside a running process.
No, but changing the CMD column is only eye-candy. Its not necessary to
be able to tell which processes are children and which is the parent.
--
| Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? |
^ permalink raw reply [nested|flat] 141+ messages in thread
* RE: [HACKERS] Open 6.4 items
@ 1998-10-29 17:05 Taral <taral@mail.utexas.edu>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 141+ messages in thread
From: Taral @ 1998-10-29 17:05 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; Bill.Allie@mug.org; +Cc: scrappy@hub.org; brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
> Wow, that really is strange. Seems like with the -f, it looks in one
> place, as though it knows the child did not exec, so they params must be
> the same, while with no -f, it looks in the proper area. The really
> weird thing is that even the postmaster is called postgres. That is
> bizarre.
Yes. With -f, it looks in the process's argv... without, it looks in the
task struct where only the executable name was stored (no path or anything
else). It's a feature to prevent processes that spoof as something else...
(not very effective, IMHO)
Taral
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 17:19 The Hermit Hacker <scrappy@hub.org>
parent: Billy G. Allie <Bill.Allie@mug.org>
0 siblings, 0 replies; 141+ messages in thread
From: The Hermit Hacker @ 1998-10-29 17:19 UTC (permalink / raw)
To: Billy G. Allie <Bill.Allie@mug.org>; +Cc: Brook Milligan <brook@trillium.NMSU.Edu>; maillist@candle.pha.pa.us; jwieck@debis.com; hackers@postgreSQL.org
On Thu, 29 Oct 1998, Billy G. Allie wrote:
> Doesn't work under UnixWare, either.
>
How about sendmail? That is "broken" too?
> The Hermit Hacker wrote:
> > Doesn't work under Solaris, but, then again, neither does sendamil's, so
> > that isn't a shock :)
> >
> >
> >
> > On Wed, 28 Oct 1998, Brook Milligan wrote:
> >
> > > > I'm running Linux 2.1.88 and get
> > > >
> > > > 15572 p2 S 0:01 /usr/local/pgsql/bin/postmaster -o -F
> > > > 16121 p2 S 0:01 /usr/local/pgsql/bin/postgres localhost twieck twieck idle
> > > >
> > > > from ps. So what isn't working?
> > >
> > > Whoh, this is a shock. I thought this trick did not work under Linux.
> > > If it does, and no one has complained, we can consider the issue closed.
> > >
> > > For whatever it's worth, I see the same status stuff changing under
> > > NetBSD 1.3.2. Seems to work fine.
> > >
> > > Cheers,
> > > Brook
> > >
> >
> > Marc G. Fournier
> > Systems Administrator @ hub.org
> > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> >
> >
>
> --
> ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
> | /| | 7436 Hartwell | Compuserve: 76337,2061
> |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
> |/ |LLIE | (313) 582-1540 |
>
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 17:24 The Hermit Hacker <scrappy@hub.org>
parent: Matthew N. Dodd <winter@jurai.net>
1 sibling, 2 replies; 141+ messages in thread
From: The Hermit Hacker @ 1998-10-29 17:24 UTC (permalink / raw)
To: Matthew N. Dodd <winter@jurai.net>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
On Thu, 29 Oct 1998, Matthew N. Dodd wrote:
> On Thu, 29 Oct 1998, The Hermit Hacker wrote:
> > Solaris just doesn't have any mechanisms to work around the
> > limitation, I guess *shrug* It really sucks when you want to SIGHUP
> > the "parent process", which, under FreeBSD at least, is the one that
> > states: -accepting connections, but under Solaris they are *all* the
> > same :)
>
> $ ps -eaf
> UID PID PPID C STIME TTY TIME CMD
> root 0 0 0 Oct 12 ? 0:01 sched
> root 1 0 0 Oct 12 ? 0:15 /etc/init -
> ...
>
> You'll note the 'PPID' field.
>
> 3 guesses what that stands for.
Okay, now you risk getting on my bad side :) I know what PPID
stands for...now you tell me which of these processes to SIGHUP:
root 18942 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail
root 18946 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail
root 18948 1 0 13:22:04 ? 0:00 /usr/local/sbin/sendmail
root 22213 1 0 Oct 26 ? 1:40 /usr/local/sbin/sendmail
And ya, I know, the one with the older date...the point is that
you can't really automate this, except to do:
kill -HUP `ps -aef | grep sendmail | awk '{print $2}'`
And SIGHUP them all...
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 17:26 The Hermit Hacker <scrappy@hub.org>
parent: Jan Wieck <jwieck@debis.com>
1 sibling, 0 replies; 141+ messages in thread
From: The Hermit Hacker @ 1998-10-29 17:26 UTC (permalink / raw)
To: Jan Wieck <jwieck@debis.com>; +Cc: Matthew N. Dodd <winter@jurai.net>; maillist@candle.pha.pa.us; brook@trillium.NMSU.Edu; hackers@postgreSQL.org
On Thu, 29 Oct 1998, Jan Wieck wrote:
> >
> > On Thu, 29 Oct 1998, The Hermit Hacker wrote:
> > > Solaris just doesn't have any mechanisms to work around the
> > > limitation, I guess *shrug* It really sucks when you want to SIGHUP
> > > the "parent process", which, under FreeBSD at least, is the one that
> > > states: -accepting connections, but under Solaris they are *all* the
> > > same :)
> >
> > $ ps -eaf
> > UID PID PPID C STIME TTY TIME CMD
> > root 0 0 0 Oct 12 ? 0:01 sched
> > root 1 0 0 Oct 12 ? 0:15 /etc/init -
> > ...
> >
> > You'll note the 'PPID' field.
> >
> > 3 guesses what that stands for.
> >
>
> Don't see how this is related to the topic - sorry.
>
> PPID is the parent process ID. sched has no parent (it's a
> kernel pseudo process) and init has sched as father. For all
> other processes the PPID is set to init's PID at the time
> their father dies (you'll see lot's of PPID=1).
>
> But this all has nothing to do with changing the CMD column
> of the ps output from inside a running process.
In Matthew's defence, I think the point he was trying to bring across was
that you should be able to look at hte PPID. sendmail, when you start,
tends to list its PPID as '1'...but, as I showed in my last email, that
doesn't appear to be "unique"...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 17:34 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Billy G. Allie <Bill.Allie@mug.org>
2 siblings, 0 replies; 141+ messages in thread
From: Bruce Momjian @ 1998-10-29 17:34 UTC (permalink / raw)
To: Bill.Allie@mug.org; +Cc: scrappy@hub.org; brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
> Bruce Momjian wrote:
> > > Doesn't work under Solaris, but, then again, neither does sendamil's, so
> > > that isn't a shock :)
> >
> > Man, if sendmail's doesn't work, that is really broken.
>
> If you want strange, here is the output from the UnixWare 7 ps command with
> some different options:
>
> $ ps -ef | fgrep post
> pgsql 10775 1 TS 80 0 01:34:12 ? 0:00 postmaster -S -i -o -F
> pgsql 10869 10775 TS 80 0 01:45:30 ? 0:00 postmaster -S -i -o -F
>
> $ ps -e | fgrep post
> 10775 TS 80 ? 0:00 postgres
> 10869 TS 80 ? 0:00 postgres
My guess is that ps without -f looks at the inode that opened the file,
and postmaster and postgres have the same inode because postmaster is
symlinked to postgres.
--
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
^ permalink raw reply [nested|flat] 141+ messages in thread
* RE: [HACKERS] Open 6.4 items
@ 1998-10-29 17:36 Taral <taral@mail.utexas.edu>
parent: The Hermit Hacker <scrappy@hub.org>
1 sibling, 2 replies; 141+ messages in thread
From: Taral @ 1998-10-29 17:36 UTC (permalink / raw)
To: The Hermit Hacker <scrappy@hub.org>; Matthew N. Dodd <winter@jurai.net>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
> root 18942 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail
> root 18946 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail
> root 18948 1 0 13:22:04 ? 0:00 /usr/local/sbin/sendmail
> root 22213 1 0 Oct 26 ? 1:40 /usr/local/sbin/sendmail
Er... if you have this, you have a problem. This means there are TWO
sendmail daemons running... There should only be ONE with a ppid of 1. It
looks like 18948 is blah.
Taral
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 17:40 Matthew N. Dodd <winter@jurai.net>
parent: The Hermit Hacker <scrappy@hub.org>
1 sibling, 1 reply; 141+ messages in thread
From: Matthew N. Dodd @ 1998-10-29 17:40 UTC (permalink / raw)
To: The Hermit Hacker <scrappy@hub.org>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
On Thu, 29 Oct 1998, The Hermit Hacker wrote:
> Okay, now you risk getting on my bad side :) I know what PPID
> stands for...now you tell me which of these processes to SIGHUP:
>
> root 18942 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail
> root 18946 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail
2 open connections.
> root 18948 1 0 13:22:04 ? 0:00 /usr/local/sbin/sendmail
a local delivery spawned by an open connection that closed and left the
local delivery to finish, thus orphaning it to init (PID1)
> root 22213 1 0 Oct 26 ? 1:40 /usr/local/sbin/sendmail
The listener.
> And ya, I know, the one with the older date...the point is that
> you can't really automate this, except to do:
You're trying to kill the listener?
You do know you can use truss and lsof to figure this out as well right?
Or you could do:
kill -HUP `head -1 /var/run/sendmail.pid`
Also, check out what the BSD style ps shows under Solaris (/usr/ucb/ps).
--
| Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? |
^ permalink raw reply [nested|flat] 141+ messages in thread
* RE: [HACKERS] Open 6.4 items
@ 1998-10-29 17:43 Matthew N. Dodd <winter@jurai.net>
parent: Taral <taral@mail.utexas.edu>
1 sibling, 0 replies; 141+ messages in thread
From: Matthew N. Dodd @ 1998-10-29 17:43 UTC (permalink / raw)
To: Taral <taral@mail.utexas.edu>; +Cc: The Hermit Hacker <scrappy@hub.org>; Bruce Momjian <maillist@candle.pha.pa.us>; brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
On Thu, 29 Oct 1998, Taral wrote:
> > root 18942 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail
> > root 18946 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail
> > root 18948 1 0 13:22:04 ? 0:00 /usr/local/sbin/sendmail
> > root 22213 1 0 Oct 26 ? 1:40 /usr/local/sbin/sendmail
>
> Er... if you have this, you have a problem. This means there are TWO
> sendmail daemons running... There should only be ONE with a ppid of 1. It
> looks like 18948 is blah.
No, it looks like there are 4 sendmail daemons running.
The issue is to determine what each of them are doing.
daemon != listener
--
| Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? |
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-29 18:17 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Matthew N. Dodd <winter@jurai.net>
0 siblings, 0 replies; 141+ messages in thread
From: Thomas G. Lockhart @ 1998-10-29 18:17 UTC (permalink / raw)
To: Matthew N. Dodd <winter@jurai.net>; +Cc: Jan Wieck <jwieck@debis.com>; scrappy@hub.org; maillist@candle.pha.pa.us; brook@trillium.NMSU.Edu; hackers@postgreSQL.org
> I really have to start explaining things using more words don't I.
Only if you want anyone to bother paying attention to you.
- Thomas (who didn't)
^ permalink raw reply [nested|flat] 141+ messages in thread
* RE: [HACKERS] Open 6.4 items
@ 1998-10-30 02:02 The Hermit Hacker <scrappy@hub.org>
parent: Taral <taral@mail.utexas.edu>
1 sibling, 0 replies; 141+ messages in thread
From: The Hermit Hacker @ 1998-10-30 02:02 UTC (permalink / raw)
To: Taral <taral@mail.utexas.edu>; +Cc: Matthew N. Dodd <winter@jurai.net>; Bruce Momjian <maillist@candle.pha.pa.us>; brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
On Thu, 29 Oct 1998, Taral wrote:
> > root 18942 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail
> > root 18946 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail
> > root 18948 1 0 13:22:04 ? 0:00 /usr/local/sbin/sendmail
> > root 22213 1 0 Oct 26 ? 1:40 /usr/local/sbin/sendmail
>
> Er... if you have this, you have a problem. This means there are TWO
> sendmail daemons running... There should only be ONE with a ppid of 1. It
> looks like 18948 is blah.
Good guess, but that is normal behaviour, at least under Solaris :) It
took me several 'ps -aef's to actually find it duplicated, it isn't always
there.
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
^ permalink raw reply [nested|flat] 141+ messages in thread
* Re: [HACKERS] Open 6.4 items
@ 1998-10-30 02:06 The Hermit Hacker <scrappy@hub.org>
parent: Matthew N. Dodd <winter@jurai.net>
0 siblings, 0 replies; 141+ messages in thread
From: The Hermit Hacker @ 1998-10-30 02:06 UTC (permalink / raw)
To: Matthew N. Dodd <winter@jurai.net>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; brook@trillium.NMSU.Edu; jwieck@debis.com; hackers@postgreSQL.org
On Thu, 29 Oct 1998, Matthew N. Dodd wrote:
> On Thu, 29 Oct 1998, The Hermit Hacker wrote:
> > Okay, now you risk getting on my bad side :) I know what PPID
> > stands for...now you tell me which of these processes to SIGHUP:
> >
> > root 18942 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail
> > root 18946 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail
>
> 2 open connections.
>
> > root 18948 1 0 13:22:04 ? 0:00 /usr/local/sbin/sendmail
>
> a local delivery spawned by an open connection that closed and left the
> local delivery to finish, thus orphaning it to init (PID1)
>
> > root 22213 1 0 Oct 26 ? 1:40 /usr/local/sbin/sendmail
>
> The listener.
>
> > And ya, I know, the one with the older date...the point is that
> > you can't really automate this, except to do:
>
> You're trying to kill the listener?
>
> You do know you can use truss and lsof to figure this out as well right?
>
> Or you could do:
>
> kill -HUP `head -1 /var/run/sendmail.pid`
Yes, of course, but this was not the point of the whole
thread...:)
> Also, check out what the BSD style ps shows under Solaris (/usr/ucb/ps).
No apparent difference in the output...wait, you'll take me too
literally on that, eh? :) Both show the sasme information in the last
field../usr/local/sbin/sendmail -bd -q1h :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
^ permalink raw reply [nested|flat] 141+ messages in thread
end of thread, other threads:[~1998-10-30 02:06 UTC | newest]
Thread overview: 141+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1998-08-24 02:08 Open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-24 07:34 ` Peter T Mount <peter@retep.org.uk>
1998-08-24 15:27 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-24 16:04 ` Brook Milligan <brook@trillium.NMSU.Edu>
1998-08-25 02:58 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-25 06:28 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-25 07:05 ` Tatsuo Ishii <t-ishii@sra.co.jp>
1998-08-25 15:19 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-25 17:31 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-25 15:32 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-25 17:55 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-30 10:55 ` Peter T Mount <peter@retep.org.uk>
1998-08-30 18:40 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-30 21:11 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-30 23:07 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-25 19:50 ` Nick Bastin <nbastin@rbbsystems.com>
1998-08-25 21:41 ` The Hermit Hacker <scrappy@hub.org>
1998-08-26 03:03 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-26 03:44 ` The Hermit Hacker <scrappy@hub.org>
1998-08-26 04:47 ` Re: [HACKERS] Open 6.4 items] Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-25 03:59 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-25 06:13 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-25 06:26 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-26 00:13 ` Henry B. Hotz <hotz@jpl.nasa.gov>
1998-08-25 01:01 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-25 03:56 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-29 04:40 Open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-30 10:53 ` Peter T Mount <peter@retep.org.uk>
1998-09-04 03:42 ` Vadim Mikheev <vadim@krs.ru>
1998-09-04 03:40 ` David Hartwig <daybee@bellatlantic.net>
1998-09-04 04:19 ` Vadim Mikheev <vadim@krs.ru>
1998-09-04 00:53 ` David Hartwig <daybee@bellatlantic.net>
1998-09-04 05:21 ` Vadim Mikheev <vadim@krs.ru>
1998-09-04 04:54 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-09-10 05:04 open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-09-10 05:53 ` Re: [HACKERS] open 6.4 items Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-09-10 06:15 ` Re: [HACKERS] open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-09-10 13:38 ` Re: [HACKERS] open 6.4 items Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-09-10 14:25 ` Re: [HACKERS] open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-09-10 15:32 ` Re: [HACKERS] open 6.4 items Vadim Mikheev <vadim@krs.ru>
1998-09-10 16:38 ` Re: [HACKERS] open 6.4 items D'Arcy J.M. Cain <darcy@druid.net>
1998-09-10 17:44 ` Re: [HACKERS] open 6.4 items Vadim Mikheev <vadim@krs.ru>
1998-09-10 17:06 ` Re: [HACKERS] open 6.4 items Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-09-10 17:59 ` Re: [HACKERS] open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-09-10 06:23 ` Re: [HACKERS] open 6.4 items Peter T Mount <peter@retep.org.uk>
1998-09-21 02:28 Open 6.4 Items Bruce Momjian <maillist@candle.pha.pa.us>
1998-09-23 04:23 ` Re: [HACKERS] Open 6.4 Items Nick Bastin <nbastin@rbbsystems.com>
1998-09-23 02:32 ` Re: [HACKERS] Open 6.4 Items Bruce Momjian <maillist@candle.pha.pa.us>
1998-09-23 05:08 ` Re: [HACKERS] Open 6.4 Items Nick Bastin <nbastin@rbbsystems.com>
1998-10-02 06:18 Open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-02 10:21 ` Jan Wieck <jwieck@debis.com>
1998-10-02 14:47 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-02 15:45 ` Jan Wieck <jwieck@debis.com>
1998-10-02 16:26 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-02 19:05 ` Jan Wieck <jwieck@debis.com>
1998-10-02 21:34 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-02 11:29 ` D'Arcy J.M. Cain <darcy@druid.net>
1998-10-02 14:09 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-10-02 14:43 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-05 05:05 ` Marc G. Fournier <scrappy@hub.org>
1998-10-06 01:56 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-02 21:58 Open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-03 05:50 Re: [HACKERS] Open 6.4 Items Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-03 06:05 Open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-05 02:04 ` Tatsuo Ishii <t-ishii@sra.co.jp>
1998-10-06 02:05 ` Tatsuo Ishii <t-ishii@sra.co.jp>
1998-10-06 03:03 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-05 05:28 ` Marc G. Fournier <scrappy@hub.org>
1998-10-05 14:36 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-10-05 18:29 ` Marc G. Fournier <scrappy@hub.org>
1998-10-06 02:49 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-10-06 04:33 Open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-07 03:20 Open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-07 09:26 ` Tom Ivar Helbekkmo <tih@nhh.no>
1998-10-08 00:12 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-08 07:13 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-09 08:50 ` Tom Ivar Helbekkmo <tih@nhh.no>
1998-10-09 15:01 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-10-09 20:38 ` Tom Ivar Helbekkmo <tih@nhh.no>
1998-10-09 21:20 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-10-10 10:28 ` Tom Ivar Helbekkmo <tih@nhh.no>
1998-10-10 12:38 ` Tom Ivar Helbekkmo <tih@nhh.no>
1998-10-10 18:14 ` Tom Ivar Helbekkmo <tih@nhh.no>
1998-10-10 05:34 ` Paul A Vixie <paul@vix.com>
1998-10-10 12:12 ` Tom Ivar Helbekkmo <tih@nhh.no>
1998-10-12 01:31 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-12 02:16 ` Taral <taral@mail.utexas.edu>
1998-10-12 06:03 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-12 13:47 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-12 15:16 ` Tom Ivar Helbekkmo <tih@nhh.no>
1998-10-12 15:57 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-13 07:37 ` Paul A Vixie <paul@vix.com>
1998-10-09 04:29 Open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-13 15:40 Open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-15 05:59 Open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-28 05:17 Open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-28 14:19 ` Jan Wieck <jwieck@debis.com>
1998-10-28 15:14 ` The Hermit Hacker <scrappy@hub.org>
1998-10-28 16:16 ` Jan Wieck <jwieck@debis.com>
1998-10-28 16:12 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-28 16:46 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-28 16:06 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-28 16:31 ` Jan Wieck <jwieck@debis.com>
1998-10-28 16:18 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-28 19:16 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-10-28 17:18 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-28 19:19 ` The Hermit Hacker <scrappy@hub.org>
1998-10-28 16:16 Open 6.4 items Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-28 16:53 ` Jan Wieck <jwieck@debis.com>
1998-10-28 16:49 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-28 17:08 ` Brook Milligan <brook@trillium.NMSU.Edu>
1998-10-28 19:22 ` The Hermit Hacker <scrappy@hub.org>
1998-10-29 03:37 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-29 04:32 ` The Hermit Hacker <scrappy@hub.org>
1998-10-29 15:24 ` Matthew N. Dodd <winter@jurai.net>
1998-10-29 16:31 ` Jan Wieck <jwieck@debis.com>
1998-10-29 16:43 ` Matthew N. Dodd <winter@jurai.net>
1998-10-29 18:17 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-29 17:26 ` The Hermit Hacker <scrappy@hub.org>
1998-10-29 17:24 ` The Hermit Hacker <scrappy@hub.org>
1998-10-29 17:36 ` Taral <taral@mail.utexas.edu>
1998-10-29 17:43 ` Matthew N. Dodd <winter@jurai.net>
1998-10-30 02:02 ` The Hermit Hacker <scrappy@hub.org>
1998-10-29 17:40 ` Matthew N. Dodd <winter@jurai.net>
1998-10-30 02:06 ` The Hermit Hacker <scrappy@hub.org>
1998-10-29 06:48 ` Billy G. Allie <Bill.Allie@mug.org>
1998-10-29 07:07 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-29 17:05 ` Taral <taral@mail.utexas.edu>
1998-10-29 07:31 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-29 17:34 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-29 06:41 ` Billy G. Allie <Bill.Allie@mug.org>
1998-10-29 17:19 ` The Hermit Hacker <scrappy@hub.org>
1998-10-28 17:06 ` Jan Wieck <jwieck@debis.com>
1998-10-28 17:06 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-28 17:35 ` Jan Wieck <jwieck@debis.com>
1998-10-28 17:20 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-28 17:30 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-10-29 02:35 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-10-28 17:20 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-10-28 19:17 ` The Hermit Hacker <scrappy@hub.org>
1998-10-29 03:36 ` Bruce Momjian <maillist@candle.pha.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox