Re: [HACKERS] RFD: Don't force plpgsql IN parameters to constant
Tom Lane wrote: Is there a reason we force plpgsql IN parameters to constant? Now having said all that, I'm not really in favor of Steve's proposal --- it seems like it mostly would be encouraging dubious programming practices. But it's hard to say that the arguments against are more than theoretical/aesthetic ones. Does anyone happen to know how it works in Oracle's PL/SQL? I think that following their lead is usually the argument-settler when it comes to plpgsql behavior. Oracle 10.2.0.4: CREATE PROCEDURE test2(a NUMBER) AUTHID CURRENT_USER AS BEGIN a := 2; END; / PLS-00363: expression 'A' cannot be used as an assignment target So it does not work in Oracle. The proposed feature would have come handy for me once or twice, but maybe that is more a sign of my sloppy coding habits than anything else ... Still, +1 from me for the proposal. In my experience, restrictive languages have never kept people from writing bad and confusing code. What about introducing a keyword CONSTANT in the parameter list to force the old behaviour? (This would remove us further from Oracle though.) Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: Deferrable unique constraints
2009/7/29 Tom Lane t...@sss.pgh.pa.us: Dean Rasheed dean.a.rash...@googlemail.com writes: [ deferrable unique constraints patch ] Applied after rather extensive editorialization. Excellent! Thanks for all your work sorting out my rookie mistakes. I haven't had a chance to go through all your editorializations in detail yet, but I'm sure that I'll learn a lot from them, so thanks again. And thanks also to everyone else who reviewed this and provided helpful feedback and advice. Cheers! - Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] improvements for dict_xsyn extended synonym dictionary - RRR
Andres Freund and...@anarazel.de writes:
Hi Andres,
Looks nice. The only small gripe I have is that the patch adds trailing
whitespaces at a lot of places...
Except maybe that I do see no need for changes anymore...
My fault. Please check the patch version attached - I've tried to fix
all those.
Thanks,
Sergey
Index: contrib/dict_xsyn/dict_xsyn.c
===
RCS file: /projects/cvsroot/pgsql/contrib/dict_xsyn/dict_xsyn.c,v
retrieving revision 1.6
diff -u -r1.6 dict_xsyn.c
--- contrib/dict_xsyn/dict_xsyn.c 1 Jan 2009 17:23:32 - 1.6
+++ contrib/dict_xsyn/dict_xsyn.c 30 Jul 2009 07:37:54 -
@@ -26,6 +26,7 @@
char *key; /* Word */
char *value; /* Unparsed list of synonyms, including the
* word itself */
+ int pos;/* Position of key word in original string */
} Syn;
typedef struct
@@ -33,7 +34,10 @@
int len;
Syn *syn;
+ bool matchorig;
bool keeporig;
+ bool matchsynonyms;
+ bool keepsynonyms;
} DictSyn;
@@ -88,6 +92,7 @@
{
char *value;
char *key;
+ char *pos;
char *end = NULL;
if (*line == '\0')
@@ -96,26 +101,39 @@
value = lowerstr(line);
pfree(line);
- key = find_word(value, end);
- if (!key)
- {
- pfree(value);
- continue;
- }
+ pos = value;
- if (cur == d-len)
+ while((key = find_word(pos, end)) != NULL)
{
- d-len = (d-len 0) ? 2 * d-len : 16;
- if (d-syn)
-d-syn = (Syn *) repalloc(d-syn, sizeof(Syn) * d-len);
- else
-d-syn = (Syn *) palloc(sizeof(Syn) * d-len);
- }
+ if (cur == d-len)
+ {
+d-len = (d-len 0) ? 2 * d-len : 16;
+if (d-syn)
+ d-syn = (Syn *) repalloc(d-syn, sizeof(Syn) * d-len);
+else
+ d-syn = (Syn *) palloc(sizeof(Syn) * d-len);
+ }
+
+ /* Read first word only if we will match it */
+ if (pos != value || d-matchorig)
+ {
+d-syn[cur].key = pnstrdup(key, end - key);
+d-syn[cur].value = pstrdup(value);
+d-syn[cur].pos = key - value;
- d-syn[cur].key = pnstrdup(key, end - key);
- d-syn[cur].value = value;
+cur++;
+ }
+
+ pos = end;
+
+ /* Don't read synonyms if we do not match them */
+ if (!d-matchsynonyms)
+ {
+break;
+ }
+ }
- cur++;
+ pfree(value);
}
tsearch_readline_end(trst);
@@ -133,23 +151,40 @@
List *dictoptions = (List *) PG_GETARG_POINTER(0);
DictSyn*d;
ListCell *l;
+ char *filename = NULL;
d = (DictSyn *) palloc0(sizeof(DictSyn));
d-len = 0;
d-syn = NULL;
+ d-matchorig = true;
d-keeporig = true;
+ d-matchsynonyms = false;
+ d-keepsynonyms = true;
foreach(l, dictoptions)
{
DefElem*defel = (DefElem *) lfirst(l);
- if (pg_strcasecmp(defel-defname, KEEPORIG) == 0)
+ if (pg_strcasecmp(defel-defname, MATCHORIG) == 0)
+ {
+ d-matchorig = defGetBoolean(defel);
+ }
+ else if (pg_strcasecmp(defel-defname, KEEPORIG) == 0)
{
d-keeporig = defGetBoolean(defel);
}
+ else if (pg_strcasecmp(defel-defname, MATCHSYNONYMS) == 0)
+ {
+ d-matchsynonyms = defGetBoolean(defel);
+ }
+ else if (pg_strcasecmp(defel-defname, KEEPSYNONYMS) == 0)
+ {
+ d-keepsynonyms = defGetBoolean(defel);
+ }
else if (pg_strcasecmp(defel-defname, RULES) == 0)
{
- read_dictionary(d, defGetString(defel));
+ /* we can't read the rules before parsing all options! */
+ filename = pstrdup(defGetString(defel));
}
else
{
@@ -160,6 +195,12 @@
}
}
+ if(filename)
+ {
+ read_dictionary(d, filename);
+ pfree(filename);
+ }
+
PG_RETURN_POINTER(d);
}
@@ -198,7 +239,6 @@
int value_length = strlen(value);
char *pos = value;
int nsyns = 0;
- bool is_first = true;
res = palloc(0);
@@ -214,8 +254,8 @@
res = repalloc(res, sizeof(TSLexeme) * (nsyns + 2));
res[nsyns].lexeme = NULL;
- /* first word is added to result only if KEEPORIG flag is set */
- if (d-keeporig || !is_first)
+ /* The first word is added only if keeporig=true */
+ if (pos != value || d-keeporig)
{
res[nsyns].lexeme = pstrdup(syn);
res[nsyns + 1].lexeme = NULL;
@@ -223,9 +263,12 @@
nsyns++;
}
- is_first = false;
-
pos = end + 1;
+
+ if(!d-keepsynonyms)
+ {
+break;
+ }
}
pfree(value);
Index: contrib/dict_xsyn/expected/dict_xsyn.out
===
RCS file: /projects/cvsroot/pgsql/contrib/dict_xsyn/expected/dict_xsyn.out,v
retrieving revision 1.1
diff -u -r1.1 dict_xsyn.out
--- contrib/dict_xsyn/expected/dict_xsyn.out 15 Oct 2007 21:36:50 - 1.1
+++ contrib/dict_xsyn/expected/dict_xsyn.out 30 Jul 2009 07:37:54 -
@@ -5,10 +5,76 @@
SET client_min_messages = warning;
\set ECHO none
RESET client_min_messages;
---configuration
-ALTER TEXT SEARCH DICTIONARY xsyn (RULES='xsyn_sample', KEEPORIG=false);
+-- default configuration - match first word and return it among with all synonyms
+ALTER TEXT SEARCH DICTIONARY xsyn (RULES='xsyn_sample',
Re: [HACKERS] [RFC] new digest datatypes, or generic fixed-len hex types?
On Wednesday 29 July 2009 20:16:48 decibel wrote: bytea doesn't cast well to and from text when you're dealing with hex data; you end up using the same amount of space as a varchar. What would probably work well is a hex datatype that internally works like bytea but requires that the input data is hex (I know you can use encode/decode, but that added step is a pain). A similar argument could be made for base64 encoded data. There is a patch in the queue that adds hex input and output to bytea. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
Peter Eisentraut wrote: On Tuesday 28 July 2009 15:36:29 KaiGai Kohei wrote: Peter Eisentraut wrote: On Sunday 26 July 2009 14:35:41 Sam Mason wrote: I'm coming to the conclusion that you really need to link to external material here; there must be good (and canonical) definitions of these things outside and because SE-PG isn't self contained I really think you need to link to them. This is not supposed to be user documentation. It's supposed to be a feature specification that an implementation can be validated against. Hmm... What kind of descriptions are necessary for a feature specifications? It describes what the feature does and why. Currently, I guess the specification describes when/where the security hook should be invoked, what permission should be checked and what result should be returned for each security hooks. Is it correct? Or, do you expect any other stuffs? That is a pretty good start, but it's drifting into implementation details. Apart from that, user documentation is also necessary. If the specification should be described from completely different viewpoint, I'll provide it. Yes, user documentation will eventually also be necessary, and the original specification may be usable as a source for that. I'm just reacting to those who commented whether or not references should be added and what reference style the documentation uses. We're not there yet. The purpose of this document is to explain what the feature does, not to teach users to use the feature. For a couple of days, I have paid my efforts to provide the design specifications more than user documentations. (But a few sections are under construction.) http://wiki.postgresql.org/wiki/SEPostgreSQL_Development Some of sections are copied from the SEPostgreSQL_Draft and edited, rest of sections are also revised to represent its feature and behavior more correctly. At the current moment, I can agree it is too early to discuss the style for user documentation. So, I would like to freeze the efforts to the user documentation for a while, and begin to discuss the design specification which focuses on developers. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 win32 shared memory patch
On Wed, Jul 29, 2009 at 19:52, Kevin Fieldkevinjamesfi...@gmail.com wrote: On Win2k3 Std SP2, the service won't start once I've applied the patch. In the log, I get: %t LOG: CreateProcess call failed: A blocking operation was interrupted by a call to WSACancelBlockingCall. Now, that's just strange :-O First of all, the code from this patch hasn't even executed when that error pops up... So it really shouldn't be that one. Second, that error message just makes no sense in the context. However, the errorcode 2 makes a bit more sense - that's a file not found error. It's still strange that it would show up, but it makes sense in the context of CreateProcess(). Are you sure that there weren't any old processes hanging around when you tried it? Would it be possible for you to test by doing stop - reboot - replace file - start and see if the issue remains? -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] multi-threaded pgbench
On Wed, Jul 29, 2009 at 23:31, Josh Williamsjoshwilli...@ij.net wrote: On Tue, 2009-07-28 at 23:38 -0400, Josh Williams wrote: Huh, running the patched version on a single thread with 128 clients just got it to crash. Actually consistently, three times now. Will try the same thing on the development box tomorrow morning to get some better debugging information. So yeah, buffer overrun. In pgbench.c FD_SETSIZE is redefined to get around the Windows default of 64. But this is done after bringing in winsock2.h (a couple levels in as a result of first including postgres_fe.h). So any fd_set is built with an array of 64 descriptors, while pgbench thinks it has 1024 available to work with. This was introduced a while back; the multi-threaded patch just makes it visible by giving it an important pointer to write over. Previously it would just run over into the loop counter (and probably a couple other things) and thus it'd continue on happily with the [sub]set it has. Yikes. Yeah, this is fallout from the hacking we did with moving the winsock includes around a while back. At the time the #defines were added, winsock came in through the win32.h file :S In either case this seems to be a simple fix, to move that #define earlier (see pgbench_win32.patch.) Yes, and it seems to be entirely unrelated to the multithreaded patch. Thus, applied as a separate patch. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Compiling Postgres 8.3.7 MSVC 2005
Compilation fails with the following errors. C:\Program Files\Microsoft Visual Studio 8\VC\include\sys/types.h(23): fatal error C1189: #error : ERROR: Only Win32 target supported! This seems something very trivial but I have'nt been able to figure it out yet I use MSVC 2005 M$ Plaform SDK v6.0 ... I have updated the LIB, PATH and INCLUDE . echo'ing from the VC command prompt shows that its in the path. Bison version 2.1 and Flex 2.5.4 Appreciate any pointers.. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Alvaro Herrera írta: Boszormenyi Zoltan wrote: The vague consensus for syntax options was that the GUC 'lock_timeout' and WAIT [N] extension (wherever NOWAIT is allowed) both should be implemented. Behaviour would be that N seconds timeout should be applied to every lock that the statement would take. In http://archives.postgresql.org/message-id/291.1242053...@sss.pgh.pa.us Tom argues that lock_timeout should be sufficient. I'm not sure what does WAIT [N] buy Okay, we implemented only the lock_timeout GUC. Patch attached, hopefully in an acceptable form. Documentation included in the patch, lock_timeout works the same way as statement_timeout, takes value in milliseconds and 0 disables the timeout. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ diff -dcrpN pgsql.orig/doc/src/sgml/config.sgml pgsql/doc/src/sgml/config.sgml *** pgsql.orig/doc/src/sgml/config.sgml 2009-07-17 07:50:48.0 +0200 --- pgsql/doc/src/sgml/config.sgml 2009-07-30 13:12:07.0 +0200 *** COPY postgres_log FROM '/full/path/to/lo *** 4018,4023 --- 4018,4046 /listitem /varlistentry + varlistentry id=guc-lock-timeout xreflabel=lock_timeout + termvarnamelock_timeout/varname (typeinteger/type)/term + indexterm +primaryvarnamelock_timeout/ configuration parameter/primary + /indexterm + listitem +para + Abort any statement that tries to lock any rows or tables and the lock + has to wait more than the specified number of milliseconds, starting + from the time the command arrives at the server from the client. + If varnamelog_min_error_statement/ is set to literalERROR/ or + lower, the statement that timed out will also be logged. + A value of zero (the default) turns off the limitation. +/para + +para + Setting varnamelock_timeout/ in + filenamepostgresql.conf/ is not recommended because it + affects all sessions. +/para + /listitem + /varlistentry + varlistentry id=guc-vacuum-freeze-table-age xreflabel=vacuum_freeze_table_age termvarnamevacuum_freeze_table_age/varname (typeinteger/type)/term indexterm diff -dcrpN pgsql.orig/doc/src/sgml/ref/lock.sgml pgsql/doc/src/sgml/ref/lock.sgml *** pgsql.orig/doc/src/sgml/ref/lock.sgml 2009-01-16 11:44:56.0 +0100 --- pgsql/doc/src/sgml/ref/lock.sgml 2009-07-30 13:29:07.0 +0200 *** where replaceable class=PARAMETERloc *** 39,46 literalNOWAIT/literal is specified, commandLOCK TABLE/command does not wait to acquire the desired lock: if it cannot be acquired immediately, the command is aborted and an !error is emitted. Once obtained, the lock is held for the !remainder of the current transaction. (There is no commandUNLOCK TABLE/command command; locks are always released at transaction end.) /para --- 39,49 literalNOWAIT/literal is specified, commandLOCK TABLE/command does not wait to acquire the desired lock: if it cannot be acquired immediately, the command is aborted and an !error is emitted. If varnamelock_timeout/varname is set to a value !higher than 0, and the lock cannot be acquired under the specified !timeout value in milliseconds, the command is aborted and an error !is emitted. Once obtained, the lock is held for the remainder of !the current transaction. (There is no commandUNLOCK TABLE/command command; locks are always released at transaction end.) /para diff -dcrpN pgsql.orig/doc/src/sgml/ref/select.sgml pgsql/doc/src/sgml/ref/select.sgml *** pgsql.orig/doc/src/sgml/ref/select.sgml 2009-05-04 11:00:49.0 +0200 --- pgsql/doc/src/sgml/ref/select.sgml 2009-07-30 13:36:57.0 +0200 *** FOR SHARE [ OF replaceable class=param *** 1101,1106 --- 1101,1114 /para para + If literalNOWAIT/ option is not specified and varnamelock_timeout/varname + is set to a value higher than 0, and the lock needs to wait more than + the specified value in milliseconds, the command reports an error after + timing out, rather than waiting indefinitely. The note in the previous + paragraph applies to the varnamelock_timeout/varname, too. +/para + +para literalFOR SHARE/literal behaves similarly, except that it acquires a shared rather than exclusive lock on each retrieved row. A shared lock blocks other transactions from performing diff -dcrpN pgsql.orig/src/backend/access/heap/heapam.c
Re: [HACKERS] Compiling Postgres 8.3.7 MSVC 2005
On Thu, Jul 30, 2009 at 12:17, Santosh Ahujacodes...@yahoo.com wrote: Compilation fails with the following errors. C:\Program Files\Microsoft Visual Studio 8\VC\include\sys/types.h(23): fatal error C1189: #error : ERROR: Only Win32 target supported! This seems something very trivial but I have'nt been able to figure it out yet How exactly did you run the build? Just ran build.bat, or do something else? I use MSVC 2005 M$ Plaform SDK v6.0 ... I have updated the LIB, PATH and INCLUDE . echo'ing from the VC command prompt shows that its in the path. Bison version 2.1 and Flex 2.5.4 It doesn't look like this should be the error - possibly that it's including something else (non-pg and non-platformsdk) *before* it reaches the proper files. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
2009/7/30 Pavel Stehule pavel.steh...@gmail.com: 2009/7/29 Brendan Jurd dire...@gmail.com: I don't see any problem with extending this to allow up to 3 exponent digits ... Pavel, any comment? I am not sure - this function should be used in reports witl fixed line's width. And I am thinking, so it's should be problem - I prefer showing some #.### chars. It's clean signal, so some is wrong, but it doesn't break generating long run reports (like exception in Oracle) and doesn't broke formating like 3 exponent digits. Hmm. For what it's worth, I think Pavel makes a good point about the number of exponent digits -- a large chunk of the use case for numeric formatting would be fixed-width reporting. Limiting to two exponent digits also has the nice property that the output always matches the length of the format pattern: 9.99 1.23E+02 I don't know whether being able to represent 3-digit exponents outweighs the value of reliable fixed-width output. Would anyone else care to throw in their opinion? However we end up handling it, we will probably need to flesh out the docs regarding this. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: Revise parallel pg_restore's scheduling heuristic
Kevin Grittner kevin.gritt...@wicourts.gov wrote: with the default settings, the patched version ran an additional 1% faster than the unpatched; although I don't have enough samples to have a high degree of confidence it wasn't noise. I'll run another slew of tests tonight with the existing dump file to confirm to debunk that result The timings vary by up to 2.5% between runs, so that's the noise level. Five runs of each (alternating between the two) last night give an average performance of 1.89% faster for the patched version. Combining that with yesterday's results starts to give me pretty good confidence that the patch is beneficial for this database with this configuration. I haven't found any database or configuration where it hurts. (For most tests, adding up the results gave a net difference measured in thousandths of a percent.) Is that good enough, or is it still worth the effort of constructing the artificial case where it might *really* shine? Or should I keep running with the real database a few more nights to get a big enough sample to further increase the confidence level with this test? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Brendan Jurd escreveu: Hmm. For what it's worth, I think Pavel makes a good point about the number of exponent digits -- a large chunk of the use case for numeric formatting would be fixed-width reporting. But it doesn't cover all numbers in the interval. And in this case, all numbers can be easily represented. Limiting to two exponent digits also has the nice property that the output always matches the length of the format pattern: 9.99 1.23E+02 I don't think neglecting to represent a valid number is a nice property. What does the length of format pattern have to do with output format? -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Brendan Jurd escreveu: I can't imagine anyone reading the code getting confused about this, and don't know how to go about writing a comment explaining something that is intuitively obvious to me. I don't understand what aspect of it requires explanation. The test is not in the switch because it doesn't belong there. It was just a suggestion. If you think it is self-explanatory, so it is. But I (as the first time reading that piece of code) take some time to figure out why that test is outside the switch. -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
On Thu, Jul 30, 2009 at 12:17 PM, Euler Taveira de Oliveiraeu...@timbira.com wrote: Brendan Jurd escreveu: I can't imagine anyone reading the code getting confused about this, and don't know how to go about writing a comment explaining something that is intuitively obvious to me. I don't understand what aspect of it requires explanation. The test is not in the switch because it doesn't belong there. It was just a suggestion. If you think it is self-explanatory, so it is. But I (as the first time reading that piece of code) take some time to figure out why that test is outside the switch. I don't think we should worry about this particular issue too much. If the biggest problem this patch has is whether or not this deserves a comment, we're doing well; the committer can (and doubtless will) adjust that as they may see fit. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote: 2009/7/30 Pavel Stehule pavel.steh...@gmail.com: 2009/7/29 Brendan Jurd dire...@gmail.com: I don't see any problem with extending this to allow up to 3 exponent digits ... Pavel, any comment? I am not sure - this function should be used in reports witl fixed line's width. And I am thinking, so it's should be problem - I prefer showing some #.### chars. It's clean signal, so some is wrong, but it doesn't break generating long run reports (like exception in Oracle) and doesn't broke formating like 3 exponent digits. Hmm. For what it's worth, I think Pavel makes a good point about the number of exponent digits -- a large chunk of the use case for numeric formatting would be fixed-width reporting. Limiting to two exponent digits also has the nice property that the output always matches the length of the format pattern: 9.99 1.23E+02 I don't know whether being able to represent 3-digit exponents outweighs the value of reliable fixed-width output. Would anyone else care to throw in their opinion? However we end up handling it, we will probably need to flesh out the docs regarding this. Well, what if my whole database is full of numbers with three and four digit exponents? Do I have an out, or am I just hosed? Apologies if this is a stupid question, I haven't read this patch. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
2009/7/30 Robert Haas robertmh...@gmail.com: On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote: 2009/7/30 Pavel Stehule pavel.steh...@gmail.com: 2009/7/29 Brendan Jurd dire...@gmail.com: I don't see any problem with extending this to allow up to 3 exponent digits ... Pavel, any comment? I am not sure - this function should be used in reports witl fixed line's width. And I am thinking, so it's should be problem - I prefer showing some #.### chars. It's clean signal, so some is wrong, but it doesn't break generating long run reports (like exception in Oracle) and doesn't broke formating like 3 exponent digits. Hmm. For what it's worth, I think Pavel makes a good point about the number of exponent digits -- a large chunk of the use case for numeric formatting would be fixed-width reporting. Limiting to two exponent digits also has the nice property that the output always matches the length of the format pattern: 9.99 1.23E+02 I don't know whether being able to represent 3-digit exponents outweighs the value of reliable fixed-width output. Would anyone else care to throw in their opinion? However we end up handling it, we will probably need to flesh out the docs regarding this. Well, what if my whole database is full of numbers with three and four digit exponents? Do I have an out, or am I just hosed? Maybe we should to support some modificator like Large - L or E ?? that it use 3-digit exponents Pavel Apologies if this is a stupid question, I haven't read this patch. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
2009/7/31 Euler Taveira de Oliveira eu...@timbira.com: Brendan Jurd escreveu: Limiting to two exponent digits also has the nice property that the output always matches the length of the format pattern: 9.99 1.23E+02 I don't think neglecting to represent a valid number is a nice property. What does the length of format pattern have to do with output format? Most of the format patterns in to_char() are chosen to match the length of their expected output. The output of DD is two characters, Mon is three and so on. That's why the scientific notation pattern is and not just E. There're certainly exceptions though. SG is actually output as one character, and expands to however many digits you happen to have in your year value. In fact is probably our closest analogy in to_char() to the number of digits in the exponent. In almost all cases, it will come out as four characters but for extraordinarily large values it will occupy more characters as necessary. This breaks fixed-width, but is probably a better outcome than failure to represent the value. If we apply the same logic to then it should expand to admit whatever exponent was given to it. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Pavel Stehule pavel.steh...@gmail.com writes: 2009/7/30 Robert Haas robertmh...@gmail.com: On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote: Hmm. For what it's worth, I think Pavel makes a good point about the number of exponent digits -- a large chunk of the use case for numeric formatting would be fixed-width reporting. +1. If you aren't trying to get the format exactly so, it's not clear why you're bothering with to_char() at all. Maybe we should to support some modificator like Large - L or E Five (or more?) E's seems like a natural extension to me. However, that still leaves us with the question of what to do when the exponent doesn't fit in however many digits we'd like to print. Seems like the options are * print #'s * force the output wider * throw an error None of these are very nice, but the first two could cause problems that you don't find out until it's too late to fix. What about throwing an error? Sorry if this was already covered in the thread, but: anybody know what Oracle does for this? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest Status Summary - 2009-07-25
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: ... One thing I have belatedly realized about this CommitFest is that we (or at least, I) did not think about asking the committers about their schedules, and it turns out that three of them - Heikki, Michael Meskes, Joe Conway - are away at the moment. About 25% of the remaining patches are waiting for one of those three people to take the next step (as either patch author, or reviewer, or committer). Well, any commitfest is going to have some issues of that sort, especially one scheduled during the summer. If we get to the point where those patches are the only ones left, and the relevant people still aren't back, I think we can just push them all to the next fest. But I doubt we are moving fast enough to make that happen. I just got home last night, and am currently plowing through my pg mailing list queue. I should be able to make progress before the weekend is out. Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iQIcBAEBCAAGBQJKcdITAAoJEDfy90M199hle5cP/1AiepmKpBO0LONGzX3Lu0JW L/ilfv0Ea3L/YRksld9YjaVZgMjtMXhF/srHP2L1nyTylKTeFIfYLTwjAWz79bf3 S1yamofxSvfzYYLhRcTEHE6MXaQwrGJwkzkcgsHM2E8TJm4xdFOqIqsTUqI5ExOS PclWH1W8GWC8grJ4+kzN2kOEh5hQcdq+zZeFQP5C405TVjP+AQJu3uXR44VtlExL q1VOxICUwWiXldqCiFhE6AWX1RSWWhfoaP6lkVmySyn2QVyK2JFmuF8r1XUhE7qW H/Oya7NOz3aDjziNZc20ggW63KwjLxddeCE1kkuqnnNLNEeKcbPykcZUlVgfZevv 1X71KSPNw/eMtTItkGqSEIYW7LZ622uOT1VOC0ZZcKhSnDVh7KTloiGhjUVPYeCJ SqocXN6kR1qA2z6iAxuxIZE2yl8xMA9EGecVuxDdiO/SS9cgBAgD3gxSgzsoUt7F rL+IK25+dErynMzDcVK7ZJEvQd5m8YjMAKEPLzs6ELjlt9yA6E+P8c/Tx+nEvCEu Ac+ayVsklLx8fbg4PCFY+dD7nSDEqX/1yYtZdx+6T23vx6VcAAcTVwU/O/g5FGKw 7ovpL2ruL/Gx9X527Vs2hBHOWG4odtsFyIvsQz/ZsDNftIJ7kkCgitscE8KKF4ha Im4yCTz6hpF2CBfKyYSF =rcGM -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
On Thu, Jul 30, 2009 at 12:46 PM, Tom Lanet...@sss.pgh.pa.us wrote: Pavel Stehule pavel.steh...@gmail.com writes: 2009/7/30 Robert Haas robertmh...@gmail.com: On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote: Hmm. For what it's worth, I think Pavel makes a good point about the number of exponent digits -- a large chunk of the use case for numeric formatting would be fixed-width reporting. +1. If you aren't trying to get the format exactly so, it's not clear why you're bothering with to_char() at all. Maybe we should to support some modificator like Large - L or E Five (or more?) E's seems like a natural extension to me. However, that still leaves us with the question of what to do when the exponent doesn't fit in however many digits we'd like to print. Seems like the options are The tricky thing here is that there are two independent parameters here - the MINIMUM number of exponent digits you want (which might be 1, 2, 3, or more), and the MAXIMUM number of exponent digits you want (which might be the same as minimum, or a larger number, or infinity). ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Brendan Jurd escreveu: 2009/7/31 Euler Taveira de Oliveira eu...@timbira.com: Brendan Jurd escreveu: Limiting to two exponent digits also has the nice property that the output always matches the length of the format pattern: 9.99 1.23E+02 I don't think neglecting to represent a valid number is a nice property. What does the length of format pattern have to do with output format? Most of the format patterns in to_char() are chosen to match the length of their expected output. The output of DD is two characters, Mon is three and so on. Brendan, the main point of to_*() functions is Oracle-compatibility. So let's just do it. No matter it seems bizarre (like 999.99). That's why the scientific notation pattern is and not just E. I don't know. Ask Oracle. ;) We don't need to bother with that. Let's just be compatible. -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
2009/7/30 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: 2009/7/30 Robert Haas robertmh...@gmail.com: On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote: Hmm. For what it's worth, I think Pavel makes a good point about the number of exponent digits -- a large chunk of the use case for numeric formatting would be fixed-width reporting. +1. If you aren't trying to get the format exactly so, it's not clear why you're bothering with to_char() at all. Maybe we should to support some modificator like Large - L or E Five (or more?) E's seems like a natural extension to me. However, that still leaves us with the question of what to do when the exponent doesn't fit in however many digits we'd like to print. Seems like the options are * print #'s * force the output wider * throw an error None of these are very nice, but the first two could cause problems that you don't find out until it's too late to fix. What about throwing an error? I thing, so Oracle raise error. But I don't thing, so it is necessary repeat all Oracle the behave - mainly when is maybe not too much practical. * print #s, and force the output wider has one disadvantage - it cannot put clean signal about data problem in development time, maybe we should to add raise warning. * throw an error should to break bad written application in production, when is too late too. So anybody should have not complete test data set and there are a problem. I prefer print # with raising an warning. Pavel Sorry if this was already covered in the thread, but: anybody know what Oracle does for this? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: Revise parallel pg_restore's scheduling heuristic
Kevin Grittner kevin.gritt...@wicourts.gov writes: The timings vary by up to 2.5% between runs, so that's the noise level. Five runs of each (alternating between the two) last night give an average performance of 1.89% faster for the patched version. Combining that with yesterday's results starts to give me pretty good confidence that the patch is beneficial for this database with this configuration. I haven't found any database or configuration where it hurts. (For most tests, adding up the results gave a net difference measured in thousandths of a percent.) Is that good enough, or is it still worth the effort of constructing the artificial case where it might *really* shine? Or should I keep running with the real database a few more nights to get a big enough sample to further increase the confidence level with this test? I think we've pretty much established that it doesn't make things *worse*, so I'm sort of inclined to go ahead and apply it. The theoretical advantage of eliminating O(N^2) search behavior seems like reason enough, even if it takes a ridiculous number of tables for that to become significant. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: Revise parallel pg_restore's scheduling heuristic
On Thu, Jul 30, 2009 at 1:24 PM, Tom Lanet...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: The timings vary by up to 2.5% between runs, so that's the noise level. Five runs of each (alternating between the two) last night give an average performance of 1.89% faster for the patched version. Combining that with yesterday's results starts to give me pretty good confidence that the patch is beneficial for this database with this configuration. I haven't found any database or configuration where it hurts. (For most tests, adding up the results gave a net difference measured in thousandths of a percent.) Is that good enough, or is it still worth the effort of constructing the artificial case where it might *really* shine? Or should I keep running with the real database a few more nights to get a big enough sample to further increase the confidence level with this test? I think we've pretty much established that it doesn't make things *worse*, so I'm sort of inclined to go ahead and apply it. The theoretical advantage of eliminating O(N^2) search behavior seems like reason enough, even if it takes a ridiculous number of tables for that to become significant. That makes sense to me, but OTOH if Kevin's willing to be more testing on some artificial cases, particularly the interleaved-index-names case, I think those results would be interesting too. We already know that the slowness of dump + restore is a big issue, so any data we can gather to understand it better (and perhaps eventually design further improvements) seems like it would be time well spent. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: Revise parallel pg_restore's scheduling heuristic
Tom Lane t...@sss.pgh.pa.us wrote: I think we've pretty much established that it doesn't make things *worse*, so I'm sort of inclined to go ahead and apply it. The theoretical advantage of eliminating O(N^2) search behavior seems like reason enough, even if it takes a ridiculous number of tables for that to become significant. Agreed, although I'm having some concerns about whether this should proceed based exclusively on my benchmarks. On a thread on the performance list, people are talking about restores which go several times faster with parallel restore (compared to a single job). On my hardware, I haven't even gotten it to run twice as fast. This means that parallel restore is not a good fit for servers like we have, at least with databases like we have, which means it's probably a poor environment to get benchmarks for this patch. :-( Can we get someone who has benchmarks showing parallel restore to be eight times the speed of a single job to benchmark with this patch, just for confirmation? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] improvements for dict_xsyn extended synonym dictionary - RRR
kar...@sao.ru (Sergey V. Karpov) writes: Andres Freund and...@anarazel.de writes: Looks nice. The only small gripe I have is that the patch adds trailing whitespaces at a lot of places... My fault. Please check the patch version attached - I've tried to fix all those. I did some minor cleanup on this patch: * make the two parsing loops less confusingly different * remove unused 'pos' field of Syn * avoid some unnecessary pallocs * improve the comments and docs a bit I think it's ready for committer too, but the committer I have in mind is Teodor --- he's the ultimate expert on tsearch stuff. Teodor, have you got time to look this over and commit it? regards, tom lane bin6EDiXbmqbR.bin Description: dict_xsyn_3.patch.gz -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PATCH: make plpgsql IN args mutable (v1)
Since I didn't get completely shot out of the water and a couple people seemed to think it was helpful, I'm submitting this patch for consideration in the next commitfest. This patch changes plpgsql IN parameters so they are mutable. Previously, they were being forced constant. This patch modifies the plpgsql.sql regression test and corresponding .out file. The regression test also makes sure the passed in parameter does not get changed in the calling function. I decided not to update the docs for this change because the docs don't currently indicate that an IN parameter is constant and I didn't want to encourage it because it isn't universally considered good programming practice to assign to an IN parameter. If others think we need a doc change for this, I'll update the patch. The following function will compile with this patch: create or replace function param_assign_test(a int, val int) returns void as $$ begin a := val; end $$ language plpgsql; This function would have failed to compile previously. -Steve plpgsql_in_args_mutable-v1.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1)
On Thu, Jul 30, 2009 at 4:37 PM, Steve Prenticeprent...@cisco.com wrote: Since I didn't get completely shot out of the water and a couple people seemed to think it was helpful, I'm submitting this patch for consideration in the next commitfest. This patch changes plpgsql IN parameters so they are mutable. Previously, they were being forced constant. This patch modifies the plpgsql.sql regression test and corresponding .out file. The regression test also makes sure the passed in parameter does not get changed in the calling function. I decided not to update the docs for this change because the docs don't currently indicate that an IN parameter is constant and I didn't want to encourage it because it isn't universally considered good programming practice to assign to an IN parameter. If others think we need a doc change for this, I'll update the patch. The following function will compile with this patch: create or replace function param_assign_test(a int, val int) returns void as $$ begin a := val; end $$ language plpgsql; This function would have failed to compile previously. We're in the middle of a CommitFest right now for which the deadline for submissions was 2009-07-14. Please go to https://commitfest.postgresql.org/action/commitfest_view/open and add your patch there. Thanks, ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] mixed, named notation support
--On Montag, Juli 27, 2009 15:24:12 +0200 Bernd Helmle maili...@oopsware.de wrote: Hi, I sending a little bit modified version - I removed my forgotten comment in gram.y Thanks, i'll look on it asap. Looks good now. Here is a slightly edited reviewed patch version. I've edited the docs and fixed some spelling errors in a few error messages. It seems the patch mangled some source comments in namespace.c, i've rearranged them and tried to explain the purpose of VerifyCandidateNamedNotation(). I'm continuing reviewing this but can't get on it again until sunday. Pavel, can you have a look at the docs part of this patch and watch out for any gotchas? -- Thanks Bernd named_and_mixed_notation_review2.patch.gz Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bytea vs. pg_dump
--On Freitag, Juli 24, 2009 20:50:16 +0200 Bernd Helmle maili...@oopsware.de wrote: I don't believe i can do very much this weekend... I have to delay that until sunday, but will get my hands on some performance and function tests again, since i have access on the customer machine then. -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] RFD: Don't force plpgsql IN parameters to constant
Tom Lane wrote: Steve Prentice prent...@cisco.com writes: On Jul 29, 2009, at 4:55 PM, Steve Prentice wrote: Tom added a comment in 1995 For the record, I meant 2005. I was intending to say something like I've been around this project a long time, but not THAT long ... I was looking at a 1997 pgsql-hackers mailbox yesterday and I noticed that tgl back then was Thomas Lockhart. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1)
On Thu, Jul 30, 2009 at 05:06:17PM -0400, Robert Haas wrote: On Thu, Jul 30, 2009 at 4:37 PM, Steve Prenticeprent...@cisco.com wrote: Since I didn't get completely shot out of the water and a couple people seemed to think it was helpful, I'm submitting this patch for consideration in the next commitfest. This patch changes plpgsql IN parameters so they are mutable. Previously, they were being forced constant. This patch modifies the plpgsql.sql regression test and corresponding .out file. The regression test also makes sure the passed in parameter does not get changed in the calling function. Wouldn't INOUT parameters cover this case? Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1)
On Thu, 2009-07-30 at 17:40 -0700, David Fetter wrote: This patch changes plpgsql IN parameters so they are mutable. Previously, they were being forced constant. This patch modifies the plpgsql.sql regression test and corresponding .out file. The regression test also makes sure the passed in parameter does not get changed in the calling function. Wouldn't INOUT parameters cover this case? That was my first, thought, but I don't think it solves his concern. The out parameters are returned as part of a record, but he actually wants to mutate the value passed in. If mutable IN parameters were allowed, I don't even think it could be allowable to call them from the SQL level, you could only from another function. For instance, what would it mean if you did something like: SELECT foo(a) FROM mytable; Where foo() mutated it's IN argument? Would that really be an UPDATE? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1)
Jeff Davis wrote: If mutable IN parameters were allowed, I don't even think it could be allowable to call them from the SQL level, you could only from another function. For instance, what would it mean if you did something like: SELECT foo(a) FROM mytable; Where foo() mutated it's IN argument? Would that really be an UPDATE? No, surely the mutated value will only be visible within the scope of the function, i.e. it will be a purely local copy that gets altered. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] xpath not a good replacement for xpath_string
On Jul 29, 2009, at 12:12 PM, Andrew Dunstan wrote: As I said upthread, I think we can easily provide some extra convenience functions which will do what you want. The only thing I was really arguing about was the function name for such a gadget. +1. xpath_string does seem unfortunate, but I'm not offended by it. =) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1)
On Thu, 2009-07-30 at 21:45 -0400, Andrew Dunstan wrote: For instance, what would it mean if y SELECT foo(a) FROM mytable; Where foo() mutated it's IN argument? Would that really be an UPDATE? No, surely the mutated value will only be visible within the scope of the function, i.e. it will be a purely local copy that gets altered. Oh, I misunderstood the example here: http://archives.postgresql.org/pgsql-hackers/2009-07/msg01931.php I thought he was saying that the PERFORM in test1() _should_ have mutated a, when in fact, he was trying to demonstrate that it does not (with his patch or without). Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
