Re: [PATCHES] Headers dependencies cleanup
Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: During my work I found some header files, which include useless headers and on other way there are some headers which silently assume that requested header will be included by some other headers file. Bruce periodically runs a script that's supposed to catch this type of problem. Maybe we are overdue for another run? Yes, but This problem is there for long time and I think Bruce's script does not catch it. Exactly what problem do you see that he didn't catch? bufpage.h includes bufmgr.h, but bufpage.h does not require any definition from bufmgr.h. I think this dependency is there for long time. Zdenek -- 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] Headers dependencies cleanup
Zdenek Kotala <[EMAIL PROTECTED]> writes: >>> During my work I found some header files, which include useless headers >>> and on other way there are some headers which silently assume that >>> requested header will be included by some other headers file. >> >> Bruce periodically runs a script that's supposed to catch this type >> of problem. Maybe we are overdue for another run? > Yes, but This problem is there for long time and I think Bruce's script does > not > catch it. Exactly what problem do you see that he didn't catch? 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] Headers dependencies cleanup
Tom Lane napsal(a): Alvaro Herrera <[EMAIL PROTECTED]> writes: Zdenek Kotala wrote: During my work I found some header files, which include useless headers and on other way there are some headers which silently assume that requested header will be included by some other headers file. This patch fixes these dependencies around bufpage.h, bufmgr.h What's the point here, again? Bruce periodically runs a script that's supposed to catch this type of problem. Maybe we are overdue for another run? Yes, but This problem is there for long time and I think Bruce's script does not catch it. Zdenek -- 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] Headers dependencies cleanup
Alvaro Herrera napsal(a): Zdenek Kotala wrote: During my work I found some header files, which include useless headers and on other way there are some headers which silently assume that requested header will be included by some other headers file. This patch fixes these dependencies around bufpage.h, bufmgr.h What's the point here, again? Main point there is bufpage.h I have needed include this header in page layout convector but it include bufmgr.h which is useless there and generates a lot of another dependences (e.g. on fmgr.h). Other changes are related to this change. Zdenek -- 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] Headers dependencies cleanup
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Zdenek Kotala wrote: >> During my work I found some header files, which include useless headers >> and on other way there are some headers which silently assume that >> requested header will be included by some other headers file. >> >> This patch fixes these dependencies around bufpage.h, bufmgr.h > What's the point here, again? Bruce periodically runs a script that's supposed to catch this type of problem. Maybe we are overdue for another run? 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] libpq type system 0.9a
Andrew Chernow wrote: Joe Conway wrote: Alvaro Herrera wrote: Merlin Moncure escribió: Yesterday, we notified -hackers of the latest version of the libpq type system. Just to be sure the right people are getting notified, we are posting the latest patch here as well. Would love to get some feedback on this. I had a look at this patch some days ago, and the first question in my mind was: why is it explicitely on libpq? Why not have it as a separate library (say libpqtypes)? That way, applications not using it would not need to link to it. Applications interested in using it would just need to add another -l switch to their link line. +1 Joe What is gained by having a separate library? Our changes don't bloat the library size so I'm curious what the benefits are to not linking with it? If someone doesn't want to use, they don't have to. Similar to the backend, there is stuff in there I personally don't use (like geo types), but I'm not sure that justifies a link option -lgeotypes. The changes we made are closely tied to libpq's functionality. Adding PQputf to simplify the parameterized API, adding PQgetf to compliment PQgetvalue and added the ability to register user-defined type handlers (used by putf and getf). PQgetf makes extensive use of PGresult's internal API, especially for arrays and composites. Breaking this into a separate library would require an external library to access the private internals of libpq. Personally, I am not really in favor of this idea because it breaks apart code that is very related. Although, it is doable. I poked around to see how this would work. There are some problems. 1. members were added to PGconn so connection-based type handler information can be copied to PGparam and PGresult objects. 2. members were added to PGresult, referenced in #1. To properly getf values, the connection-based type handler information must be available to PGresult. Otherwise, PQgetf would require an additional argument, a PGconn, which may have been closed already. 3. PQfinish calls pqClearTypeHandler to free type info assigned to the PGconn. 4. PQclear also calls pqClearTypeHandlers It would also remove some of the simplicity. Creating a connection would no longer initialized type info, which gets copied to PGparam and PGresult. Type info includes a list of built-in handlers and backend config, like integer_datetimes, server-version, etc... That means an additional function must be called after PQconnectdb. But where would the type info be stored? It wouldn't exist in PGconn anymore? Also, this would require double frees. You have to free the result as well as the type info since they are no longer one object. Same holds true for a pgconn. There is something elegant about not requiring additional API calls to perform a putf or getf. It'll just work if you want to use it. You can use PQgetf on a result returned by PQexec and you can use PQputf, PQparamExec followed by PQgetvalue. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- 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] libpq type system 0.9a
Joe Conway wrote: Alvaro Herrera wrote: Merlin Moncure escribió: Yesterday, we notified -hackers of the latest version of the libpq type system. Just to be sure the right people are getting notified, we are posting the latest patch here as well. Would love to get some feedback on this. I had a look at this patch some days ago, and the first question in my mind was: why is it explicitely on libpq? Why not have it as a separate library (say libpqtypes)? That way, applications not using it would not need to link to it. Applications interested in using it would just need to add another -l switch to their link line. +1 Joe What is gained by having a separate library? Our changes don't bloat the library size so I'm curious what the benefits are to not linking with it? If someone doesn't want to use, they don't have to. Similar to the backend, there is stuff in there I personally don't use (like geo types), but I'm not sure that justifies a link option -lgeotypes. The changes we made are closely tied to libpq's functionality. Adding PQputf to simplify the parameterized API, adding PQgetf to compliment PQgetvalue and added the ability to register user-defined type handlers (used by putf and getf). PQgetf makes extensive use of PGresult's internal API, especially for arrays and composites. Breaking this into a separate library would require an external library to access the private internals of libpq. Personally, I am not really in favor of this idea because it breaks apart code that is very related. Although, it is doable. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- 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] [HACKERS] Minor changes to Recovery related code
Nice, applied. I only modified some of the documentation wording. I was a little worried that statement_timeout might cancel pg_stop_backup() _before_ it had gotten to waiting for the archive logs to be saved, but based on what little code there is before that block, I think we are OK. --- Simon Riggs wrote: > On Thu, 2008-03-27 at 17:34 +, Simon Riggs wrote: > > Follow-up during March 2008 CommitFest > > > > On Thu, 2007-06-07 at 21:53 +0100, Simon Riggs wrote: > > > On Sat, 2007-03-31 at 00:51 +0200, Florian G. Pflug wrote: > > > > - pg_stop_backup() will wait until the WAL file that ends the backup is > > > safely archived, even if a failure to archive occurs. This is a change > > > to current behaviour, but since it implements the originally *expected* > > > behaviour IMHO it should be the default. > > > > The most straightforward thing is to make pg_stop_backup() wait as > > described above. > > > > If people want it to timeout, they can use a statement_timeout as > > suggested by Florian. > > > > This can be implemented by having the function poll in an infinite loop > > for archive_status/LOG.done. Also, as Florian suggests, we should have > > it output a WARNING message every 60 seconds. > > > > I'll write a patch now. > > Patch to implement waiting pg_stop_backup(). > > Tested and ready to apply, includes docs. > > -- > Simon Riggs > 2ndQuadrant http://www.2ndQuadrant.com > > PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk [ Attachment, skipping... ] -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/backup.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v retrieving revision 2.116 diff -c -c -r2.116 backup.sgml *** doc/src/sgml/backup.sgml 28 Mar 2008 15:00:28 - 2.116 --- doc/src/sgml/backup.sgml 5 Apr 2008 01:28:09 - *** *** 761,772 Once the WAL segment files used during the backup are archived, you are done. The file identified by pg_stop_backup's result is ! the last segment that needs to be archived to complete the backup. ! Archival of these files will happen automatically, since you have ! already configured archive_command. In many cases, this ! happens fairly quickly, but you are advised to monitor your archival ! system to ensure this has taken place so that you can be certain you ! have a complete backup. --- 761,779 Once the WAL segment files used during the backup are archived, you are done. The file identified by pg_stop_backup's result is ! the last segment that is required to form a complete set of backup files. ! pg_stop_backup does not return until the last segment has ! been archived. ! Archiving of these files happens automatically since you have ! already configured archive_command. In most cases this ! happens quickly, but you are advised to monitor your archive ! system to ensure there are no delays. ! If the archive process has fallen behind ! because of failures of the archive command, it will keep retrying ! until the archive succeeds and the backup is complete. ! If you wish to place a time limit on the execution of ! pg_stop_backup, set an appropriate ! statement_timeout value. *** *** 1044,1050 The stop point must be after the ending time of the base backup, i.e., ! the time of pg_stop_backup. You cannot use a base backup to recover to a time when that backup was still going on. (To recover to such a time, you must go back to your previous base backup and roll forward from there.) --- 1051,1057 The stop point must be after the ending time of the base backup, i.e., ! the end time of pg_stop_backup. You cannot use a base backup to recover to a time when that backup was still going on. (To recover to such a time, you must go back to your previous base backup and roll forward from there.) *** *** 1322,1327 --- 1329,1335 After the backup the switch file is removed. Archived WAL files are then added to the backup so that both base backup and all required WAL files are part of the same tar file. + Please remember to add error handling to your backup scripts. Index: src/backend/access/transam/xlog.c === RCS file: /cvsroot/pgsql/src/backend/access/transam/xlog.c,v retrieving revision 1.295 diff -c -c -r1.295 xlog.c *** src/backend/access/transam/xlog.c 25 Mar 2008 22
Re: [PATCHES] libpq type system 0.9a
Alvaro Herrera wrote: Merlin Moncure escribió: Yesterday, we notified -hackers of the latest version of the libpq type system. Just to be sure the right people are getting notified, we are posting the latest patch here as well. Would love to get some feedback on this. I had a look at this patch some days ago, and the first question in my mind was: why is it explicitely on libpq? Why not have it as a separate library (say libpqtypes)? That way, applications not using it would not need to link to it. Applications interested in using it would just need to add another -l switch to their link line. +1 Joe -- 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] libpq type system 0.9a
Merlin Moncure escribió: > Yesterday, we notified -hackers of the latest version of the libpq > type system. Just to be sure the right people are getting notified, > we are posting the latest patch here as well. Would love to get some > feedback on this. I had a look at this patch some days ago, and the first question in my mind was: why is it explicitely on libpq? Why not have it as a separate library (say libpqtypes)? That way, applications not using it would not need to link to it. Applications interested in using it would just need to add another -l switch to their link line. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Expose checkpoint start/finish times into SQL.
On Fri, 2008-04-04 at 02:21 -0400, Greg Smith wrote: > Database stops checkpointing. WAL files pile up. In the middle of > backup, system finally dies, and when it starts recovery there's a bad > record in the WAL files--which there are now thousands of to apply, and > the bad one is 4 hours of replay in. Believe it or not, it goes downhill > from there. > > It's what kicked off the first step that's the big mystery. The only code > path I thought of that can block checkpoints like this is when the > archive_command isn't working anymore, and that wasn't being used. Given > some of the other corruption found later and the bad memory issues > discovered, a bit flipping in the "do I need to checkpoint now?" code or > data seems just as likely as any other explanation. A few additional comments here: If you set checkpoint_segments very, very high you can avoid a checkpoint via checkpoint_timeout for up to 60 minutes. If you did this for performance reasons presumably you've got lots of WAL files and might end up with 1000s of them in that time period. If you set it too high, you hit the disk limits first and can then crash the server if the pg_xlog directory's physical limits are unluckily low enough. Starvation of the checkpoint start lock has been witnessed previously, so if you're running 8.2 or previous that could be a possible explanation here. What can happen is that a checkpoint is triggered yet the bgwriter needs to wait to get access to the CheckpointStartLock. I witnessed a starvation of 3 minutes once during testing a server running at max velocity with 200 users, in 2006. I assumed that was an outlier, but its possible for that to be longer. I wouldn't believe too much longer, though. That was patched in 8.3 as a result. Anyway, either of those factors, or their combination, plus a small pg_xlog disk would be sufficient to explain the crash and wal file build up. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] fixing sql generated features - plpgsql case statement
Hello
I am sorry, I sent wrong patch, I did diff from generated files.
Current patch set sql features correctly.
Regards
Pavel Stehule
*** ./doc/src/sgml/plpgsql.sgml.orig 2008-04-04 12:07:12.0 +0200
--- ./doc/src/sgml/plpgsql.sgml 2008-04-04 21:55:08.0 +0200
***
*** 1590,1595
--- 1590,1611
IF ... THEN ... ELSEIF ... THEN ... ELSE
+
+ and four forms of CASE:
+
+
+ CASE ... WHEN ... THEN ... END CASE
+
+
+ CASE ... WHEN ... THEN ... ELSE ... END CASE
+
+
+ CASE WHEN ... THEN ... END CASE
+
+
+ CASE WHEN ... THEN ... ELSE ... END CASE
+
+
***
*** 1740,1745
--- 1756,1827
ELSEIF is an alias for ELSIF.
+
+
+ Simple CASE statement
+
+ CASE expression
+ WHEN expression , expression ... THEN
+ statements
+WHEN expression , expression ... THEN
+ statements
+WHEN expression , expression ... THEN
+ statements
+ ...
+ELSE
+ statements
+ END CASE;
+
+
+ Provide conditional execution based on equality of operands. If no case is matched,
+ then is ELSE clause executed. If statement doesn't contains ELSE clause,
+ then CASE_NOT_FOUND exception is raised.
+
+ Here is example:
+
+ CASE a
+ WHEN 1, 2 THEN
+ msg := 'one or two';
+ ELSE
+ msg := 'other value than one or two';
+ END CASE;
+
+
+
+
+
+ Searched CASE statement
+
+ CASE
+ WHEN boolean-expression THEN
+ statements
+WHEN boolean-expression THEN
+ statements
+WHEN boolean-expression THEN
+ statements
+ ...
+ELSE
+ statements
+ END CASE;
+
+
+ Provide conditional execution based on truth of
+ boolean-expression. If no case is matched,
+ then is ELSE clause executed. If statement doesn't contains ELSE clause,
+ then CASE_NOT_FOUND exception is raised.
+
+ Here is example:
+
+ CASE
+ WHEN a BETWEEN 0 AND 10 THEN
+ msg := 'value is between zero and ten';
+ WHEN a BETWEEN 11 AND 20 THEN
+ msg := 'value is between eleven and twenty';
+ END CASE;
+
+
+
+
*** ./src/backend/catalog/sql_feature_packages.txt.orig 2008-04-04 22:47:55.0 +0200
--- ./src/backend/catalog/sql_feature_packages.txt 2008-04-04 22:59:55.0 +0200
***
*** 41,46
--- 41,48
F671 Enhanced integrity management
F701 Enhanced integrity management
F812 Core
+ P004 PSM
+ P008 PSM
S011 Core
S023 Basic object support
S024 Enhanced object support
*** ./src/backend/catalog/sql_features.txt.orig 2008-04-04 22:45:52.0 +0200
--- ./src/backend/catalog/sql_features.txt 2008-04-04 23:05:31.0 +0200
***
*** 297,302
--- 297,304
F831 Full cursor update NO
F831 Full cursor update 01 Updatable scrollable cursors NO
F831 Full cursor update 02 Updatable ordered cursors NO
+ P004 Extended CASE statement YES
+ P008 Comma-separated predicates in simple CASE statement YES
S011 Distinct data types NO
S011 Distinct data types 01 USER_DEFINED_TYPES view NO
S023 Basic structured types NO
*** ./src/include/utils/errcodes.h.orig 2008-04-02 14:02:06.0 +0200
--- ./src/include/utils/errcodes.h 2008-04-03 07:49:40.0 +0200
***
*** 107,112
--- 107,113
/* Class 22 - Data Exception */
#define ERRCODE_DATA_EXCEPTIONMAKE_SQLSTATE('2','2', '0','0','0')
+ #define ERRCODE_CASE_NOT_FOUNDERRCODE_DATA_EXCEPTION
#define ERRCODE_ARRAY_ELEMENT_ERROR MAKE_SQLSTATE('2','2', '0','2','E')
/* SQL99's actual definition of "array element error" is subscript error */
#define ERRCODE_ARRAY_SUBSCRIPT_ERROR ERRCODE_ARRAY_ELEMENT_ERROR
*** ./src/pl/plpgsql/src/gram.y.orig 2008-04-02 13:57:35.0 +0200
--- ./src/pl/plpgsql/src/gram.y 2008-04-03 22:24:49.0 +0200
***
*** 17,23
#include "plpgsql.h"
#include "parser/parser.h"
!
static PLpgSQL_expr *read_sql_construct(int until,
int until2,
--- 17,23
#include "plpgsql.h"
#include "parser/parser.h"
! #include "parser/gramparse.h"
static PLpgSQL_expr *read_sql_construct(int until,
int until2,
***
*** 37,42
--- 37,44
static PLpgSQL_stmt *make_return_stmt(int lineno);
static PLpgSQL_stmt *make_return_next_stmt(int lineno);
static PLpgSQL_stmt *make_return_query_stmt(int lineno);
+ static PLpgSQL_stmt *make_case(int lineno, PLpgSQL_expr *case_expr,
+ List *case_path_list, List *else_stmts);
static void check_assignable(PLpgSQL_datum *datum);
static void read_into_target(PLpgSQL_rec **rec, PLpgSQL_row **row,
bool *strict);
***
*** 83,88
--- 85,95
char *end_label;
List *stmts;
} loop
Re: [PATCHES] Replace offnum++ by OffsetNumberNext
Fujii Masao <[EMAIL PROTECTED]> writes: > This is the patch replace offnum++ by OffsetNumberNext. > According to off.h, OffsetNumberNext is the macro prepared to > disambiguate the different manipulations on OffsetNumbers. > But, increment operator was used in some places instead of the macro. I wonder if we shouldn't go the other way, ie, use ++ everywhere. OffsetNumberNext seems like just useless obscurantism ... 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
[PATCHES] Partial match in GIN
We (Oleg and me) would like to present patch implements partial match for GIN
index and two extensions which use this new feature. We hope that after short
review they will be committed to CVS.
This work was sponsored by EnterpriseDB.
http://www.sigaev.ru/misc/partial_match_gin-0.7.gz
Implements partial match for GIN. It extends interface of support function but
keeps backward compatibility. The basic idea is to find first greater or equal
value in index and scan sequentially until support function says stop. For each
matched entry all corresponding ItemPointers are collected in TIDBitmap
structure to effective merge ItemPointers from different entries. Patch
introduces following changes in interface:
- compare function has third (optional) argument, of boolean type, it points to
kind of compare: partial or exact match. If argument is equal to 'false',
function should produce comparing as usual, else function's result is
treated as:
= 0 - match
< 0 - doesn't match but continue scan
> 0 - stop scan
- extractQuery function has fourth (optional) argument of bool** type. Function
is responsible to allocate correct memory for that array with the same size
as returning array of searching entries. if extractQuery wishs to point
partial match for some entry it should set corresponding element of bool
array to true.
If function described above hasn't extra arguments then GIN will not be able to
use partial match.
http://www.sigaev.ru/misc/tsearch_prefix-0.6.gz
Implements prefix search. This was one of the most wanted feature of text
search. Lexeme to partial match should be labeled with asterisk:
select count(*) from apod where fti @@ 'star:*';
or even
select count(*) from apod where fti @@ to_tsquery('star:*');
Dictionary may set a normalized lexeme with flag (TSL_PREFIX) to point to its
prefix path.
Here there is a unclean issue: now tsquery has new flag to label prefix search
and cstring representation has backward compatibility, but external binary
hasn't it now. Now, extra byte is used for storage of this flag. In other hand,
there 4 unused bits in external binary representation (in byte stores weights of
lexeme), so it's possible to use one of them to store this flag. What are opinions?
http://www.sigaev.ru/misc/wildspeed-0.10.tgz
docs: http://mira.sai.msu.su/~megera/pgsql/pgdoc/wildspeed.html
http://www.sai.msu.su/~megera/wiki/wildspeed
In short, it's a contrib module that speeds up LIKE operation with any kind of
expression, like 'foo%bar' or '%foo%' or even '%foo%bar'. This module is based
on partial match patch of GIN.
NOTICE 1: current index support of LIKE believes that only BTree can speed up
LIKE and becomes confused with this module with error 'unexpected opfamily' in
prefix_quals(). For this reason, partial match patch adds small check before
calling expand_indexqual_opclause().
NOTICE 2: it seems to me, that similar technique could be implemented for
ordinary BTree to eliminate hack around LIKE support.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
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] Expose checkpoint start/finish times into SQL.
Alvaro Herrera <[EMAIL PROTECTED]> writes: > These kind of things can be monitored externally very easily, say by > Nagios, when the values are available via the database. If you have to > troll the logs, it's quite a bit harder to do it. > I'm not sure about the right values to export -- last checkpoint start > time is the most obvious idea, but I would also suggest exporting last > checkpoint end, or NULL if the checkpoint is ongoing; and also previous- > to-last checkpoint start and end. Any Nagios-style monitoring would have to watch checkpoint end (and we'd better define that field as only updating at *successful* checkpoint end). Consider the case where some dirty buffer has a persistent write failure condition. I'm almost inclined to say that the patch shouldn't expose checkpoint start at all, just to make sure people won't get this wrong. We've pretty thoroughly trashed the notion that looking at the interval is helpful anyway. 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
[PATCHES] plpgsql CASE statement
Hello
I finished this patch.
Proposal: http://archives.postgresql.org/pgsql-hackers/2008-01/msg00696.php
It's compatible with PL/SQL (Oracle) and SQL/PSM (ANSI).
CASE statements is parsed and transformed to CASE expression and
statements paths. Result of CASE expression is used as index to array
of statements paths.
Sample:
CREATE OR REPLACE FUNCTION foo(int)
RETURNS void AS $$
BEGIN
CASE $1
WHEN 1,2,3 THEN
RAISE NOTICE '1,2';
RAISE NOTICE '3';
WHEN 4 THEN
RAISE NOTICE '4';
ELSE
RAISE NOTICE 'other than 1,2,3,4';
END CASE;
RETURN;
END;
$$ LANGUAGE plpgsql;
This statement is transformated to:
three statement paths:
[0]
RAISE NOTICE 'other than 1,2,3,4';
[1]
RAISE NOTICE '1,2';
RAISE NOTICE '3';
[2]
RAISE NOTICE '4';
and case expression
CASE $1
WHEN 1 THEN 1
WHEN 2 THEN 1
WHEN 3 THEN 1
WHEN 4 THEN 2
END;
When result is NULL then it uses 0 path.
Regards
Pavel Stehule
*** ./doc/src/sgml/features-supported.sgml.orig 2008-04-04 14:16:52.0 +0200
--- ./doc/src/sgml/features-supported.sgml 2008-04-04 21:20:46.0 +0200
***
*** 1338,1343
--- 1338,1355
+ P004
+ PSM
+ Extended CASE statement
+
+
+
+ P008
+ PSM
+ Comma-separated predicates in simple CASE statement
+
+
+
S071
Enhanced object support
SQL paths in function and type name resolution
*** ./doc/src/sgml/plpgsql.sgml.orig 2008-04-04 12:07:12.0 +0200
--- ./doc/src/sgml/plpgsql.sgml 2008-04-04 21:55:08.0 +0200
***
*** 1590,1595
--- 1590,1611
IF ... THEN ... ELSEIF ... THEN ... ELSE
+
+ and four forms of CASE:
+
+
+ CASE ... WHEN ... THEN ... END CASE
+
+
+ CASE ... WHEN ... THEN ... ELSE ... END CASE
+
+
+ CASE WHEN ... THEN ... END CASE
+
+
+ CASE WHEN ... THEN ... ELSE ... END CASE
+
+
***
*** 1740,1745
--- 1756,1827
ELSEIF is an alias for ELSIF.
+
+
+ Simple CASE statement
+
+ CASE expression
+ WHEN expression , expression ... THEN
+ statements
+WHEN expression , expression ... THEN
+ statements
+WHEN expression , expression ... THEN
+ statements
+ ...
+ELSE
+ statements
+ END CASE;
+
+
+ Provide conditional execution based on equality of operands. If no case is matched,
+ then is ELSE clause executed. If statement doesn't contains ELSE clause,
+ then CASE_NOT_FOUND exception is raised.
+
+ Here is example:
+
+ CASE a
+ WHEN 1, 2 THEN
+ msg := 'one or two';
+ ELSE
+ msg := 'other value than one or two';
+ END CASE;
+
+
+
+
+
+ Searched CASE statement
+
+ CASE
+ WHEN boolean-expression THEN
+ statements
+WHEN boolean-expression THEN
+ statements
+WHEN boolean-expression THEN
+ statements
+ ...
+ELSE
+ statements
+ END CASE;
+
+
+ Provide conditional execution based on truth of
+ boolean-expression. If no case is matched,
+ then is ELSE clause executed. If statement doesn't contains ELSE clause,
+ then CASE_NOT_FOUND exception is raised.
+
+ Here is example:
+
+ CASE
+ WHEN a BETWEEN 0 AND 10 THEN
+ msg := 'value is between zero and ten';
+ WHEN a BETWEEN 11 AND 20 THEN
+ msg := 'value is between eleven and twenty';
+ END CASE;
+
+
+
+
*** ./src/include/utils/errcodes.h.orig 2008-04-02 14:02:06.0 +0200
--- ./src/include/utils/errcodes.h 2008-04-03 07:49:40.0 +0200
***
*** 107,112
--- 107,113
/* Class 22 - Data Exception */
#define ERRCODE_DATA_EXCEPTIONMAKE_SQLSTATE('2','2', '0','0','0')
+ #define ERRCODE_CASE_NOT_FOUNDERRCODE_DATA_EXCEPTION
#define ERRCODE_ARRAY_ELEMENT_ERROR MAKE_SQLSTATE('2','2', '0','2','E')
/* SQL99's actual definition of "array element error" is subscript error */
#define ERRCODE_ARRAY_SUBSCRIPT_ERROR ERRCODE_ARRAY_ELEMENT_ERROR
*** ./src/pl/plpgsql/src/gram.y.orig 2008-04-02 13:57:35.0 +0200
--- ./src/pl/plpgsql/src/gram.y 2008-04-03 22:24:49.0 +0200
***
*** 17,23
#include "plpgsql.h"
#include "parser/parser.h"
!
static PLpgSQL_expr *read_sql_construct(int until,
int until2,
--- 17,23
#include "plpgsql.h"
#include "parser/parser.h"
! #include "parser/gramparse.h"
static PLpgSQL_expr *read_sql_construct(int until,
int until2,
***
*** 37,42
--- 37,44
static PLpgSQL_stmt *make_return_stmt(int lineno);
static PLpgSQL_stmt *make_return_next_stmt(int lineno);
static PLpgSQL_stmt *make_return_query_stmt(int lineno);
+ static PLpgSQL_stmt *make_case(int lineno, PLpgSQL_expr *case_expr,
+ Lis
[PATCHES] Replace offnum++ by OffsetNumberNext
This is the patch replace offnum++ by OffsetNumberNext.
According to off.h, OffsetNumberNext is the macro prepared to
disambiguate the different manipulations on OffsetNumbers.
But, increment operator was used in some places instead of the macro.
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
TEL (03)5860-5115
FAX (03)5463-5490
? patch.diff
Index: src/backend/access/heap/pruneheap.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/access/heap/pruneheap.c,v
retrieving revision 1.9
diff -c -r1.9 pruneheap.c
*** src/backend/access/heap/pruneheap.c 26 Mar 2008 21:10:37 - 1.9
--- src/backend/access/heap/pruneheap.c 4 Apr 2008 14:34:19 -
***
*** 789,795
MemSet(root_offsets, 0, MaxHeapTuplesPerPage * sizeof(OffsetNumber));
maxoff = PageGetMaxOffsetNumber(page);
! for (offnum = FirstOffsetNumber; offnum <= maxoff; offnum++)
{
ItemId lp = PageGetItemId(page, offnum);
HeapTupleHeader htup;
--- 789,795
MemSet(root_offsets, 0, MaxHeapTuplesPerPage * sizeof(OffsetNumber));
maxoff = PageGetMaxOffsetNumber(page);
! for (offnum = FirstOffsetNumber; offnum <= maxoff; offnum =
OffsetNumberNext(offnum))
{
ItemId lp = PageGetItemId(page, offnum);
HeapTupleHeader htup;
Index: src/backend/executor/nodeBitmapHeapscan.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/executor/nodeBitmapHeapscan.c,v
retrieving revision 1.25
diff -c -r1.25 nodeBitmapHeapscan.c
*** src/backend/executor/nodeBitmapHeapscan.c 26 Mar 2008 21:10:38 -
1.25
--- src/backend/executor/nodeBitmapHeapscan.c 4 Apr 2008 14:34:19 -
***
*** 301,307
OffsetNumber maxoff = PageGetMaxOffsetNumber(dp);
OffsetNumber offnum;
! for (offnum = FirstOffsetNumber; offnum <= maxoff; offnum++)
{
ItemId lp;
HeapTupleData loctup;
--- 301,307
OffsetNumber maxoff = PageGetMaxOffsetNumber(dp);
OffsetNumber offnum;
! for (offnum = FirstOffsetNumber; offnum <= maxoff; offnum =
OffsetNumberNext(offnum))
{
ItemId lp;
HeapTupleData loctup;
Index: src/backend/storage/page/bufpage.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/storage/page/bufpage.c,v
retrieving revision 1.78
diff -c -r1.78 bufpage.c
*** src/backend/storage/page/bufpage.c 10 Feb 2008 20:39:08 - 1.78
--- src/backend/storage/page/bufpage.c 4 Apr 2008 14:34:19 -
***
*** 533,539
* Since this is just a hint, we must confirm
that there is
* indeed a free line pointer
*/
! for (offnum = FirstOffsetNumber; offnum <=
nline; offnum++)
{
ItemId lp =
PageGetItemId(page, offnum);
--- 533,539
* Since this is just a hint, we must confirm
that there is
* indeed a free line pointer
*/
! for (offnum = FirstOffsetNumber; offnum <=
nline; offnum = OffsetNumberNext(offnum))
{
ItemId lp =
PageGetItemId(page, offnum);
***
*** 736,742
totallen = 0;
nused = 0;
nextitm = 0;
! for (offnum = 1; offnum <= nline; offnum++)
{
lp = PageGetItemId(page, offnum);
Assert(ItemIdHasStorage(lp));
--- 736,742
totallen = 0;
nused = 0;
nextitm = 0;
! for (offnum = FirstOffsetNumber; offnum <= nline; offnum =
OffsetNumberNext(offnum))
{
lp = PageGetItemId(page, offnum);
Assert(ItemIdHasStorage(lp));
--
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] Expose checkpoint start/finish times into SQL.
"Alvaro Herrera" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Greg Smith <[EMAIL PROTECTED]> writes: >> > ... If they'd have noticed it while the server was up, perhaps because the >> > "last checkpoint" value hadn't changed in a long time (which seems like it >> > might be available via stats even if, as you say, the background writer is >> > out of its mind at that point), they could have done such a kill and >> > collected some actual useful information here. That's the theory at >> > least. >> >> Well, mebbe, but that still seems to require a lot of custom monitoring >> infrastructure that is not present in this patch, and furthermore that >> this patch doesn't especially aid the development of. > > These kind of things can be monitored externally very easily, say by > Nagios, when the values are available via the database. If you have to > troll the logs, it's quite a bit harder to do it. I can see Tom's reluctance out of fear that really this is going to be the first of hundreds of dials which have to be monitored so a single function to handle that single dial is kind of short sighted. I would think eventually it should be part of the Postgres SNMP MIB. But I would say from my experience on the not-really-a-sysadmin side I think the time of the last checkpoint is probably the *most* important thing to be monitoring. Effectively it's monitoring how stale your data on disk is potentially becoming by showing how much recovery will be necessary. > I'm not sure about the right values to export -- last checkpoint start > time is the most obvious idea, but I would also suggest exporting last > checkpoint end, or NULL if the checkpoint is ongoing; and also previous- > to-last checkpoint start and end. I'm surprised y'all want the time of the last checkpoint *start* though. It seems to me that only the last checkpoint *end* is actually interesting. A checkpoint which has started but not ended yet is not really a checkpoint at all. It's nothing. In the future there could be multiple checkpoints which have "started" but not finished. Or we could add support for lazy checkpoints in which case there could be an infinite number of "potential" checkpoints which haven't finished. Worse, the time the last checkpoint actually finished isn't actually interesting either. What you want to know is what time the record which the last finished checkpoint *checkpointed up to* was inserted. That is, the time of the record that the last checkpoint record *points to*. That represents the "guarantee" that the database is making to the sysadmin about data integrity. Everything before that time is guaranteed to have reached data files already. Everything after it may or may not be in the data files and has to be checked against the WAL logs. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- 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] Expose checkpoint start/finish times into SQL.
On Friday 04 April 2008 03:14, Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > ... If they'd have noticed it while the server was up, perhaps because
> > the "last checkpoint" value hadn't changed in a long time (which seems
> > like it might be available via stats even if, as you say, the background
> > writer is out of its mind at that point), they could have done such a
> > kill and collected some actual useful information here. That's the
> > theory at least.
>
> Well, mebbe, but that still seems to require a lot of custom monitoring
> infrastructure that is not present in this patch, and furthermore that
> this patch doesn't especially aid the development of.
>
This patch makes that a 1 line sql call, which can be plugged into any number
of monitoring systems.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
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] Expose checkpoint start/finish times into SQL.
On Friday 04 April 2008 01:59, Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > On Thu, 3 Apr 2008, Tom Lane wrote:
> >> I'd much rather be spending our time and effort on understanding what
> >> broke for you, and fixing the code so it doesn't happen again.
> >
> > [ shit happens... ]
>
> Completely fair, but I still don't see how this particular patch would
> be a useful addition to the DBA's monitoring-tool arsenal. The scope
> seems too narrow.
>
So, thinking about this for a few minutes, here are some of the things that
knowing the last checkpoint time might help a DBA determine.
1) Alert if checkpointing stops occuring within a reasonable time frame (note
there are failure cases and normal use cases where this might occur) (also
note I'll agree, this isn't common, but the results are pretty disatrous if
it does happen)
2) Can be graphed over time (using rrdtool and others) for trending checkpoint
activity
3) Ease monitoring of checkpoints across pitr setups
4) Help determine if your checkpoints are being timeout driven or segment
driven, or if you need to look at those settings
5) Determine the number of log files that will need to be replayed in the
event of a crash
6) Helps give an indication on if you should enter a manual checkpoint before
issuing a pg_start_backup call
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
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] Expose checkpoint start/finish times into SQL.
Tom Lane wrote: > Greg Smith <[EMAIL PROTECTED]> writes: > > ... If they'd have noticed it while the server was up, perhaps because the > > "last checkpoint" value hadn't changed in a long time (which seems like it > > might be available via stats even if, as you say, the background writer is > > out of its mind at that point), they could have done such a kill and > > collected some actual useful information here. That's the theory at > > least. > > Well, mebbe, but that still seems to require a lot of custom monitoring > infrastructure that is not present in this patch, and furthermore that > this patch doesn't especially aid the development of. These kind of things can be monitored externally very easily, say by Nagios, when the values are available via the database. If you have to troll the logs, it's quite a bit harder to do it. I'm not sure about the right values to export -- last checkpoint start time is the most obvious idea, but I would also suggest exporting last checkpoint end, or NULL if the checkpoint is ongoing; and also previous- to-last checkpoint start and end. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Headers dependencies cleanup
Zdenek Kotala wrote: > During my work I found some header files, which include useless headers > and on other way there are some headers which silently assume that > requested header will be included by some other headers file. > > This patch fixes these dependencies around bufpage.h, bufmgr.h What's the point here, again? -- 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] Friendly help for psql
bruce wrote:
> Greg Sabino Mullane wrote:
> -- Start of PGP signed section.
> > Why not run help when someone enters "help" (or "HELP ME!") on the
> > command line? \? is hardly an easy thing to remember (and some people
> > can't be bothered to actually read the screen...)
> >
>
> I have applied this patch (attached) with a few modifications. First
> you were printing \? help for any string beginning with "help" so
> "helplkjasdf" also printed help --- I don't think we want that. I
> allowed "help", "help "*, and "help;", so "help select" does work
> (prints \?).
>
> I also added \? to the list of \? help options because now someone can
> get to \? without typing \?.
>
> Shame we can't make \h more prominent in \? output. I am going to try
> to trim down that top help section, but that will a separate patch
> posting by me.
Ah, I see now we later agreed to have 'help' just output a suggestion to
use \?. I have expanded on that and removed the mention of the web
site, which seemed odd to be just in the 'help' output. (I added a \h
mention.)
Update patch applied, that also reverses the previous patch.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/bin/psql/help.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/help.c,v
retrieving revision 1.125
diff -c -c -r1.125 help.c
*** src/bin/psql/help.c 4 Apr 2008 17:42:43 - 1.125
--- src/bin/psql/help.c 4 Apr 2008 17:57:18 -
***
*** 188,194
ON(pset.timing));
fprintf(output, _(" \\unset NAMEunset (delete) internal variable\n"));
fprintf(output, _(" \\! [COMMAND] execute command in shell or start interactive shell\n"));
- fprintf(output, _(" \\? display this help output\n"));
fprintf(output, "\n");
fprintf(output, _("Query Buffer\n"));
--- 188,193
Index: src/bin/psql/mainloop.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/mainloop.c,v
retrieving revision 1.88
diff -c -c -r1.88 mainloop.c
*** src/bin/psql/mainloop.c 4 Apr 2008 17:42:43 - 1.88
--- src/bin/psql/mainloop.c 4 Apr 2008 17:57:18 -
***
*** 11,17
#include "command.h"
#include "common.h"
- #include "help.h"
#include "input.h"
#include "settings.h"
--- 11,16
***
*** 172,184
continue;
}
! /* A request for help? Be friendly and show them the slash way of doing things */
if (pset.cur_cmd_interactive && query_buf->len == 0 &&
pg_strncasecmp(line, "help", 4) == 0 &&
(line[4] == '\0' || line[4] == ';' || isspace(line[4])))
{
free(line);
! slashUsage(pset.popt.topt.pager);
continue;
}
--- 171,186
continue;
}
! /* A request for help? Be friendly and give them some guidance */
if (pset.cur_cmd_interactive && query_buf->len == 0 &&
pg_strncasecmp(line, "help", 4) == 0 &&
(line[4] == '\0' || line[4] == ';' || isspace(line[4])))
{
free(line);
! puts("You are using psql, the command-line interface to PostgreSQL.");
! puts("Enter SQL commands, or type \\? for a list of backslash options.");
! puts("Use \\h for SQL command help.");
! puts("Use \\q to quit.");
continue;
}
--
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] Implemented current_query
I have applied a modified version of this patch, attached. I made a few
changes:
o You had current_query() returning 'void' so it didn't work
o I removed the dblink regression tests for current_query() as
it is now a backend function
o Update documentation to mention the possibility of multiple
statements
o Used the new cstring_to_text() usage that Tom had updated in
CVS for this function
o The pg_proc.h oids and number of columns didn't match CVS
Thanks for the patch.
---
Tomas Doran wrote:
>
> On 10 May 2007, at 03:09, Alvaro Herrera wrote:
> > FWIW I think you should still provide dblink_current_query, even if
> > it's
> > only a wrapper over current_query(), for backwards compatibility.
>
> Good point. Done as suggested (I think, or did you mean also the
> change of instances to use current_query()?). Replaced
> dblink_current_query with an SQL procedure wrapper, I assume that's
> the most efficient way of doing it?
>
> > Also, typically we don't remove items from the TODO list. We mark
> > them
> > as "done" prepending them with a dash. Patch authors are not expected
> > to do it either (though I don't see it be a problem if they did).
>
> Not quite sure what you're suggesting (which way round), so I just
> didn't do it (as you said I'm not expected to).
>
> > Doesn't matter ... just make sure duplicate_oids doesn't report a
> > problem. unused_oids is useful to find, err, unused OIDs.
>
> Ahh, hadn't found those, thanks. They're in the dev FAQ too, *blush*.
> I need this for something I'm doing at $ork, and thought I'd
> implement it in the backend, as well as a .so, it's been a learning
> experience :)
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: contrib/dblink/dblink.c
===
RCS file: /cvsroot/pgsql/contrib/dblink/dblink.c,v
retrieving revision 1.71
diff -c -c -r1.71 dblink.c
*** contrib/dblink/dblink.c 26 Mar 2008 21:10:36 - 1.71
--- contrib/dblink/dblink.c 4 Apr 2008 16:45:36 -
***
*** 1631,1653
PG_RETURN_TEXT_P(cstring_to_text(sql));
}
- /*
- * dblink_current_query
- * return the current query string
- * to allow its use in (among other things)
- * rewrite rules
- */
- PG_FUNCTION_INFO_V1(dblink_current_query);
- Datum
- dblink_current_query(PG_FUNCTION_ARGS)
- {
- if (debug_query_string)
- PG_RETURN_TEXT_P(cstring_to_text(debug_query_string));
- else
- PG_RETURN_NULL();
- }
-
-
/*
* internal functions
*/
--- 1631,1636
Index: contrib/dblink/dblink.h
===
RCS file: /cvsroot/pgsql/contrib/dblink/dblink.h,v
retrieving revision 1.19
diff -c -c -r1.19 dblink.h
*** contrib/dblink/dblink.h 1 Jan 2008 19:45:45 - 1.19
--- contrib/dblink/dblink.h 4 Apr 2008 16:45:36 -
***
*** 56,61
extern Datum dblink_build_sql_insert(PG_FUNCTION_ARGS);
extern Datum dblink_build_sql_delete(PG_FUNCTION_ARGS);
extern Datum dblink_build_sql_update(PG_FUNCTION_ARGS);
- extern Datum dblink_current_query(PG_FUNCTION_ARGS);
#endif /* DBLINK_H */
--- 56,60
Index: contrib/dblink/dblink.sql.in
===
RCS file: /cvsroot/pgsql/contrib/dblink/dblink.sql.in,v
retrieving revision 1.14
diff -c -c -r1.14 dblink.sql.in
*** contrib/dblink/dblink.sql.in 13 Nov 2007 04:24:27 - 1.14
--- contrib/dblink/dblink.sql.in 4 Apr 2008 16:45:36 -
***
*** 163,173
AS 'MODULE_PATHNAME','dblink_build_sql_update'
LANGUAGE C STRICT;
- CREATE OR REPLACE FUNCTION dblink_current_query ()
- RETURNS text
- AS 'MODULE_PATHNAME','dblink_current_query'
- LANGUAGE C;
-
CREATE OR REPLACE FUNCTION dblink_send_query(text, text)
RETURNS int4
AS 'MODULE_PATHNAME', 'dblink_send_query'
--- 163,168
Index: contrib/dblink/uninstall_dblink.sql
===
RCS file: /cvsroot/pgsql/contrib/dblink/uninstall_dblink.sql,v
retrieving revision 1.5
diff -c -c -r1.5 uninstall_dblink.sql
*** contrib/dblink/uninstall_dblink.sql 13 Nov 2007 04:24:27 - 1.5
--- contrib/dblink/uninstall_dblink.sql 4 Apr 2008 16:45:36 -
***
*** 3,10
-- Adjust this setting to control where the objects get dropped.
SET search_path = public;
- DROP FUNCTION dblink_current_query ();
-
DROP FUNCTION dblink_build_sql_update (text, int2vector, int4, _text, _text);
DROP FUNCTION dblink_build_sql_delete (text, int2vector, int4, _text);
--- 3,8
Index: contrib/dblink/expected/dblink.out
===
Re: [PATCHES] Friendly help for psql
Greg Sabino Mullane wrote:
-- Start of PGP signed section.
> Why not run help when someone enters "help" (or "HELP ME!") on the
> command line? \? is hardly an easy thing to remember (and some people
> can't be bothered to actually read the screen...)
>
I have applied this patch (attached) with a few modifications. First
you were printing \? help for any string beginning with "help" so
"helplkjasdf" also printed help --- I don't think we want that. I
allowed "help", "help "*, and "help;", so "help select" does work
(prints \?).
I also added \? to the list of \? help options because now someone can
get to \? without typing \?.
Shame we can't make \h more prominent in \? output. I am going to try
to trim down that top help section, but that will a separate patch
posting by me.
Any adjustments?
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/bin/psql/help.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/help.c,v
retrieving revision 1.124
diff -c -c -r1.124 help.c
*** src/bin/psql/help.c 29 Mar 2008 19:40:12 - 1.124
--- src/bin/psql/help.c 4 Apr 2008 17:39:05 -
***
*** 188,193
--- 188,194
ON(pset.timing));
fprintf(output, _(" \\unset NAMEunset (delete) internal variable\n"));
fprintf(output, _(" \\! [COMMAND] execute command in shell or start interactive shell\n"));
+ fprintf(output, _(" \\? display this help output\n"));
fprintf(output, "\n");
fprintf(output, _("Query Buffer\n"));
Index: src/bin/psql/mainloop.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/mainloop.c,v
retrieving revision 1.87
diff -c -c -r1.87 mainloop.c
*** src/bin/psql/mainloop.c 1 Jan 2008 19:45:56 - 1.87
--- src/bin/psql/mainloop.c 4 Apr 2008 17:39:05 -
***
*** 11,16
--- 11,17
#include "command.h"
#include "common.h"
+ #include "help.h"
#include "input.h"
#include "settings.h"
***
*** 171,176
--- 172,187
continue;
}
+ /* A request for help? Be friendly and show them the slash way of doing things */
+ if (pset.cur_cmd_interactive && query_buf->len == 0 &&
+ pg_strncasecmp(line, "help", 4) == 0 &&
+ (line[4] == '\0' || line[4] == ';' || isspace(line[4])))
+ {
+ free(line);
+ slashUsage(pset.popt.topt.pager);
+ continue;
+ }
+
/* echo back if flag is set */
if (pset.echo == PSQL_ECHO_ALL && !pset.cur_cmd_interactive)
puts(line);
--
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] Re: [BUGS] BUG #4070: Join more then ~15 tables let postgreSQL produces wrong data
-Ursprüngliche Nachricht- Von: Tom Lane [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 3. April 2008 21:33 An: Heikki Linnakangas Cc: Alvaro Herrera; pgsql-patches; Ceschia, Marcello; PostgreSQL Bugs Betreff: Re: [PATCHES] Re: [BUGS] BUG #4070: Join more then ~15 tables let postgreSQL produces wrong data > What I propose we do is throw error for the moment, and make a TODO > note to revisit the question after redesigning outer-join planning. > Which is something I do intend to do for 8.4. For me that's a good solution. My motivation for reporting this bug was to notice the developer about the problem. Of course the query we did is a strange way to get a result, but it was possible without warning/error. At the moment we use a function to join the tables one by one and for the moment it is working. Thank you for your helps Marcello -- 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] Expose checkpoint start/finish times into SQL.
Greg Smith <[EMAIL PROTECTED]> writes: > ... If they'd have noticed it while the server was up, perhaps because the > "last checkpoint" value hadn't changed in a long time (which seems like it > might be available via stats even if, as you say, the background writer is > out of its mind at that point), they could have done such a kill and > collected some actual useful information here. That's the theory at > least. Well, mebbe, but that still seems to require a lot of custom monitoring infrastructure that is not present in this patch, and furthermore that this patch doesn't especially aid the development of. 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] Expose checkpoint start/finish times into SQL.
On Fri, 4 Apr 2008, Tom Lane wrote: The actual advice I'd give to a DBA faced with such a case is to kill -ABRT the bgwriter and send the stack trace to -hackers. And that's a perfect example of where they're trying to get to. They didn't notice the problem until after the crash. The server didn't come back up (busy processing WALs) and that downtime was caught by a monitoring system. At that point it was too late to collect debugging information on what was wrong inside the server processes that might have given a clue what happened. If they'd have noticed it while the server was up, perhaps because the "last checkpoint" value hadn't changed in a long time (which seems like it might be available via stats even if, as you say, the background writer is out of its mind at that point), they could have done such a kill and collected some actual useful information here. That's the theory at least. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
