Re: [HACKERS] Upgrades for 6.4.1 - Mailing list pgsql-hackers
From | Thomas G. Lockhart |
---|---|
Subject | Re: [HACKERS] Upgrades for 6.4.1 |
Date | |
Msg-id | 3679FF70.FBDCB083@alumni.caltech.edu Whole thread Raw |
In response to | Upgrades for 6.4.1 (Bruce Momjian <maillist@candle.pha.pa.us>) |
Responses |
Re: [HACKERS] Upgrades for 6.4.1
Re: [HACKERS] Upgrades for 6.4.1 |
List | pgsql-hackers |
> * Two and three dimmensional arrays display improperly, missing {} My simple test case shows as many brackets as I expect. Can someone remember what this was about? Or at least take the extra "m" out of "dimensional"? :) > * SELECT * FROM table WHERE int4_column = '1' fails postgres=> select * from x where i = '1'; i - 1 (1 row) Works now, no? The new type coersion stuff... > * default char() value not to full length crashes server on some OS's postgres=> create table x (c char(10) default 'abc'); CREATE postgres=> insert into x default values; INSERT 901452 1 postgres=> select * from x; c --- abc (1 row) I distinctly recall fixing this, or watching someone else do it... > * SELECT DISTINCT i FROM dtest ORDER BY j generates strange output In my simple test case, it orders by j, then only shows i. Is that strange? What did it used to do? The current behavior makes sense, if it should be allowed at all... > * views with spaces in view name fail when referenced Still a problem. > * plpgsql does not handle quoted mixed-case identifiers Ditto. > * do not allow bpchar column creation without length ? char is now the same as char(1), which should solve this, if that's what it means... > ENHANCEMENTS > ------------ > * Add full ANSI SQL capabilities > * add OUTER joins, left and right (Thomas) > * add INTERSECTS, SUBTRACTS(Stephan) > * add temporary tables > * add sql3 recursive unions > * add the concept of dataspaces > * add DECIMAL, NUMERIC, DOUBLE PRECISION, BIT, BIT VARYING We've got DOUBLE PRECISION, DECIMAL, and NUMERIC (the latter two are brain-damaged though) > * add CONSTRAINT Already here, from Vadim. > * Full set of text operations and functions > * word searches, concat,max() on text, char Not sure about "word searches", others are done. v6.4.1 will require a dump/reload to find min/max for string types. In fact, can someone test to make sure it is ok that I added these to the pg_aggregate system table? And a couple of support functions to pg_proc? Since they weren't available before, and since everything else still works, I thought it might be OK to include them. But I can rip them out of the system tables if that would be best for v6.4.1. > * Add word index for text fields, maybe with trigrams, i.e.: > * ' (cat | dog) & ! fox ' meaning text has cat aor dog, but not fox How is this different from the "word searches" above? > * Allow INSERT INTO ... SELECT to convert column types Probably does. The new type coersion stuff :) > * remove non-standard types from the system, and make them loadable This made the ToDo list, but I'm not sure we want to do it. Native types still have a few advantages over loadable types, and our types are one of our strongest features... > * Allow variable casts with BETWEEN 'today'::asbtime AND 'today'::abstime postgres=> select 'yes' where 'now'::datetime between 'today'::datetime and 'tomorrow'::datetime; ?column? -------- yes (1 row) What did this item mean?? > * Change all references of Postgres to PostgreSQL, including binary > names I've standardized all Postgres docs to use "Postgres" within the body, and "PostgreSQL" for titles and in the introduction. > * Change LOCK tablename to LOCK TABLE tablename(?) Both syntaxes are now legal and accepted. > * Generate error on CREATE OPERATOR of ~~, ~ and and ~* ? Because gram.y mucks around with them? > * Allow constraint NULL just as we honor NOT NULL Fundamental yacc problem with this as I recall. Gives rise to shift/reduce problems since it is ambiguous with other uses of "NULL" in the same area. > * do autocommit so always in a transaction block This is already the case, right? Every statement has an implicit begin/end around it, unless it is within an explicit begin/end. Or does this mean something else? > * no min/max for oid type Fixed. New type coersion stuff. > * remove un-needed conversion functions ? An explicit conversion function is always/usually faster than one which requires multiple steps. > DOCUMENTATION > ------------- > * Add keyword list to documentation, already in /tools Done. In the User's Guide chapter on "Syntax". > CHANGES IN THE 6.4.1 RELEASE > ---------------------------- > Add pg_dump -N flag to force double quotes around identifiers. This is > the default (Thomas) in case you have room :) > Fix test for table existance to allow mixed-case and whitespace in > the table name Ditto. At least when combined with Billy's fixes to make a complete set. > Fix for creating tables with constraints when table name is mixed-case(Billy) > Fixes for mixed-case table names(Billy) These all sure sound similar... > contrib/linux/postgres.init.csh/sh fix (Thomas) > Change exp() behavior to generate error on underflow (Tom), right? > Timezone fixes(Tom) ? Not sure we see an improvement yet, if this is the date->datetime conversion problem reported by Oleg. > Use implicit type coersion for matching DEFAULT values (Thomas) but wasn't this mentioned above somewhere? Maybe not... - Tom
pgsql-hackers by date: