
Not having heard anything otherwise, assume we can go Beta today, as
planned?


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


Mon, 21 Feb 2000 09:45:35 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Beta for 4:30AST ... ?
The Hermit Hacker <scrappy@hub.org> writes:
> Not having heard anything otherwise, assume we can go Beta today, as
> planned?

Might as well --- we have open issues, but there'll always be open
issues.  I don't think anyone is still hoping to shoehorn new features
into 7.0, just bug fixes.  (Wait, does a unary-minus operator for
numeric count as a new feature ;-) ?)

I do suggest that we had better commit the current state of the rules
regress test output as the expected output, so that we don't have a
lot of confused beta-testers.  An actual fix will have to wait for
Thomas to return, but I don't think we want to put off going to beta
just because he's on vacation.

			regards, tom lane

Mon, 21 Feb 2000 10:41:53 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ? 
At 10:41 AM 2/21/00 -0500, Tom Lane wrote:
>The Hermit Hacker <scrappy@hub.org> writes:
>> Not having heard anything otherwise, assume we can go Beta today, as
>> planned?
>
>Might as well --- we have open issues, but there'll always be open
>issues.  I don't think anyone is still hoping to shoehorn new features
>into 7.0, just bug fixes.  (Wait, does a unary-minus operator for
>numeric count as a new feature ;-) ?)

I've been using a snapshot taken a couple of days ago, which includes
the new datetime stuff and outer join syntax stuff.  I've loaded 
several thousand lines of data model which has been ported from Oracle
into it, and have been testing our port of the Ars Digita web toolkit
extensively on it.  This consists of literally thousands of queries
against the aforementioned data model, which includes nearly 500 foreign
keys including some "on delete/update cascade" and "set null" clauses.

It is all working GREAT.  Better than 6.5 (in which case the referential
actions have to be removed anyway, of course), in fact.  I've had no
problems with the new datetime stuff, which was of particular concern
to me because the toolkit is full of queries to grab information from
the last week, since your last visit to the website, to update robot
detection tables, to send e-mail alerts to folks who request them daily
or weekly (similar to majordomo digests), to update the database's view
of the site's static content, to build reports on usage of the site,
etc etc.  Certain bug fixes really make the port work cleaner, the
"group by" fix (to return no rows if no groups exist) in particular.

Even pg_dump works, though I had to modify a couple of views in order
to get them reload correctly.  If I sound like I was a bit nervous of
pg_dump it has to do with those nearly 500 foreign keys I mentioned.

Anyway, from my POV it sure feels like it should be a very solid beta.
I've not run across anything causing me to want to switch back to 6.5.



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Mon, 21 Feb 2000 09:28:23 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Beta for 4:30AST ... ? 
> It is all working GREAT.  Better than 6.5 (in which case the referential
> actions have to be removed anyway, of course), in fact.  I've had no
> problems with the new datetime stuff, which was of particular concern
> to me because the toolkit is full of queries to grab information from
> the last week, since your last visit to the website, to update robot
> detection tables, to send e-mail alerts to folks who request them daily
> or weekly (similar to majordomo digests), to update the database's view
> of the site's static content, to build reports on usage of the site,
> etc etc.  Certain bug fixes really make the port work cleaner, the
> "group by" fix (to return no rows if no groups exist) in particular.
> 
> Even pg_dump works, though I had to modify a couple of views in order
> to get them reload correctly.  If I sound like I was a bit nervous of
> pg_dump it has to do with those nearly 500 foreign keys I mentioned.
> 
> Anyway, from my POV it sure feels like it should be a very solid beta.
> I've not run across anything causing me to want to switch back to 6.5.

You can thank our may testers, and Tom Lane, who is fixing things like
crazy.  Tom has fixed more PostgreSQL bugs than anyone else in the
history of our development.

Though bug fixing is not a glorious job, without reliability, we are
useless.

Thanks, Tom.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Mon, 21 Feb 2000 12:57:44 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
At 12:57 PM 2/21/00 -0500, Bruce Momjian wrote:

>You can thank our may testers, and Tom Lane, who is fixing things like
>crazy.  Tom has fixed more PostgreSQL bugs than anyone else in the
>history of our development.
>
>Though bug fixing is not a glorious job, without reliability, we are
>useless.
>
>Thanks, Tom.

Yes, I've noticed that Tom takes on bugs like a pitbull takes on
mail carriers, and I do appreciate it.

I'm not allergic to fixing bugs, and as I learn more about PG 
hope to dig into doing so with gusto.



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Mon, 21 Feb 2000 10:08:56 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Beta for 4:30AST ... ?
Don Baccus wrote:
> 
> Even pg_dump works, though I had to modify a couple of views in order
> to get them reload correctly.  

Don, could you elaborate on what you had to do to make your views
reload correctly?

Cheers,
Ed Loehr

Mon, 21 Feb 2000 12:11:16 -0600
Ed Loehr <eloehr@austin.rr.com>
Re: [HACKERS] Beta for 4:30AST ... ?
At 12:11 PM 2/21/00 -0600, Ed Loehr wrote:
>Don Baccus wrote:
>> 
>> Even pg_dump works, though I had to modify a couple of views in order
>> to get them reload correctly.  
>
>Don, could you elaborate on what you had to do to make your views
>reload correctly?

Good timing - I was about to post on this subject anyway.

I was able to fix my views by changing:

create view foo as select * from bar;

to:

...select * from bar bar;

In other words, an explicit declaration of the range table name (is
that the right term?P my mind's numb from porting queries all weekend)
leads to a rule that will reload.

I figured this out because there are some fairly complex views in
this datamodel, which use explicit names to avoid ambiguous column
references.

The standard actually says that a from clause like "from bar" 
implicitly declares "bar" for you, i.e. is exactly equivalent
to "from bar bar".  If Postgres name scoping - which I know is
not standard-compliant in the JOIN syntax case - is close enough
so that a transformation of "from bar" to "from bar bar" could
be done in the parser without breaking existing code, then a
lot more views could be successfully be dumped and reloaded.

Would all views dump/reload, or are there other problems I don't know
about?  I'm not in a position to judge, I've been too deeply embedded
in getting this toolkit ready for release (our first will be Wednesday)
to worry about the general case.  However, I do know that doing the
transformation by hand in the datamodel source has fixed the problem
for me.

Does anyone know if there are other problems?

Even if there are, a simple transformation such as I describe would
help - IF it didn't break existing code.  If it would break existing
code, then it is due to non-compliance with the standard so perhaps
wouldn't be such a terrible thing, either.  I'm not really in a
position to judge.

What do folks think?  



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Mon, 21 Feb 2000 10:27:15 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Beta for 4:30AST ... ?
> At 12:57 PM 2/21/00 -0500, Bruce Momjian wrote:
> 
> >You can thank our may testers, and Tom Lane, who is fixing things like
> >crazy.  Tom has fixed more PostgreSQL bugs than anyone else in the
> >history of our development.
> >
> >Though bug fixing is not a glorious job, without reliability, we are
> >useless.
> >
> >Thanks, Tom.
> 
> Yes, I've noticed that Tom takes on bugs like a pitbull takes on
> mail carriers, and I do appreciate it.

Yes, and we badly needed someone like that before Tom came along.  I
used to do it, but in a very pitiful way.  Mostly I just added them to
the TODO list.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Mon, 21 Feb 2000 13:59:07 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
Tom Lane <tgl@sss.pgh.pa.us> writes:
> The Hermit Hacker <scrappy@hub.org> writes:
>> Not having heard anything otherwise, assume we can go Beta today, as
>> planned?

> Might as well --- we have open issues, but there'll always be open
> issues.  I don't think anyone is still hoping to shoehorn new features
> into 7.0, just bug fixes.

OK, I'm done shoehorning in last-minute bug fixes, too.  You may fire
when ready, as far as I'm concerned.

I did commit current rules output per my previous note.  Regression
tests pass 100% clean on my primary box; haven't tried other systems
yet.

			regards, tom lane

Mon, 21 Feb 2000 14:06:13 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ? 
> At 12:11 PM 2/21/00 -0600, Ed Loehr wrote:
> >Don Baccus wrote:
> >> 
> >> Even pg_dump works, though I had to modify a couple of views in order
> >> to get them reload correctly.  
> >
> >Don, could you elaborate on what you had to do to make your views
> >reload correctly?
> 
> Good timing - I was about to post on this subject anyway.
> 
> I was able to fix my views by changing:
> 
> create view foo as select * from bar;
> 
> to:
> 
> ...select * from bar bar;
> 
> In other words, an explicit declaration of the range table name (is

Yes, right name.

I am totally confused why "from bar bar" is different from "bar".

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Mon, 21 Feb 2000 14:07:26 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > The Hermit Hacker <scrappy@hub.org> writes:
> >> Not having heard anything otherwise, assume we can go Beta today, as
> >> planned?
> 
> > Might as well --- we have open issues, but there'll always be open
> > issues.  I don't think anyone is still hoping to shoehorn new features
> > into 7.0, just bug fixes.
> 
> OK, I'm done shoehorning in last-minute bug fixes, too.  You may fire
> when ready, as far as I'm concerned.

Last call for partially implemented changes that you want to get in
before feature freeze...  :-)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Mon, 21 Feb 2000 14:19:37 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
Don Baccus <dhogaza@pacifier.com> writes:
> I was able to fix my views by changing:
> create view foo as select * from bar;
> to:
> ...select * from bar bar;

Hmm, I think I see it.

create view foo as select * from int8_tbl;

$ pg_dump -t foo regression
\connect - postgres
CREATE TABLE "foo" (
        "q1" int8,
        "q2" int8
);
CREATE RULE "_RETfoo" AS ON SELECT TO foo DO INSTEAD SELECT int8_tbl.q1,
int8_tbl.q2 FROM int8_tbl (q1, q2);

IIRC, Thomas explained that the ANSI syntax says you *must* supply a
table alias if you are going to supply any column aliases in FROM.
The regurgitated rule violates that.

I guess this is another manifestation of the issue about the system
shoving in column "aliases" that the user never typed.  pg_dump is
probably repeating what the backend told it.  Think we'll have to
leave it unfixed till Thomas gets back.

It's also a reminder that the regress tests don't exercise pg_dump :-(

			regards, tom lane

Mon, 21 Feb 2000 14:27:08 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ? 
At 02:07 PM 2/21/00 -0500, Bruce Momjian wrote:

>
>I am totally confused why "from bar bar" is different from "bar".

In the rule created for the view, the from clause gets generated
like this:

"from foo (list of columns), ..."

or - if an explicit range table name is given

"from foo foo (list of columns), ..."

The parser doesn't like the first form, is googoo-eyed over
the second and takes it without error.  I'm too busy to look at Date
or the SQL standard at the moment, but the list of columns is a non-standard
PG-ism anyway, isn't it?  Something lingering from pre-SQL days?

Is the list of columns even needed?  Is this some inheritance-related
thing?

As I mentioned in my earlier note, I was too swamped by my porting
effort to dig into this at all, and between work, the web toolkit,
and work on http://birdnotes.net won't have time to explore this
in the next couple of weeks.  I did take enough time to see that
the rule is built on the parse tree for the underlying select which
is why the hack of adding the range table name explicitly while
parsing if it's not mentioned came to mind.



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Mon, 21 Feb 2000 11:28:04 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Beta for 4:30AST ... ?
At 02:27 PM 2/21/00 -0500, Tom Lane wrote:
>Don Baccus <dhogaza@pacifier.com> writes:

>IIRC, Thomas explained that the ANSI syntax says you *must* supply a
>table alias if you are going to supply any column aliases in FROM.
>The regurgitated rule violates that.

Ahhh...column aliases...these ARE standard SQL, then!  I'll be...

I need to spend a couple of days studying Date thorougly someday, rather
than just cherry-picking when specific questions come to mind.

>I guess this is another manifestation of the issue about the system
>shoving in column "aliases" that the user never typed. 

Yes.

> pg_dump is probably repeating what the backend told it.

My fifteen minute sprint through the code led me to believe this
is true.  

>  Think we'll have to
>leave it unfixed till Thomas gets back.

That would be plenty of time to get it in for the real 7.0 release.

If indeed PG would survive the insertion of the table name as a
table alias when none is given - the standard semantics, in other
words - it would be very simple to do.  I'm just a little queasy
about possible side-effects.

>It's also a reminder that the regress tests don't exercise pg_dump :-(

Ohhh...that's not good.



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Mon, 21 Feb 2000 11:38:24 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Beta for 4:30AST ... ? 
> At 02:07 PM 2/21/00 -0500, Bruce Momjian wrote:
> 
> >
> >I am totally confused why "from bar bar" is different from "bar".
> 
> In the rule created for the view, the from clause gets generated
> like this:
> 
> "from foo (list of columns), ..."
> 
> or - if an explicit range table name is given
> 
> "from foo foo (list of columns), ..."

Got it:

	test=> select * from pg_class pg_class (relname);

Wow, that is some strange syntax, and I didn't know we even allowed
that.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Mon, 21 Feb 2000 14:39:08 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
> You can thank our may testers, and Tom Lane, who is fixing things like
> crazy.  Tom has fixed more PostgreSQL bugs than anyone else in the
> history of our development.

It's very impressive. I've noticed many times that someone mentions a bug, and
sometimes hours later Tom has cornered the problem. Maybe one or two questions
about how to go about it, and then the hole is plugged.

Mon, 21 Feb 2000 20:58:44 +0100
Kaare Rasmussen <kar@webline.dk>
Re: [HACKERS] Beta for 4:30AST ... ?
Having been away for some time I'm very anxious to see that there's a 7.0
release coming very soon. I extracted the TODO list from the CVS (latest update
February 9).  The only really really big issue as I see it is referential
integrity. This is big, I admit but why going to 7.0 for this? Or is it because
it's long overdue (MSVC and stuff)?

There are other things that must have taken a lot of work, only it's not
mainstream the same way referential integrity is (PL/Perl and more). I had
hoped to find outer joins, but look forward to the next release if it will be
there.

Maybe I missed something in the TODO list or in the fixed list, but I couldn't
find VIEWs with UNIONs, which I understand would be solved by a rewrite of the
rules system.

Mon, 21 Feb 2000 21:01:26 +0100
Kaare Rasmussen <kar@webline.dk>
TODO list / why 7.0 ?
Don Baccus <dhogaza@pacifier.com> writes:
>> Think we'll have to
>> leave it unfixed till Thomas gets back.

> That would be plenty of time to get it in for the real 7.0 release.

I don't like shipping betas with broken pg_dump; that makes life
unreasonably difficult for beta testers, if we have to force another
initdb before release.  So I put in a quick hack solution: don't print
the column alias list at all unless there is a table alias.  This makes
the rule's FROM clause conform to ANSI syntax.  If you actually did
write
	create view foo as SELECT alias FROM table table (alias);
then it will dump as
	create view foo as SELECT table.realcolname AS alias FROM table;
but there's no harm done.  Better solution needed but I'll let Thomas
provide it.

And now, it's 4:30 PM AST and we are outta here ... right Marc?

			regards, tom lane

Mon, 21 Feb 2000 15:27:12 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ? 
At 03:27 PM 2/21/00 -0500, Tom Lane wrote:

>I don't like shipping betas with broken pg_dump; that makes life
>unreasonably difficult for beta testers, if we have to force another
>initdb before release.  So I put in a quick hack solution: don't print
>the column alias list at all unless there is a table alias.  This makes
>the rule's FROM clause conform to ANSI syntax.  If you actually did
>write
>	create view foo as SELECT alias FROM table table (alias);
>then it will dump as
>	create view foo as SELECT table.realcolname AS alias FROM table;
>but there's no harm done.  Better solution needed but I'll let Thomas
>provide it.

EXCELLENT!



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Mon, 21 Feb 2000 12:28:28 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Beta for 4:30AST ... ? 

Long Overdue ;)


On Mon, 21 Feb 2000, Kaare Rasmussen wrote:

> Having been away for some time I'm very anxious to see that there's a 7.0
> release coming very soon. I extracted the TODO list from the CVS (latest update
> February 9).  The only really really big issue as I see it is referential
> integrity. This is big, I admit but why going to 7.0 for this? Or is it because
> it's long overdue (MSVC and stuff)?
> 
> There are other things that must have taken a lot of work, only it's not
> mainstream the same way referential integrity is (PL/Perl and more). I had
> hoped to find outer joins, but look forward to the next release if it will be
> there.
> 
> Maybe I missed something in the TODO list or in the fixed list, but I couldn't
> find VIEWs with UNIONs, which I understand would be solved by a rewrite of the
> rules system.
> 
> ************
> 

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


Mon, 21 Feb 2000 16:40:59 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] TODO list / why 7.0 ?
Kaare Rasmussen <kar@webline.dk> writes:
> This is big, I admit but why going to 7.0 for this? Or is it because
> it's long overdue (MSVC and stuff)?

A number of people thought 6.5 should have been called 7.0 because of
MVCC.  A number of other people thought that this release should be 6.6,
and the next one (which should have outer joins and much better VIEWs
thanks to a redesigned querytree representation) should be 7.0.

I think it's kind of a compromise ;-).

OTOH, if you look less at bullet points on a feature list and more at
reliability and quality of implementation, there's plenty of material
to argue that this indeed deserves to be 7.0.  I think we have made
a quantum jump in our ability to understand and improve the Berkeley
code over the past year --- at least I have, maybe I shouldn't speak
for the other developers.  There have been some pretty significant
improvements under-the-hood, and I think those are going to translate
directly into a more reliable system.

			regards, tom lane

Mon, 21 Feb 2000 17:21:15 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] TODO list / why 7.0 ? 

Working on the Release Announcement now ... Bruce, how accurate is the
current TODO list?  If I go through it looking for all items marked as
'-', I come up with the following list.  Is it missing anything?  I know
not *everything* has to be listed, so I'm more afraid of listing something
that shouldn't then not listing enough ...

The beta1.tar.gz snapshot has been created ... I'll put out an
announcement later tonight once I've heard back on this list, which also
gives some of the mirror sites a chance to sync up, and Vince a chance to
update the web site...

=============================================
RELIABILITY

RESOURCES

   * -Disallow inherited columns with the same name as new columns
   * -Elog() does not free all its memory
   * -spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgr
   * -Recover or force failure when disk space is exhausted(Hiroshi)

PARSER

   * -INSERT INTO ... SELECT with AS columns matching result columns problem
   * -Select a[1] FROM test fails, it needs test.a[1](Tom)
   * -Array index references without table name cause problems [array](Tom)
   * -INSERT ... SELECT ... GROUP BY groups by target columns not source
     columns(Tom)
   * -CREATE TABLE test (a char(5) DEFAULT text '', b int4) fails on
     INSERT(Tom)
   * -UNION with LIMIT fails
   * -CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
   * -CREATE TABLE test(col char(2) DEFAULT user) fails in length
     restriction
   * -mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
   * -SELECT ... UNION ... ORDER BY fails when sort expr not in result list,
     ORDER BY is applied only to the first SELECT
   * -select * from pg_class where oid in (0,-1)
   * -prevent primary key that exceeds max index columns [primary]
   * -SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes
   * -require SELECT DISTINCT target list to have all ORDER BY columns
   * -When using aggregates + GROUP BY, no rows in should yield no rows
     out(Tom)
   * -Allow HAVING to use comparisons that have no aggregates(Tom)
   * -Allow COUNT(DISTINCT col))(TOm)

VIEWS

   * -Views with spaces in view name fail when referenced

MISC

   * -User who can create databases can modify pg_database table(Peter E)
   * -Fix btree to give a useful elog when key > 1/2 (page - overhead)(Tom)
   * -pg_dump should preserve primary key information
   * -database names with spaces fail
   * -insert of 0.0 into DECIMAL(4,4) field fails(Tom)
   * -* Interlock to prevent DROP DATABASE on a database with running
     backendsInterlock to prevent DROP DATABASE on a database with running
     backends

ENHANCEMENTS

URGENT

   * -Add referential integrity(Jan)[primary]
   * -Eliminate limits on query length
   * -Fix memory leak for aggregates(Tom)

ADMIN

   * -Better interface for adding to pg_group(Peter E)
   * -Generate postmaster pid file and remove flock/fcntl lock
     code[flock](Tatsuo)

TYPES

   * -Add BIT, BIT VARYING
   * -Allow pg_descriptions when creating tables
   * -Allow pg_descriptions when creating types, columns, and functions
   * -Allow LOCALE to use indexes in regular expression searches(Tom)
   * -Allow array on int8[](Thomas)
   * -Add index on NUMERIC/DECIMAL type(Jan)
   * -Make Absolutetime/Relativetime int4 because time_t can be int8 on some
     ports
   * -Make type equivalency apply to aggregates

INDEXES

   * -Permissions on indexes, prevent them(Peter E)
   * -Allow indexing of LIKE with localle character sets
   * -Allow indexing of more than eight columns

COMMANDS

   * -Add ALTER TABLE DROP/ALTER COLUMN feature(Peter E)
   * -Move LIKE index optimization handling to the optimizer(Tom)

CLIENTS

   * -Allow flag to control COPY input/output of NULLs
   * -Allow psql \copy to allow delimiters
   * -Add a function to return the last inserted oid, for use in psql
     scripts (Peter E)
   * -Allow psql to print nulls as distinct from "" [null]

MISC

   * -Certain indexes will not shrink, i.e. oid indexes with many
     inserts(Vadim)
   * -Allow WHERE restriction on ctid(Hiroshi)
   * -Allow PQrequestCancel() to terminate when in waiting-for-lock state
   * -Allow subqueries in target list(Tom)
   * -Document/trigger/rule so changes to pgshadow recreate pgpwd
     [pg_shadow]
   * -Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup
   * -Add PL/Perl(Mark Hollomon)
   * -Add option for postgres user have a password by default(Peter E)

PERFORMANCE

FSYNC

   * -Prevent fsync in SELECT-only queries(Vadim)

INDEXES

   * -Convert function(constant) into a constant for index use(Bernard
     Frankpitt)
   * -Make index creation use psort code, because it is now faster(Tom)
   * -Allow creation of sort temp tables > 1 Gig
   * -Create more system table indexes for faster cache lookups
   * -fix indexscan() so it does leak memory by not requiring caller to
     free(Tom)
   * -Improve btbinsrch() to handle equal keys better, remove
     btfirsteq()(Tom)
   * -Allow optimizer to prefer plans that match ORDER BY(Tom)

CACHE

   * -elog() flushes cache, try invalidating just entries from current xact,
     perhaps using invalidation cache

MISC

   * -Fix memory exhaustion when using many OR's [cnfify](Tom)
   * -Process const = const parts of OR clause in separate pass(Bernard
     Frankpitt)
   * -fix memory leak in cache code when non-existant table is referenced In
     WHERE tab1.x=3 AND tab1.x=tab2.y, add tab2.y=3
   * -pass atttypmod through parser in more cases [atttypmod]
   * -remove duplicate type in/out functions for disk and net

SOURCE CODE

   * -Add needed includes and removed unneeded include files(Bruce)
   * -Make configure --enable-debug add -g on compile line
   * -Pre-generate lex and yacc output so not required for install

==================================================
On Mon, 21 Feb 2000, Tom Lane wrote:

> Don Baccus <dhogaza@pacifier.com> writes:
> >> Think we'll have to
> >> leave it unfixed till Thomas gets back.
> 
> > That would be plenty of time to get it in for the real 7.0 release.
> 
> I don't like shipping betas with broken pg_dump; that makes life
> unreasonably difficult for beta testers, if we have to force another
> initdb before release.  So I put in a quick hack solution: don't print
> the column alias list at all unless there is a table alias.  This makes
> the rule's FROM clause conform to ANSI syntax.  If you actually did
> write
> 	create view foo as SELECT alias FROM table table (alias);
> then it will dump as
> 	create view foo as SELECT table.realcolname AS alias FROM table;
> but there's no harm done.  Better solution needed but I'll let Thomas
> provide it.
> 
> And now, it's 4:30 PM AST and we are outta here ... right Marc?
> 
> 			regards, tom lane
> 

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


Mon, 21 Feb 2000 19:57:56 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Beta for 4:30AST ... ? 
At 07:57 PM 2/21/00 -0400, The Hermit Hacker wrote:

>   * -Add referential integrity(Jan)[primary]

This is only PARTIALLY complete:

MATCH FULL and MATCH <unspecified> foreign keys and their related
referential actions are complete.  MATCH PARTIAL isn't in - I'll be
doing that for 7.1.

It doesn't check that the columns referenced in a foreign key
form a primary key or are contrained by UNIQUE in the referenced
table.  This will be checked in 7.1, not sure who will do it (who
ever gets to it first, probably).

Those are the two major user-visible loose ends with this feature.



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Mon, 21 Feb 2000 16:34:48 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Beta for 4:30AST ... ? 
Should be accurate.  I usually make a release list after the feature
freeze/beta starts.

> 
> Working on the Release Announcement now ... Bruce, how accurate is the
> current TODO list?  If I go through it looking for all items marked as
> '-', I come up with the following list.  Is it missing anything?  I know
> not *everything* has to be listed, so I'm more afraid of listing something
> that shouldn't then not listing enough ...
> 
> The beta1.tar.gz snapshot has been created ... I'll put out an
> announcement later tonight once I've heard back on this list, which also
> gives some of the mirror sites a chance to sync up, and Vince a chance to
> update the web site...
> 
> =============================================
> RELIABILITY
> 
> RESOURCES
> 
>    * -Disallow inherited columns with the same name as new columns
>    * -Elog() does not free all its memory
>    * -spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgr
>    * -Recover or force failure when disk space is exhausted(Hiroshi)
> 
> PARSER
> 
>    * -INSERT INTO ... SELECT with AS columns matching result columns problem
>    * -Select a[1] FROM test fails, it needs test.a[1](Tom)
>    * -Array index references without table name cause problems [array](Tom)
>    * -INSERT ... SELECT ... GROUP BY groups by target columns not source
>      columns(Tom)
>    * -CREATE TABLE test (a char(5) DEFAULT text '', b int4) fails on
>      INSERT(Tom)
>    * -UNION with LIMIT fails
>    * -CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
>    * -CREATE TABLE test(col char(2) DEFAULT user) fails in length
>      restriction
>    * -mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
>    * -SELECT ... UNION ... ORDER BY fails when sort expr not in result list,
>      ORDER BY is applied only to the first SELECT
>    * -select * from pg_class where oid in (0,-1)
>    * -prevent primary key that exceeds max index columns [primary]
>    * -SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes
>    * -require SELECT DISTINCT target list to have all ORDER BY columns
>    * -When using aggregates + GROUP BY, no rows in should yield no rows
>      out(Tom)
>    * -Allow HAVING to use comparisons that have no aggregates(Tom)
>    * -Allow COUNT(DISTINCT col))(TOm)
> 
> VIEWS
> 
>    * -Views with spaces in view name fail when referenced
> 
> MISC
> 
>    * -User who can create databases can modify pg_database table(Peter E)
>    * -Fix btree to give a useful elog when key > 1/2 (page - overhead)(Tom)
>    * -pg_dump should preserve primary key information
>    * -database names with spaces fail
>    * -insert of 0.0 into DECIMAL(4,4) field fails(Tom)
>    * -* Interlock to prevent DROP DATABASE on a database with running
>      backendsInterlock to prevent DROP DATABASE on a database with running
>      backends
> 
> ENHANCEMENTS
> 
> URGENT
> 
>    * -Add referential integrity(Jan)[primary]
>    * -Eliminate limits on query length
>    * -Fix memory leak for aggregates(Tom)
> 
> ADMIN
> 
>    * -Better interface for adding to pg_group(Peter E)
>    * -Generate postmaster pid file and remove flock/fcntl lock
>      code[flock](Tatsuo)
> 
> TYPES
> 
>    * -Add BIT, BIT VARYING
>    * -Allow pg_descriptions when creating tables
>    * -Allow pg_descriptions when creating types, columns, and functions
>    * -Allow LOCALE to use indexes in regular expression searches(Tom)
>    * -Allow array on int8[](Thomas)
>    * -Add index on NUMERIC/DECIMAL type(Jan)
>    * -Make Absolutetime/Relativetime int4 because time_t can be int8 on some
>      ports
>    * -Make type equivalency apply to aggregates
> 
> INDEXES
> 
>    * -Permissions on indexes, prevent them(Peter E)
>    * -Allow indexing of LIKE with localle character sets
>    * -Allow indexing of more than eight columns
> 
> COMMANDS
> 
>    * -Add ALTER TABLE DROP/ALTER COLUMN feature(Peter E)
>    * -Move LIKE index optimization handling to the optimizer(Tom)
> 
> CLIENTS
> 
>    * -Allow flag to control COPY input/output of NULLs
>    * -Allow psql \copy to allow delimiters
>    * -Add a function to return the last inserted oid, for use in psql
>      scripts (Peter E)
>    * -Allow psql to print nulls as distinct from "" [null]
> 
> MISC
> 
>    * -Certain indexes will not shrink, i.e. oid indexes with many
>      inserts(Vadim)
>    * -Allow WHERE restriction on ctid(Hiroshi)
>    * -Allow PQrequestCancel() to terminate when in waiting-for-lock state
>    * -Allow subqueries in target list(Tom)
>    * -Document/trigger/rule so changes to pgshadow recreate pgpwd
>      [pg_shadow]
>    * -Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup
>    * -Add PL/Perl(Mark Hollomon)
>    * -Add option for postgres user have a password by default(Peter E)
> 
> PERFORMANCE
> 
> FSYNC
> 
>    * -Prevent fsync in SELECT-only queries(Vadim)
> 
> INDEXES
> 
>    * -Convert function(constant) into a constant for index use(Bernard
>      Frankpitt)
>    * -Make index creation use psort code, because it is now faster(Tom)
>    * -Allow creation of sort temp tables > 1 Gig
>    * -Create more system table indexes for faster cache lookups
>    * -fix indexscan() so it does leak memory by not requiring caller to
>      free(Tom)
>    * -Improve btbinsrch() to handle equal keys better, remove
>      btfirsteq()(Tom)
>    * -Allow optimizer to prefer plans that match ORDER BY(Tom)
> 
> CACHE
> 
>    * -elog() flushes cache, try invalidating just entries from current xact,
>      perhaps using invalidation cache
> 
> MISC
> 
>    * -Fix memory exhaustion when using many OR's [cnfify](Tom)
>    * -Process const = const parts of OR clause in separate pass(Bernard
>      Frankpitt)
>    * -fix memory leak in cache code when non-existant table is referenced In
>      WHERE tab1.x=3 AND tab1.x=tab2.y, add tab2.y=3
>    * -pass atttypmod through parser in more cases [atttypmod]
>    * -remove duplicate type in/out functions for disk and net
> 
> SOURCE CODE
> 
>    * -Add needed includes and removed unneeded include files(Bruce)
>    * -Make configure --enable-debug add -g on compile line
>    * -Pre-generate lex and yacc output so not required for install
> 
> ==================================================
> On Mon, 21 Feb 2000, Tom Lane wrote:
> 
> > Don Baccus <dhogaza@pacifier.com> writes:
> > >> Think we'll have to
> > >> leave it unfixed till Thomas gets back.
> > 
> > > That would be plenty of time to get it in for the real 7.0 release.
> > 
> > I don't like shipping betas with broken pg_dump; that makes life
> > unreasonably difficult for beta testers, if we have to force another
> > initdb before release.  So I put in a quick hack solution: don't print
> > the column alias list at all unless there is a table alias.  This makes
> > the rule's FROM clause conform to ANSI syntax.  If you actually did
> > write
> > 	create view foo as SELECT alias FROM table table (alias);
> > then it will dump as
> > 	create view foo as SELECT table.realcolname AS alias FROM table;
> > but there's no harm done.  Better solution needed but I'll let Thomas
> > provide it.
> > 
> > And now, it's 4:30 PM AST and we are outta here ... right Marc?
> > 
> > 			regards, tom lane
> > 
> 
> Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
> Systems Administrator @ hub.org 
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
> 
> 
> ************
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Mon, 21 Feb 2000 19:53:39 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
> At 07:57 PM 2/21/00 -0400, The Hermit Hacker wrote:
> 
> >   * -Add referential integrity(Jan)[primary]
> 
> This is only PARTIALLY complete:
> 
> MATCH FULL and MATCH <unspecified> foreign keys and their related
> referential actions are complete.  MATCH PARTIAL isn't in - I'll be
> doing that for 7.1.

