Re: [PATCHES] Implementation of SQLSTATE and SQLERRM variables
Is this implementation is available in postgres 8.0.2 ? Or which version of Postgres? Thanks Dinesh Pandey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pavel Stehule Sent: Thursday, May 26, 2005 12:47 PM To: Neil Conway Cc: Bruce Momjian; pgsql-patches@postgresql.org; 'Tom Lane' Subject: Re: [PATCHES] Implementation of SQLSTATE and SQLERRM variables I think the docs need more than just these variables are set when an exception is raised. The patch current resets SQLSTATE and SQLERRM whenever a new block is entered. So: create function trap_exceptions() returns void as $_$ begin begin raise exception 'first exception'; exception when others then raise notice '% %', SQLSTATE, SQLERRM; begin raise notice '% %', SQLSTATE, SQLERRM; end; end; return; end; $_$ language plpgsql; The second RAISE will report successful completion. Is this the behavior we want? True, its foggy behave. Only if block contains exception than variables SQLSTATE and SQLERRM are created. Is SQLERRM the best name for that variable? It seems a little obscure to me. This name use Oracle in PL/SQL. ESQL Oracle and DB2 too. I think so is better use well knowed names for it than creating own. There is one argument for it. PL/pgSQL is language very similar Oracle PL/SQL. PL/SQL know SQLERRM, SQLCODE and SQLSTATE. An people which know PL/SQL will like use this names in Pg. Pavel Stehule -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Implementation of SQLSTATE and SQLERRM variables
Dinesh Pandey wrote: Is this implementation is available in postgres 8.0.2 ? Or which version of Postgres? At this time, it's not available anywhere. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] wchareq improvement
Bruce Momjian wrote: Patch applied with adjustment --- the second part of your patch that skips comparing the first byte seemed unnecessary. It seemed likely to cause a cpu stall, so just doing the loop seemed faster. Did you test if the second part of your patch actually caused a speedup? Well, I measured the performance today. As a result, I confirmed the second part of my patch is unnecessary as you pointed it out. Thanks for comment and applying patch. a_ogawa wrote: In SQL that uses 'like' operator, wchareq is used to compare characters. At the head of wchareq, length of (multibyte) character is compared by using pg_mblen. Therefore, pg_mblen is executed many times, and it becomes a bottleneck. regards, --- Atsushi Ogawa ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL (was Re: [HACKERS] Feature freeze date for 8.1)
Oliver Jowett [EMAIL PROTECTED] writes: Here's a patch that adds four new GUCs: tcp_keepalives (defaults to on, controls SO_KEEPALIVE) tcp_keepalives_idle (controls TCP_KEEPIDLE) tcp_keepalives_interval (controls TCP_KEEPINTVL) tcp_keepalives_count (controls TCP_KEEPCNT) Do you think the system defaults are really going to be port-specific? I'm slightly annoyed by the number of syscalls this adds to every connection startup ... getting rid of redundant getsockopt calls would help. Getting rid of redundant setsockopt calls (ie, a call to establish the value that we already know is in force) would help more. Alternatively, we could lose the frammish that PostgreSQL can tell you what the system defaults are: 0 in the GUC just means do nothing, not find out what the current setting is on the off chance that the user might want to know. Or, if you really think that's important, it could be left to the SHOW routines to extract the value on-demand. That is: GUC = 0: do nothing at connection start GUC != 0: setsockopt at connection start SHOW: do getsockopt and report result regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Fix for timestamp rouding
Michael Fuhr wrote: I'm getting time, timetz, and horology regression failures in HEAD on Solaris 9 / gcc 3.4.2. So are other machines in the build farm, such as this one: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=sharkdt=2005-05-26%2004:21:00 I'm getting the same regression failures shown in that link; here's an example: OK, I have a new patch, which simplifies the code by using TrimTrailingZeros(), gives more consistent subsecond display, and subpresses the rounding problem: test= select '2005 years 4 mons 20 days 15 hours 57 mins 12.1 secs ago'::interval; interval --- -2005 years -4 mons -20 days -15:57:12.10 (1 row) test= select '2005 years 4 mons 20 days 15 hours 57 mins 12.13 secs ago'::interval; interval --- -2005 years -4 mons -20 days -15:57:12.13 (1 row) test= select '2005 years 4 mons 20 days 15 hours 57 mins 12.134 secs ago'::interval; interval -2005 years -4 mons -20 days -15:57:12.134 (1 row) -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: src/backend/utils/adt/datetime.c === RCS file: /cvsroot/pgsql/src/backend/utils/adt/datetime.c,v retrieving revision 1.147 diff -c -c -r1.147 datetime.c *** src/backend/utils/adt/datetime.c26 May 2005 15:26:00 - 1.147 --- src/backend/utils/adt/datetime.c26 May 2005 18:10:03 - *** *** 3461,3472 #ifdef HAVE_INT64_TIMESTAMP sprintf(str + strlen(str), :%02d.%06d, tm-tm_sec, fsec); #else ! sprintf(str + strlen(str), :%013.10f, tm-tm_sec + fsec); #endif ! /* chop off trailing pairs of zeros... */ ! while (strcmp((str + strlen(str) - 2), 00) == 0 ! *(str + strlen(str) - 3) != '.') ! *(str + strlen(str) - 2) = '\0'; } else sprintf(str + strlen(str), :%02d, tm-tm_sec); --- 3461,3469 #ifdef HAVE_INT64_TIMESTAMP sprintf(str + strlen(str), :%02d.%06d, tm-tm_sec, fsec); #else ! sprintf(str + strlen(str), :%012.9f, tm-tm_sec + fsec); #endif ! TrimTrailingZeros(str); } else sprintf(str + strlen(str), :%02d, tm-tm_sec); *** *** 3804,3810 sprintf(cp, .%06d, Abs(fsec)); #else fsec += tm-tm_sec; ! sprintf(cp, :%013.10f, fabs(fsec)); #endif TrimTrailingZeros(cp); cp += strlen(cp); --- 3801,3807 sprintf(cp, .%06d, Abs(fsec)); #else fsec += tm-tm_sec; ! sprintf(cp, :%012.9f, fabs(fsec)); #endif TrimTrailingZeros(cp); cp += strlen(cp); Index: src/interfaces/ecpg/pgtypeslib/interval.c === RCS file: /cvsroot/pgsql/src/interfaces/ecpg/pgtypeslib/interval.c,v retrieving revision 1.19 diff -c -c -r1.19 interval.c *** src/interfaces/ecpg/pgtypeslib/interval.c 26 May 2005 16:44:05 - 1.19 --- src/interfaces/ecpg/pgtypeslib/interval.c 26 May 2005 18:10:04 - *** *** 511,517 sprintf(cp, .%06d, Abs(fsec)); #else fsec += tm-tm_sec; ! sprintf(cp, :%013.10f, fabs(fsec)); #endif TrimTrailingZeros(cp); cp += strlen(cp); --- 511,517 sprintf(cp, .%06d, Abs(fsec)); #else fsec += tm-tm_sec; ! sprintf(cp, :%012.9f, fabs(fsec)); #endif TrimTrailingZeros(cp); cp += strlen(cp); Index: src/test/regress/expected/horology.out === RCS file: /cvsroot/pgsql/src/test/regress/expected/horology.out,v retrieving revision 1.53 diff -c -c -r1.53 horology.out *** src/test/regress/expected/horology.out 7 Apr 2005 01:51:40 - 1.53 ---
Re: [PATCHES] Fix for timestamp rouding
Bruce Momjian pgman@candle.pha.pa.us writes: OK, I have a new patch, which simplifies the code by using TrimTrailingZeros(), gives more consistent subsecond display, and subpresses the rounding problem: Does anyone have any idea why the existing code is designed to keep the number of displayed fractional digits even? It seems a bit silly to me too, but we probably ought not remove what was clearly an intentional behavior without understanding why it was intentional. Also, I will point out once more that the problem is not we only have nine digits of precision not ten. The problem is that the precision degrades as the interval gets larger. regression=# select '20 days 15 hours 57 mins 12.1 secs ago'::interval; interval --- -20 days -15:57:12.11 (1 row) regression=# select '100020 days 15 hours 57 mins 12.1 secs ago'::interval; interval --- -100020 days -15:57:12.103815 (1 row) regression=# select '10020 days 15 hours 57 mins 12.1 secs ago'::interval; interval - -10020 days -15:57:12.099609375 (1 row) regression=# Without accounting for that fundamental fact, you will not have a solution, only a kluge. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL
Tom Lane wrote: Oliver Jowett [EMAIL PROTECTED] writes: Here's a patch that adds four new GUCs: tcp_keepalives (defaults to on, controls SO_KEEPALIVE) tcp_keepalives_idle (controls TCP_KEEPIDLE) tcp_keepalives_interval (controls TCP_KEEPINTVL) tcp_keepalives_count (controls TCP_KEEPCNT) Do you think the system defaults are really going to be port-specific? I don't understand what you mean. TCP_* override the system defaults on a per-connection basis, if that's what you mean. I'm slightly annoyed by the number of syscalls this adds to every connection startup ... getting rid of redundant getsockopt calls would help. Getting rid of redundant setsockopt calls (ie, a call to establish the value that we already know is in force) would help more. I originally did this but went in favor of simpler code. Are the extra syscalls an issue? I didn't think they were that expensive.. Alternatively, we could lose the frammish that PostgreSQL can tell you what the system defaults are: 0 in the GUC just means do nothing, not find out what the current setting is on the off chance that the user might want to know. I didn't do this as it meant that using SET tcp_whatever = 0 does *not* reset the setting to what you'd get with a value of 0 in postgresql.conf, which seemed confusing to me. This could all get simpler if we didn't allow per-connection changing of that GUC (i.e. set it once at startup and forget about it), which probably isn't unreasonable. I wonder if those socket options get inherited from the listening socket? Will check. -O ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Remove second argument from textToQualifiedNameList
Jaime Casanova wrote: i found out that the function textToQualifiedNameList doesn't use the second argument it receive (caller). i suppose in the past was used and now it is useless, if that is the case here is a patch removing. Or are any reasons to keep that argument? Applied to HEAD. Thanks for the patch. -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] psql backslash consistency
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Attached is my backslash consistency patch which basically makes all
the backslash commands behave as \dt does: \d* shows non-system objects,
and \d*S shows system objects. See the archives for more discussion on
this. I wrote this patch some time ago, and have been meaning to work on
enhancing the tab-completion stuff more. However, I'm going to leave it
as it is for now[1], and I've updated my patch to the recent cvs. This
was done hastily, so it definitely needs a looking over.
[1] I'd like to eventually fix psql so that \di [tab] only lists schemas
that actually contain possible indexes (or indexes), rather than the
current behavior which is to just list all schemas.
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200505261242
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-
iD8DBQFClfyjvJuQZxSWSsgRAv4aAJ48KPwfzYGpU80KcjS9/obMqKMK0wCgx+M0
hCAJLpFXpj72anOnb+2E0yg=
=ezLT
-END PGP SIGNATURE-
Index: command.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.143
diff -c -r1.143 command.c
*** command.c 29 Apr 2005 13:42:20 - 1.143
--- command.c 26 May 2005 20:09:37 -
***
*** 298,310
else if (cmd[0] == 'd')
{
char *pattern;
! bool show_verbose;
/* We don't do SQLID reduction on the pattern yet */
pattern = psql_scan_slash_option(scan_state,
OT_NORMAL, NULL, true);
show_verbose = strchr(cmd, '+') ? true : false;
switch (cmd[1])
{
--- 298,311
else if (cmd[0] == 'd')
{
char *pattern;
! bool show_verbose, show_system;
/* We don't do SQLID reduction on the pattern yet */
pattern = psql_scan_slash_option(scan_state,
OT_NORMAL, NULL, true);
show_verbose = strchr(cmd, '+') ? true : false;
+ show_system = strchr(cmd, 'S') ? true: false;
switch (cmd[1])
{
***
*** 314,341
success = describeTableDetails(pattern, show_verbose);
else
/* standard listing of interesting things */
! success = listTables(tvs, NULL, show_verbose);
break;
case 'a':
! success = describeAggregates(pattern, show_verbose);
break;
case 'b':
success = describeTablespaces(pattern, show_verbose);
break;
case 'c':
! success = listConversions(pattern);
break;
case 'C':
success = listCasts(pattern);
break;
case 'd':
! success = objectDescription(pattern);
break;
case 'D':
! success = listDomains(pattern);
break;
case 'f':
! success = describeFunctions(pattern, show_verbose);
break;
case 'g':
success = describeGroups(pattern);
--- 315,342
success = describeTableDetails(pattern, show_verbose);
else
/* standard listing of interesting things */
! success = listTables(tvs, NULL, show_verbose, show_system);
break;
case 'a':
! success = describeAggregates(pattern, show_verbose, show_system);
break;
case 'b':
success = describeTablespaces(pattern, show_verbose);
break;
case 'c':
! success = listConversions(pattern, show_system);
break;
case 'C':
success = listCasts(pattern);
break;
case 'd':
! success = objectDescription(pattern, show_system);
break;
case 'D':
! success = listDomains(pattern, show_system);
break;
case 'f':
! success = describeFunctions(pattern, show_verbose, show_system);
break;
case 'g':
success = describeGroups(pattern);
***
*** 347,366
success = listSchemas(pattern, show_verbose);
break;
case 'o':
! success = describeOperators(pattern);
break;
case 'p':
success = permissionsList(pattern);
break;
case 'T':
! success = describeTypes(pattern, show_verbose);
break;
case 't':
case 'v':
case 'i':
case 's':
case 'S':
! success = listTables(cmd[1], pattern, show_verbose);
break;
case 'u':
success = describeUsers(pattern);
--- 348,367
success = listSchemas(pattern, show_verbose);
break;
case 'o':
! success = describeOperators(pattern, show_system);
break;
case 'p':
success = permissionsList(pattern);
break;
case 'T':
! success = describeTypes(pattern, show_verbose, show_system);
break;
case 't':
case 'v':
case 'i':
case 's':
case 'S':
! success = listTables(cmd[1], pattern, show_verbose, show_system);
break;
case 'u':
success = describeUsers(pattern);
Index: describe.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.115
diff -c
Re: [PATCHES] psql backslash consistency
Greg Sabino Mullane [EMAIL PROTECTED] writes: Attached is my backslash consistency patch which basically makes all the backslash commands behave as \dt does: \d* shows non-system objects, and \d*S shows system objects. Could we have a way to turn this off? At least for functions and operators? For my usage, at least, this will be a serious step backwards in usefulness. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
