PostgreSQL Weekly News - May 7th 2003 - Mailing list pgsql-announce
From | Robert Treat |
---|---|
Subject | PostgreSQL Weekly News - May 7th 2003 |
Date | |
Msg-id | 1052335164.30185.431.camel@camel Whole thread Raw |
List | pgsql-announce |
== PostgreSQL Weekly News - May 7th 2003 == There's been some discussion of pushing back the 7.4 release schedule 1 month in order to accommodate some of the major new development going on. While this is the direction things are leaning toward, a final decision hasn't been reached yet, but I'll report in more detail on it next week. That said, a 7.3.3 release should be coming "real soon now" so be ready for an official announcement of that in the next week or two as well. Tom Lane stated that he feels that enough of the Front End / Back End structure is in place that some front end development could begin on it. Additions this week include some additional portal and memory management infrastructure for extended query protocol. Both plannable queries and utility commands are now always executed within Portals, which have been revamped so that they can handle the load (they used to be good only for single SELECT queries). The query protocol was extended for parse, bind, execute, and describe FE/BE messages, though it's only been lightly tested as yet. Another new feature implemented is that RowDescription now identifies the column by table OID and column number, if it's a simple column reference. The display of eventual result RowDescription (if any) to the output of Describe on a prepared statement was also added. It is now ensured that an Execute operation can't send tuples in cases where Describe would claim that no tuples will be returned (This only affects SELECTs added to non-SELECT base queries by rewrite rules) We also saw the restructuring of command destination handling so that we pass around DestReceiver pointers instead of just CommandDest values. The DestReceiver is made at the point where the destination is selected, rather than deep inside the executor. This cleans up the original implementation and makes it easy to support retrieving results from utility statements inside portals. What does all this mean? Well, you can now do fun things like Bind and Execute a FETCH or EXPLAIN command, and it'll all work as expected. Win32 development has hit some snags with fork() and exec() support, but development continues there as well. Bruce Momjian hopes to have a good estimate of the amount of work that still needs to be done sometime over the weekend. In the mean time, there is now the ability to dump/read non-default GUC values for use by exec'ed backends, handling of clog structure in shared memory in exec() case, and pass shared memory id and socket descriptor number on command line for fork/exec. Some other changes along these lines are changing of the alternate database location patch to test for symlink support before allowing it (like on win32), some renaming of internal variables for consistency, and reorder of non-default variable loading until PGDATA is defined. Some other miscellaneous fixes that should be noted include Michael Meskes continued work on ecpg, including fixing a double definition of ecpg_compat_mode, adding a rfmtlong compatibility function, adding an option to force ecpg to parse files included via '#include', and some additional informix compatibility stuff. Tom did some clean up of plpgsql's lexer so that yylineno and yymore are not used. This avoids 'input buffer overflow' failure on long literals, improves performance, gives the right answer for line position in functions containing multi-line literals, and suppresses some annoying compiler warnings. Speaking of cleanups, mergeclause pathkey allocation was cleaned up, some erroneous space calculations in dumpProcLangs (per report from Oliver Prenant) were fixed and and off-by-one space calculation in ReadToc was fixed. ExecGetTupType() was removed in favor of the much simpler ExecGetResultType(), which essentially does the same thing. We also saw a few changes to time oriented data handling, some of which was related to some recent discussions on the -general list. Now when a TIMESTAMP, TIME, or INTERVAL precision is specified larger than our implementation limits, a NOTICE is issued and we use the max supported value. Previously this would have resorted in an error, but the change was needed to allow easy porting from pre-7.3 releases where the limits were higher. We also now allow 60 seconds fields of TIMESTAMP, TIME, or INTERVAL input values. This is actually appropriate for spec compliance and will also help in porting from older pg_dump files. And some final things worth mentioning; we now accept GLOBAL TEMP/ TEMPORARY as a synonym for TEMPORARY as the SQL92's GLOBAL temp tables are closer to what we have than their local ones. Peter Eisentraut has also reported that he has committed in what he feels are the last rounds of his reference page editing work. == PostgreSQL Product News == @Road Launches DirectData 2.1 http://www.directionsmag.com/pressreleases.php?press_id=7007 Igalia releases first public release of Fisterra: Open Source ERP http://www.gnomedesktop.org/article.php?sid=1091&mode=thread&order=0 == PostgreSQL In the News == Users Take Open-Source Databases for a Spin http://www.newsfactor.com/perl/story/21460.html == Upcoming Events == PostgreSQL Conference 2003: Tokyo, Japan: May 17 Japan PostgreSQL Users Group will have a technical conference focusing on PostgreSQL performance tuning and enterprise use. http://www.postgresql.jp/ Fenasoft Brasil Software Week: Sao Paulo, Brazil: May 27-30 dbExperts will have a PostgreSQL demonstration http://www.dbexperts.com.br/noticias/mostraNoticia?id=55 Open Source Conference: Portland, Oregon: July 7-11 A PostgreSQL track is available this year http://conferences.oreillynet.com/os2003 == PostgreSQL Weekly News - May 7th 2003 == Don't forget to read Elein Mustain's Weekly Summary of the PostgreSQL General Mailing List http://www.varlena.com/GeneralBits/ On the Web: http://www.postgresql.org http://advocacy.postgresql.org
pgsql-announce by date: