[PATCHES] update for brazilian portuguese translation
Hi, I have updated the brazilian portuguese translation. I just revised libpq, psql, pg_dump, pgscripts, pg_controldata, pg_resetxlog and jdbc. I just finished the translation of postgres. Now, postgresql is 100% in pt_BR. :) This is a big file, so I put it here: http://www.ufgnet.ufg.br/euler/translation_7_4_pt_BR.tgz Please apply. Regards, -- Euler Taveira de Oliveira euler (at) ufgnet.ufg.br Desenvolvedor Web e Administrador de Sistemas UFGNet - Universidade Federal de Goiás ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] update for brazilian portuguese translation
Euler Taveira de Oliveira wrote: I have updated the brazilian portuguese translation. I just revised libpq, psql, pg_dump, pgscripts, pg_controldata, pg_resetxlog and jdbc. I just finished the translation of postgres. Now, postgresql is 100% in pt_BR. :) Cool! This is a big file, so I put it here: http://www.ufgnet.ufg.br/euler/translation_7_4_pt_BR.tgz Please apply. Done. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] add WITH OIDS to CREATE TABLE AS
Tom Lane [EMAIL PROTECTED] writes:
One thing that is *not* fine is something that I see had snuck past
me in the previous WITH OIDS patch. It is not okay for gram.y or
scan.l to be looking at GUC variables --- that creates
synchronization issues.
Good point (I remember reading gram.y's warning about this, but it
must have slipped my mind...). Attached is a revised patch that
corrects this.
-Neil
Index: doc/src/sgml/runtime.sgml
===
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.227
diff -c -r1.227 runtime.sgml
*** doc/src/sgml/runtime.sgml 13 Dec 2003 23:59:06 - 1.227
--- doc/src/sgml/runtime.sgml 7 Jan 2004 02:29:15 -
***
*** 2437,2453
termvarnamedefault_with_oids/varname (typeboolean/type)/term
listitem
para
! This controls whether commandCREATE TABLE/command will
! include OIDs in newly-created tables, if neither literalWITH
! OIDS/literal or literalWITHOUT OIDS/literal have been
! specified. It also determines whether OIDs will be included in
! the table generated by commandSELECT INTO/command and
! commandCREATE TABLE AS/command. In
productnamePostgreSQL/productname version;
! varnamedefault_with_oids/varname defaults to true. This is
! also the behavior of previous versions of
! productnamePostgreSQL/productname. However, assuming that
! tables will contain OIDs by default is not
encouraged. Therefore, this option will default to false in a
future release of productnamePostgreSQL/productname.
/para
--- 2437,2453
termvarnamedefault_with_oids/varname (typeboolean/type)/term
listitem
para
! This controls whether commandCREATE TABLE/command
! and commandCREATE TABLE AS/command will include OIDs in
! newly-created tables, if neither literalWITH OIDS/literal
! or literalWITHOUT OIDS/literal have been specified. It
! also determines whether OIDs will be included in the table
! created by commandSELECT INTO/command. In
productnamePostgreSQL/productname version;
! varnamedefault_with_oids/varname defaults to
! true. This is also the behavior of previous versions
! of productnamePostgreSQL/productname. However, assuming
! that tables will contain OIDs by default is not
encouraged. Therefore, this option will default to false in a
future release of productnamePostgreSQL/productname.
/para
Index: doc/src/sgml/ref/create_table_as.sgml
===
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/create_table_as.sgml,v
retrieving revision 1.19
diff -c -r1.19 create_table_as.sgml
*** doc/src/sgml/ref/create_table_as.sgml 13 Dec 2003 23:59:07 - 1.19
--- doc/src/sgml/ref/create_table_as.sgml 7 Jan 2004 03:18:20 -
***
*** 20,26
refsynopsisdiv
synopsis
! CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE replaceabletable_name/replaceable [ (replaceablecolumn_name/replaceable [, ...] ) ]
AS replaceablequery/replaceable
/synopsis
/refsynopsisdiv
--- 20,26
refsynopsisdiv
synopsis
! CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE replaceabletable_name/replaceable [ (replaceablecolumn_name/replaceable [, ...] ) ] [ [ WITH | WITHOUT ] OIDS ]
AS replaceablequery/replaceable
/synopsis
/refsynopsisdiv
***
*** 99,104
--- 99,118
/varlistentry
varlistentry
+ termliteralWITH OIDS/literal/term
+ termliteralWITHOUT OIDS/literal/term
+ listitem
+ para
+This optional clause specifies whether the table created by
+commandCREATE TABLE AS/command should include OIDs. If
+neither form of this clause if specified, the value of the
+varnamedefault_with_oids/varname configuration parameter is
+used.
+ /para
+ /listitem
+/varlistentry
+
+varlistentry
termreplaceablequery/replaceable/term
listitem
para
***
*** 121,143
This command is functionally similar to xref
linkend=sql-selectinto endterm=sql-selectinto-title, but it is
preferred since it is less likely to be confused with other uses of
!the commandSELECT INTO/command syntax.
/para
para
!Prior to productnamePostgreSQL/ 7.5, commandCREATE TABLE
!AS/command always included OIDs in the table it
produced. Furthermore, these OIDs were newly generated: they were
distinct from the OIDs of any of the rows in the source tables of
the commandSELECT/command or commandEXECUTE/command
statement. Therefore, if commandCREATE TABLE AS/command was
frequently executed, the OID counter would be rapidly
!incremented. As of
Re: [PATCHES] add WITH OIDS to CREATE TABLE AS
Neil Conway wrote: Bruce Momjian [EMAIL PROTECTED] writes: Couldn't we use SET only when we need to change the existing value? I'm not sure what you mean. The pg_dump output will look like: -- at the top of the dump SET default_with_oids = false; -- or true, doesn't really matter -- for a table that doesn't have OIDs CREATE TABLE (...); -- for a table that does have OIDs SET default_with_oids = true; CREATE TABLE (...); SET default_with_oids = false; The point is that in this example if all the tables in the DB have OIDs, you'll emit two SETs for each CREATE TABLE, so what you'd really like is to have chosen a different default to begin with. Anyway, it's just an implementation detail: I'll definitely implement it one way or another in time for 7.5 (unless someone else would like to do it, in which case I'd gladly step aside). I assume we would _remember_ the current with_oids value inside pg_dump. For example, if I create two tables as user 'guest', I see in pg_dump output: SET SESSION AUTHORIZATION 'guest'; -- -- Name: g1; Type: TABLE; Schema: public; Owner: guest -- CREATE TABLE g1 ( x integer ) WITH OIDS; -- -- Name: g2; Type: TABLE; Schema: public; Owner: guest -- CREATE TABLE g2 ( x integer ) WITH OIDS; SET SESSION AUTHORIZATION 'postgres'; Notice that only one SESSION AUTHORIZATION is used for guest. Can't we do the same for WITH/WITHOUT OIDS? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] SIGPIPE handling
Here is my solution to ignoring SIGPIPE in libpq's send() for threaded apps. It defines a custom SIGPIPE handler if one is not already defined by the application, and uses a thread-local variable that is checked in the SIGPIPE handler to know if the SIGPIPE was caused by a libpq send() call. The documentation is at the top of the patch. Changed from the description below is that applications can define their own SIGPIPE handler after establishing the first database connection. However, custom SIGPIPE handlers must check PQinSend() to determine if the signal should be ignored. --- pgman wrote: Attached is my idea for implementing safe SIGPIPE in threaded apps. The code has the same libpq behavior if not compiled using --enable-thread-safety. If compiled with that option, an app wanting to define its own SIGPIPE handler has to do so before connecting to a database. On first connection, the code checks to see if there is a SIGPIPE handler, and if not, installs its own, and creates a thread-local variable. Then, on each send(), it sets, calls send(), then clears the thread-local variable. The SIGPIPE handler checks the thread-local variable and either ignores or exits depending on whether it was in send(). Right now the thread-local variable is static to the file, but we could export it as a boolean so custom SIGPIPE handlers could check it and take action or ignore the signal just like our code. Not sure if that is a good idea or not. In fact, even cleaner, we could create a function that allows users to define their own SIGPIPE handler and it would be called only when not called by libpq send(), and it would work safely for threaded apps. I think the big problem with my approach is that it requires special custom SIGPIPE handler code even if the app isn't multi-threaded but libpq is compiled as multi-threaded. Another idea is to create PQsigpipefromsend() that returns true/false depending on whether the SIGPIPE was from libpq's send(). It could be a global variable set/cleared in non-threaded libpq and a thread-local variable in threaded libpq. It would allow the same API/behavior for both libpq versions and all custom SIGPIPE handlers using libpq would have to check it. The one good thing about the patch is that it ignores send() SIGPIPE, and gives default SIG_DFL behavior for libpq apps with no special app coding, with the downside of requiring extra cost for custom SIGPIPE handlers. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/libpq.sgml === RCS file: /cvsroot/pgsql-server/doc/src/sgml/libpq.sgml,v retrieving revision 1.144 diff -c -c -r1.144 libpq.sgml *** doc/src/sgml/libpq.sgml 13 Dec 2003 23:59:06 - 1.144 --- doc/src/sgml/libpq.sgml 7 Jan 2004 21:42:56 - *** *** 3587,3593 One restriction is that no two threads attempt to manipulate the same structnamePGconn/ object at the same time. In particular, you cannot issue concurrent commands from different threads through the same ! connection object. (If you need to run concurrent commands, start up multiple connections.) /para --- 3587,3593 One restriction is that no two threads attempt to manipulate the same structnamePGconn/ object at the same time. In particular, you cannot issue concurrent commands from different threads through the same ! connection object. (If you need to run concurrent commands, use multiple connections.) /para *** *** 3611,3616 --- 3611,3635 not thread-safe.indextermprimarycrypt/secondarythread safety// It is better to use the literalmd5/literal method, which is thread-safe on all platforms. + /para + + para + applicationlibpq/application must ignore literalSIGPIPE/ signals + generated internally by functionsend()/ calls to backend processes. + When productnamePostgreSQL/ is configured without + literal--enable-thread-safety/, applicationlibpq/ sets + literalSIGPIPE/ to literalSIG_IGN/ before each + functionsend()/ call and restores the original signal handler after + completion. When literal--enable-thread-safety/ is used, + applicationlibpq/ installs its own literalSIGPIPE/ handler + before the first database connection if no custom literalSIGPIPE/ + handler has been installed previously. This handler uses thread-local + storage to determine if a literalSIGPIPE/ signal has been generated + by an internal functionsend()/. If an application wants to install + its own literalSIGPIPE/ signal handler, it should call + functionPQinSend()/ to determine if it should ignore the + literalSIGPIPE/ signal. This function is
Re: [PATCHES] SIGPIPE handling
One issue I had is in the following function. How can I easily find the
current signal value without causing possible signal loss during
testing, or possible abort if signals were previously ignored. I could
use sigblock, and I think that would exist on a system that doesn't have
sigaction, but is it worth the portability issue? Does any platform
have threads and not sigaction?
---
+
+ pqsigfunc
+ pqsignalinquire(int signo)
+ {
+ #if !defined(HAVE_POSIX_SIGNALS)
+ pqsigfunc old;
+
+ /*
+ * We could lose a signal during this test.
+ * In a multi-threaded application, this might
+ * be a problem. Do any non-threaded platforms
+ * lack sigaction()?
+ */
+ old = signal(signo, SIG_IGN);
+ signal(signo, old);
+ return old;
+ #else
+ struct sigaction oact;
+
+ if (sigaction(signo, NULL, oact) 0)
+return SIG_ERR;
+ return oact.sa_handler;
+ #endif /* !HAVE_POSIX_SIGNALS */
+ }
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[PATCHES] psql error in \? output on \w line
As far as I can tell, the file argument for \w is required; this contradicts what \? says for it (namely that it's optional). A patch follows to fix this if it really is an error and not my misunderstanding. Zach Irmen === RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/help.c,v retrieving revision 1.84 diff -c -r1.84 help.c *** help.c 1 Dec 2003 22:34:48 - 1.84 --- help.c 8 Jan 2004 03:02:10 - *** *** 195,201 fprintf(output, _( \\p show the contents of the query buffer\n)); fprintf(output, _( \\r reset (clear) the query buffer\n)); fprintf(output, _( \\s [FILE] display history or save it to file\n)); ! fprintf(output, _( \\w [FILE] write query buffer to file\n)); fprintf(output, \n); fprintf(output, _(Input/Output\n)); --- 195,201 fprintf(output, _( \\p show the contents of the query buffer\n)); fprintf(output, _( \\r reset (clear) the query buffer\n)); fprintf(output, _( \\s [FILE] display history or save it to file\n)); ! fprintf(output, _( \\w FILEwrite query buffer to file\n)); fprintf(output, \n); fprintf(output, _(Input/Output\n)); ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] psql \i handling ~ in specified file name
Peter Eisentraut wrote:
Zach Irmen wrote:
refers to following item on TODO
Have psql '\i ~/tabtab' actually load files it displays from home
dir
This expansion should also apply to all other commands that take file
names.
Here is a patch that handles ~ in all the file cases. Thanks for the
initial patch.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/bin/psql/command.c
===
RCS file: /cvsroot/pgsql-server/src/bin/psql/command.c,v
retrieving revision 1.108
diff -c -c -r1.108 command.c
*** src/bin/psql/command.c 1 Dec 2003 22:21:54 - 1.108
--- src/bin/psql/command.c 8 Jan 2004 05:17:35 -
***
*** 65,70
--- 65,72
static bool do_connect(const char *new_dbname, const char *new_user);
static bool do_shell(const char *command);
+ static char *expand_tilde(char **filename);
+
/*--
* HandleSlashCmds:
*
***
*** 413,418
--- 415,421
else
{
fname = scan_option(string, OT_NORMAL, NULL, true);
+ expand_tilde(fname);
status = do_edit(fname, query_buf) ? CMD_NEWEDIT : CMD_ERROR;
free(fname);
}
***
*** 494,500
--- 497,506
if (!fname)
pset.gfname = NULL;
else
+ {
+ expand_tilde(fname);
pset.gfname = xstrdup(fname);
+ }
free(fname);
status = CMD_SEND;
}
***
*** 531,536
--- 537,543
}
else
{
+ expand_tilde(fname);
success = (process_file(fname) == EXIT_SUCCESS);
free(fname);
}
***
*** 602,607
--- 609,615
{
char *fname = scan_option(string, OT_FILEPIPE, NULL, true);
+ expand_tilde(fname);
success = setQFout(fname);
free(fname);
}
***
*** 653,658
--- 661,667
{
char *fname = scan_option(string, OT_NORMAL, NULL, true);
+ expand_tilde(fname);
success = saveHistory(fname ? fname : /dev/tty);
if (success !quiet fname)
***
*** 771,776
--- 780,786
else
{
fname = scan_option(string, OT_FILEPIPE, NULL, true);
+ expand_tilde(fname);
if (!fname)
{
***
*** 1678,1683
--- 1688,1747
}
+ /* expand_tilde
+ *
+ * substitute '~' with HOME or '~username' with username's home dir
+ *
+ */
+ static char *
+ expand_tilde(char **filename)
+ {
+ if (!filename || !(*filename))
+ return NULL;
+
+ #ifndef WIN32
+
+ /* try tilde expansion */
+ if (**filename == '~')
+ {
+ char *fn;
+ char *home;
+ char oldp, *p;
+ struct passwd *pw;
+
+ fn = *filename;
+ home = NULL;
+
+ p = fn+1;
+ while (*p != '/' *p != '\0')
+ p++;
+
+ oldp = *p;
+ *p = '\0';
+
+ if (*(fn+1) == '\0')
+ home = getenv(HOME);
+ else if ((pw = getpwnam(fn+1)) != NULL)
+ home = pw-pw_dir;
+
+ *p = oldp;
+ if (home)
+ {
+ char *newfn;
+
+ newfn = malloc(strlen(home) + strlen(p) + 1);
+ strcpy(newfn,home);
+ strcat(newfn,p);
+
+ free(fn);
+ *filename = newfn;
+ }
+ }
+
+ #endif
+
+ return *filename;
+ }
/*
* process_file
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] SIGPIPE handling
Bruce Momjian wrote: + /* +* We could lose a signal during this test. +* In a multi-threaded application, this might +* be a problem. Do any non-threaded platforms Threaded or non-threaded? +* lack sigaction()? +*/ Additionally, the problem is not restricted to multithreaded apps: signal(,SIG_IGN) clears all pending signals. -- Manfred ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Patch of intarray module in v7.4.1
In 7.4.1, intarray module have a problme about equal operator (=).
select * from table where intarray_column = '{}';
above query make error.
because when not equal operator () is made,
this make incorrect equal operator by implicate.
so, I patched.
Patch content is here.
= BEGIN of FILE =
--- _int.sql.in.origThu Jun 12 03:44:15 2003
+++ _int.sql.in Wed Jan 7 13:14:37 2004
@@ -140,15 +140,15 @@
-- SORT2 = ''
--);
-CREATE OPERATOR (
- LEFTARG = _int4,
- RIGHTARG = _int4,
- PROCEDURE = _int_different,
- COMMUTATOR = '',
- NEGATOR = '=',
- RESTRICT = neqsel,
- JOIN = neqjoinsel
-);
+--CREATE OPERATOR (
+-- LEFTARG = _int4,
+-- RIGHTARG = _int4,
+-- PROCEDURE = _int_different,
+-- COMMUTATOR = '',
+-- NEGATOR = '=',
+-- RESTRICT = neqsel,
+-- JOIN = neqjoinsel
+--);
CREATE OPERATOR @ (
LEFTARG = _int4,
@@ -343,7 +343,7 @@
CREATE OPERATOR CLASS gist__int_ops
DEFAULT FOR TYPE _int4 USING gist AS
OPERATOR3 ,
- OPERATOR6 = RECHECK,
+ OPERATOR6 = (anyarray, anyarray) RECHECK,
OPERATOR7 @,
OPERATOR8 ~,
OPERATOR20 @@ (_int4, query_int),
@@ -418,7 +418,7 @@
FOR TYPE _int4 USING gist
AS
OPERATOR3 RECHECK,
- OPERATOR6 = RECHECK,
+ OPERATOR6 = (anyarray, anyarray) RECHECK,
OPERATOR7 @ RECHECK,
OPERATOR8 ~ RECHECK,
OPERATOR20 @@ (_int4, query_int) RECHECK,
= End of FILE =
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] psql \i handling ~ in specified file name
Bruce Momjian wrote: Here is a patch that handles ~ in all the file cases. Beat me to it. :) I do have a few issues that I was trying to sort out myself regarding this, but I guess now is as good a time as any to ask them here. First off, there should be a check after the malloc to make sure NULL wasn't returned in the expand_tilde function. I missed that one. Secondly, there are a couple of SQL commands (like COPY and LOAD) and psql commands handled outside command.c (like \copy) which also take filenames. I'm guessing that eventually you'll want substitution in those cases as well. So does this mean that the expand_tilde function probably should not be in command.c? Placing it in common.c seems the logical place to make it at least available to all the psql commands (\copy included). And finally, I was wondering if arguments with leading pipes (e.g. |~/file) should also get substituted. Zach Irmen ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
