Thread: Beta for 4:30AST ... ?
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
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
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 Serviceand other goodies at http://donb.photo.net.
> 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, Pennsylvania19026
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
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 Serviceand other goodies at http://donb.photo.net.
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 Serviceand other goodies at http://donb.photo.net.
> 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, Pennsylvania19026
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
> 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, Pennsylvania19026
> 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, Pennsylvania19026
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
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 Serviceand other goodies at http://donb.photo.net.
> 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, Pennsylvania19026
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 Serviceand other goodies at http://donb.photo.net.
> 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.
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.
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
writecreate view foo as SELECT alias FROM table table (alias);
then it will dump ascreate 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
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 Serviceand other goodies at http://donb.photo.net.
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
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
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
stuckproblem 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
BYgroups 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(colchar(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
onlyto 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
haveall ORDER BY columns * -When using aggregates + GROUP BY, no rows in should yield no rows out(Tom) * -Allow
HAVINGto 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 *
-insertof 0.0 into DECIMAL(4,4) field fails(Tom) * -* Interlock to prevent DROP DATABASE on a database with running
backendsInterlockto 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
int8on 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
indexingof 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
returnthe 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
doubleunlinking and double opens, cleanup * -Add PL/Perl(Mark Hollomon) * -Add option for postgres user have a
passwordby 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
forfaster 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
ANDtab1.x=tab2.y, add tab2.y=3 * -pass atttypmod through parser in more cases [atttypmod] * -remove duplicate type
in/outfunctions 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
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 Serviceand other goodies at http://donb.photo.net.
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,
Pennsylvania19026
> 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, Pennsylvania19026
> 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
> > > > 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, Pennsylvania19026
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 Serviceand other goodies at http://donb.photo.net.
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
> "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
> 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, Pennsylvania19026
> 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.
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
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
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
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
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" :-))
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
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
>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 specifyreferenced columns, it will not guarantee that those columns actually are a foreign key or have a unique constraintupon them. * It does not enforce uniqueness of constraint names. (A big reason that I didn't also due an FK version of ALTER TABLEDROP CONSTRAINT) Theoretically the constraint names for unique, check and fk constraints must all be checked to guaranteeuniqueness. Also, constraint names made by the system must also not conflict with existing constraint names, andprobably 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 constraintcontext (hopefully). It also checks the current table data and refuses to add the constraint if the constraintwould be immediately violated (again hopefully -- it's worked for our tests, but let's see what happens in thereal world). * pg_dump will dump CREATE CONSTRAINT TRIGGER statements for tables with foreign key constraints. In data only dumps, pg_dumpdoes a little bit of magic with the system catalogs to turn off all triggers on user defined tables and turn themback on at the end. It currently does not enforce that the data in between does not violate the constraint. This isunfortunate, but we didn't come up with a good way to do this for possibly circular fk constraints and still be able todeal 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
>> 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
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
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*
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
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
> 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, Pennsylvania19026
> 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, Pennsylvania19026
> 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, Pennsylvania19026
> 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, Pennsylvania19026
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 ...
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 Serviceand other goodies at http://donb.photo.net.
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 Serviceand other goodies at http://donb.photo.net.
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 Serviceand other goodies at http://donb.photo.net.
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 Serviceand other goodies at http://donb.photo.net.
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/moor less at Pop4 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> 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, Pennsylvania19026
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, Pennsylvania19026
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/moor less at Pop4 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
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
[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, Pennsylvania19026
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
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
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, Pennsylvania19026
> 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, Pennsylvania19026
> > >> 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
> > 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, Pennsylvania19026
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
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
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
[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, Pennsylvania19026
(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
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
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
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
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
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
> 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
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
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
> 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, Pennsylvania19026
> ... 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
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
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
> > 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
> 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,
Pennsylvania19026
> > > 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,
Pennsylvania19026
> > 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