Re: [PATCHES] Proposed patch to avoid translation risks in psql's \d commands
Tom Lane a écrit : > Guillaume Lelarge <[EMAIL PROTECTED]> writes: >> Tom Lane a écrit : >>> The attached patch does this, and seems to resolve Guillaume Lelarge's >>> original complaint. > >> It does resolve it. I applied your patch on my CVS HEAD checkout and it >> works just great. > > Patch is applied to CVS. > Thanks. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Proposed patch to avoid translation risks in psql's \d commands
Guillaume Lelarge <[EMAIL PROTECTED]> writes: > Tom Lane a écrit : >> The attached patch does this, and seems to resolve Guillaume Lelarge's >> original complaint. > It does resolve it. I applied your patch on my CVS HEAD checkout and it > works just great. Patch is applied to CVS. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] archiver ps display
Now that we have set archiver messages to DEBUG levels, there's no easy
way of seeing what file we are on.
Patch to set ps display for archiver enclosed, intended for 8.3
Before archive_command
postgres: archiver process archiving 0001000B
After archive_command
postgres: archiver process archived 0001000B
So the behaviour of the startup process and archiver are now
symmetrical, allowing it to be used for replication monitoring.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
Index: src/backend/postmaster/pgarch.c
===
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/postmaster/pgarch.c,v
retrieving revision 1.34
diff -c -r1.34 pgarch.c
*** src/backend/postmaster/pgarch.c 12 Dec 2007 09:39:54 - 1.34
--- src/backend/postmaster/pgarch.c 12 Dec 2007 21:01:52 -
***
*** 414,419
--- 414,420
{
char xlogarchcmd[MAXPGPATH];
char pathname[MAXPGPATH];
+ char activitymsg[MAXFNAMELEN + 16];
char *dp;
char *endp;
const char *sp;
***
*** 471,476
--- 472,482
ereport(DEBUG3,
(errmsg_internal("executing archive command \"%s\"",
xlogarchcmd)));
+
+ /* Report archive command execution in PS display */
+ snprintf(activitymsg, sizeof(activitymsg), "archiving %s", xlog);
+ set_ps_display(activitymsg, false);
+
rc = system(xlogarchcmd);
if (rc != 0)
{
***
*** 519,524
--- 525,533
ereport(DEBUG1,
(errmsg("archived transaction log file \"%s\"", xlog)));
+ snprintf(activitymsg, sizeof(activitymsg), "archived %s", xlog);
+ set_ps_display(activitymsg, false);
+
return true;
}
---(end of broadcast)---
TIP 1: 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] Proposed patch to avoid translation risks in psql's \d commands
Tom Lane a écrit : > I proposed here: > http://archives.postgresql.org/pgsql-hackers/2007-12/msg00436.php > that we change the way that psql deals with localization of column > names and other fixed strings in the output of \d and related commands > (basically, anything that calls printQuery()). Specifically, we should > avoid shipping already-translated strings to the server, because they > might not be in the expected encoding and also might contain quote > marks, which the existing code doesn't guard against. We can instead > apply the gettext() conversion when the query results come back from > the server. > > The attached patch does this, and seems to resolve Guillaume Lelarge's > original complaint. > It does resolve it. I applied your patch on my CVS HEAD checkout and it works just great. > I found just one place where the proposed new method doesn't work quite > as nicely as the old. In \dC (describe casts), the Function column > contains either a function name or '(binary compatible)' to indicate > a cast WITHOUT FUNCTION. The existing code is able to localize '(binary > compatible)', but this patch does not, because applying gettext to every > value in the column seems to pose an unacceptably high risk of > "translating" some function name that happens to match a string in > psql's .PO database. > > I'm inclined to just live with that, since it seems a relatively minor > deficiency, but I wonder if anyone has a better idea how to do it? > I have no problem with this. Other strings are not available for translation (for example RECORD # when using the \x command) and that's not really a big deal. Thanks. Regards. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] result of convert_to is bytea
Hello documentation fix. result of convert_to is bytea, not text. Regards Pavel Stehule *** ./src/sgml/func.sgml.orig 2007-12-12 17:18:55.0 +0100 --- ./src/sgml/func.sgml 2007-12-12 17:19:56.0 +0100 *** *** 1386,1392 convert_to(string text, dest_encoding name) !text Convert string to dest_encoding. --- 1386,1392 convert_to(string text, dest_encoding name) !bytea Convert string to dest_encoding. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] DDL in EDB-SPL
Pavel Stehule wrote: Wrong address :) O.k. now that makes more sense :) Joshua D. Drake Pavel On 12/12/2007, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: While looking at the package function precedence problem, I bumped into another unrelated bug: ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] DDL in EDB-SPL
Pavel Stehule wrote: Wrong address :) Shit! I knew this was going to happen eventually, because when I start to type "pa..." in the address bar, [EMAIL PROTECTED] is the first hit... Sorry for the noise, please ignore... -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] DDL in EDB-SPL
Wrong address :) Pavel On 12/12/2007, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > While looking at the package function precedence problem, I bumped into > another unrelated bug: > > According to a quick Google search, Oracle doesn't accept DDL in PL/SQL; > you have to use EXECUTE IMMEDIATE to do that. Trying to run DDL in the > edb-spl fails with a bizarre error message. For example, for CREATE > TABLE footable (full test case attached): > ERROR: syntax error at or near "footable" > LINE 1: CREATE footable2 (id integer) > > So the TABLE token seems to be stripped away somewhere. This begs the > question of what happens with CREATE TEMPORARY TABLE. Lo and behold, it > does what you might've guessed, kind of. TEMPORARY is stripped away, > leaving just "CREATE TABLE ". However, we've set the package > namespace as the special namespace, and that's the current "default > creation namespace". Therefore the table gets created inside the package > namespace. > > -- >Heikki Linnakangas >EnterpriseDB http://www.enterprisedb.com > > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster > > > ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] DDL in EDB-SPL
While looking at the package function precedence problem, I bumped into another unrelated bug: According to a quick Google search, Oracle doesn't accept DDL in PL/SQL; you have to use EXECUTE IMMEDIATE to do that. Trying to run DDL in the edb-spl fails with a bizarre error message. For example, for CREATE TABLE footable (full test case attached): ERROR: syntax error at or near "footable" LINE 1: CREATE footable2 (id integer) So the TABLE token seems to be stripped away somewhere. This begs the question of what happens with CREATE TEMPORARY TABLE. Lo and behold, it does what you might've guessed, kind of. TEMPORARY is stripped away, leaving just "CREATE TABLE ". However, we've set the package namespace as the special namespace, and that's the current "default creation namespace". Therefore the table gets created inside the package namespace. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com DROP PACKAGE foopack; CREATE PACKAGE foopack IS foovar integer; PROCEDURE fooproc; END; CREATE PACKAGE BODY foopack IS PROCEDURE fooproc IS BEGIN CREATE TEMPORARY TABLE footable2 (id integer); END; END; exec foopack.fooproc; ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
