Re: [PATCHES] actualised execute using patch
On 25/03/2008, Zdenek Kotala [EMAIL PROTECTED] wrote:
you have extra space onPavel Stehule napsal(a):
Hello
http://archives.postgresql.org/pgsql-patches/2007-10/msg00161.php
I actualized this patch for current CVS
Hi Pavel,
I tested your patch and it works regarding to proposal. However
I have some small comments:
1) you have extra space in ./src/pl/plpgsql/src/gram.y on line 1351
I didn't find it
2) there is some Czech text in regression tests diffs
fixed
3) I would like to add two more tests:
a) test which check if execute really takes 3rd parameter and inject it as a
first one:
create or replace function test(int,int,int) returns int as $$
declare
a int;
begin
execute 'select $1' into a using $3;
return a;
end
$$ language plpgsql;
select test(1,2,3);
b) and second test which control number of arguments:
for example:
create or replace function test(int,int,int) returns int as $$
begin
execute 'select $3' into a using $1;
return a;
end
$$ language plpgsql;
select test(1,2,3);
I did it
Zdenek
*** ./doc/src/sgml/plpgsql.sgml.orig 2008-03-23 01:24:19.0 +0100
--- ./doc/src/sgml/plpgsql.sgml 2008-03-24 20:41:27.0 +0100
***
*** 1005,1011
commandEXECUTE/command statement is provided:
synopsis
! EXECUTE replaceable class=commandcommand-string/replaceable optional INTO optionalSTRICT/optional replaceabletarget/replaceable /optional;
/synopsis
where replaceablecommand-string/replaceable is an expression
--- 1005,1011
commandEXECUTE/command statement is provided:
synopsis
! EXECUTE replaceable class=commandcommand-string/replaceable optional INTO optionalSTRICT/optional replaceabletarget/replaceable /optional optional USING replaceable class=parameterexpression/replaceable optional, .../optional /optional;
/synopsis
where replaceablecommand-string/replaceable is an expression
***
*** 1046,1051
--- 1046,1066
If the literalSTRICT/ option is given, an error is reported
unless the query produces exactly one row.
/para
+
+ para
+ The commandEXECUTE/command statement can take parameters. To refer
+ to the parameters use $1, $2, $3, etc. Any parameter have to be bind to
+ any variable or any expression with USING clause. You cannot use bind
+ arguments to pass the names of schema objects to a dynamic SQL statement.
+ The use of arguments is perfect protection from SQL injection.
+ programlisting
+ EXECUTE 'SELECT count(*) FROM '
+ || tabname::regclass
+ || ' WHERE inserted_by = $1 AND inserted = $2'
+INTO c
+USING checked_user, checked_date;
+ /programlisting
+ /para
para
commandSELECT INTO/command is not currently supported within
***
*** 1997,2003
rows:
synopsis
optional lt;lt;replaceablelabel/replaceablegt;gt; /optional
! FOR replaceabletarget/replaceable IN EXECUTE replaceabletext_expression/replaceable LOOP
replaceablestatements/replaceable
END LOOP optional replaceablelabel/replaceable /optional;
/synopsis
--- 2012,2018
rows:
synopsis
optional lt;lt;replaceablelabel/replaceablegt;gt; /optional
! FOR replaceabletarget/replaceable IN EXECUTE replaceabletext_expression/replaceable optional USING replaceable class=parameterexpression/replaceable optional, .../optional /optional LOOP
replaceablestatements/replaceable
END LOOP optional replaceablelabel/replaceable /optional;
/synopsis
*** ./src/pl/plpgsql/src/gram.y.orig 2008-03-26 07:30:27.0 +0100
--- ./src/pl/plpgsql/src/gram.y 2008-03-24 20:41:27.0 +0100
***
*** 21,26
--- 21,27
static PLpgSQL_expr *read_sql_construct(int until,
int until2,
+ int until3,
const char *expected,
const char *sqlstart,
bool isexpression,
***
*** 200,205
--- 201,207
%token K_THEN
%token K_TO
%token K_TYPE
+ %token K_USING
%token K_WARNING
%token K_WHEN
%token K_WHILE
***
*** 892,899
{
PLpgSQL_stmt_dynfors *new;
PLpgSQL_expr *expr;
! expr = plpgsql_read_expression(K_LOOP, LOOP);
new = palloc0(sizeof(PLpgSQL_stmt_dynfors));
new-cmd_type = PLPGSQL_STMT_DYNFORS;
--- 894,907
{
PLpgSQL_stmt_dynfors *new;
PLpgSQL_expr *expr;
+ int term;
! expr = read_sql_construct(K_LOOP,
! K_USING,
! 0,
! LOOP|USING,
! SELECT ,
! true, true, term);
new = palloc0(sizeof(PLpgSQL_stmt_dynfors));
new-cmd_type = PLPGSQL_STMT_DYNFORS;
***
*** 920,925
--- 928,948
yyerror(loop variable of loop over rows must be a record or row variable or list of scalar variables);
Re: [PATCHES] Auto Partitioning Patch - WIP version 1
Bruce Momjian escribió: This has been saved for the next commit-fest: I noticed you broke an URL that previously worked: what was http://momjian.us/mhonarc/patches/[EMAIL PROTECTED] is now http://momjian.us/mhonarc/patches_hold/[EMAIL PROTECTED] May I suggest that the URLs with Message-Ids are stored outside the particular patch queue directory? The script I showed you yesterday could be used to do that. Also I noticed that by moving it to the hold queue, the comments that may have existed on the patch queue are now gone :-( I'm not sure if there were any in this case, but it's better if we're aware of that fact. I think this could be solved if the namespace of the comment does not contain the patch queue name. I moved it to the May commitfest on the wiki too. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] \password in psql help
The \password command appears to be documented in the psql reference
page, but not included in the output of the \? command. Is there any
actual reason for that, or should I just apply the attached patch?
(which means I will apply it unless there are objections :-P)
//Magnus
Index: src/bin/psql/help.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/help.c,v
retrieving revision 1.122
diff -c -r1.122 help.c
*** src/bin/psql/help.c 20 Jan 2008 21:13:55 - 1.122
--- src/bin/psql/help.c 26 Mar 2008 12:43:09 -
***
*** 185,190
--- 185,192
fprintf(output, _( \\unset NAMEunset (delete) internal variable\n));
fprintf(output, _( \\prompt [TEXT] NAME\n
prompt user to set internal variable\n));
+ fprintf(output, _( \\password [USERNAME]\n
+ securely change the password for a user\n));
fprintf(output, _( \\! [COMMAND] execute command in shell or start interactive shell\n));
fprintf(output, \n);
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Consistent \d commands in psql
Greg Sabino Mullane wrote: Attached is an updated version of my psql patch that makes the \d backslash commands perform in an intuitive, consistent way. Specifically, the following objects will be treated as first class citizens (as tables and indexes currently are) by showing all the non-system objects by default and requiring a S to see the system ones. aggregates conversions comments domains operators functions types Currently, there is no way to view all the non-system functions in a database using backslash commands, as you can with \dt, unless all of the functions happen to be in a single schema (\df myschema.). With this patch, it would be as simple as \df, and the current behavior would be done with \dfS. Yes, that seems like a good idea. \df in particular has been too noisy to be usable. Not sure about conversions and domains; I doubt anyone creates custom conversions in practice, and there's no system domains in a standard installation. Does anyone want to argue that there's a backward-compatibility problem with changing \df? I don't think there is; you shouldn't be using psql backslash commands in an application. This patch also adds a few new things to the tab-completion table, such as comments and conversions. There's a bunch of merge conflicts in the diff. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Bulk Insert tuning
On Tue, 2008-02-26 at 15:12 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: Following patch implements a simple mechanism to keep a buffer pinned while we are bulk loading. This will fail to clean up nicely after a subtransaction abort, no? (For that matter I don't think it's right even for a top-level abort.) And I'm pretty sure it will trash your table entirely if someone inserts into another relation while a bulk insert is happening. (Not at all impossible, think of triggers for instance.) From a code structural point of view, we are already well past the number of distinct options that heap_insert ought to have. I was thinking the other day that bulk inserts ought to use a ring-buffer strategy to avoid having COPY IN trash the whole buffer arena, just as we've taught COPY OUT not to. Agree with that. That was mentioned here again http://archives.postgresql.org/pgsql-hackers/2008-02/msg01080.php What do you think of the Full Block List idea? So maybe a better idea is to generalize BufferAccessStrategy to be able to handle write as well as read concerns; or have two versions of it, one for writing and one for reading. In any case the point being to encapsulate all these random little options in a struct, which could also carry along state that needs to be saved across a series of inserts, such as the last pinned buffer. I'm trying to implement this, but it begins to look quite ugly. First, if we allow multiple BulkInsertBuffers then we have to remember them all in a list so we can unpin them all in case of abort. The change isn't needed for correctness, as explained before. Second, we need multiple BufferIOStrategy objects for various purposes. There is no single default strategy, since normal inserts, normal updates and toast all have different default behaviour. That makes it ugly because we either need to differentiate between update/insert and toast/main inserts - which leads to just as many options, or we need to have lots of statically defined BufferIOStrategy objects for various purposes. I did agree that it was sensible to try to refactor the code, but now it just looks like a big pile of ugly changes for no benefit. I'll save my WIP so we can judge. Coding it using flags that can be ORd together makes more sense than a list of bools and will be easier to read. I'm going to try that approach instead. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] \password in psql help
Magnus Hagander wrote: + fprintf(output, _( \\password [USERNAME]\n + securely change the password for a user\n)); I would leave out the word securely. Unless you want to provide another command for changing it insecurely ;-). What does it mean, anyway? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Auto Partitioning Patch - WIP version 1
Alvaro Herrera wrote: Bruce Momjian escribi?: This has been saved for the next commit-fest: I noticed you broke an URL that previously worked: what was http://momjian.us/mhonarc/patches/[EMAIL PROTECTED] is now http://momjian.us/mhonarc/patches_hold/[EMAIL PROTECTED] May I suggest that the URLs with Message-Ids are stored outside the particular patch queue directory? The script I showed you yesterday could be used to do that. My email are added/removed so I am unsure how to do that easily becuase the lists would share the same directory. We don't have that problem with the archives. Also I noticed that by moving it to the hold queue, the comments that may have existed on the patch queue are now gone :-( I'm not sure if there were any in this case, but it's better if we're aware of that fact. I think this could be solved if the namespace of the comment does not contain the patch queue name. I specifically set things up so the comments should move with the email. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Friendly help for psql
Greg Sabino Mullane wrote: Why not run help when someone enters help (or HELP ME!) on the command line? \? is hardly an easy thing to remember (and some people can't be bothered to actually read the screen...) So, have you produced a followup patch? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Auto Partitioning Patch - WIP version 1
Bruce Momjian escribió: Alvaro Herrera wrote: I noticed you broke an URL that previously worked: what was http://momjian.us/mhonarc/patches/[EMAIL PROTECTED] is now http://momjian.us/mhonarc/patches_hold/[EMAIL PROTECTED] May I suggest that the URLs with Message-Ids are stored outside the particular patch queue directory? The script I showed you yesterday could be used to do that. My email are added/removed so I am unsure how to do that easily becuase the lists would share the same directory. We don't have that problem with the archives. My point is that you should only _add_ Message-Ids, not remove them. You can move the messages from one queue to the other to your heart's content, but the Message-Id URL should continue to work with no changes. Also I noticed that by moving it to the hold queue, the comments that may have existed on the patch queue are now gone :-( I'm not sure if there were any in this case, but it's better if we're aware of that fact. I think this could be solved if the namespace of the comment does not contain the patch queue name. I specifically set things up so the comments should move with the email. Yeah, I noticed that after sending the email -- the js-kit name seems to be only msgid-foo. I thought the permalink= attribute was part of that, but perhaps not? In case you added that permalink attribute because of my request the other day, let me clarify that what I was actually thinking was having something like a href=http://momjian.us/msgid/[EMAIL PROTECTED]permalink/a after the name of the poster, so that it would be visible on the index page and the user didn't have to open the page to get it. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] \password in psql help
Heikki Linnakangas wrote: Magnus Hagander wrote: +fprintf(output, _( \\password [USERNAME]\n + securely change the password for a user\n)); I would leave out the word securely. Unless you want to provide another command for changing it insecurely ;-). What does it mean, anyway? The point is that the password is encrypted on the client and transmitted in md5 form. If you were to use ALTER USER to change the password, it could end up unencrypted in the server log. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Auto Partitioning Patch - WIP version 1
Alvaro Herrera wrote: Bruce Momjian escribi?: Alvaro Herrera wrote: I noticed you broke an URL that previously worked: what was http://momjian.us/mhonarc/patches/[EMAIL PROTECTED] is now http://momjian.us/mhonarc/patches_hold/[EMAIL PROTECTED] May I suggest that the URLs with Message-Ids are stored outside the particular patch queue directory? The script I showed you yesterday could be used to do that. My email are added/removed so I am unsure how to do that easily becuase the lists would share the same directory. We don't have that problem with the archives. My point is that you should only _add_ Message-Ids, not remove them. You can move the messages from one queue to the other to your heart's content, but the Message-Id URL should continue to work with no changes. Well, when an email is applied, it is deleted. How do I update the message-id for that in an automated manner. Right now a rebuild deleted all the links and recreates them. Also I noticed that by moving it to the hold queue, the comments that may have existed on the patch queue are now gone :-( I'm not sure if there were any in this case, but it's better if we're aware of that fact. I think this could be solved if the namespace of the comment does not contain the patch queue name. I specifically set things up so the comments should move with the email. Yeah, I noticed that after sending the email -- the js-kit name seems to be only msgid-foo. I thought the permalink= attribute was part of that, but perhaps not? In case you added that permalink attribute because of my request the other day, let me clarify that what I was actually thinking was having something like a href=http://momjian.us/msgid/[EMAIL PROTECTED]permalink/a The permalink is for people who get email --- it tells them which message got the comment. (People were complaining before I fixed that.) after the name of the poster, so that it would be visible on the index page and the user didn't have to open the page to get it. We can do that if people want. I used to show the message id on the thread page but several felt it was too cluttered-looking. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Auto Partitioning Patch - WIP version 1
Bruce Momjian escribió: Alvaro Herrera wrote: My point is that you should only _add_ Message-Ids, not remove them. You can move the messages from one queue to the other to your heart's content, but the Message-Id URL should continue to work with no changes. Well, when an email is applied, it is deleted. How do I update the message-id for that in an automated manner. Right now a rebuild deleted all the links and recreates them. Well, remove the part that deletes links, and keep the part that creates links. That way, links that used to work continue working. I am assuming you use hard links -- obviously this doesn't work with symlinks. (My script creates hard links.) after the name of the poster, so that it would be visible on the index page and the user didn't have to open the page to get it. We can do that if people want. I used to show the message id on the thread page but several felt it was too cluttered-looking. Well, it would have helped me. I suggested permalink as text because it is less clutter than the full Message-Id. Besides, the Message-Id by itself is useless, whereas a link is useful. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Auto Partitioning Patch - WIP version 1
Alvaro Herrera wrote: Bruce Momjian escribi?: Alvaro Herrera wrote: My point is that you should only _add_ Message-Ids, not remove them. You can move the messages from one queue to the other to your heart's content, but the Message-Id URL should continue to work with no changes. Well, when an email is applied, it is deleted. How do I update the message-id for that in an automated manner. Right now a rebuild deleted all the links and recreates them. Well, remove the part that deletes links, and keep the part that creates links. That way, links that used to work continue working. I am assuming you use hard links -- obviously this doesn't work with symlinks. (My script creates hard links.) I was using symlinks. I try to avoid hardlinks that cross directories --- not sure why, probably because I can't easily manage them to find out what something is linked to without playing with inodes. You are right that if I used hard-links I put things in a separate directory, and the hard links would still contain the email, though if the email has been removed, should we still be returning it from a query? I suppose I could delete items with only one link. Well, if I move the permanent links to another directory, as you suggest, I am going to invalidate every link. Maybe we should wait for this commit fest to end and then I can create a permanent link directory and use hard links. Or is everyone OK with invalidating all the permanent links now. after the name of the poster, so that it would be visible on the index page and the user didn't have to open the page to get it. We can do that if people want. I used to show the message id on the thread page but several felt it was too cluttered-looking. Well, it would have helped me. I suggested permalink as text because it is less clutter than the full Message-Id. Besides, the Message-Id by itself is useless, whereas a link is useful. Are you talking about the permalink in the js-kit comment or the permalink at the top of each message? What text do you want to be the permalink? How is that created in an automated manner? -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] pg_dump -i wording
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have developed the attached patch with improves wording for the
pg_dump -i (ignore version) option.
I think this is going in exactly the wrong direction --- it makes
both the documentation and the warning message less scary not more
so.
OK, updated pg_dump -i wording, more scary.
Updated patch applied, with improved wording when the -i option is
specified.
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/ref/pg_dump.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v
retrieving revision 1.99
diff -c -c -r1.99 pg_dump.sgml
*** doc/src/sgml/ref/pg_dump.sgml 20 Mar 2008 17:36:57 - 1.99
--- doc/src/sgml/ref/pg_dump.sgml 26 Mar 2008 14:26:54 -
***
*** 296,314
termoption--ignore-version//term
listitem
para
! Ignore version mismatch between
applicationpg_dump/application and the database server.
/para
para
- applicationpg_dump/application can dump from servers running
- previous releases of productnamePostgreSQL/, but very old
- versions are not supported anymore (currently, those prior to 7.0).
Dumping from a server newer than applicationpg_dump/application
! is likely not to work at all.
! Use this option if you need to override the version check (and
! if applicationpg_dump/application then fails, don't say
! you weren't warned).
/para
/listitem
/varlistentry
--- 296,313
termoption--ignore-version//term
listitem
para
! Ignore incompatible version check between
applicationpg_dump/application and the database server.
/para
para
Dumping from a server newer than applicationpg_dump/application
! is likely fail and is disabled by default.
! Also, while applicationpg_dump/application can dump from servers running
! previous releases of productnamePostgreSQL/, some very old
! versions are not supported (currently, pre-7.0).
! Use this option if you need to override the version check, but
! be prepared for applicationpg_dump/application to fail.
/para
/listitem
/varlistentry
Index: src/bin/pg_dump/pg_backup_db.c
===
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_backup_db.c,v
retrieving revision 1.77
diff -c -c -r1.77 pg_backup_db.c
*** src/bin/pg_dump/pg_backup_db.c 9 Dec 2007 19:01:40 - 1.77
--- src/bin/pg_dump/pg_backup_db.c 26 Mar 2008 14:26:54 -
***
*** 72,80
write_msg(NULL, server version: %s; %s version: %s\n,
remoteversion_str, progname, PG_VERSION);
if (ignoreVersion)
! write_msg(NULL, proceeding despite version mismatch\n);
else
! die_horribly(AH, NULL, aborting because of version mismatch (Use the -i option to proceed anyway.)\n);
}
}
--- 72,81
write_msg(NULL, server version: %s; %s version: %s\n,
remoteversion_str, progname, PG_VERSION);
if (ignoreVersion)
! write_msg(NULL, ignoring server version mismatch\n);
else
! die_horribly(AH, NULL, aborting because of server version mismatch\n
! Use the -i option to bypass server version check, but be prepared for failure.\n);
}
}
Index: src/bin/pg_dump/pg_dump.c
===
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_dump.c,v
retrieving revision 1.483
diff -c -c -r1.483 pg_dump.c
*** src/bin/pg_dump/pg_dump.c 20 Mar 2008 17:36:57 - 1.483
--- src/bin/pg_dump/pg_dump.c 26 Mar 2008 14:26:54 -
***
*** 745,752
printf(_(\nGeneral options:\n));
printf(_( -f, --file=FILENAME output file name\n));
printf(_( -F, --format=c|t|p output file format (custom, tar, plain text)\n));
! printf(_( -i, --ignore-version proceed even when server version mismatches\n
! pg_dump version\n));
printf(_( -v, --verboseverbose mode\n));
printf(_( -Z, --compress=0-9 compression level for compressed formats\n));
printf(_( --help show this help, then exit\n));
--- 745,751
printf(_(\nGeneral options:\n));
printf(_( -f, --file=FILENAME output file name\n));
printf(_( -F, --format=c|t|p output file format (custom, tar, plain text)\n));
! printf(_( -i, --ignore-version ignore server version mismatch\n));
printf(_( -v, --verboseverbose mode\n));
printf(_( -Z, --compress=0-9 compression level for compressed formats\n));
Re: [PATCHES] \password in psql help
On Wed, 26 Mar 2008 10:43:48 -0300 Alvaro Herrera [EMAIL PROTECTED] wrote: Heikki Linnakangas wrote: Magnus Hagander wrote: + fprintf(output, _( \\password [USERNAME]\n +securely change the password for a user\n)); I would leave out the word securely. Unless you want to provide another command for changing it insecurely ;-). What does it mean, anyway? The point is that the password is encrypted on the client and transmitted in md5 form. If you were to use ALTER USER to change the password, it could end up unencrypted in the server log. That, and it will go over the network in plaintext. And it will go in your .psql_history. \password closes all these. //Magnus -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] \password in psql help
Magnus Hagander [EMAIL PROTECTED] writes: The \password command appears to be documented in the psql reference page, but not included in the output of the \? command. Is there any actual reason for that, or should I just apply the attached patch? Presumably somebody forgot. While you're at it, please fix the gratuitous non-alphabetical ordering of the items in that list ... regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] \password in psql help
On Wed, 26 Mar 2008 10:44:43 -0400 Tom Lane [EMAIL PROTECTED] wrote: Magnus Hagander [EMAIL PROTECTED] writes: The \password command appears to be documented in the psql reference page, but not included in the output of the \? command. Is there any actual reason for that, or should I just apply the attached patch? Presumably somebody forgot. While you're at it, please fix the gratuitous non-alphabetical ordering of the items in that list ... Yeah, I noticed that. Will fix. Just to be sure - this is non-backpatch stuff, correct? //Magnus -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Remove ipcclean
There are patch queue comments suggesting the removal of the ipcclean
command-line utility. ipcclean doesn't work on Windows, and it probably
doesn't work perfectly all Unixes either.
The attached patch removes the utility, though some files will have to
be removed as well.
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/array.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/array.sgml,v
retrieving revision 1.62
diff -c -c -r1.62 array.sgml
*** doc/src/sgml/array.sgml 7 Jun 2007 14:49:56 - 1.62
--- doc/src/sgml/array.sgml 26 Mar 2008 14:42:14 -
***
*** 258,263
--- 258,266
{{meeting,lunch},{training,presentation}}
(1 row)
/programlisting
+
+ To avoid confusion with slices, use slice syntax for all dimmension
+ references, e.g. literal[1:2][1:1]/, not literal[2][1:1]/.
/para
para
***
*** 275,281
any of the subscript expressions are null. However, in other corner
cases such as selecting an array slice that
is completely outside the current array bounds, a slice expression
! yields an empty (zero-dimensional) array instead of null.
If the requested slice partially overlaps the array bounds, then it
is silently reduced to just the overlapping region.
/para
--- 278,285
any of the subscript expressions are null. However, in other corner
cases such as selecting an array slice that
is completely outside the current array bounds, a slice expression
! yields an empty (zero-dimensional) array instead of null. (This
! does not match non-slice behavior and is done for historical reasons.)
If the requested slice partially overlaps the array bounds, then it
is silently reduced to just the overlapping region.
/para
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] \password in psql help
Magnus Hagander [EMAIL PROTECTED] writes: The \password command appears to be documented in the psql reference page, but not included in the output of the \? command. Is there any actual reason for that, or should I just apply the attached patch? Just to be sure - this is non-backpatch stuff, correct? You could argue it either way, I think. Lack of documentation is a bug, but hardly a critical one. Since you're adding a string it would create new work for translators, but it still seems better if the entry is there and untranslated than not there at all. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] \password in psql help
On Wed, 26 Mar 2008 11:35:22 -0400 Tom Lane [EMAIL PROTECTED] wrote: Magnus Hagander [EMAIL PROTECTED] writes: The \password command appears to be documented in the psql reference page, but not included in the output of the \? command. Is there any actual reason for that, or should I just apply the attached patch? Just to be sure - this is non-backpatch stuff, correct? You could argue it either way, I think. Lack of documentation is a bug, but hardly a critical one. Since you're adding a string it would create new work for translators, but it still seems better if the entry is there and untranslated than not there at all. Heh, that's only slightly clearer than what I had before I asked the question ;-) But - will go ahead and backpatch then. //Magnus -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Moving snapshot code around
Tom Lane wrote:
I think thinking of snapshot.h as an external interface is
wrongheaded. In the proposed refactoring, snapshot.h is concerned with
snapshot *management* (creating, copying, deleting) while tqual.h is
concerned with tuple visibility testing (which requires a snapshot as an
input, but doesn't do any management). They're really entirely
orthogonal concerns.
Agreed, it makes a lot more sense considered in this light. I renamed
snapshot.{c,h} into snapmgmt.{c,h}, hopefully making the intent clearer.
I also separated the definition of the snapshot struct to snapshot.h.
This caused the new snapmgmt.h header be required in more files, but I
don't see this as a problem because it means tqual.h is now less
generally included.
Patch committed that way.
One thing I'm unhappy about is that tqual.h needs to be included in
heapam.h (which is included just about everywhere) just to get the
definition of the HTSU_Result enum, which is a bit useless because it is
only used in three switch statements that contain a default clause
anyway. I propose changing the result type of heap_update, heap_delete
and heap_lock_tuple to a plain int.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Moving snapshot code around
Alvaro Herrera [EMAIL PROTECTED] writes:
Agreed, it makes a lot more sense considered in this light. I renamed
snapshot.{c,h} into snapmgmt.{c,h}, hopefully making the intent clearer.
I'd have gone with snapmgr.h/c for consistency with existing filenames
(bufmgr, lmgr, etc).
One thing I'm unhappy about is that tqual.h needs to be included in
heapam.h (which is included just about everywhere) just to get the
definition of the HTSU_Result enum, which is a bit useless because it is
only used in three switch statements that contain a default clause
anyway. I propose changing the result type of heap_update, heap_delete
and heap_lock_tuple to a plain int.
I don't like that very much. What about just moving the HTSU_Result
enum's declaration somewhere else? Two possibilities are heapam.h
itself, or the new snapshot.h file (which'd then have to be included
by heapam.h, but it seems lightweight enough that that's not too
terrible).
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Moving snapshot code around
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Agreed, it makes a lot more sense considered in this light. I renamed
snapshot.{c,h} into snapmgmt.{c,h}, hopefully making the intent clearer.
I'd have gone with snapmgr.h/c for consistency with existing filenames
(bufmgr, lmgr, etc).
Doh! Sorry. We're at the best time for changing the name, since the
file has no history. Shall I?
One thing I'm unhappy about is that tqual.h needs to be included in
heapam.h (which is included just about everywhere) just to get the
definition of the HTSU_Result enum, which is a bit useless because it is
only used in three switch statements that contain a default clause
anyway. I propose changing the result type of heap_update, heap_delete
and heap_lock_tuple to a plain int.
I don't like that very much. What about just moving the HTSU_Result
enum's declaration somewhere else? Two possibilities are heapam.h
itself, or the new snapshot.h file (which'd then have to be included
by heapam.h, but it seems lightweight enough that that's not too
terrible).
Well, heapam.h includes a lot of other headers, so it doesn't look a
good candidate to me. I think snapshot.h is a reasonably good
candidate.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Auto Partitioning Patch - WIP version 1
bruce wrote: I am assuming you use hard links -- obviously this doesn't work with symlinks. (My script creates hard links.) I was using symlinks. I try to avoid hardlinks that cross directories --- not sure why, probably because I can't easily manage them to find out what something is linked to without playing with inodes. You are right that if I used hard-links I put things in a separate directory, and the hard links would still contain the email, though if the email has been removed, should we still be returning it from a query? I suppose I could delete items with only one link. Well, if I move the permanent links to another directory, as you suggest, I am going to invalidate every link. Maybe we should wait for this commit fest to end and then I can create a permanent link directory and use hard links. Or is everyone OK with invalidating all the permanent links now. OK, I remember now. The problem wasn't symlinks but that mhonarc generates URLs relative to the current directory. If we have message-id files outside the directory, links like Thread Next will not work. We could try to change those to absolute with a script. The community archives are going to have the same problem. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Auto Partitioning Patch - WIP version 1
Bruce Momjian escribió: OK, I remember now. The problem wasn't symlinks but that mhonarc generates URLs relative to the current directory. If we have message-id files outside the directory, links like Thread Next will not work. We could try to change those to absolute with a script. The community archives are going to have the same problem. Ahh, thanks for pointing it out. I think I will use an HTTP redirect. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Auto Partitioning Patch - WIP version 1
Alvaro Herrera wrote: Bruce Momjian escribi?: OK, I remember now. The problem wasn't symlinks but that mhonarc generates URLs relative to the current directory. If we have message-id files outside the directory, links like Thread Next will not work. We could try to change those to absolute with a script. The community archives are going to have the same problem. Ahh, thanks for pointing it out. I think I will use an HTTP redirect. How do you know which directory to redirect to? -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Moving snapshot code around
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: I'd have gone with snapmgr.h/c for consistency with existing filenames (bufmgr, lmgr, etc). Doh! Sorry. We're at the best time for changing the name, since the file has no history. Shall I? +1 I don't like that very much. What about just moving the HTSU_Result enum's declaration somewhere else? Two possibilities are heapam.h itself, or the new snapshot.h file (which'd then have to be included by heapam.h, but it seems lightweight enough that that's not too terrible). Well, heapam.h includes a lot of other headers, so it doesn't look a good candidate to me. I think snapshot.h is a reasonably good candidate. Works for me. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Auto Partitioning Patch - WIP version 1
Bruce Momjian wrote: Alvaro Herrera wrote: Bruce Momjian escribi?: OK, I remember now. The problem wasn't symlinks but that mhonarc generates URLs relative to the current directory. If we have message-id files outside the directory, links like Thread Next will not work. We could try to change those to absolute with a script. The community archives are going to have the same problem. Ahh, thanks for pointing it out. I think I will use an HTTP redirect. How do you know which directory to redirect to? I can't see how Apache redirects would work, but I suppose you could use HTML redirect because you know at the time you are creating the message file which directory to point to, but again the title bar will change to relative once you do that. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Moving snapshot code around
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: I'd have gone with snapmgr.h/c for consistency with existing filenames (bufmgr, lmgr, etc). Doh! Sorry. We're at the best time for changing the name, since the file has no history. Shall I? +1 Done. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Auto Partitioning Patch - WIP version 1
Bruce Momjian wrote: Alvaro Herrera wrote: Ahh, thanks for pointing it out. I think I will use an HTTP redirect. How do you know which directory to redirect to? The script gets the directory as a parameter. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] V1.1 patch for TODO Item: SQL-language reference parameters by name.
Gevik Babakhani [EMAIL PROTECTED] writes: This is a minor update to 1.0 (corrected some typo here and there). Please see: http://archives.postgresql.org/pgsql-patches/2007-11/msg00253.php I looked this over a bit and feel that it's nowhere near ready to apply. The main problem is that the callback mechanism is very awkwardly designed. In the first place, I don't see a need for a stack: if you're parsing a statement in a function body, there is only one function that could possibly be supplying parameter names. Having to manipulate a global variable to change the stack is expensive (you are lacking PG_TRY blocks that would be needed to restore the stack after error). But the real problem is that unconditionally calling every handler on the stack means you need strange rules to detect which handler will or has already handled the situation, plus you've got extremely ad-hoc structs that pass information in both directions since you've not provided any other way for a handler to return information. Also, once you've built the callback mechanism, why in the world would you funnel all the callbacks into a single handler that you then place inside the parser? The point of this exercise is to let code that is *outside* the main parser have some say over how names are resolved. And it shouldn't be necessary to expand code or enums known to the main parser to add a new use of the feature. I think a better design would rely on a callback function typedef'd this way: Node * (*Parser_Callback_Func) (Node *node, void *callback_args) where the node argument is an untransformed ColumnRef or ParamRef node that the regular parser isn't able to resolve, and the void * argument is some opaque state data that gets passed through the parser from the original caller. The charter of the function is to return a transformed node (most likely a Param, but it could be any legal expression tree) if it can make sense of the node, or NULL if it doesn't have a referent for the name. Rather than using a global stack I'd just make the function pointer and the callback_args be new parameters to parse_analyze(). They could then be stashed in ParseState till needed. I believe that we could use this mechanism to replace both the p_value_substitute kluge for domain CHECK expressions, and the parser's current handling of $n parameters. It'd be nice to get those hacks out of the core parser --- in particular parse_analyze_varparams should go away in favor of using two different callback functions depending on whether the set of param types is frozen or not. SQL function parameters, and someday plpgsql local variables, would be next. There are a number of other things I don't like here, notably ERRCODE_UNDEFINED_FUNCTION_PARAMETER_NAME ... if it's undefined, how do you know it's a parameter name? I'd just leave the error responses alone. And please find some less horrid solution around addImplicitRTE/warnAutoRange. If you have to refactor to get the callback to be executed at the right time then do so, but don't add parameters that fundamentally change the behavior of a function and then not bother to document them. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Moving snapshot code around
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: I don't like that very much. What about just moving the HTSU_Result enum's declaration somewhere else? Two possibilities are heapam.h itself, or the new snapshot.h file (which'd then have to be included by heapam.h, but it seems lightweight enough that that's not too terrible). Well, heapam.h includes a lot of other headers, so it doesn't look a good candidate to me. I think snapshot.h is a reasonably good candidate. Works for me. This part done too. Thanks for the input. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Zdenek Kotala [EMAIL PROTECTED] writes: Thank your for Your and Alvaro's comments. I attached updated patch version only with YYSTYPE definition. Applied with minor revisions. I fixed pg_conversion.h as well; the only remaining special inclusions in the catalog header files are of pg_list.h. For the moment that header doesn't seem to be a problem for client-side code to include, but someday we may want to do more cleanup here. The immediate remaining problem is that pg_resetxlog.c still includes a bunch of backend-only headers, which as far as I understand still blocks your build requirements. I poked at this a little bit, but didn't see any easy solution ... regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
