Re: [HACKERS] Client Messages

2012-03-14 Thread Robert Haas
On Thu, Mar 8, 2012 at 8:40 AM, Robert Haas robertmh...@gmail.com wrote:
 On Wed, Feb 29, 2012 at 9:39 PM, Fujii Masao masao.fu...@gmail.com wrote:
  Do we have an updated patch?  Fujii?

 No. I believe that the author Jim will submit the updated version.

 Jim, are you going to submit an updated version?

Hearing no response, I'm marking this Returned with Feedback.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
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] Client Messages

2012-03-08 Thread Robert Haas
On Wed, Feb 29, 2012 at 9:39 PM, Fujii Masao masao.fu...@gmail.com wrote:
  Do we have an updated patch?  Fujii?

 No. I believe that the author Jim will submit the updated version.

Jim, are you going to submit an updated version?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
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] Client Messages

2012-02-29 Thread Alvaro Herrera

Excerpts from Heikki Linnakangas's message of jue ene 26 15:58:58 -0300 2012:
 On 26.01.2012 17:31, Tom Lane wrote:

  The idea that occurs to me is to have the code that uses the GUC do a
  verify_mbstr(noerror) on it, and silently ignore it if it doesn't pass
  (maybe with a LOG message).  This would have to be documented of course,
  but it seems better than the potential consequences of trying to send a
  wrongly-encoded string.
 
 Hmm, fine with me. It would be nice to plug the hole that these bogus 
 characters can leak elsewhere into the system through current_setting, 
 though. Perhaps we could put the verify_mbstr() call somewhere in guc.c, 
 to forbid incorrectly encoded characters from being stored in the guc 
 variable in the first place.

This patch is listed as Needs review but that seems to be wrong --
it's waiting on author, I think.  Do we have an updated patch?  Fujii?

-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
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] Client Messages

2012-02-29 Thread Fujii Masao
On Thu, Mar 1, 2012 at 4:13 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:

 Excerpts from Heikki Linnakangas's message of jue ene 26 15:58:58 -0300 2012:
 On 26.01.2012 17:31, Tom Lane wrote:

  The idea that occurs to me is to have the code that uses the GUC do a
  verify_mbstr(noerror) on it, and silently ignore it if it doesn't pass
  (maybe with a LOG message).  This would have to be documented of course,
  but it seems better than the potential consequences of trying to send a
  wrongly-encoded string.

 Hmm, fine with me. It would be nice to plug the hole that these bogus
 characters can leak elsewhere into the system through current_setting,
 though. Perhaps we could put the verify_mbstr() call somewhere in guc.c,
 to forbid incorrectly encoded characters from being stored in the guc
 variable in the first place.

 This patch is listed as Needs review but that seems to be wrong --
 it's waiting on author, I think.

Yes. I marked the patch as waiting on author.

  Do we have an updated patch?  Fujii?

No. I believe that the author Jim will submit the updated version.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
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] Client Messages

2012-01-26 Thread Heikki Linnakangas

On 25.01.2012 15:29, Jim Mlodgenski wrote:

On Tue, Jan 24, 2012 at 7:38 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com  wrote:

There's one little problem remaining with this, which is what to do if the
message is in a different encoding than used by the client? That's not a new
problem, we have the same problem with any string GUC, if you do SHOW
setting. We restricted application_name to ASCII characters, which is an
obvious way to avoid the problem, but I think it would be a shame to
restrict this to ASCII-only.

Isn't that an issue for the administrator understanding his audience.
Maybe some additional documentation explaining the encoding issue?


The thing is, there's currently no encoding conversion happening, so if 
you have one database in LATIN1 encoding and another in UTF-8, for 
example, whatever you put in your postgresql.conf is going to be wrong 
for one database. I'm happy to just document the issue for per-database 
messages, ALTER DATABASE ... SET welcome_message, the encoding used 
there need to match the encoding of the database, or it's displayed as 
garbage. But what about per-user messages, when the user has access to 
several databases, or postgresql.conf?


For postgresql.conf I think we could make a rule that it's always in 
UTF-8. We haven't had to take a stance on the encoding used in 
postgresql.conf before, but IMHO UTF-8 only would be quite reasonable. 
We already have a problem there if for example you have two database 
with different encodings, a schema with non-ascii characters in it, and 
you try to put that schema in search_path in postgresql.conf. That's 
such a rare situation that we haven't heard any complaints, but it's not 
so unreasonable for welcome_message.


