[HACKERS] Wishlist updates
Hello, Currently on the wishlist [1] we have the following items as posponed: * WITH RECURSIVE hierarchical queries (Gregory Stark) * SQL:2003 windowing queries (Gavin) * Fix permissions properly on custom GUC vars (Andrew Dunstan) * Create a mechanism for plperl to load modules safely (Andrew Dunstan) * Notification payload messages (Andrew Dunstan) * Better handling of partitioning (Nikhils) I have already moved updatable views to the newly created 8.4 wishlist [2]. Please let me know if any item is infact not posponed or should be moved to the 8.4 wishlist. regards, Lukas [1] http://developer.postgresql.org/index.php/Todo:WishlistFor83 [2] http://developer.postgresql.org/index.php/Todo:WishlistFor84 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Server-side support of all encodings
Tatsuo Ishii [EMAIL PROTECTED] writes: I think the best way to proceed is probably to fix this in HEAD but not back-patch it. During a dump and reload the encoding can be corrected to something safe. Ok. Shall I go ahead and remove JOHAB in HEAD? +1 for me. regards, tom lane Done. BTW, do we have to modify pg_dump or pg_restore so that it can automatically adjust JOHAB to UTF8 (it's the only safe encoding compatible with JOHAB)? I'm not sure it's worth the trouble. Maybe documenting in the release note is enough? I guess that there is 0 users who are using JOHAB. -- Tatsuo Ishii SRA OSS, Inc. Japan ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Wishlist updates
Lukas Kahwe Smith wrote: * Fix permissions properly on custom GUC vars (Andrew Dunstan) * Create a mechanism for plperl to load modules safely (Andrew Dunstan) * Notification payload messages (Andrew Dunstan) Unfortunately none of these got done. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Replacement of readline by libedit in PostgreSQL 8.1.x
Hi all, In 8.2.x version of postgres, there is a configuration switch --with-libedit-preferred prefer BSD Libedit over GNU Readline. However, I don't see this switch in 8.1.x. Since people still use 8.1.x version, is there any plan to back-port this feature? If so, I like to work on this. Thanks Dhanaraj ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Replacement of readline by libedit in PostgreSQL 8.1.x
Dhanaraj M wrote: Hi all, In 8.2.x version of postgres, there is a configuration switch --with-libedit-preferred prefer BSD Libedit over GNU Readline. However, I don't see this switch in 8.1.x. Since people still use 8.1.x version, is there any plan to back-port this feature? If so, I like to work on this. Policy is that we don't backport features. That is one of the ways in which we guarantee stability in the released branches. IIRC there are ways to build earlier releases with libedit. Note that psql is the only place where this is used. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Server-side support of all encodings
Tatsuo Ishii [EMAIL PROTECTED] writes: BTW, do we have to modify pg_dump or pg_restore so that it can automatically adjust JOHAB to UTF8 (it's the only safe encoding compatible with JOHAB)? I'm not sure it's worth the trouble. Maybe documenting in the release note is enough? Do we actually need to do anything? Dumps taken in client_encoding JOHAB could exist regardless of the source server_encoding --- the same is true of other client-only encodings. Such dumps should load fine into a UTF8 server_encoding database, as long as we have the right conversion available. I can imagine someone wanting to take a dump in a client-only encoding for other reasons (export of the data to somewhere else, say) so I don't think pg_dump should try to prevent it. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Makefile patch to make gcov work on Postgres contrib modules
Greg Stark wrote: Perhaps the flags need to be in a separate variable instead of CFLAGS specifically advertised to ensure the flags will show up in both compile and linking lines. CFLAGS ordinarily does show up in both of these places. Where it doesn't, it should be added. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] RESET command seems pretty disjointed now
The current documentation for RESET exhibits a certain lack of, um,
intellectual cohesiveness:
Name
RESET -- restore the value of a run-time parameter to the default value
Synopsis
RESET configuration_parameter
RESET ALL
RESET { PLANS | SESSION | TEMP | TEMPORARY }
That one-line summary has got approximately zip to do with the newly
added options; as does most of the Description section. At the very
least this manual page needs an extensive rewrite. But I wonder whether
the real problem isn't that we chose a bad name for the new commands.
Is there another keyword we could use instead of RESET? A concrete
objection to the current state of affairs is that absolutely anyone,
looking at this set of options with no prior knowledge of PG, would
expect that RESET ALL subsumes all the other cases.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[HACKERS] Build-Problem with pgc.c on OSX 10.4
Hi When I try to build CVS HEAD on OSX 10.4, compiling src/interfaces/ecpg/preproc/preproc.c fails with: In file included from preproc.y:6951: pgc.l:3:20: error: config.h: No such file or directory In file included from pgc.l:28, from preproc.y:6951: preproc.h:996: error: conflicting types for 'base_yylloc' y.tab.c:18673: error: previous declaration of 'base_yylloc' was here In file included from preproc.y:6951: pgc.l:43: error: 'MAX_PARSE_BUFFER' undeclared here (not in a function) If I delete pgc.c, it is rebuilt automatically, and then preproc.c compiles just fine. I'm using gcc 4.0.1, flex 2.5.4 and bison 2.3 greetings, Florian Pflug ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Build-Problem with pgc.c on OSX 10.4
Florian G. Pflug [EMAIL PROTECTED] writes: When I try to build CVS HEAD on OSX 10.4, compiling src/interfaces/ecpg/preproc/preproc.c fails with: ... If I delete pgc.c, it is rebuilt automatically, and then preproc.c compiles just fine. ... I'm using gcc 4.0.1, flex 2.5.4 and bison 2.3 Perhaps you changed bison versions and didn't force a rebuild? Those line numbers don't seem to sync up with my copies of the derived files. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] SoC Students/Projects selected
All, Our seven students and projects have been officially announced by Google: http://code.google.com/soc/postgres/about.html Column-level privilege implementation for PostgreSQL by Guodong Liu, mentored by Andrew Dunstan ER diagraming tool for pgAdmin by Euler Taveira de Oliveira, mentored by David Page Implementing support for read-only queries on PITR slaves by Florian Pflug, mentored by Simon Riggs Full Text Search support in PostgreSQL GUI Tools by Ivan Zolotukhin, mentored by Oleg Bartunov Autovacuum Scheduling by Germán Poó-Caamaño, mentored by Alvaro HERRERA Muñoz Integrity check algorithm for data files by Robert Mach, mentored by Zdenek Kotala [pgUnitTest] Query and stored procedure unit tests for PostgreSQL by Mickael Deloison, mentored by Mark Wong This means that we'll have some new beginning hackers on this list very soon. Please treat them well! These can be our future major contributors (aside from Florian, who already is one). Now, while each of these students has an assigned mentor, that doesn't mean other people shouldn't help. If you're interested in their work, please pitch in. Note that we'll also be using the pgsql-students mailing list for discussions about SoC itself. Unfortunately, we only got ONE proposal to work on the buildfarm, and that one was snagged by another project. So I'm going to be proposing that we use SPI funds to get the Buildfarm work done; if anyone knows a likely candidate, speak up. As last year, if we'd had more slots from Google and more mentors we'd have taken quite a few more projects. Here's a few which may be of strong interest to one or more of the companies involved in PostgresQL; ping me if someone wants a summer intern: -- Implement modification of postgresql.conf file values via an SQL API -- Optimizing Aggregate Queries over Joins of Multiple Relations -- Command line tool for dump PostgreSQL data file structure -- Asynchronous IO support for PostgreSQL -- PostgreSQL Zeroconf integration -- SQL Compliance Flagger -- AssoRow, an algebraic operator and SQL primitive for mining association rules -- Ajax Database Monitoring Widgets --Josh Berkus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] RESET command seems pretty disjointed now
Tom Lane wrote:
The current documentation for RESET exhibits a certain lack of, um,
intellectual cohesiveness:
Name
RESET -- restore the value of a run-time parameter to the default value
Synopsis
RESET configuration_parameter
RESET ALL
RESET { PLANS | SESSION | TEMP | TEMPORARY }
That one-line summary has got approximately zip to do with the newly
added options; as does most of the Description section. At the very
least this manual page needs an extensive rewrite. But I wonder whether
the real problem isn't that we chose a bad name for the new commands.
Is there another keyword we could use instead of RESET? A concrete
objection to the current state of affairs is that absolutely anyone,
looking at this set of options with no prior knowledge of PG, would
expect that RESET ALL subsumes all the other cases.
Maybe DISCARD for the plans etc might be more intuitive than extending
RESET?
Mark
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Build-Problem with pgc.c on OSX 10.4
Tom Lane wrote: Florian G. Pflug [EMAIL PROTECTED] writes: When I try to build CVS HEAD on OSX 10.4, compiling src/interfaces/ecpg/preproc/preproc.c fails with: ... If I delete pgc.c, it is rebuilt automatically, and then preproc.c compiles just fine. ... I'm using gcc 4.0.1, flex 2.5.4 and bison 2.3 Perhaps you changed bison versions and didn't force a rebuild? Those line numbers don't seem to sync up with my copies of the derived files. I just realized that this file isn't even in the postgresql CVS repo. But it _is_ part of the SVN mirror at https://projects.commandprompt.com/public/pgsql/repo. The version that shows up in the trunk of the SVN repo is the revision 1.5 from CVS (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/preproc/Attic/pgc.c?rev=1.5;content-type=text%2Fplain;hideattic=0) This is the same as https://projects.commandprompt.com/public/pgsql/repo/trunk/pgsql/src/interfaces/ecpg/preproc/pgc.c modulo the expansion of the $Header macro. Seems to be a bug in the CVS-SVN conversion process... greetings, Florian Pflug ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