Added to TODO.

> It doesn't check that the columns referenced in a foreign key
> form a primary key or are contrained by UNIQUE in the referenced
> table.  This will be checked in 7.1, not sure who will do it (who
> ever gets to it first, probably).

Added.  

* Foreign key does not check that columns referenced form a primary key 
  or constrained by UNIQUE

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Mon, 21 Feb 2000 19:57:36 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
> At 07:57 PM 2/21/00 -0400, The Hermit Hacker wrote:
> 
> >   * -Add referential integrity(Jan)[primary]
> 
> This is only PARTIALLY complete:
> 
> MATCH FULL and MATCH <unspecified> foreign keys and their related
> referential actions are complete.  MATCH PARTIAL isn't in - I'll be
> doing that for 7.1.
> 
> It doesn't check that the columns referenced in a foreign key
> form a primary key or are contrained by UNIQUE in the referenced
> table.  This will be checked in 7.1, not sure who will do it (who
> ever gets to it first, probably).
> 
> Those are the two major user-visible loose ends with this feature.

What about ALTER TABLE table DROP CONSTRAINT? I see this:

alter table t1 drop constraint t1_fk cascade;
ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented

Note that we seem to have ALTER TABLE table ADD CONSTRAINT, though.
--
Tatsuo Ishii

Tue, 22 Feb 2000 13:45:39 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Beta for 4:30AST ... ? 
> > 
> > Those are the two major user-visible loose ends with this feature.
> 
> What about ALTER TABLE table DROP CONSTRAINT? I see this:
> 
> alter table t1 drop constraint t1_fk cascade;
> ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented
> 
> Note that we seem to have ALTER TABLE table ADD CONSTRAINT, though.

I thought that was going in.  According to Marc, if it sufficiently
warned users, and required them to type it twice, it would do Peter's
alter table code.  Perhaps Peter decided to wait for 7.1?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Tue, 22 Feb 2000 00:09:11 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
At 01:45 PM 2/22/00 +0900, Tatsuo Ishii wrote:

>> Those are the two major user-visible loose ends with this feature.

>What about ALTER TABLE table DROP CONSTRAINT? I see this:
>
>alter table t1 drop constraint t1_fk cascade;
>ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented
>
>Note that we seem to have ALTER TABLE table ADD CONSTRAINT, though.

"ALTER TABLE ... DROP CONSTRAINT" I view as being a more general
problem not simply restricted to referential integrity.  My comment
was meant to be strictly interpreted within the realm of RI.  Obviously,
general dropping of columns and constraints needs to be solved, but these
aren't RI issues specifically.

And, no, you don't have ALTER TABLE ... ADD CONSTRAINT.  What you have
is the ability to add foreign key constraints only.  When this was
added, we (Stephan Szabo, myself, and Jan Wieck) discussed doing
general constraints, too, but Jan pointed out that we were all busy
with RI-specific stuff and that we should concentrate on those issue.
A good call, IMO, as I was buried in trying to understand "NO ACTION"
and "MATCH <unspecified>" at the same; Stephan was working on pg_dump;
and Jan was really busy with his real job.  I only had one weekend to
pour into implementing the proper semantics for the RI triggers, and
as a result of our decision to concentrate on RI-specific issues was
able to complete the necessary work for fully SQL92 compliant "MATCH
<unspecified>" foreign keys.

However, Stephan's ALTER TABLE ... work to allow you to add foreign
keys should be fairly easy to extend to general constraints, he and
Jan discussed this a couple of weeks ago.

7.1 would seem to be the likely target for this.



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Mon, 21 Feb 2000 21:15:05 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Beta for 4:30AST ... ? 
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented

> I thought that was going in.  According to Marc, if it sufficiently
> warned users, and required them to type it twice, it would do Peter's
> alter table code.  Perhaps Peter decided to wait for 7.1?

I thought the rest of us beat him up until he took it out ;-)

			regards, tom lane

Tue, 22 Feb 2000 00:31:34 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ? 
> "ALTER TABLE ... DROP CONSTRAINT" I view as being a more general
> problem not simply restricted to referential integrity.  My comment
> was meant to be strictly interpreted within the realm of RI.  Obviously,
> general dropping of columns and constraints needs to be solved, but these
> aren't RI issues specifically.

That's ok, as long as stated somewhere in TODO or whatever.

> And, no, you don't have ALTER TABLE ... ADD CONSTRAINT.  What you have
> is the ability to add foreign key constraints only.  When this was

This is more than ok:-) Since without ADD CONSTRAINTS, we could not
define a circular referential integrity at all. Good job!
--
Tatsuo Ishii

Tue, 22 Feb 2000 14:33:59 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Beta for 4:30AST ... ? 
> A number of people thought 6.5 should have been called 7.0 because of
> MVCC.  A number of other people thought that this release should be 6.6,

You know, I actually woke in the middle of the night and said to myself, Why
did you call MVCC for MSVC. My only answer is that it was late, after a 16
hours work day.

> and the next one (which should have outer joins and much better VIEWs
> thanks to a redesigned querytree representation) should be 7.0.

Can't wait for this one. If you throw large objects in also, let's go straight
to 8.0 :-)

> OTOH, if you look less at bullet points on a feature list and more at
> reliability and quality of implementation, there's plenty of material

I didn't try to pick on the development or the state of PostgreSQL. I'm
impressed with the current speed of development and also the number of new
people joining in (you, Peter Eisentraut, maybe more) that relatively easy
understands and becomes productive.

Tue, 22 Feb 2000 06:40:25 +0100
Kaare Rasmussen <kar@webline.dk>
Re: [HACKERS] TODO list / why 7.0 ?
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented
> 
> > I thought that was going in.  According to Marc, if it sufficiently
> > warned users, and required them to type it twice, it would do Peter's
> > alter table code.  Perhaps Peter decided to wait for 7.1?
> 
> I thought the rest of us beat him up until he took it out ;-)

Yes, he was badly beaten up about it, but I felt that the code as is was
pretty good, considering how bad CLUSTER is.  If people are told the
limitations, it could be a win.

I felt that the more advanced features like not using 2x disk space were
quite hard to implement, considering the other TODO items.  Marc agreed
and was going to e-mail him to tell him that with proper user warning,
we wanted the patch.

Do people disagree?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Tue, 22 Feb 2000 00:43:37 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I felt that the more advanced features like not using 2x disk space were
> quite hard to implement, considering the other TODO items.  Marc agreed
> and was going to e-mail him to tell him that with proper user warning,
> we wanted the patch.

> Do people disagree?

Hmmm ... well ... I really don't want to restart that argument, but
I thought the plurality of opinion was that we didn't want it until
a more complete implementation could be provided.

Certainly I'm not enthused about shoehorning it in *after* we've
gone to feature-freeze mode.  If beta means anything around here,
it means "you missed the bus for adding features".

			regards, tom lane

Tue, 22 Feb 2000 00:53:30 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ? 
Don Baccus wrote:
> 
> At 07:57 PM 2/21/00 -0400, The Hermit Hacker wrote:
> 
> >   * -Add referential integrity(Jan)[primary]
> 
> This is only PARTIALLY complete:
> 
> MATCH FULL and MATCH <unspecified> foreign keys and their related
> referential actions are complete.  MATCH PARTIAL isn't in - I'll be
> doing that for 7.1.

Can anyone point me to a written description of the expected
functionality (and maybe limitations) provided by this release of RI? 
I'm not asking for a definition of RI, but rather the status of
*current* (7.0) pgsql RI functionality, i.e., what one should
expect...

Cheers,
Ed Loehr

Tue, 22 Feb 2000 00:34:01 -0600
Ed Loehr <eloehr@austin.rr.com>
Re: [HACKERS] Beta for 4:30AST ... ?
The Hermit Hacker <scrappy@hub.org> writes:
> Working on the Release Announcement now ...

>    * -SELECT ... UNION ... ORDER BY fails when sort expr not in result list,
>      ORDER BY is applied only to the first SELECT

This is still broken AFAIK.  Not sure how it got marked as done.

>    * -Make type equivalency apply to aggregates

IIRC, Peter should get the credit for that one.

>    * -Certain indexes will not shrink, i.e. oid indexes with many
>      inserts(Vadim)

AFAIK that isn't done either.

>    * -Document/trigger/rule so changes to pgshadow recreate pgpwd
>      [pg_shadow]

Peter's work also...

>    * -fix memory leak in cache code when non-existant table is referenced In
>      WHERE tab1.x=3 AND tab1.x=tab2.y, add tab2.y=3

This looks like 2 items got merged somehow.  AFAIK only the first is
done.


Looking at my own notes about completed changes, it sure seems like
there have been one heck of a lot of bugfixes and performance
improvements that don't correspond to anything on the official TODO
list.  It might be worth making some opening remarks along that line
rather than just presenting the checked-off items.

			regards, tom lane

Tue, 22 Feb 2000 01:57:40 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ? 
Tom Lane wrote:
> 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented
> 
> > I thought that was going in.  According to Marc, if it sufficiently
> > warned users, and required them to type it twice, it would do Peter's
> > alter table code.  Perhaps Peter decided to wait for 7.1?
> 
> I thought the rest of us beat him up until he took it out ;-)
> 

Was'nt that DROP COLUMN ? 

Is'nt  DROP CONSTRAINT something completely different ?

AFAIK constraints are not (should not;) be implemented as extra columns, 
even though they look like it in CREATE TABLE clause.

So removing them would actually mean deleting some rows from some system 
table(s). And you don't even have to check the validity of existing data as 
have to when doing ADD CONSTRAINT.

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

Tue, 22 Feb 2000 12:14:39 +0200
Hannu Krosing <hannu@tm.ee>
Re: [HACKERS] Beta for 4:30AST ... ?

On Mon, 21 Feb 2000, Bruce Momjian wrote:

> Should be accurate.  I usually make a release list after the feature
> freeze/beta starts.

 I'am not sure that TODO is accurate. The 7.0 has non-TODO (small) features 
too --> The Oracle compatible TO_CHAR() for date/time, numbers 
(int/float/numeric) formatting and (reverse) TO_DATE() / TO_TIMESTAMP() /
TO_NUMBER() for string to number or data/time conversion. 

Number part (TO_NUMBER() and TO_CHAR()) support locale and allow you convert
number to locale-like number. 

							Karel

PS. for exact changes: "diff -r --new-file  6.5.x  7.0"  :-))


Tue, 22 Feb 2000 11:26:11 +0100 (CET)
Karel Zak - Zakkr <zakkr@zf.jcu.cz>
Re: [HACKERS] Beta for 4:30AST ... ?
On Tue, 22 Feb 2000, Bruce Momjian wrote:

> > What about ALTER TABLE table DROP CONSTRAINT? I see this:

> > Note that we seem to have ALTER TABLE table ADD CONSTRAINT, though.

> Perhaps Peter decided to wait for 7.1?

Yes and no. I never had anything like this. I was afraid to get crossed up
with Jan. Anyway, to add/drop unique constraints create/drop the index. To
add/drop foreign keys, use create/drop constraint trigger(????). To
add/drop check contraints you're on your own. Not so bad all in all.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Tue, 22 Feb 2000 12:58:52 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Beta for 4:30AST ... ?
On Mon, 21 Feb 2000, The Hermit Hacker wrote:

>    * -Add BIT, BIT VARYING

This is currently suffering from BIT rot in contrib. Not really usable.
And we can't squeeze it in until the bootstrap scanner recognizes tokens
with spaces in it. (Does it?)

>    * -Add ALTER TABLE DROP/ALTER COLUMN feature(Peter E)

Since there seems to be some confusion here: What currently exists all
done is ALTER TABLE ALTER COLUMN (which allows you to set and drop
defaults). What does not exist is DROP COLUMN and ADD/DROP CONTRAINT in
its full glory.


If someone cares for accuracy, I also did these:

>    * -pg_dump should preserve primary key information
>    * -Allow flag to control COPY input/output of NULLs
>    * -Allow psql \copy to allow delimiters
>    * -Allow psql to print nulls as distinct from "" [null]
>    * -Make configure --enable-debug add -g on compile line
>    * -Pre-generate lex and yacc output so not required for install
>    * -Make Absolutetime/Relativetime int4 because time_t can be int8 on some ports
>    * -Make type equivalency apply to aggregates

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Tue, 22 Feb 2000 13:07:29 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Beta for 4:30AST ... ? 

>Don Baccus wrote:
>> 
>> At 07:57 PM 2/21/00 -0400, The Hermit Hacker wrote:
>> 
>> >   * -Add referential integrity(Jan)[primary]
>> 
>> This is only PARTIALLY complete:
>> 
>> MATCH FULL and MATCH <unspecified> foreign keys and their related
>> referential actions are complete.  MATCH PARTIAL isn't in - I'll be
>> doing that for 7.1.
>
>Can anyone point me to a written description of the expected
>functionality (and maybe limitations) provided by this release of RI? 
>I'm not asking for a definition of RI, but rather the status of
>*current* (7.0) pgsql RI functionality, i.e., what one should
>expect...

Well, I have some documentation patches currently out for the people
in the FK project, but we haven't gotten that completely finished,
and there are a few subtle differences right now due to some stuff
that we weren't able to get finished, in the meantime, while we're
working on that, I believe the following should sum it up:

* You can make both column and table constraints for foreign key
  constraints.  Currently, column FK constraints may not 
  specify NOT DEFERRABLE or INITIALLY (DEFERRED|IMMEDIATE)
  due to shift/reduce problems in the parser.

* You can only specify MATCH FULL or use MATCH unspecified for 
  the matching types.  MATCH PARTIAL should be in 7.1.

* If you do not specify the referenced columns, it will look for
  the primary key on the referenced table, but if you specify
  referenced columns, it will not guarantee that those columns
  actually are a foreign key or have a unique constraint upon 
  them.

* It does not enforce uniqueness of constraint names.  (A big
  reason that I didn't also due an FK version of ALTER TABLE
  DROP CONSTRAINT)  Theoretically the constraint names for
  unique, check and fk constraints must all be checked to
  guarantee uniqueness.  Also, constraint names made by the
  system must also not conflict with existing constraint
  names, and probably should not fail, but instead have
  a way of forcing a unique name.

* ALTER TABLE ADD CONSTRAINT will allow the adding of any
  foreign key constraint that would be legal in the 
  table constraint context (hopefully).  It also checks
  the current table data and refuses to add the constraint
  if the constraint would be immediately violated (again
  hopefully -- it's worked for our tests, but let's see
  what happens in the real world).

* pg_dump will dump CREATE CONSTRAINT TRIGGER statements for
  tables with foreign key constraints.  In data only dumps,
  pg_dump does a little bit of magic with the system catalogs
  to turn off all triggers on user defined tables and turn
  them back on at the end.  It currently does not enforce
  that the data in between does not violate the constraint.
  This is unfortunate, but we didn't come up with a good
  way to do this for possibly circular fk constraints and
  still be able to deal with the possibility that the user
  may have changed the constraints since the dump, since
  it's data-only.

[Anything you can think of to add to this Don?]

Stephan


Tue, 22 Feb 2000 07:15:20 -0500
sszabo@bigpanda.com
Re: [HACKERS] Beta for 4:30AST ... ? 

>> At 07:57 PM 2/21/00 -0400, The Hermit Hacker wrote:
>> 
>> >   * -Add referential integrity(Jan)[primary]
>> 
>> This is only PARTIALLY complete:
>> 
>> MATCH FULL and MATCH <unspecified> foreign keys and their related
>> referential actions are complete.  MATCH PARTIAL isn't in - I'll be
>> doing that for 7.1.
>> 
>> It doesn't check that the columns referenced in a foreign key
>> form a primary key or are contrained by UNIQUE in the referenced
>> table.  This will be checked in 7.1, not sure who will do it (who
>> ever gets to it first, probably).
>> 
>> Those are the two major user-visible loose ends with this feature.
>
>What about ALTER TABLE table DROP CONSTRAINT? I see this:
>
>alter table t1 drop constraint t1_fk cascade;
>ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented
>
>Note that we seem to have ALTER TABLE table ADD CONSTRAINT, though.

I looked at drop constraint for the foreign key case while I was doing
add constraint, but right now the system doesn't generate unique 
constraint names (although it should) so drop constraint could be
dangerous if you're not careful.  Yeah, let me drop this RI constraint
'<unknown>' that I just created... oops...  And unfortunately, to be 
really compliant, all of the constraint names have to be unique, and
I really didn't want to hack something in that was going to make it
harder to do it right later.  

Stephan

Tue, 22 Feb 2000 07:21:28 -0500
sszabo@bigpanda.com
Re: [HACKERS] Beta for 4:30AST ... ? 
On Tue, 22 Feb 2000 sszabo@bigpanda.com wrote:

> * pg_dump will dump CREATE CONSTRAINT TRIGGER statements for
>   tables with foreign key constraints.  In data only dumps,
>   pg_dump does a little bit of magic with the system catalogs
>   to turn off all triggers on user defined tables and turn
>   them back on at the end.

Whatever happened to the idea of a SET command for this? IIRC, SQL already
has a contraint related set command (for deferring, etc.). Why not
overload that to turn off foreign keys? I could imagine that being useful
for people developing database schemas.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Tue, 22 Feb 2000 13:49:41 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Beta for 4:30AST ... ? 
On Tue, 22 Feb 2000, Bruce Momjian wrote:

> > > 
> > > Those are the two major user-visible loose ends with this feature.
> > 
> > What about ALTER TABLE table DROP CONSTRAINT? I see this:
> > 
> > alter table t1 drop constraint t1_fk cascade;
> > ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented
> > 
> > Note that we seem to have ALTER TABLE table ADD CONSTRAINT, though.
> 
> I thought that was going in.  According to Marc, if it sufficiently
> warned users, and required them to type it twice, it would do Peter's
> alter table code.  Perhaps Peter decided to wait for 7.1?

Ummm...I don't recall ever talking about DROP CONTRAINT *raised eyebrow*



Tue, 22 Feb 2000 09:09:47 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Beta for 4:30AST ... ?
On Tue, 22 Feb 2000, Bruce Momjian wrote:

> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > >> ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented
> > 
> > > I thought that was going in.  According to Marc, if it sufficiently
> > > warned users, and required them to type it twice, it would do Peter's
> > > alter table code.  Perhaps Peter decided to wait for 7.1?
> > 
> > I thought the rest of us beat him up until he took it out ;-)
> 
> Yes, he was badly beaten up about it, but I felt that the code as is was
> pretty good, considering how bad CLUSTER is.  If people are told the
> limitations, it could be a win.

god, I hate this argument: we did it badly for CLUSTER, so its okay to do
it badly here too :(

> I felt that the more advanced features like not using 2x disk space were
> quite hard to implement, considering the other TODO items.  Marc agreed
> and was going to e-mail him to tell him that with proper user warning,
> we wanted the patch.

"agreed" is a weak word in this sense ... :)

> Do people disagree?

I don't like it, and think with some effort, it could be done better, and
will stick with that ... but if "its the best that can be done" ...
*shrug*

But, after 7.0 is released ... I still believe that the outstanding issues
were such that putting it into 7.0 was a bad thing ...


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


Tue, 22 Feb 2000 09:12:35 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Beta for 4:30AST ... ?
On Tue, 22 Feb 2000, Kaare Rasmussen wrote:

> Can't wait for this one. If you throw large objects in also, let's go straight
> to 8.0 :-)

IMHO, 8.0 should be reserved for the first SQL Entry level (direct entry)
compliant release. A recent survey lead me to believe that, if we really
make a push, this is only two or three releases away.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Tue, 22 Feb 2000 14:14:23 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] TODO list / why 7.0 ?
> The Hermit Hacker <scrappy@hub.org> writes:
> > Working on the Release Announcement now ...
> 
> >    * -SELECT ... UNION ... ORDER BY fails when sort expr not in result list,
> >      ORDER BY is applied only to the first SELECT
> 
> This is still broken AFAIK.  Not sure how it got marked as done.

Not marked as done on my copy.

> 
> >    * -Make type equivalency apply to aggregates
> 
> IIRC, Peter should get the credit for that one.

Added.

> 
> >    * -Certain indexes will not shrink, i.e. oid indexes with many
> >      inserts(Vadim)
> 
> AFAIK that isn't done either.
> 

Fixed.

> >    * -Document/trigger/rule so changes to pgshadow recreate pgpwd
> >      [pg_shadow]

Added.

> 
> Peter's work also...
> 
> >    * -fix memory leak in cache code when non-existant table is referenced In
> >      WHERE tab1.x=3 AND tab1.x=tab2.y, add tab2.y=3
> 
> This looks like 2 items got merged somehow.  AFAIK only the first is
> done.

Split.

> 
> 
> Looking at my own notes about completed changes, it sure seems like
> there have been one heck of a lot of bugfixes and performance
> improvements that don't correspond to anything on the official TODO
> list.  It might be worth making some opening remarks along that line
> rather than just presenting the checked-off items.

Yes, that is what I will do by going through CVS.  It is better for Marc
to just specify the release and wait for my full release blurb coming in
a few days.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Tue, 22 Feb 2000 09:07:11 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
> On Tue, 22 Feb 2000, Bruce Momjian wrote:
> 
> > > What about ALTER TABLE table DROP CONSTRAINT? I see this:
> 
> > > Note that we seem to have ALTER TABLE table ADD CONSTRAINT, though.
> 
> > Perhaps Peter decided to wait for 7.1?
> 