That still leaves the problem with per-user messages, though. We've 
managed to dodge the encoding issue in shared catalogs this far. It 
would be pretty hard to enforce any given encoding there, I think. 
Perhaps we could just document that, and advice to create per-database 
and per-user settings in that case.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.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] Client Messages

2012-01-26 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
 The thing is, there's currently no encoding conversion happening, so if 
 you have one database in LATIN1 encoding and another in UTF-8, for 
 example, whatever you put in your postgresql.conf is going to be wrong 
 for one database. I'm happy to just document the issue for per-database 
 messages, ALTER DATABASE ... SET welcome_message, the encoding used 
 there need to match the encoding of the database, or it's displayed as 
 garbage. But what about per-user messages, when the user has access to 
 several databases, or postgresql.conf?

I've not looked at the patch, but what exactly will happen if the string
has the wrong encoding?

The idea that occurs to me is to have the code that uses the GUC do a
verify_mbstr(noerror) on it, and silently ignore it if it doesn't pass
(maybe with a LOG message).  This would have to be documented of course,
but it seems better than the potential consequences of trying to send a
wrongly-encoded string.

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] Client Messages

2012-01-26 Thread Peter Eisentraut
On tor, 2012-01-26 at 10:34 +0200, Heikki Linnakangas wrote:
 For postgresql.conf I think we could make a rule that it's always in 
 UTF-8. We haven't had to take a stance on the encoding used in 
 postgresql.conf before, but IMHO UTF-8 only would be quite reasonable.

We have so far violently resisted forcing UTF-8 anywhere, and this
doesn't seem like a good place to start.

We could perhaps recognize an encoding declaration like this in the
file:

http://docs.python.org/reference/lexical_analysis.html#encoding-declarations


-- 
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] Client Messages

2012-01-26 Thread Heikki Linnakangas

On 26.01.2012 17:31, Tom Lane wrote:

Heikki Linnakangasheikki.linnakan...@enterprisedb.com  writes:

The thing is, there's currently no encoding conversion happening, so if
you have one database in LATIN1 encoding and another in UTF-8, for
example, whatever you put in your postgresql.conf is going to be wrong
for one database. I'm happy to just document the issue for per-database
messages, ALTER DATABASE ... SET welcome_message, the encoding used
there need to match the encoding of the database, or it's displayed as
garbage. But what about per-user messages, when the user has access to
several databases, or postgresql.conf?


I've not looked at the patch, but what exactly will happen if the string
has the wrong encoding?


You get an incorrectly encoded string, ie. garbage, in your console, 
when you log in with psql.


You can also use current_setting() to copy the incorrectly-encoded 
string elsewhere in the system. If you insert it into a table and run 
pg_dump, I think the dump might not be restorable. That's a bit of a 
stretch, perhaps, but it would be nice to avoid that.


BTW, you can already do that if you set e.g default_text_search_config 
to something non-ASCII in postgresql.conf. Or if you do it with 
search_path, you get a warning at login. For example, I did ALTER USER 
foouser set search_path ='kääk'; in a LATIN1 database, and then 
connected to a UTF-8 database and got:


$ ~/pgsql.master/bin/psql postgres foouser
WARNING:  invalid value for parameter search_path: k��k
DETAIL:  schema k��k does not exist
psql (9.2devel)
Type help for help.

(in case that didn't get across right, I set the search_path to a string 
containing two a-with-umlauts, and in the warning, they got replaced 
with question marks with inverse colors, which is apparently a character 
that the console uses to display bytes that are not valid UTF-8).


The problem with welcome_message would look just like that. No-one is 
likely to run into that with search_path, but it's quite reasonable and 
expected to use your native language in a welcome message.



The idea that occurs to me is to have the code that uses the GUC do a
verify_mbstr(noerror) on it, and silently ignore it if it doesn't pass
(maybe with a LOG message).  This would have to be documented of course,
but it seems better than the potential consequences of trying to send a
wrongly-encoded string.


Hmm, fine with me. It would be nice to plug the hole that these bogus 
characters can leak elsewhere into the system through current_setting, 
though. Perhaps we could put the verify_mbstr() call somewhere in guc.c, 
to forbid incorrectly encoded characters from being stored in the guc 
variable in the first place.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.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] Client Messages

