[PATCHES] Minor pedantry for help text
Attached is a patch that makes some minor changes to the text emitted by
the new help command. Previous output:
postgres=# help
You are using psql, the command-line interface to PostgreSQL.
\? for psql help
\h or \help for SQL help
\g or ; to execute a query
\q to quit psql
\copyright to view the copyright
postgres=#
New output:
postgres=# help
You are using psql, the command-line interface to PostgreSQL.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
postgres=#
The newlines in the previous text were inconsistent with psql error
message style elsewhere, aside from being distracting. The advice on
commands to enter next was also just emitted, without actually telling
the user that these are possible inputs. Essentially the text was a
regression from the text we've always used in the startup banner, so I
just re-instituted the old text.
-Neil, doing his best to suppress his aesthetic objection to having
help be valid psql input in the first place
*** a/src/bin/psql/mainloop.c
--- b/src/bin/psql/mainloop.c
***
*** 177,188 MainLoop(FILE *source)
(line[4] == '\0' || line[4] == ';' || isspace((unsigned char) line[4])))
{
free(line);
! puts(_(\nYou are using psql, the command-line interface to PostgreSQL.));
! puts(_(\t\\? for psql help));
! puts(_(\t\\h or \\help for SQL help\n));
! puts(_(\t\\g or \;\ to execute a query));
! puts(_(\t\\q to quit psql\n));
! puts(_(\t\\copyright to view the copyright\n));
fflush(stdout);
continue;
--- 177,188
(line[4] == '\0' || line[4] == ';' || isspace((unsigned char) line[4])))
{
free(line);
! puts(_(You are using psql, the command-line interface to PostgreSQL.));
! printf(_(Type: \\copyright for distribution terms\n
! \\h for help with SQL commands\n
! \\? for help with psql commands\n
! \\g or terminate with semicolon to execute query\n
! \\q to quit\n));
fflush(stdout);
continue;
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] minor ts_type.h comment fix
These should read TSQuery, not TSVector, no? -- Jan Urbanski GPG key ID: E583D7D2 ouden estin *** src/include/tsearch/ts_type.h --- src/include/tsearch/ts_type.h 2008-06-09 23:41:26.0 +0200 *** *** 239,248 */ #define COMPUTESIZE(size, lenofoperand) ( HDRSIZETQ + (size) * sizeof(QueryItem) + (lenofoperand) ) ! /* Returns a pointer to the first QueryItem in a TSVector */ #define GETQUERY(x) ((QueryItem*)( (char*)(x)+HDRSIZETQ )) ! /* Returns a pointer to the beginning of operands in a TSVector */ #define GETOPERAND(x) ( (char*)GETQUERY(x) + ((TSQuery)(x))-size * sizeof(QueryItem) ) /* --- 239,248 */ #define COMPUTESIZE(size, lenofoperand) ( HDRSIZETQ + (size) * sizeof(QueryItem) + (lenofoperand) ) ! /* Returns a pointer to the first QueryItem in a TSQuery */ #define GETQUERY(x) ((QueryItem*)( (char*)(x)+HDRSIZETQ )) ! /* Returns a pointer to the beginning of operands in a TSQuery */ #define GETOPERAND(x) ( (char*)GETQUERY(x) + ((TSQuery)(x))-size * sizeof(QueryItem) ) /* -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] SQL: table function support
On Tue, 2008-06-03 at 13:03 +0200, Pavel Stehule wrote: this patch add support of table functions syntax like ANSI SQL 2003. I'm not necessarily opposed to this, but I wonder if we really need *more* syntax variants for declaring set-returning functions. The existing patchwork of features is confusing enough as it is... -Neil -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Tentative patch for making DROP put dependency info in DETAIL
There was some discussion a few days ago about making dependency.c emit dependency reports in the same style that pg_shdepend.c does, viz a lot of DETAIL lines on a single message instead of separate NOTICE messages. Attached is a tentative patch that does that. See the regression-test diffs for samples of what the output looks like. I'm not entirely sure whether I like the results better than what we have. Opinions anyone? There are some cases where it seems clearly better, eg the sequence.out changes, but in a lot of others it doesn't seem much better. One particular case of interest is in truncate.out, where the table-at-a-time implementation of DROP TABLE is clearly exposed by the fact that you get multiple NOTICEs. I wonder if it would be worth refactoring the code so that a multiple-object DROP is implemented via performMultipleDeletions(). This would have more than just cosmetic advantages: it would no longer matter what order you listed the tables in. But the refactoring required looks bigger and more tedious than I want to tackle right now. I also want to note that we've historically had the code report auto-cascade drops as DEBUG2 messages. I tried to merge those reports into the main one but it was a complete mess :-( because the client and server-log messages might have different numbers of entries depending on their log-level settings. Almost the first case I tried favored me with NOTICE: drop cascades to 0 other object(s) DETAIL: reported to the client (with the server log of course saying something different). So I gave up and left that behavior separate. Comments? Should we do this, or leave things alone? regards, tom lane binLODlX7W7vf.bin Description: dependency-notices-1.patch.gz -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] SQL: table function support
Neil Conway [EMAIL PROTECTED] writes: On Tue, 2008-06-03 at 13:03 +0200, Pavel Stehule wrote: this patch add support of table functions syntax like ANSI SQL 2003. I'm not necessarily opposed to this, but I wonder if we really need *more* syntax variants for declaring set-returning functions. I've been saying right along that we don't. The proposed patch adds no measurable new functionality; its only reason to live is standards compliance, and I'm not convinced that's worth the confusion. Our implementation of functions is (and always will be) far enough away from the standard that notational issues like this are hardly the top of the problem list for someone wishing to import a spec-compliant function. (It's also worth asking where the import is coming from. Who implements the spec syntax anyway? DB2 maybe, but when was the last time we heard from anyone trying to migrate from DB2 to PG?) regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] SQL: table function support
Tom Lane escribió: (It's also worth asking where the import is coming from. Who implements the spec syntax anyway? DB2 maybe, but when was the last time we heard from anyone trying to migrate from DB2 to PG?) Sourceforge? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] SQL: table function support
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane escribió: (It's also worth asking where the import is coming from. Who implements the spec syntax anyway? DB2 maybe, but when was the last time we heard from anyone trying to migrate from DB2 to PG?) Sourceforge? They gave up on us years ago :-( regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] SQL: table function support
2008/6/10 Tom Lane [EMAIL PROTECTED]: Neil Conway [EMAIL PROTECTED] writes: On Tue, 2008-06-03 at 13:03 +0200, Pavel Stehule wrote: this patch add support of table functions syntax like ANSI SQL 2003. I'm not necessarily opposed to this, but I wonder if we really need *more* syntax variants for declaring set-returning functions. I've been saying right along that we don't. The proposed patch adds no measurable new functionality; its only reason to live is standards compliance, and I'm not convinced that's worth the confusion. Our implementation of functions is (and always will be) far enough away from the standard that notational issues like this are hardly the top of the problem list for someone wishing to import a spec-compliant function. a) current syntax is strange for beginers (and I am sure - isn't nice) - look to mailing lists. I belive so ansi syntax is better. b) it's needed for well SQL/PSM support. With table functions and RETURN QUERY we are neer standard. (It's also worth asking where the import is coming from. Who implements the spec syntax anyway? DB2 maybe, but when was the last time we heard from anyone trying to migrate from DB2 to PG?) lot of smaller new databases respect ANSI SQL 200x well - not only db2 regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] SQL: table function support
2008/6/10 Neil Conway [EMAIL PROTECTED]: On Tue, 2008-06-03 at 13:03 +0200, Pavel Stehule wrote: this patch add support of table functions syntax like ANSI SQL 2003. I'm not necessarily opposed to this, but I wonder if we really need *more* syntax variants for declaring set-returning functions. The existing patchwork of features is confusing enough as it is... internally is table functions implemenation identical with SRF. Semantically is far - user's doesn't specify return type (what is from PostgreSQL), but specifies return table, what is more natural. What more - for users is transparent chaotic joice betwen SETOF RECORD for multicolumns sets and SETOF type. Pavel -Neil -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] VACUUM Improvements - WIP Patch
Here is a WIP patch based on the discussions here: http://archives.postgresql.org/pgsql-hackers/2008-05/msg00863.php The attached WIP patch improves the LAZY VACUUM by limiting or avoiding the second heap scan. This not only saves considerable time in VACUUM, but also reduces the double-writes of vacuumed blocks. If the second heap scan is considerably limited, that should also save CPU usage and reduce WAL log writing. With HOT, the first heap scan prunes and defrags every page in the heap. That truncates all the dead tuples to their DEAD line pointers and releases all the free space in the page. The second scan only removes these DEAD line pointers and records the free space in the FSM. The free space in fact does not change from the first pass. But to do so, it again calls RepairPageFragmentation on each page, dirties the page and calls log_heap_clean() again on the page. This clearly looks like too much work for a small gain. As this patch stands, the first phase of vacuum prunes the heap pages as usual. But it marks the DEAD line pointers as DEAD_RECLAIMED to signal that the index pointers to these line pointers are being removed, if certain conditions are satisfied. Other backend when prunes a page, also reclaims DEAD_RECLAIMED line pointers by marking them UNUSED. We need some additional logic to do this in a safe way: - An additional boolean pg_class attribute (relvac_inprogress) is used to track the status of vacuum on a relation. If the attribute is true, either vacuum is in progress on the relation or the last vacuum did not complete successfully. When VACUUM starts, it sets relvac_inprogress to true. The transaction is committed and a new transaction is started so that all other backends can see the change. We also note down the transactions which may already have the table open. VACUUM then starts the first heap scan. It prunes the page, but it can start marking the DEAD line pointers as DEAD_RECLAIMED only after it knows that all other backends can see that VACUUM is in progress on the target relation. Otherwise there is a danger that backends might reclaim DEAD line pointers before their index pointers are removed and that would lead to index corruption. We do that by periodic conditional waits on the noted transactions ids. Once all old transactions are gone, VACUUM sets the second scan limit to the current block number and starts marking subsequent DEAD line pointers as DEAD_RECLAIMED. In most of the cases where the old transactions quickly go away, and for large tables, the second scan will be very limited. In the worst case, we might incur the overhead of conditional waits without any success. TODO: - We can potentially update FSM at the end of first pass. This is not a significant issue if the second scan is very limited. But if we do this, we need to handle the truncate case properly. - As the patch stands, we check of old transactions at every block iteration. This might not be acceptable for the cases where there are long running transactions. We probably need some exponential gap here. - As the patch stands, the heap_page_prune handles reclaiming the DEAD_RECLAIMED line pointers since it already has ability to WAL log similar changes. We don't do any extra work to trigger pruning though (except than setting page_prune_xid). May be we should trigger pruning if we got a line pointer bloat in a page too. Please let me know comments/suggestions and any other improvements. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com VACUUM_second_scan-v5.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