I was speaking off DROP COLUMN.  Sorry to have added to the confusion.


> Yes and no. I never had anything like this. I was afraid to get crossed up
> with Jan. Anyway, to add/drop unique constraints create/drop the index. To
> add/drop foreign keys, use create/drop constraint trigger(????). To
> add/drop check contraints you're on your own. Not so bad all in all.
> 
> -- 
> Peter Eisentraut                  Sernanders vaeg 10:115
> peter_e@gmx.net                   75262 Uppsala
> http://yi.org/peter-e/            Sweden
> 
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Tue, 22 Feb 2000 09:11:52 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
> On Mon, 21 Feb 2000, The Hermit Hacker wrote:
> 
> >    * -Add BIT, BIT VARYING
> 
> This is currently suffering from BIT rot in contrib. Not really usable.
> And we can't squeeze it in until the bootstrap scanner recognizes tokens
> with spaces in it. (Does it?)

Aw man, I promised to put that into the main tree.  Is it not usable? 
Spaces?

> 
> >    * -Add ALTER TABLE DROP/ALTER COLUMN feature(Peter E)
> 
> Since there seems to be some confusion here: What currently exists all
> done is ALTER TABLE ALTER COLUMN (which allows you to set and drop
> defaults). What does not exist is DROP COLUMN and ADD/DROP CONTRAINT in
> its full glory.
> 
> 
> If someone cares for accuracy, I also did these:
> 
> >    * -pg_dump should preserve primary key information
> >    * -Allow flag to control COPY input/output of NULLs
> >    * -Allow psql \copy to allow delimiters
> >    * -Allow psql to print nulls as distinct from "" [null]
> >    * -Make configure --enable-debug add -g on compile line
> >    * -Pre-generate lex and yacc output so not required for install
> >    * -Make Absolutetime/Relativetime int4 because time_t can be int8 on some ports
> >    * -Make type equivalency apply to aggregates

TODO updated.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Tue, 22 Feb 2000 09:15:54 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
> On Tue, 22 Feb 2000, Bruce Momjian wrote:
> 
> > > > 
> > > > Those are the two major user-visible loose ends with this feature.
> > > 
> > > What about ALTER TABLE table DROP CONSTRAINT? I see this:
> > > 
> > > alter table t1 drop constraint t1_fk cascade;
> > > ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented
> > > 
> > > Note that we seem to have ALTER TABLE table ADD CONSTRAINT, though.
> > 
> > I thought that was going in.  According to Marc, if it sufficiently
> > warned users, and required them to type it twice, it would do Peter's
> > alter table code.  Perhaps Peter decided to wait for 7.1?
> 
> Ummm...I don't recall ever talking about DROP CONTRAINT *raised eyebrow*

Again, I am a goof.  I was thinking of DROP COLUMN.
-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Tue, 22 Feb 2000 09:18:02 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
At 02:33 PM 2/22/00 +0900, Tatsuo Ishii wrote:

>> And, no, you don't have ALTER TABLE ... ADD CONSTRAINT.  What you have
>> is the ability to add foreign key constraints only.  When this was
>
>This is more than ok:-) Since without ADD CONSTRAINTS, we could not
>define a circular referential integrity at all. Good job!

Stephan Szabo did that particular piece of work, and, yeah, good job
indeed, Stephan!



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Tue, 22 Feb 2000 06:43:32 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Beta for 4:30AST ... ? 
At 12:34 AM 2/22/00 -0600, Ed Loehr wrote:

>Can anyone point me to a written description of the expected
>functionality (and maybe limitations) provided by this release of RI? 
>I'm not asking for a definition of RI, but rather the status of
>*current* (7.0) pgsql RI functionality, i.e., what one should
>expect...

Jan was working on docs, and I think maybe Stephan Szabo?  But Jan
seems to have dropped out of site, again - total immersion at work
is my diagnosis.  I actually enjoy doing documentation but I'm swamped
at the moment, too.

In short...if you read Date's SQL primer, all foreign key functionality
is there EXCEPT "MATCH PARTIAL" and the check on the target columns being
constrained UNIQUE or PRIMARY KEY.  We also need to assign a unique name
to the foreign key constraint if you don't give one (right now they're
just listed "unnamed") because otherwise you don't know which of several
foreign key constraints failed unless you explicitly name them yourself.

(I forgot that one in my previous note).




- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Tue, 22 Feb 2000 06:55:43 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Beta for 4:30AST ... ?
On Tue, 22 Feb 2000, Bruce Momjian wrote:

> 
> Yes, that is what I will do by going through CVS.  It is better for Marc
> to just specify the release and wait for my full release blurb coming in
> a few days.

'K, will do that ... I also wanted to give a day for the miror sites to
pick up the beta ...



Tue, 22 Feb 2000 11:02:42 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Beta for 4:30AST ... ?
At 12:58 PM 2/22/00 +0100, Peter Eisentraut wrote:

>Yes and no. I never had anything like this. I was afraid to get crossed up
>with Jan. Anyway, to add/drop unique constraints create/drop the index. To
>add/drop foreign keys, use create/drop constraint trigger(????).

To add a foreign key try "alter table foo add foreign key(column)
references bar".

You'll like what you see.




- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Tue, 22 Feb 2000 07:09:54 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Beta for 4:30AST ... ?
At 07:15 AM 2/22/00 -0500, sszabo@bigpanda.com wrote:

>* You can make both column and table constraints for foreign key
>  constraints.  Currently, column FK constraints may not 
>  specify NOT DEFERRABLE or INITIALLY (DEFERRED|IMMEDIATE)
>  due to shift/reduce problems in the parser.

Fixed by Thomas, I believe...though I've not tested it myself.



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Tue, 22 Feb 2000 07:12:40 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Beta for 4:30AST ... ? 
On Tue, 22 Feb 2000, The Hermit Hacker wrote:

> On Tue, 22 Feb 2000, Bruce Momjian wrote:
> 
> > 
> > Yes, that is what I will do by going through CVS.  It is better for Marc
> > to just specify the release and wait for my full release blurb coming in
> > a few days.
> 
> 'K, will do that ... I also wanted to give a day for the miror sites to
> pick up the beta ...

Anyone have a **SHORT** list of highlights for the initial website
announcement?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
   128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Tue, 22 Feb 2000 10:46:06 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] Beta for 4:30AST ... ?
> On Tue, 22 Feb 2000, Bruce Momjian wrote:
> 
> > 
> > Yes, that is what I will do by going through CVS.  It is better for Marc
> > to just specify the release and wait for my full release blurb coming in
> > a few days.
> 
> 'K, will do that ... I also wanted to give a day for the miror sites to
> pick up the beta ...
> 

The cvs logs since 6.5.0 are 108k lines, and the merged file with
duplicates removed is 21k lines.  Man, that's big.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Tue, 22 Feb 2000 10:51:47 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
Working on that now.  Give me until the end of the day.  I will have the
usual paragraphs and a long list.  Looks like no billable work today.


> On Tue, 22 Feb 2000, The Hermit Hacker wrote:
> 
> > On Tue, 22 Feb 2000, Bruce Momjian wrote:
> > 
> > > 
> > > Yes, that is what I will do by going through CVS.  It is better for Marc
> > > to just specify the release and wait for my full release blurb coming in
> > > a few days.
> > 
> > 'K, will do that ... I also wanted to give a day for the miror sites to
> > pick up the beta ...
> 
> Anyone have a **SHORT** list of highlights for the initial website
> announcement?
> 
> Vince.
> -- 
> ==========================================================================
> Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
>    128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
>         Online Campground Directory    http://www.camping-usa.com
>        Online Giftshop Superstore    http://www.cloudninegifts.com
> ==========================================================================
> 
> 
> 
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Tue, 22 Feb 2000 11:24:10 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
On Tue, 22 Feb 2000, Bruce Momjian wrote:

> Working on that now.  Give me until the end of the day.  I will have the
> usual paragraphs and a long list.  Looks like no billable work today.

Ok.  I'm using Marc's announcement for the announcements and news, when
I get yours I'll replace the one on news and put in a pointer.

Vince.

> 
> 
> > On Tue, 22 Feb 2000, The Hermit Hacker wrote:
> > 
> > > On Tue, 22 Feb 2000, Bruce Momjian wrote:
> > > 
> > > > 
> > > > Yes, that is what I will do by going through CVS.  It is better for Marc
> > > > to just specify the release and wait for my full release blurb coming in
> > > > a few days.
> > > 
> > > 'K, will do that ... I also wanted to give a day for the miror sites to
> > > pick up the beta ...
> > 
> > Anyone have a **SHORT** list of highlights for the initial website
> > announcement?
> > 
> > Vince.
> > -- 
> > ==========================================================================
> > Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
> >    128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
> >         Online Campground Directory    http://www.camping-usa.com
> >        Online Giftshop Superstore    http://www.cloudninegifts.com
> > ==========================================================================
> > 
> > 
> > 
> > 
> 
> 
> 

-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
   128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Tue, 22 Feb 2000 11:35:11 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] Beta for 4:30AST ... ?
On 2000-02-22, Bruce Momjian mentioned:

> > On Mon, 21 Feb 2000, The Hermit Hacker wrote:
> > 
> > >    * -Add BIT, BIT VARYING
> > 
> > This is currently suffering from BIT rot in contrib. Not really usable.
> > And we can't squeeze it in until the bootstrap scanner recognizes tokens
> > with spaces in it. (Does it?)
> 
> Aw man, I promised to put that into the main tree.  Is it not usable? 
> Spaces?

Somehow you have to do something similar to
insert OID = 9999 ( bit varying PGUID 1 1 t b t \054 0 0 bitvaryingin ... )

And no, naming the type bit_varying internally is not an acceptable
answer. ;) We might want to start thinking about this item before national
character comes our way. (Or just document the solution, if it already
exists.)

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



Wed, 23 Feb 2000 02:20:49 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] Beta for 4:30AST ... ?
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> On 2000-02-22, Bruce Momjian mentioned:
> 
> > > On Mon, 21 Feb 2000, The Hermit Hacker wrote:
> > > 
> > > >    * -Add BIT, BIT VARYING
> > > 
> > > This is currently suffering from BIT rot in contrib. Not really usable.
> > > And we can't squeeze it in until the bootstrap scanner recognizes tokens
> > > with spaces in it. (Does it?)
> > 
> > Aw man, I promised to put that into the main tree.  Is it not usable? 
> > Spaces?
> 
> Somehow you have to do something similar to
> insert OID = 9999 ( bit varying PGUID 1 1 t b t \054 0 0 bitvaryingin ... )
> 
> And no, naming the type bit_varying internally is not an acceptable
> answer. ;) We might want to start thinking about this item before national
> character comes our way. (Or just document the solution, if it already
> exists.)

Huh, I still don't get it.  What is the matter with that insert?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Tue, 22 Feb 2000 20:30:18 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Somehow you have to do something similar to
>> insert OID = 9999 ( bit varying PGUID 1 1 t b t \054 0 0 bitvaryingin ... )

> Huh, I still don't get it.  What is the matter with that insert?

The space in the type name is gonna confuse things.

>> And no, naming the type bit_varying internally is not an acceptable
>> answer. ;) We might want to start thinking about this item before national
>> character comes our way. (Or just document the solution, if it already
>> exists.)

AFAICS the solution would have to be similar to what we already do for
CHARACTER VARYING: parse the type declaration specially in gram.y,
and translate it to an internal type name.

gram.y already knows about NATIONAL CHARACTER [ VARYING ] too, BTW.
Seems to just translate it into bpchar or varchar :-( ... but the
syntax problem is solved.

			regards, tom lane

Wed, 23 Feb 2000 01:14:31 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ? 
On Wed, 23 Feb 2000, Tom Lane wrote:

> >> insert OID = 9999 ( bit varying PGUID 1 1 t b t \054 0 0 bitvaryingin ... )

> The space in the type name is gonna confuse things.

> AFAICS the solution would have to be similar to what we already do for
> CHARACTER VARYING: parse the type declaration specially in gram.y,
> and translate it to an internal type name.

Those are only workarounds on the backend level though. Every new hack
like this will require fixing every client applicatiion to translate that
type right. It's fine with CHARACTER VARYING, because VARCHAR is an
official alias (although it's not the real type name, mind you), but there
is no VARBIT or NVARCHAR. It seems that allowing something like

	bit\ varying

in the bootstrap scanner will solve the problem where it's being caused.
Internal type names should go away, not accumulate. ;)


-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Wed, 23 Feb 2000 13:54:42 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Beta for 4:30AST ... ? 
I am still going through the CVS logs, and I can already say that this
release will have more updated items than any previous release.  We can
blame Tom Lane for most of this.  :-)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Wed, 23 Feb 2000 11:51:56 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
> I am still going through the CVS logs, and I can already say that this
> release will have more updated items than any previous release.  We can
> blame Tom Lane for most of this.  :-)

Let me cast blame on Peter Eisentraut too.  ;-)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Wed, 23 Feb 2000 12:08:14 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
> > >> insert OID = 9999 ( bit varying PGUID 1 1 ...
> > The space in the type name is gonna confuse things.
> > AFAICS the solution would have to be similar to what we already do for
> > CHARACTER VARYING: parse the type declaration specially in gram.y,
> > and translate it to an internal type name.
> Those are only workarounds on the backend level though. Every new hack
> like this will require fixing every client applicatiion to translate that
> type right. It's fine with CHARACTER VARYING, because VARCHAR is an
> official alias (although it's not the real type name, mind you), but there
> is no VARBIT or NVARCHAR. It seems that allowing something like
>         bit\ varying
> in the bootstrap scanner will solve the problem where it's being caused.
> Internal type names should go away, not accumulate. ;)

I'm not sure that I agree that multi-word character types are required
internally. Somehow that seems to just push the problem of
SQL92-specific syntax to another part of the code. We could just as
easily (?) translate *every* "xxx VARYING" to "varxxx" on input, and
do the inverse on output or pg_dump.

                      - Thomas

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

Mon, 28 Feb 2000 08:51:50 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Beta for 4:30AST ... ?
> > in the bootstrap scanner will solve the problem where it's being caused.
> > Internal type names should go away, not accumulate. ;)
> 
> I'm not sure that I agree that multi-word character types are required
> internally. Somehow that seems to just push the problem of
> SQL92-specific syntax to another part of the code. We could just as
> easily (?) translate *every* "xxx VARYING" to "varxxx" on input, and
> do the inverse on output or pg_dump.

Yes, seems we just don't want to do that during beta.  I forgot about
this item I had promised.  Sorry.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Mon, 28 Feb 2000 04:11:51 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> It seems that allowing something like
>> bit\ varying
>> in the bootstrap scanner will solve the problem where it's being caused.
>> Internal type names should go away, not accumulate. ;)

> I'm not sure that I agree that multi-word character types are required
> internally. Somehow that seems to just push the problem of
> SQL92-specific syntax to another part of the code.

It doesn't push it anywhere: you still have the problem that the parser
expects type names to be single tokens, not multiple tokens, and any
exceptions need to be special-cased in the grammar.  We can handle that
for the few multi-word type names decreed by SQL92.  But allowing
internal type names to be multi-word as well will create more headaches
in other places (even if it doesn't make the grammar ambiguous, which
it well might).  I think the bootstrap scanner would just be the tip of
the iceberg...

			regards, tom lane

Mon, 28 Feb 2000 09:46:10 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ? 
Tom Lane writes:

> > I'm not sure that I agree that multi-word character types are required
> > internally. Somehow that seems to just push the problem of
> > SQL92-specific syntax to another part of the code.
> 
> It doesn't push it anywhere: you still have the problem that the parser
> expects type names to be single tokens, not multiple tokens, and any
> exceptions need to be special-cased in the grammar.  We can handle that
> for the few multi-word type names decreed by SQL92.  But allowing
> internal type names to be multi-word as well will create more headaches
> in other places (even if it doesn't make the grammar ambiguous, which
> it well might).  I think the bootstrap scanner would just be the tip of
> the iceberg...

I don't get that. What's wrong with (conceptually) having a rule like
this:

Type: TIME { $$ = "time"; }
    | REAL { $$ = "real"; }
    | CHAR { $$ = "char"; }
    | BIT VARYING { $$ = "bit varying"; }
    | Id { $$ = $1; } /* potentially user-defined type */

This is pretty much what it does now, only that the right side of $$ =
"..." never contains a space, which is purely coincidental.

The list of multi-token SQL types is very finite. Any user-defined
types with spaces would have to use the usual double-quote mechanism. The
advantage of the above is that once I have "bit varying" in the catalog, I
don't have to worry mangling it when I want to get it out.

I don't understand where you get the notion of "multiworded internal
types" from. All that would be required is concatenating a set of specific
token combinations to one and you're done. Once that is done, no one
worries about the fact that there is in fact a space in the type name.

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Tue, 29 Feb 2000 00:19:22 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] Beta for 4:30AST ... ? 
Thomas Lockhart writes:

> I'm not sure that I agree that multi-word character types are required
> internally. Somehow that seems to just push the problem of
> SQL92-specific syntax to another part of the code. We could just as
> easily (?) translate *every* "xxx VARYING" to "varxxx" on input, and
> do the inverse on output or pg_dump.

On the one hand I propose what seems like editing a handful of lines in
the bootstrap scanner (an internal interface) to solve this problem once
and for all. What you are proposing is that every client interface (libpq,
SPI, PL du jour, who knows) will have to know a list of the latest hacks
of type conversions in the backend. And it would be very confusing to
people defining user types like "varxxx".

You can define user types with spaces in them (note to self: better check
this), so I don't see why we should hack around it. What do you plan on
doing with DOUBLE PRECISION and TIME WITH TIMEZONE?

Confused ...

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Tue, 29 Feb 2000 00:20:05 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] Beta for 4:30AST ... ?
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> Thomas Lockhart writes:
> 
> > I'm not sure that I agree that multi-word character types are required
> > internally. Somehow that seems to just push the problem of
> > SQL92-specific syntax to another part of the code. We could just as
> > easily (?) translate *every* "xxx VARYING" to "varxxx" on input, and
> > do the inverse on output or pg_dump.
> 
> On the one hand I propose what seems like editing a handful of lines in
> the bootstrap scanner (an internal interface) to solve this problem once
> and for all. What you are proposing is that every client interface (libpq,
> SPI, PL du jour, who knows) will have to know a list of the latest hacks

libpq doesn't know anything about syntax.  It is mostly gram.y files.  I
think ecpg is the only other one that needs the fix.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Mon, 28 Feb 2000 18:30:26 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ?
(sorry for the delay in responding...)

> You can define user types with spaces in them (note to self: better check
> this), so I don't see why we should hack around it. What do you plan on
> doing with DOUBLE PRECISION and TIME WITH TIMEZONE?

DOUBLE PRECISION is already supported, and becomes float8. TIME WITH
TIMEZONE is currently transparently swallowed to become equivalent to
TIME, for reasons spelled out in the docs. I've toyed with the idea of
implementing the SQL92 version of it, but it is *so* useless and brain
damaged (cf Date et al) that I (at least so far) cannot bring myself
to do so. But if and when, it might be ztime internally.

It is unlikely that we can transparently parse two-word types in
gram.y without explicit support for it. Just adding IDENT IDENT to
simple types leads to a shift/reduce conflict.

                    - Thomas

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

Wed, 01 Mar 2000 06:50:45 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Beta for 4:30AST ... ?
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> It is unlikely that we can transparently parse two-word types in
> gram.y without explicit support for it. Just adding IDENT IDENT to
> simple types leads to a shift/reduce conflict.

Right.  I think what Peter is actually suggesting is that BIT VARYING
(which must be special-cased in gram.y) could be equivalent to
"bit varying" (as a quoted identifier, that works already in most
places, and arguably should work everywhere).  There's a certain amount
of intellectual cleanliness in that.  OTOH, it's not apparent that it's
really any *better* than `varbit' or your choice of other space-free
internal names.

If SQL92 were a moving target then I'd be concerned about having to
track the special cases in a lot of bits of code ... but it's not
a moving target.

			regards, tom lane

Wed, 01 Mar 2000 01:53:37 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Beta for 4:30AST ... ? 
On Wed, 1 Mar 2000, Thomas Lockhart wrote:

> It is unlikely that we can transparently parse two-word types in
> gram.y without explicit support for it. Just adding IDENT IDENT to
> simple types leads to a shift/reduce conflict.

I am not saying that we should support two token types in general. Only
the SQL types. We already do that anyway, like (kind of)

Type: CHARACTER VARYING { $$ = "varchar"; }
      | etc.

All I'm saying is that we add

      | BIT VARYING { $$ = "bit varying"; }

No problem so far, right? Especially, if this is dumped out, then it
becomes bit varying without any extra effort.

The only problem is that with the current syntax the bootstrap scanner
cannot insert fields that contain spaces. Simple fix there, and we're
done.

To be clear again: I am not vaguely suggesting that we support any
multi-token types. I am just saying that we shouldn't introduce any new
and unnecessary external/internal type discrepancies just because the
bootstrap scanner is stupid.

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Wed, 1 Mar 2000 15:47:11 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Beta for 4:30AST ... ?
On Wed, 1 Mar 2000, Thomas Lockhart wrote:

> TIME WITH
> TIMEZONE is currently transparently swallowed to become equivalent to
> TIME, for reasons spelled out in the docs. I've toyed with the idea of
> implementing the SQL92 version of it, but it is *so* useless and brain
> damaged (cf Date et al) that I (at least so far) cannot bring myself
> to do so. But if and when, it might be ztime internally.

I've read the documentation and SQL92 and I can't see anything wrong with
it. Care to enlighten me?

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Wed, 1 Mar 2000 15:48:38 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Beta for 4:30AST ... ?
On Wed, 1 Mar 2000, Tom Lane wrote:

> Right.  I think what Peter is actually suggesting is that BIT VARYING
> (which must be special-cased in gram.y) could be equivalent to
> "bit varying" (as a quoted identifier, that works already in most
> places, and arguably should work everywhere).  There's a certain amount
> of intellectual cleanliness in that.

{Grin} That's exactly what I wanted.

> OTOH, it's not apparent that it's really any *better* than `varbit' or
> your choice of other space-free internal names.

It's better because then you don't need any special casing when you
provide the type back to the client. And it's better because you don't
need to remember that "foo" is really "bar" internally. And it's better
because it wouldn't disallow users from defining "varbit" themselves with
the non-obvious error message that it already exists. (Okay, the last is a
weak reason, but it is one.) Finally, it's better because it already
works, with only a minor change in the bootstrap scanner necessary.

> If SQL92 were a moving target then I'd be concerned about having to
> track the special cases in a lot of bits of code ... but it's not
> a moving target.

But PostgreSQL is a moving target in all regards. Where would you want to
do the endless internal/external type conversions on the way to the
client. In pg_dump? In psql? In libpq? In the server communications code?
Make a view around pg_type? How about nowhere and we just do the above?

Special cases suck. ;)

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Wed, 1 Mar 2000 16:15:26 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Beta for 4:30AST ... ? 
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> All I'm saying is that we add

>       | BIT VARYING { $$ = "bit varying"; }

> No problem so far, right? Especially, if this is dumped out, then it
> becomes bit varying without any extra effort.

Well, no, it becomes "bit varying", *with* quotes, if the dumper is
not broken.  (Unless we special-case the dumper to know that this
particular typename doesn't need to be quoted despite its embedded
space --- but that's what you hoped to avoid.)  So there's no automatic
way of producing a completely SQL-compliant dump for this type name,
and that removes what would otherwise be (IMHO) the strongest argument
for making the internal name be "bit varying" and not "varbit" or
whatever.

A much more significant problem for this particular datatype is that it
requires special syntax regardless, namely a length spec like the ones
for char and varchar:

         <bit string type> ::=
                BIT [ <left paren> <length> <right paren> ]
              | BIT VARYING <left paren> <length> <right paren>

Currently, char and numeric (the existing types that need length
specifications) have to be special-cased everywhere in order to
parse or append the length info.  I foresee the same will be needed
for bit and bit varying.  If you can find a way to avoid
that special-case logic, I'll get a lot more excited about not
having to treat "bit varying" as a special-case name.

			regards, tom lane

Wed, 01 Mar 2000 10:52:07 -0500
Tom Lane <tgl@sss.pgh.pa.us>
BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
> I've read the documentation and SQL92 and I can't see anything wrong with
> it. Care to enlighten me?

SQL92 "TIME WITH TIMEZONE" carries a single numeric timezone with each
time field. It has no provision for daylight savings time. And a time
field without an associated date has imho no possibility for a
meaningful "timezone" or a meaningful usage. So the definitions and
features are completely at odds with typical date and time usage and
requirements in many countries around the world.

Date et al discuss this, and have the same opinion, so the gods are
with me on this one ;)

                    - Thomas

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

Wed, 01 Mar 2000 16:49:36 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Beta for 4:30AST ... ?
On Wed, 1 Mar 2000, Tom Lane wrote:

> Well, no, it becomes "bit varying", *with* quotes, if the dumper is
> not broken.

I know, but consider psql and others just using plain libpq functionality.

> for bit and bit varying.  If you can find a way to avoid
> that special-case logic, I'll get a lot more excited about not
> having to treat "bit varying" as a special-case name.

NOOOOOOOOOOOOOO. I'm not trying to treat "bit varying" as a special case
name. I want to treat it as a normal name. There's absolutely no
difference whether the pg_type entry for the type represented by the
tokens BIT VARYING is "varbit", "bit varying", or "foo". I'm just saying
that the second would be more obvious and convenient, but that it would
require a small fix somewhere.

We're not going to allow any usertype(x) syntax in this life time, are we,
and the fact remains that we have to parse the reserved-word SQL types
separately. But this has all nothing to do with what I'm saying. Why
doesn't anyone understand me?

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Wed, 1 Mar 2000 19:35:44 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> NOOOOOOOOOOOOOO. I'm not trying to treat "bit varying" as a special case
> name. I want to treat it as a normal name. There's absolutely no
> difference whether the pg_type entry for the type represented by the
> tokens BIT VARYING is "varbit", "bit varying", or "foo". I'm just saying
> that the second would be more obvious and convenient, but that it would
> require a small fix somewhere.

OK, fair enough, but the thing is: is the bootstrap parser the only
place that will have to be changed to make this possible?  I doubt it.
The fix may not be as small as you expect.

There's another issue, which is that the routines that implement
operations for a particular type are generally named after the type's
internal name.  I trust you are not going to propose that we find a way
to put spaces into C function names ;-).  It seems to me that the
confusion created by having support code named differently from the
type's internal name is just as bad as having the internal name
different from the external name.

This being the case, it seems like "bit_varying" might be a reasonable
compromise for the internal name, and that should work already...

			regards, tom lane

Wed, 01 Mar 2000 14:58:07 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST) 
> There's another issue, which is that the routines that implement
> operations for a particular type are generally named after the type's
> internal name.  I trust you are not going to propose that we find a way
> to put spaces into C function names ;-).  It seems to me that the
> confusion created by having support code named differently from the
> type's internal name is just as bad as having the internal name
> different from the external name.
> 
> This being the case, it seems like "bit_varying" might be a reasonable
> compromise for the internal name, and that should work already...

Having only one type with an underscore seems like a mistake. We already
don't have internal names matching.  I would just make it bit, bitvar,
or maybe varbit.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Wed, 1 Mar 2000 15:26:59 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
> ... But this has all nothing to do with what I'm saying. Why
> doesn't anyone understand me?

Uh, could be that we're all a bunch of idiots. Of course, I'd prefer
some other explanation... :))

                    - Thomas

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

Thu, 02 Mar 2000 06:29:10 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
Tom Lane writes:

> There's another issue, which is that the routines that implement
> operations for a particular type are generally named after the type's
> internal name.  I trust you are not going to propose that we find a way
> to put spaces into C function names ;-).  It seems to me that the
> confusion created by having support code named differently from the
> type's internal name is just as bad as having the internal name
> different from the external name.
> 
> This being the case, it seems like "bit_varying" might be a reasonable
> compromise for the internal name, and that should work already...

Okay, that's the first reasonable argument I've heard in this thread, and
I'll buy it. Since correspondence between internal type names and function
names *is* achievable without hacks we might as well go for this one.

In turn I'm thinking that it might be nice to have a backend function like
format_type(name[, int4]) that formats an internal type and any size
modifier for client consumption, like

	format_type('varchar', 8)     => "CHARACTER VARYING(8)"
	format_type('my type')        => "\"my type\""
	format_type('numeric', {xxx}) => "NUMERIC(9,2)"

That could put an end to keeping track of backend implementation details
in psql, pg_dump, and friends.

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Sat, 4 Mar 2000 18:06:37 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST) 
Peter Eisentraut <peter_e@gmx.net> writes:
> In turn I'm thinking that it might be nice to have a backend function like
> format_type(name[, int4]) that formats an internal type and any size
> modifier for client consumption, like

> 	format_type('varchar', 8)     => "CHARACTER VARYING(8)"
> 	format_type('my type')        => "\"my type\""
> 	format_type('numeric', {xxx}) => "NUMERIC(9,2)"

> That could put an end to keeping track of backend implementation details
> in psql, pg_dump, and friends.

Seems like a good idea, though I think it's a bit late in the 7.0 cycle
for such a change.  Maybe for 7.1?

Also, I assume you mean that the int4 arg would be the typmod value ---
your examples are not right in detail for that interpretation.

			regards, tom lane

Tue, 07 Mar 2000 01:58:22 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST) 
> > format_type(name[, int4]) that formats an internal type and any size
> > modifier for client consumption, like
> >       format_type('varchar', 8)     => "CHARACTER VARYING(8)"
> >       format_type('my type')        => "\"my type\""
> >       format_type('numeric', {xxx}) => "NUMERIC(9,2)"

Ooh, that *is* a good idea (though the exact name of the function may
evolve)! Sorry I missed seeing it in Peter's earlier postings.

Funny how we can go for years banging our heads on an issue and have
something like this (ie a good idea on the subject) pop up out of the
blue.

Presumably we would include a function taking the conversion the other
direction too...

                     - Thomas

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

Tue, 07 Mar 2000 15:47:04 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
> Okay, that's the first reasonable argument I've heard in this thread, and
> I'll buy it. Since correspondence between internal type names and function
> names *is* achievable without hacks we might as well go for this one.
> 
> In turn I'm thinking that it might be nice to have a backend function like
> format_type(name[, int4]) that formats an internal type and any size
> modifier for client consumption, like
> 
> 	format_type('varchar', 8)     => "CHARACTER VARYING(8)"
> 	format_type('my type')        => "\"my type\""
> 	format_type('numeric', {xxx}) => "NUMERIC(9,2)"
> 
> That could put an end to keeping track of backend implementation details
> in psql, pg_dump, and friends.

Great idea!  psql and pg_dump can use it.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Tue, 7 Mar 2000 18:25:49 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
> > > format_type(name[, int4]) that formats an internal type and any size
> > > modifier for client consumption, like
> > >       format_type('varchar', 8)     => "CHARACTER VARYING(8)"
> > >       format_type('my type')        => "\"my type\""
> > >       format_type('numeric', {xxx}) => "NUMERIC(9,2)"
> 
> Ooh, that *is* a good idea (though the exact name of the function may
> evolve)! Sorry I missed seeing it in Peter's earlier postings.
> 
> Funny how we can go for years banging our heads on an issue and have
> something like this (ie a good idea on the subject) pop up out of the
> blue.
> 
> Presumably we would include a function taking the conversion the other
> direction too...

Not sure it is really needed.  We already to the translation in gram.y.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Tue, 7 Mar 2000 20:30:17 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
> > Presumably we would include a function taking the conversion the other
> > direction too...
> Not sure it is really needed.  We already to the translation in gram.y.

Right. And we should expose that routine as mentioned. Otherwise it is
just hidden behavior.

                  - Thomas

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

Wed, 08 Mar 2000 05:45:05 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)