2012-01-25 Thread Jim Mlodgenski
On Tue, Jan 24, 2012 at 7:38 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
 On 23.01.2012 22:52, Jim Mlodgenski wrote:

 On Wed, Jan 18, 2012 at 9:19 AM, Jim Mlodgenskijimm...@gmail.com  wrote:

 On Wed, Jan 18, 2012 at 3:08 AM, Heikki Linnakangas

 I don't think that's a problem, it's just a free-form message to
 display.

 But it also doesn't seem very useful to have it PGC_USERSET: if it's
 only
 displayed at connect time, there's no point in changing it after
 connecting.

 Should we make it PGC_BACKEND?


 In hindsight, making it PGC_BACKEND makes it much less useful, because then
 you can't set it on a per-database basis with ALTER DATABASE foo SET ...
 So I made it PGC_USERSET again.


 Here is the revised patch based on the feedback.


 Thanks! I renamed the GUC to welcome_message, to avoid confusion with
 client_min_messages. I also moved it to Connection Settings category.
 Although it's technically settable within a session, the purpose is to
 display a message when connecting, so Connection Settings feels more
 fitting.

 There's one little problem remaining with this, which is what to do if the
 message is in a different encoding than used by the client? That's not a new
 problem, we have the same problem with any string GUC, if you do SHOW
 setting. We restricted application_name to ASCII characters, which is an
 obvious way to avoid the problem, but I think it would be a shame to
 restrict this to ASCII-only.
Isn't that an issue for the administrator understanding his audience.
Maybe some additional documentation explaining the encoding issue?



 --
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.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] Client Messages

2012-01-23 Thread Jim Mlodgenski
On Wed, Jan 18, 2012 at 9:19 AM, Jim Mlodgenski jimm...@gmail.com wrote:
 On Wed, Jan 18, 2012 at 3:08 AM, Heikki Linnakangas
 heikki.linnakan...@enterprisedb.com wrote:
 On 18.01.2012 07:49, Fujii Masao wrote:

 On Fri, Jan 6, 2012 at 1:38 AM, Jim Mlodgenskijimm...@gmail.com  wrote:

 I have a need to send banner messages to a psql client that I can set
 on the server and will be displayed on any psql client that connects
 to the database. This would be mostly used as an additional indicator
 to which database you are connecting, but could also be used by people
 to force their users to see an security message when connecting to the
 database. The attached patch will allow you to execute

 ALTER DATABASE postgres SET

 client_message=E'\nBEWARE:
 You are connecting to a production database. If you do anything to\n
     bring this server down, you will be destroyed by your supreme

 overlord.\n\n';

 And then when you connect to psql, you will see:

 [e3@workstation bin]$ ./psql -U user1 postgres
 psql (9.2devel)

 
 BEWARE: You are connecting to a production database. If you do anything
 to
        bring this server down, you will be destroyed by your supreme
 overlord.

 

 Type help for help.

 postgres=


 Any feedback is welcome.


 Adding new GUC parameter only for the purpose of warning psql users
 seems overkill to me.  Basically we try to reduce the number of GUC
 parameters to make a configuration easier to a user, so I don't think that
 it's good idea to add new GUC for such a small benefit.


 It seems quite useful to me...


 Instead, how
 about using .psqlrc file and writing a warning message in it by using
 \echo command?


 That's not the same thing at all. Each client would need to put the warning
 in that file, and you'd get it regardless of the database you connect to.


 Anyway, I found one problem in the patch. The patch defines client_message
 as PGC_USERSET parameter, which means that any psql can falsify a
 warning message, e.g., by setting the environment variable PGOPTIONS
 to -c client_message=hoge. This seems to be something to avoid from
 security point of view.


 I don't think that's a problem, it's just a free-form message to display.
 But it also doesn't seem very useful to have it PGC_USERSET: if it's only
 displayed at connect time, there's no point in changing it after connecting.
 Should we make it PGC_BACKEND?


 The only security problem that I can think of is a malicious server
 (man-in-the-middle perhaps), that sends a banner that confuses

 Docs for PQparameterStatus() needs adjustment, now that client_message is
 also one of the settings automatically reported to the client.
 I'll add the docs for that..


 The placement of the banner in psql looks currently like this:

 $ psql postgres

 psql (9.2devel)
 Hello world!
 Type help for help.


 or

 postgres=# \c postgres
 Hello world!
 You are now connected to database postgres as user heikki.


 Are we happy with that? I think it would be better to print the banner just
 before the prompt:
 I like that better. I'll make that change as well.

Here is the revised patch based on the feedback.



 psql (9.2devel)
 Type help for help.

 Hello world!

 postgres=# \c postgres
 You are now connected to database postgres as user heikki.

 Hello world!
 postgres=#

 Should we prefix the banner with something that makes it clear that it's a
 message coming from the server? Something like:
 I don't think the default prefix adds much for the user. If the
 administrator wants to let the user know that its from the server, he
 can add it to the message.


 psql (9.2devel)
 Type help for help.

 Notice from server: Hello world!

 postgres=# \c postgres
 You are now connected to database postgres as user heikki.
 Notice from server: Hello world!
 postgres=#

 --
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index e55b503..04bc671 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -5324,6 +5324,19 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
   /listitem
  /varlistentry
 
+ varlistentry id=guc-client-message xreflabel=client_message
+  termvarnameclient_message/varname (typestring/type)/term
+  indexterm
+   primaryvarnameclient_message/ configuration parameter/primary
+  /indexterm
+  listitem
+   para
+The varnameclient_message/varname can be any string that will be 
+displayed to the user in the banner of psql. 
+   /para
+  /listitem
+ /varlistentry
+
  /variablelist
 /sect2
/sect1
diff --git 

Re: [HACKERS] Client Messages

2012-01-18 Thread Heikki Linnakangas

On 18.01.2012 07:49, Fujii Masao wrote:

On Fri, Jan 6, 2012 at 1:38 AM, Jim Mlodgenskijimm...@gmail.com  wrote:

I have a need to send banner messages to a psql client that I can set
on the server and will be displayed on any psql client that connects
to the database. This would be mostly used as an additional indicator
to which database you are connecting, but could also be used by people
to force their users to see an security message when connecting to the
database. The attached patch will allow you to execute

ALTER DATABASE postgres SET
client_message=E'\nBEWARE:
You are connecting to a production database. If you do anything to\n
 bring this server down, you will be destroyed by your supreme
overlord.\n\n';

And then when you connect to psql, you will see:

[e3@workstation bin]$ ./psql -U user1 postgres
psql (9.2devel)

BEWARE: You are connecting to a production database. If you do anything to
bring this server down, you will be destroyed by your supreme overlord.


Type help for help.

postgres=


Any feedback is welcome.


Adding new GUC parameter only for the purpose of warning psql users
seems overkill to me.  Basically we try to reduce the number of GUC
parameters to make a configuration easier to a user, so I don't think that
it's good idea to add new GUC for such a small benefit.


It seems quite useful to me...


Instead, how
about using .psqlrc file and writing a warning message in it by using
\echo command?


That's not the same thing at all. Each client would need to put the 
warning in that file, and you'd get it regardless of the database you 
connect to.



Anyway, I found one problem in the patch. The patch defines client_message
as PGC_USERSET parameter, which means that any psql can falsify a
warning message, e.g., by setting the environment variable PGOPTIONS
to -c client_message=hoge. This seems to be something to avoid from
security point of view.


I don't think that's a problem, it's just a free-form message to 
display. But it also doesn't seem very useful to have it PGC_USERSET: if 
it's only displayed at connect time, there's no point in changing it 
after connecting.


The only security problem that I can think of is a malicious server 
(man-in-the-middle perhaps), that sends a banner that confuses


Docs for PQparameterStatus() needs adjustment, now that client_message 
is also one of the settings automatically reported to the client.


The placement of the banner in psql looks currently like this:

 $ psql postgres

psql (9.2devel)
Hello world!
Type help for help.


or


postgres=# \c postgres
Hello world!
You are now connected to database postgres as user heikki.


Are we happy with that? I think it would be better to print the banner 
just before the prompt:



psql (9.2devel)
Type help for help.

Hello world!

postgres=# \c postgres
You are now connected to database postgres as user heikki.

 Hello world!
 postgres=#

Should we prefix the banner with something that makes it clear that it's 
a message coming from the server? Something like:


 psql (9.2devel)
 Type help for help.

 Notice from server: Hello world!

 postgres=# \c postgres
 You are now connected to database postgres as user heikki.
 Notice from server: Hello world!
 postgres=#

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.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] Client Messages

