Re: [HACKERS] Client application name

2009-10-21 Thread Dave Page
On Tue, Oct 20, 2009 at 8:55 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: I just realised there's a nasty problem with this. In my client application, I can use PQconninfoParse to determine if application_name (or fallback_application_name) are valid connection

Re: [HACKERS] Client application name

2009-10-21 Thread Heikki Linnakangas
Dave Page wrote: On Tue, Oct 20, 2009 at 8:55 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: I just realised there's a nasty problem with this. In my client application, I can use PQconninfoParse to determine if application_name (or fallback_application_name) are

Re: [HACKERS] Client application name

2009-10-21 Thread Simon Riggs
On Wed, 2009-10-14 at 18:44 +0200, Magnus Hagander wrote: On Wed, Oct 14, 2009 at 18:39, Dave Page dp...@pgadmin.org wrote: On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge e...@tcdi.com wrote: On Oct 13, 2009, at 11:02 AM, Dave Page wrote: A useful feature found in other DBMSs such as MS

Re: [HACKERS] Client application name

2009-10-21 Thread Dave Page
On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs si...@2ndquadrant.com wrote: ISTM much of the complexity discussed relates to this second feature. Let's just concentrate on getting the connection-pool-identification aspect of this done right and then maybe add second part later. That side of

Re: [HACKERS] Client application name

2009-10-21 Thread Simon Riggs
On Wed, 2009-10-21 at 10:19 +0100, Dave Page wrote: On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs si...@2ndquadrant.com wrote: ISTM much of the complexity discussed relates to this second feature. Let's just concentrate on getting the connection-pool-identification aspect of this done

Re: [HACKERS] Client application name

2009-10-21 Thread Dave Page
On Wed, Oct 21, 2009 at 10:40 AM, Simon Riggs si...@2ndquadrant.com wrote: On Wed, 2009-10-21 at 10:19 +0100, Dave Page wrote: On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs si...@2ndquadrant.com wrote: ISTM much of the complexity discussed relates to this second feature. Let's just

Re: [HACKERS] Client application name

2009-10-21 Thread Dave Page
On Wed, Oct 21, 2009 at 10:14 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Looking at the way we process the startup packet in ProcessStartupPacket, there's one dirty hack you could do. As the code stands, if you specify options key/value pair more than once, the latter

Re: [HACKERS] Client application name

2009-10-21 Thread Simon Riggs
On Wed, 2009-10-21 at 10:45 +0100, Dave Page wrote: On Wed, Oct 21, 2009 at 10:40 AM, Simon Riggs si...@2ndquadrant.com wrote: On Wed, 2009-10-21 at 10:19 +0100, Dave Page wrote: On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs si...@2ndquadrant.com wrote: ISTM much of the complexity

Re: [HACKERS] Client application name

2009-10-21 Thread Dave Page
On Wed, Oct 21, 2009 at 11:06 AM, Simon Riggs si...@2ndquadrant.com wrote: The SET seems sufficient for me. All interfaces currently support it. SET alone will not allow what I see as one of the most useful uses of this - consider: PGAPPLICATIONNAME=Nightly backup pg_dump mydb

Re: [HACKERS] Client application name

2009-10-21 Thread Heikki Linnakangas
Dave Page wrote: On Wed, Oct 21, 2009 at 10:14 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Looking at the way we process the startup packet in ProcessStartupPacket, there's one dirty hack you could do. As the code stands, if you specify options key/value pair more than

Re: [HACKERS] Client application name

2009-10-21 Thread Simon Riggs
On Wed, 2009-10-21 at 11:20 +0100, Dave Page wrote: On Wed, Oct 21, 2009 at 11:06 AM, Simon Riggs si...@2ndquadrant.com wrote: The SET seems sufficient for me. All interfaces currently support it. SET alone will not allow what I see as one of the most useful uses of this - consider:

Re: [HACKERS] Client application name

2009-10-21 Thread Magnus Hagander
On Wed, Oct 21, 2009 at 11:49, Dave Page dp...@pgadmin.org wrote: Another idea is to do something similar to the 'prefer' SSL mode, or if the server doesn't support protocol version 3: Try with the GUC in startup packet first, and if that fails, retry without it. I'm not sure if I like either

Re: [HACKERS] Client application name

2009-10-21 Thread Magnus Hagander
On Wed, Oct 21, 2009 at 12:45, Simon Riggs si...@2ndquadrant.com wrote: On Wed, 2009-10-21 at 11:20 +0100, Dave Page wrote: On Wed, Oct 21, 2009 at 11:06 AM, Simon Riggs si...@2ndquadrant.com wrote: The SET seems sufficient for me. All interfaces currently support it. SET alone will not

Re: [HACKERS] Client application name

2009-10-21 Thread Simon Riggs
On Wed, 2009-10-21 at 12:49 +0200, Magnus Hagander wrote: PGOPTIONS is the way to do that, no? It can be a bit tricky when you have to deal with quoting, but it is there and it works... Which will work for application name also. -- Simon Riggs www.2ndQuadrant.com -- Sent via

Re: [HACKERS] Client application name

2009-10-21 Thread Dave Page
On Wed, Oct 21, 2009 at 12:01 PM, Simon Riggs si...@2ndquadrant.com wrote: On Wed, 2009-10-21 at 12:49 +0200, Magnus Hagander wrote: PGOPTIONS is the way to do that, no? It can be a bit tricky when you have to deal with quoting, but it is there and it works... Which will work for application

Re: [HACKERS] Client application name

2009-10-21 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: Should we perhaps change the behaviour of the backend to give a warning only for unknown settings in the startup packet? It's not going to help, unless you first invent a time machine so we can retroactively cause all PG servers that are already in the field

Re: [HACKERS] Client application name

2009-10-21 Thread Dave Page
On Wed, Oct 21, 2009 at 3:49 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: Should we perhaps change the behaviour of the backend to give a warning only for unknown settings in the startup packet? It's not going to help, unless you first invent a time machine so

Re: [HACKERS] Client application name

2009-10-21 Thread Dave Page
On Wed, Oct 21, 2009 at 4:39 PM, Dave Page dp...@pgadmin.org wrote: On Wed, Oct 21, 2009 at 3:49 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: This might be a good argument for changing that going forward, but it will be *years* before we can rely on it for

Re: [HACKERS] Client application name

2009-10-21 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: BTW, any thoughts on Heikki's suggestions of hacking about the 'options' value or retrying the connection vs. just doing a SET post-connection in libpq? It's pretty certain that whatever I choose you probably won't like :-p The post-connect SET still seems

Re: [HACKERS] Client application name

2009-10-21 Thread Heikki Linnakangas
Tom Lane wrote: That options hack was just an ugly hack, I don't like it at all --- mainly because I don't believe that approach scales to solve more than one case either. It does if you hack it even more: don't pass the (first) options directly as command line arguments, but parse it in

Re: [HACKERS] Client application name

2009-10-21 Thread Robert Haas
On Wed, Oct 21, 2009 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: BTW, any thoughts on Heikki's suggestions of hacking about the 'options' value or retrying the connection vs. just doing a SET post-connection in libpq? It's pretty certain that whatever I

Re: [HACKERS] Client application name

2009-10-21 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Wed, Oct 21, 2009 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: The post-connect SET still seems like the best choice to me. Are we really thinking about interposing an additional server round-trip on every connection for such a marginal feature

Re: [HACKERS] Client application name

2009-10-21 Thread Robert Haas
On Wed, Oct 21, 2009 at 2:41 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Wed, Oct 21, 2009 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: The post-connect SET still seems like the best choice to me. Are we really thinking about interposing an

Re: [HACKERS] Client application name

2009-10-21 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Wed, Oct 21, 2009 at 2:41 PM, Tom Lane t...@sss.pgh.pa.us wrote: Only connections that are actually using the feature.  It doesn't bother me that much --- before 7.4 we had *multiple* round trips involved in a connection start, OK, but surely

Re: [HACKERS] Client application name

2009-10-20 Thread Dave Page
On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan and...@dunslane.net wrote: On the second question, obviously the user can call SET to set a value, as I've done for now in psql, however in other DBMSs, it may be set in the connection string. My feeling would be to do that, and possibly add

Re: [HACKERS] Client application name

2009-10-20 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: I just realised there's a nasty problem with this. In my client application, I can use PQconninfoParse to determine if application_name (or fallback_application_name) are valid connection string options for the version of libpq that I have. However, there

Re: [HACKERS] Client application name

2009-10-15 Thread Dave Page
On Wed, Oct 14, 2009 at 3:42 PM, Tom Lane t...@sss.pgh.pa.us wrote: Sure.  I'm envisioning that what the env variable or connection option actually does is cause libpq to include a SET command for a GUC variable in the initial connection request packet.  Compare, say, PGCLIENTENCODING -

Re: [HACKERS] Client application name

2009-10-15 Thread Euler Taveira de Oliveira
Dave Page escreveu: On Wed, Oct 14, 2009 at 3:42 PM, Tom Lane t...@sss.pgh.pa.us wrote: Sure. I'm envisioning that what the env variable or connection option actually does is cause libpq to include a SET command for a GUC variable in the initial connection request packet. Compare, say,

Re: [HACKERS] Client application name

2009-10-15 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: a) Added PQsetdbLogin2() with an additional option for the application name (my guess is 'no'). b) Updated the apps to use PQconnectdb c) Something else? a) is absolutely right out. b) is okay from an overall viewpoint but you would find yourself doing

Re: [HACKERS] Client application name

2009-10-15 Thread Dave Page
On Thu, Oct 15, 2009 at 3:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: a) Added PQsetdbLogin2() with an additional option for the application name (my guess is 'no'). b) Updated the apps to use PQconnectdb c) Something else? a) is absolutely right out.  b)

Re: [HACKERS] Client application name

2009-10-15 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Thu, Oct 15, 2009 at 3:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: Also, I am wondering exactly what you think psql would *do* with the parameter if it had it.  If the answer is force the setting to be 'psql', that's the wrong answer.  IMO you'd really want

Re: [HACKERS] Client application name

2009-10-15 Thread Dave Page
On Thu, Oct 15, 2009 at 3:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: On Thu, Oct 15, 2009 at 3:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: Also, I am wondering exactly what you think psql would *do* with the parameter if it had it.  If the answer is force the

Re: [HACKERS] Client application name

2009-10-15 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Thu, Oct 15, 2009 at 3:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: Hmm.  Maybe this is a generic problem.  Should libpq offer some sort of help?  Maybe a secondaryappname parameter that doesn't override the env variable. is it worth uglifying libpq? All

Re: [HACKERS] Client application name

2009-10-15 Thread Dave Page
On Thu, Oct 15, 2009 at 4:37 PM, Tom Lane t...@sss.pgh.pa.us wrote: Another possibility that should be mentioned for the record is that we could special-case the appname parameter inside libpq, so that the environment variable takes precedence over the conn setting instead of the other way

Re: [HACKERS] Client application name

2009-10-15 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: Looking further, I think this might be quite clean: - Add a precedence flag to PQconninfoOption - In conninfo_parse, in the section that grabs the envvars for empty params, modify the logic to override any existing values if a value is set in the

Re: [HACKERS] Client application name

2009-10-14 Thread Dave Page
On Tue, Oct 13, 2009 at 10:25 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 9:13 PM, Jaime Casanova jcasa...@systemguards.com.ec wrote: besides, as Robert mention, because of pooler connections using a GUC is more appropiate... I'd like

Re: [HACKERS] Client application name

2009-10-14 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 10:25 PM, Tom Lane t...@sss.pgh.pa.us wrote: We have several things already that can be fed either from an environment variable or an option in the connection string. Is there any compelling reason why those two mechanisms aren't

Re: [HACKERS] Client application name

2009-10-14 Thread Dave Page
On Wed, Oct 14, 2009 at 3:42 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 10:25 PM, Tom Lane t...@sss.pgh.pa.us wrote: We have several things already that can be fed either from an environment variable or an option in the connection string.

Re: [HACKERS] Client application name

2009-10-14 Thread Eric B. Ridge
On Oct 13, 2009, at 11:02 AM, Dave Page wrote: A useful feature found in other DBMSs such as MS SQL Server that has been requested on these lists a few times, is the ability for a client application to report its name to the server. I've been following this thread closely and haven't seen

Re: [HACKERS] Client application name

2009-10-14 Thread Dave Page
On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge e...@tcdi.com wrote: On Oct 13, 2009, at 11:02 AM, Dave Page wrote: A useful feature found in other DBMSs such as MS SQL Server that has been requested on these lists a few times, is the ability for a client application to report its name to the

Re: [HACKERS] Client application name

2009-10-14 Thread Magnus Hagander
On Wed, Oct 14, 2009 at 18:39, Dave Page dp...@pgadmin.org wrote: On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge e...@tcdi.com wrote: On Oct 13, 2009, at 11:02 AM, Dave Page wrote: A useful feature found in other DBMSs such as MS SQL Server that has been requested on these lists a few times,

Re: [HACKERS] Client application name

2009-10-14 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge e...@tcdi.com wrote: I've been following this thread closely and haven't seen mention of including the setting as part of the process name, so a 'ps' (on Unix) would display it. Thoughts? Isn't that cluttered

Re: [HACKERS] Client application name

2009-10-14 Thread Eric B. Ridge
On Oct 14, 2009, at 12:39 PM, Dave Page wrote: Isn't that cluttered enough already? I find the ps output uninformative. Having it display something that gets generated from my application would start to make it useful. Maybe what I really want is a totally different feature:

[HACKERS] Client application name

2009-10-13 Thread Dave Page
A useful feature found in other DBMSs such as MS SQL Server that has been requested on these lists a few times, is the ability for a client application to report its name to the server. This information may then be presented in logs, activity reports and so on to aid debugging and help the

Re: [HACKERS] Client application name

2009-10-13 Thread Alvaro Herrera
Dave Page wrote: The attached patch is a first quick cut of the basic functionality to do this. Currently, it makes the following changes: Couple of thoughts, - should we use argv[0] automatically in libpq unless overridden? - should we reject funny chars such as \n? (hopefully \0 won't be a

Re: [HACKERS] Client application name

2009-10-13 Thread Andrew Dunstan
Dave Page wrote: My questions to the group are: - Is my approach reasonable? - What interface should I include in libpq? On the second question, obviously the user can call SET to set a value, as I've done for now in psql, however in other DBMSs, it may be set in the connection string. My

Re: [HACKERS] Client application name

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Dave Page wrote: The attached patch is a first quick cut of the basic functionality to do this. Currently, it makes the following changes: Couple of thoughts, - should we use argv[0] automatically in libpq

Re: [HACKERS] Client application name

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan and...@dunslane.net wrote: Doing it with a GUC will not be nearly so useful as having it in the wire protocol, IMNSHO. Just one example: it wouldn't be present in connection records, because it wouldn't be set yet. I quite like the flexibility

Re: [HACKERS] Client application name

2009-10-13 Thread Alvaro Herrera
Dave Page wrote: On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: - should we reject funny chars such as \n? (hopefully \0 won't be a problem) Is there any need? I can't see that it would do any harm other than maybe messing up some query output - and

Re: [HACKERS] Client application name

2009-10-13 Thread Andrew Dunstan
Dave Page wrote: On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan and...@dunslane.net wrote: Doing it with a GUC will not be nearly so useful as having it in the wire protocol, IMNSHO. Just one example: it wouldn't be present in connection records, because it wouldn't be set yet. I

Re: [HACKERS] Client application name

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan and...@dunslane.net wrote: From time to time people ask for scalar variable facility. ISTM what you're trying to do is just a special case of that. Maybe we could approach it by providing a builtin (and non-removable) custom_variable_classes

Re: [HACKERS] Client application name

2009-10-13 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: - Is my approach reasonable? - What interface should I include in libpq? I thought the plan was to have libpq look at an environment variable, compare PGCLIENTENCODING for example. I'm not convinced psql should be involved in the logic at all --- if it is,

Re: [HACKERS] Client application name

2009-10-13 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: - should we use argv[0] automatically in libpq unless overridden? How can I get to it from libpq? You can't. regards, tom lane -- Sent via

Re: [HACKERS] Client application name

2009-10-13 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan and...@dunslane.net wrote: From time to time people ask for scalar variable facility. I'm not sure that's really related to this It isn't; I think Andrew confused this thread with the one where someone wanted

Re: [HACKERS] Client application name

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: - Is my approach reasonable? - What interface should I include in libpq? I thought the plan was to have libpq look at an environment variable, I wasn't aware we had a plan :-) compare

Re: [HACKERS] Client application name

2009-10-13 Thread Andrew Dunstan
Tom Lane wrote: Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan and...@dunslane.net wrote: From time to time people ask for scalar variable facility. I'm not sure that's really related to this It isn't; I think Andrew confused

Re: [HACKERS] Client application name

2009-10-13 Thread Kris Jurka
On Tue, 13 Oct 2009, Dave Page wrote: A useful feature found in other DBMSs such as MS SQL Server that has been requested on these lists a few times, is the ability for a client application to report its name to the server. This information may then be presented in logs, activity reports and

Re: [HACKERS] Client application name

2009-10-13 Thread Massa, Harald Armin
I can have libpq look at the environment as it does for PGCLIENTENCODING, but I'd certainly like to be able to use the connection string as well, as environment variables are not really the another challenge with the Environment variable: they are (at least on windows) usually set for one logged

Re: [HACKERS] Client application name

2009-10-13 Thread Andres Freund
On Tuesday 13 October 2009 18:30:54 Massa, Harald Armin wrote: I can have libpq look at the environment as it does for PGCLIENTENCODING, but I'd certainly like to be able to use the connection string as well, as environment variables are not really the another challenge with the Environment

Re: [HACKERS] Client application name

2009-10-13 Thread Robert Haas
On Tue, Oct 13, 2009 at 12:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: - Is my approach reasonable? - What interface should I include in libpq? I thought the plan was to have libpq look at an environment variable, compare PGCLIENTENCODING for example.  I'm

Re: [HACKERS] Client application name

2009-10-13 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: What happens if we want to change the application name after the fact? As long as it's a GUC variable you can just do SET. I think the point of discussion is what is the best convention for getting it set initially. regards, tom

Re: [HACKERS] Client application name

2009-10-13 Thread Jaime Casanova
On Tue, Oct 13, 2009 at 11:55 AM, Robert Haas robertmh...@gmail.com wrote: What happens if we want to change the application name after the fact?  Consider the case where there is a connection pooler between the database and application, for example. good point... -- Atentamente, Jaime

Re: [HACKERS] Client application name

2009-10-13 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: - Is my approach reasonable? I thought the plan was to have libpq look at an environment variable, I wasn't aware we had a plan :-) There was some

Re: [HACKERS] Client application name

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 6:38 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: - Is my approach reasonable? I thought the plan was to have libpq look at an

Re: [HACKERS] Client application name

2009-10-13 Thread Jaime Casanova
On Tue, Oct 13, 2009 at 1:07 PM, Dave Page dp...@pgadmin.org wrote: Oh, and apologies to Jaime who I just noticed had volunteered to work on this :-( never mind... i get blocked for the ugliness of the libpq api connect functions... and my first attempt to solve that was seriously broken...

Re: [HACKERS] Client application name

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 9:13 PM, Jaime Casanova jcasa...@systemguards.com.ec wrote: On Tue, Oct 13, 2009 at 1:07 PM, Dave Page dp...@pgadmin.org wrote: Oh, and apologies to Jaime who I just noticed had volunteered to work on this :-( never mind... i get blocked for the ugliness of the libpq

Re: [HACKERS] Client application name

2009-10-13 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 9:13 PM, Jaime Casanova jcasa...@systemguards.com.ec wrote: besides, as Robert mention, because of pooler connections using a GUC is more appropiate... I'd like both options to be available to the programmer. We have several things