2012-01-18 Thread Jim Mlodgenski
On Wed, Jan 18, 2012 at 3:08 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
 On 18.01.2012 07:49, Fujii Masao wrote:

 On Fri, Jan 6, 2012 at 1:38 AM, Jim Mlodgenskijimm...@gmail.com  wrote:

 I have a need to send banner messages to a psql client that I can set
 on the server and will be displayed on any psql client that connects
 to the database. This would be mostly used as an additional indicator
 to which database you are connecting, but could also be used by people
 to force their users to see an security message when connecting to the
 database. The attached patch will allow you to execute

 ALTER DATABASE postgres SET

 client_message=E'\nBEWARE:
 You are connecting to a production database. If you do anything to\n
     bring this server down, you will be destroyed by your supreme

 overlord.\n\n';

 And then when you connect to psql, you will see:

 [e3@workstation bin]$ ./psql -U user1 postgres
 psql (9.2devel)

 
 BEWARE: You are connecting to a production database. If you do anything
 to
        bring this server down, you will be destroyed by your supreme
 overlord.

 

 Type help for help.

 postgres=


 Any feedback is welcome.


 Adding new GUC parameter only for the purpose of warning psql users
 seems overkill to me.  Basically we try to reduce the number of GUC
 parameters to make a configuration easier to a user, so I don't think that
 it's good idea to add new GUC for such a small benefit.


 It seems quite useful to me...


 Instead, how
 about using .psqlrc file and writing a warning message in it by using
 \echo command?


 That's not the same thing at all. Each client would need to put the warning
 in that file, and you'd get it regardless of the database you connect to.


 Anyway, I found one problem in the patch. The patch defines client_message
 as PGC_USERSET parameter, which means that any psql can falsify a
 warning message, e.g., by setting the environment variable PGOPTIONS
 to -c client_message=hoge. This seems to be something to avoid from
 security point of view.


 I don't think that's a problem, it's just a free-form message to display.
 But it also doesn't seem very useful to have it PGC_USERSET: if it's only
 displayed at connect time, there's no point in changing it after connecting.
Should we make it PGC_BACKEND?


 The only security problem that I can think of is a malicious server
 (man-in-the-middle perhaps), that sends a banner that confuses

 Docs for PQparameterStatus() needs adjustment, now that client_message is
 also one of the settings automatically reported to the client.
I'll add the docs for that..


 The placement of the banner in psql looks currently like this:

 $ psql postgres

 psql (9.2devel)
 Hello world!
 Type help for help.


 or

 postgres=# \c postgres
 Hello world!
 You are now connected to database postgres as user heikki.


 Are we happy with that? I think it would be better to print the banner just
 before the prompt:
I like that better. I'll make that change as well.


 psql (9.2devel)
 Type help for help.

 Hello world!

 postgres=# \c postgres
 You are now connected to database postgres as user heikki.

 Hello world!
 postgres=#

 Should we prefix the banner with something that makes it clear that it's a
 message coming from the server? Something like:
I don't think the default prefix adds much for the user. If the
administrator wants to let the user know that its from the server, he
can add it to the message.


 psql (9.2devel)
 Type help for help.

 Notice from server: Hello world!

 postgres=# \c postgres
 You are now connected to database postgres as user heikki.
 Notice from server: Hello world!
 postgres=#

 --
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.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] Client Messages

2012-01-17 Thread Fujii Masao
On Fri, Jan 6, 2012 at 1:38 AM, Jim Mlodgenski jimm...@gmail.com wrote:
 I have a need to send banner messages to a psql client that I can set
 on the server and will be displayed on any psql client that connects
 to the database. This would be mostly used as an additional indicator
 to which database you are connecting, but could also be used by people
 to force their users to see an security message when connecting to the
 database. The attached patch will allow you to execute

 ALTER DATABASE postgres SET
 client_message=E'\nBEWARE:
 You are connecting to a production database. If you do anything to\n
     bring this server down, you will be destroyed by your supreme
 overlord.\n\n';

 And then when you connect to psql, you will see:

 [e3@workstation bin]$ ./psql -U user1 postgres
 psql (9.2devel)
 
 BEWARE: You are connecting to a production database. If you do anything to
        bring this server down, you will be destroyed by your supreme overlord.
 

 Type help for help.

 postgres=


 Any feedback is welcome.

Adding new GUC parameter only for the purpose of warning psql users
seems overkill to me. Basically we try to reduce the number of GUC
parameters to make a configuration easier to a user, so I don't think that
it's good idea to add new GUC for such a small benefit. Instead, how
about using .psqlrc file and writing a warning message in it by using
\echo command?

Anyway, I found one problem in the patch. The patch defines client_message
as PGC_USERSET parameter, which means that any psql can falsify a
warning message, e.g., by setting the environment variable PGOPTIONS
to -c client_message=hoge. This seems to be something to avoid from
security point of view.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
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] Client Messages

2012-01-05 Thread Kevin Grittner
Jim Mlodgenski jimm...@gmail.com wrote:
 
 Any feedback is welcome.
 
You might want to add it here to make sure it doesn't slip through the
cracks:
 
https://commitfest.postgresql.org/action/commitfest_view/open
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers