Horton
Menu

Thread

  1. Application name patch - v3

    Dave Page <dpage@pgadmin.org> — 2009-10-22T13:07:13Z

    Updated patch attached. Per discussion, this:

- Changes the envvar name to PGAPPNAME
- Removes support for setting application_name in the startup packet,
and instead sends an explicit SET command as part of the connection
setup in PQconnectPoll. In order to avoid adding to the
application-visible connection states, this is overloaded on the
CONNECTION_SETENV state which is only used in the v2 protocol at
present and seems like an ideal fit for such a similar use.

Other features are as per the last version.

-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start

  2. Re: Application name patch - v3

    Andres Freund <andres@anarazel.de> — 2009-11-12T23:32:00Z

    Hi Dave,

On Thursday 22 October 2009 15:07:13 Dave Page wrote:
> Updated patch attached. Per discussion, this:
> - Changes the envvar name to PGAPPNAME
> - Removes support for setting application_name in the startup packet,
> and instead sends an explicit SET command as part of the connection
> setup in PQconnectPoll. In order to avoid adding to the
> application-visible connection states, this is overloaded on the
> CONNECTION_SETENV state which is only used in the v2 protocol at
> present and seems like an ideal fit for such a similar use.
I had some free time so I started to take a look at that patch:

+ PostgresPollingStatusType
+ pqAppnamePoll(PGconn *conn)
...
+ 			case APPNAME_STATE_OPTION_WAIT:
...
+ 				else
+ 				{
+ 					/* Query finished, so we're done */
+ 					conn->setenv_state = APPNAME_STATE_IDLE;
+ 					return PGRES_POLLING_OK;
+ 				}
+ 				break;
+ 			}
Shouldnt that set appname_state?

The attached patch fixes this and also a couple occurances of trailing 
whitespace.

What about pg_dump/psql setting fallback_application_name?

Andres

  3. Re: Application name patch - v3

    Dave Page <dpage@pgadmin.org> — 2009-11-13T11:11:38Z

    Hi Andres,

On Thu, Nov 12, 2009 at 11:32 PM, Andres Freund <andres@anarazel.de> wrote:
> I had some free time so I started to take a look at that patch:
>
> + PostgresPollingStatusType
> + pqAppnamePoll(PGconn *conn)
> ...
> +                       case APPNAME_STATE_OPTION_WAIT:
> ...
> +                               else
> +                               {
> +                                       /* Query finished, so we're done */
> +                                       conn->setenv_state = APPNAME_STATE_IDLE;
> +                                       return PGRES_POLLING_OK;
> +                               }
> +                               break;
> +                       }
> Shouldnt that set appname_state?

Yup, well spotted.

> The attached patch fixes this and also a couple occurances of trailing
> whitespace.

Thanks.

> What about pg_dump/psql setting fallback_application_name?

Per Tom, I'm waiting on the possible new array-based libpq connect API
which will make a conversion of those utilities from PQsetdbLogin a
lot cleaner than moving to PQconnectdb (and all the ugly connection
string building that would require).

-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

  4. Re: Application name patch - v3

    Andres Freund <andres@anarazel.de> — 2009-11-25T13:22:43Z

    Hi,

On Thursday 22 October 2009 15:07:13 Dave Page wrote:
> Updated patch attached. Per discussion, this:
> 
> - Changes the envvar name to PGAPPNAME
> - Removes support for setting application_name in the startup packet,
> and instead sends an explicit SET command as part of the connection
> setup in PQconnectPoll. In order to avoid adding to the
> application-visible connection states, this is overloaded on the
> CONNECTION_SETENV state which is only used in the v2 protocol at
> present and seems like an ideal fit for such a similar use.
> 
> Other features are as per the last version.
One more question: Per my reading of the discussion (which very well might be 
flawed), wasnt the plan to limit the availale characters in the application 
name to ascii?

Greetings,

Andres

  5. Re: Application name patch - v3

    Dave Page <dpage@pgadmin.org> — 2009-11-25T13:28:14Z

    On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund <andres@anarazel.de> wrote:
> Hi,
>
> On Thursday 22 October 2009 15:07:13 Dave Page wrote:
>> Updated patch attached. Per discussion, this:
>>
>> - Changes the envvar name to PGAPPNAME
>> - Removes support for setting application_name in the startup packet,
>> and instead sends an explicit SET command as part of the connection
>> setup in PQconnectPoll. In order to avoid adding to the
>> application-visible connection states, this is overloaded on the
>> CONNECTION_SETENV state which is only used in the v2 protocol at
>> present and seems like an ideal fit for such a similar use.
>>
>> Other features are as per the last version.
> One more question: Per my reading of the discussion (which very well might be
> flawed), wasnt the plan to limit the availale characters in the application
> name to ascii?

That was suggested, but I thought the eventual outcome was to not bother.


-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

  6. Re: Application name patch - v3

    Andres Freund <andres@anarazel.de> — 2009-11-25T13:33:18Z

    On Wednesday 25 November 2009 14:28:14 Dave Page wrote:
> On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund <andres@anarazel.de> wrote:
> > Hi,
> >
> > On Thursday 22 October 2009 15:07:13 Dave Page wrote:
> >> Updated patch attached. Per discussion, this:
> >>
> >> - Changes the envvar name to PGAPPNAME
> >> - Removes support for setting application_name in the startup packet,
> >> and instead sends an explicit SET command as part of the connection
> >> setup in PQconnectPoll. In order to avoid adding to the
> >> application-visible connection states, this is overloaded on the
> >> CONNECTION_SETENV state which is only used in the v2 protocol at
> >> present and seems like an ideal fit for such a similar use.
> >>
> >> Other features are as per the last version.
> >
> > One more question: Per my reading of the discussion (which very well
> > might be flawed), wasnt the plan to limit the availale characters in the
> > application name to ascii?
> 
> That was suggested, but I thought the eventual outcome was to not bother.
Then I dont see any reason to delay any further (sorry!). I personally would 
prefer making it a bit more strict but it surely is not imporant.

Markes as ready for comitter.

Andres

  7. Re: Application name patch - v3

    Tom Lane <tgl@sss.pgh.pa.us> — 2009-11-25T22:01:35Z

    Dave Page <dpage@pgadmin.org> writes:
> On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund <andres@anarazel.de> wrote:
>> One more question: Per my reading of the discussion (which very well might be
>> flawed), wasnt the plan to limit the availale characters in the application
>> name to ascii?

> That was suggested, but I thought the eventual outcome was to not bother.

I think that's really essential, not optional.  The proposed patch will
transfer the application name from one backend to another without any
encoding conversion.  If it contains non-ASCII characters that will
result in injection of badly-encoded data inside the backend, which is
something we have been trying hard to avoid in recent versions.

The only other thing you could do about this would be to try to convert
the data from the source backend's encoding to the target's.  Which
would lead to assorted failure scenarios when no conversion is possible.

ISTM restricting the name to ASCII-only is the most reasonable tradeoff.
Of course, as a speaker of English I may be a bit biased here --- but
doing nothing about the issue doesn't seem acceptable.

			regards, tom lane

  8. Re: Application name patch - v3

    Andres Freund <andres@anarazel.de> — 2009-11-26T00:07:59Z

    On Wednesday 25 November 2009 23:01:35 Tom Lane wrote:
> Dave Page <dpage@pgadmin.org> writes:
> > On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund <andres@anarazel.de> wrote:
> >> One more question: Per my reading of the discussion (which very well
> >> might be flawed), wasnt the plan to limit the availale characters in the
> >> application name to ascii?
> > That was suggested, but I thought the eventual outcome was to not bother.
> I think that's really essential, not optional.  The proposed patch will
> transfer the application name from one backend to another without any
> encoding conversion.  If it contains non-ASCII characters that will
> result in injection of badly-encoded data inside the backend, which is
> something we have been trying hard to avoid in recent versions.
Isn't that similarly the case with pg_stat_activity?

> ISTM restricting the name to ASCII-only is the most reasonable tradeoff.
> Of course, as a speaker of English I may be a bit biased here --- but
> doing nothing about the issue doesn't seem acceptable.
I actually having a hard time imaging a use case where this would be a real 
problem...

I have to admit though that while I am not from a English speaking country but 
from Germany the amount of non ASCII chars used there routinely is not that 
big, so ...

Andres

  9. Re: Application name patch - v3

    Tom Lane <tgl@sss.pgh.pa.us> — 2009-11-26T00:35:45Z

    Andres Freund <andres@anarazel.de> writes:
> On Wednesday 25 November 2009 23:01:35 Tom Lane wrote:
>> I think that's really essential, not optional.  The proposed patch will
>> transfer the application name from one backend to another without any
>> encoding conversion.  If it contains non-ASCII characters that will
>> result in injection of badly-encoded data inside the backend, which is
>> something we have been trying hard to avoid in recent versions.

> Isn't that similarly the case with pg_stat_activity?

Well, we do still have some un-plugged holes there, but that's not an
excuse for adding more.

			regards, tom lane

  10. Re: Application name patch - v3

    Dave Page <dpage@pgadmin.org> — 2009-11-26T13:54:33Z

    On Wed, Nov 25, 2009 at 10:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> ISTM restricting the name to ASCII-only is the most reasonable tradeoff.
> Of course, as a speaker of English I may be a bit biased here --- but
> doing nothing about the issue doesn't seem acceptable.

OK - something like this? Should keep non-printable/control characters
out of logs too...

static const char *
assign_application_name(const char *newval, bool doit, GucSource source)
{
        /* Only allow clean ASCII chars in the application name */
        int x;

        char *repval = guc_malloc(ERROR, strlen(newval) + 1);
        repval[0] = 0;

        for (x=0; x<strlen(newval); x++)
        {
                if (newval[x] < 32 || newval[x] > 126)
                        repval[x] = '?';
                else
                        repval[x] = newval[x];
        }

        repval[x+1] = 0;
        return repval;
}


-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

  11. Re: Application name patch - v3

    Tom Lane <tgl@sss.pgh.pa.us> — 2009-11-26T15:09:42Z

    Dave Page <dpage@pgadmin.org> writes:
> OK - something like this? Should keep non-printable/control characters
> out of logs too...

Personally I'd use guc_strdup and then modify the string in-place,
but that's just a matter of taste I guess.  Otherwise it seems
reasonable.

			regards, tom lane

  12. Re: Application name patch - v3

    Guillaume Lelarge <guillaume@lelarge.info> — 2009-12-27T23:15:51Z

    Le 13/11/2009 12:11, Dave Page a écrit :
> [...]
>> What about pg_dump/psql setting fallback_application_name?
> 
> Per Tom, I'm waiting on the possible new array-based libpq connect API
> which will make a conversion of those utilities from PQsetdbLogin a
> lot cleaner than moving to PQconnectdb (and all the ugly connection
> string building that would require).
> 

Is it still to be done? I don't see psql pr pg_dump set an application
name on alpha 3. There are also pg_restore, vacuumdb, reindexdb, etc.


-- 
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com

  13. Re: Application name patch - v3

    Dave Page <dpage@pgadmin.org> — 2009-12-28T09:07:16Z

    On Sun, Dec 27, 2009 at 11:15 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> Le 13/11/2009 12:11, Dave Page a écrit :
>> [...]
>>> What about pg_dump/psql setting fallback_application_name?
>>
>> Per Tom, I'm waiting on the possible new array-based libpq connect API
>> which will make a conversion of those utilities from PQsetdbLogin a
>> lot cleaner than moving to PQconnectdb (and all the ugly connection
>> string building that would require).
>>
>
> Is it still to be done? I don't see psql pr pg_dump set an application
> name on alpha 3. There are also pg_restore, vacuumdb, reindexdb, etc.

Yes, still waiting on the new API.

-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

  14. Re: Application name patch - v3

    Guillaume Lelarge <guillaume@lelarge.info> — 2009-12-28T10:04:18Z

    Le 28/12/2009 10:07, Dave Page a écrit :
> On Sun, Dec 27, 2009 at 11:15 PM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>> Le 13/11/2009 12:11, Dave Page a écrit :
>>> [...]
>>>> What about pg_dump/psql setting fallback_application_name?
>>>
>>> Per Tom, I'm waiting on the possible new array-based libpq connect API
>>> which will make a conversion of those utilities from PQsetdbLogin a
>>> lot cleaner than moving to PQconnectdb (and all the ugly connection
>>> string building that would require).
>>>
>>
>> Is it still to be done? I don't see psql pr pg_dump set an application
>> name on alpha 3. There are also pg_restore, vacuumdb, reindexdb, etc.
> 
> Yes, still waiting on the new API.
> 

Is there something I can do to make this move forward?


-- 
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com

  15. Re: Application name patch - v3

    Tom Lane <tgl@sss.pgh.pa.us> — 2009-12-28T16:06:52Z

    Guillaume Lelarge <guillaume@lelarge.info> writes:
> Le 28/12/2009 10:07, Dave Page a crit :
>> Yes, still waiting on the new API.

> Is there something I can do to make this move forward?

I think we were stalled on the question of whether to use one array
or two parallel arrays.  Do you want to try coding up a sample usage
of each possibility so we can see which one seems more useful?

			regards, tom lane

  16. Re: Application name patch - v3

    Guillaume Lelarge <guillaume@lelarge.info> — 2009-12-28T21:33:22Z

    Le 28/12/2009 17:06, Tom Lane a écrit :
> Guillaume Lelarge <guillaume@lelarge.info> writes:
>> Le 28/12/2009 10:07, Dave Page a écrit :
>>> Yes, still waiting on the new API.
> 
>> Is there something I can do to make this move forward?
> 
> I think we were stalled on the question of whether to use one array
> or two parallel arrays.  Do you want to try coding up a sample usage
> of each possibility so we can see which one seems more useful?
> 

I'm interested in working on this. But I don't find the thread that talk
about this. I feel pretty dumb, but I re-read every mail on "Application
name patch - v2", "Application name patch - v3", and "Application name
patch - v4" threads. I also re-read the "Client application name"
thread. The only mail I see that relates to the new API is the one from
Dave (the one I answered today).

So, can someone point me to the thread that deals with this "new
array-based libpq connect API"? or can someone explain it to me?

Thanks.


-- 
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com

  17. Re: Application name patch - v3

    Tom Lane <tgl@sss.pgh.pa.us> — 2009-12-28T21:59:24Z

    Guillaume Lelarge <guillaume@lelarge.info> writes:
> Le 28/12/2009 17:06, Tom Lane a crit :
>> I think we were stalled on the question of whether to use one array
>> or two parallel arrays.  Do you want to try coding up a sample usage
>> of each possibility so we can see which one seems more useful?

> I'm interested in working on this. But I don't find the thread that talk
> about this.

Try here
http://archives.postgresql.org/message-id/4AAE8CCF.9070808@esilo.com

			regards, tom lane

  18. Re: Application name patch - v3

    Guillaume Lelarge <guillaume@lelarge.info> — 2009-12-28T23:03:45Z

    Le 28/12/2009 22:59, Tom Lane a écrit :
> Guillaume Lelarge <guillaume@lelarge.info> writes:
>> Le 28/12/2009 17:06, Tom Lane a écrit :
>>> I think we were stalled on the question of whether to use one array
>>> or two parallel arrays.  Do you want to try coding up a sample usage
>>> of each possibility so we can see which one seems more useful?
> 
>> I'm interested in working on this. But I don't find the thread that talk
>> about this.
> 
> Try here
> http://archives.postgresql.org/message-id/4AAE8CCF.9070808@esilo.com
> 

Thanks. I've read all the "new version of PQconnectdb" and "Determining
client_encoding from client locale" threads. I think I understand the
goal. Still need to re-read this one
(http://archives.postgresql.org/message-id/6222.1253734019@sss.pgh.pa.us) and
completely understand it (will probably need to look at the code, at
least the PQconnectdb one). But I'm definitely working on this.


-- 
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com

  19. Re: Application name patch - v3

    Guillaume Lelarge <guillaume@lelarge.info> — 2009-12-29T13:12:52Z

    Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
> Le 28/12/2009 22:59, Tom Lane a écrit :
>> Guillaume Lelarge <guillaume@lelarge.info> writes:
>>> Le 28/12/2009 17:06, Tom Lane a écrit :
>>>> I think we were stalled on the question of whether to use one array
>>>> or two parallel arrays.  Do you want to try coding up a sample usage
>>>> of each possibility so we can see which one seems more useful?
>>
>>> I'm interested in working on this. But I don't find the thread that talk
>>> about this.
>>
>> Try here
>> http://archives.postgresql.org/message-id/4AAE8CCF.9070808@esilo.com
>>
> 
> Thanks. I've read all the "new version of PQconnectdb" and "Determining
> client_encoding from client locale" threads. I think I understand the
> goal. Still need to re-read this one
> (http://archives.postgresql.org/message-id/6222.1253734019@sss.pgh.pa.us) and
> completely understand it (will probably need to look at the code, at
> least the PQconnectdb one). But I'm definitely working on this.
> 

If I try to sum up my readings so far, this is what we still have to do:

1. try the one-array approach
   PGconn *PQconnectParams(const char **params)

2. try the two-arrays approach
   PGconn *PQconnectParams(const char **keywords, const char **values)

Instead of doing a wrapper around PQconnectdb, we need to refactor the
whole function, so that we can get rid of the parsing of the conninfo
string (which is quite complicated).

Using psql as an example would be a good idea, AFAICT.

Am I right? did I misunderstand or forget something?


-- 
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com

  20. Re: Application name patch - v3

    Guillaume Lelarge <guillaume@lelarge.info> — 2010-01-04T21:36:13Z

    Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
> Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
>> Le 28/12/2009 22:59, Tom Lane a écrit :
>>> Guillaume Lelarge <guillaume@lelarge.info> writes:
>>>> Le 28/12/2009 17:06, Tom Lane a écrit :
>>>>> I think we were stalled on the question of whether to use one array
>>>>> or two parallel arrays.  Do you want to try coding up a sample usage
>>>>> of each possibility so we can see which one seems more useful?
>>>
>>>> I'm interested in working on this. But I don't find the thread that talk
>>>> about this.
>>>
>>> Try here
>>> http://archives.postgresql.org/message-id/4AAE8CCF.9070808@esilo.com
>>>
>>
>> Thanks. I've read all the "new version of PQconnectdb" and "Determining
>> client_encoding from client locale" threads. I think I understand the
>> goal. Still need to re-read this one
>> (http://archives.postgresql.org/message-id/6222.1253734019@sss.pgh.pa.us) and
>> completely understand it (will probably need to look at the code, at
>> least the PQconnectdb one). But I'm definitely working on this.
>>
> 
> If I try to sum up my readings so far, this is what we still have to do:
> 
> 1. try the one-array approach
>    PGconn *PQconnectParams(const char **params)
> 
> 2. try the two-arrays approach
>    PGconn *PQconnectParams(const char **keywords, const char **values)
> 
> Instead of doing a wrapper around PQconnectdb, we need to refactor the
> whole function, so that we can get rid of the parsing of the conninfo
> string (which is quite complicated).
> 
> Using psql as an example would be a good idea, AFAICT.
> 
> Am I right? did I misunderstand or forget something?
> 

I supposed I was right since noone yell at me :)

I worked on this tonight. You'll find two patches attached, one for the
one-array approach, one for the two-arrays approach. I know some more
factoring can be done (at least, the "get the fallback resources..."
part). I'm OK to do them. I just need to know if I'm on the right track.


-- 
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com

  21. Re: Application name patch - v3

    Guillaume Lelarge <guillaume@lelarge.info> — 2010-01-07T15:33:50Z

    Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
> Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
>> Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
>>> Le 28/12/2009 22:59, Tom Lane a écrit :
>>>> Guillaume Lelarge <guillaume@lelarge.info> writes:
>>>>> Le 28/12/2009 17:06, Tom Lane a écrit :
>>>>>> I think we were stalled on the question of whether to use one array
>>>>>> or two parallel arrays.  Do you want to try coding up a sample usage
>>>>>> of each possibility so we can see which one seems more useful?
>>>>
>>>>> I'm interested in working on this. But I don't find the thread that talk
>>>>> about this.
>>>>
>>>> Try here
>>>> http://archives.postgresql.org/message-id/4AAE8CCF.9070808@esilo.com
>>>>
>>>
>>> Thanks. I've read all the "new version of PQconnectdb" and "Determining
>>> client_encoding from client locale" threads. I think I understand the
>>> goal. Still need to re-read this one
>>> (http://archives.postgresql.org/message-id/6222.1253734019@sss.pgh.pa.us) and
>>> completely understand it (will probably need to look at the code, at
>>> least the PQconnectdb one). But I'm definitely working on this.
>>>
>>
>> If I try to sum up my readings so far, this is what we still have to do:
>>
>> 1. try the one-array approach
>>    PGconn *PQconnectParams(const char **params)
>>
>> 2. try the two-arrays approach
>>    PGconn *PQconnectParams(const char **keywords, const char **values)
>>
>> Instead of doing a wrapper around PQconnectdb, we need to refactor the
>> whole function, so that we can get rid of the parsing of the conninfo
>> string (which is quite complicated).
>>
>> Using psql as an example would be a good idea, AFAICT.
>>
>> Am I right? did I misunderstand or forget something?
>>
> 
> I supposed I was right since noone yell at me :)
> 
> I worked on this tonight. You'll find two patches attached, one for the
> one-array approach, one for the two-arrays approach. I know some more
> factoring can be done (at least, the "get the fallback resources..."
> part). I'm OK to do them. I just need to know if I'm on the right track.
> 

Hmmm... sorry but... can i have some comments on these two patches, please?


-- 
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com

  22. Re: Application name patch - v3

    Robert Haas <robertmhaas@gmail.com> — 2010-01-07T18:13:44Z

    On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
>> Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
>>> Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
>>>> Le 28/12/2009 22:59, Tom Lane a écrit :
>>>>> Guillaume Lelarge <guillaume@lelarge.info> writes:
>>>>>> Le 28/12/2009 17:06, Tom Lane a écrit :
>>>>>>> I think we were stalled on the question of whether to use one array
>>>>>>> or two parallel arrays.  Do you want to try coding up a sample usage
>>>>>>> of each possibility so we can see which one seems more useful?
>>>>>
>>>>>> I'm interested in working on this. But I don't find the thread that talk
>>>>>> about this.
>>>>>
>>>>> Try here
>>>>> http://archives.postgresql.org/message-id/4AAE8CCF.9070808@esilo.com
>>>>>
>>>>
>>>> Thanks. I've read all the "new version of PQconnectdb" and "Determining
>>>> client_encoding from client locale" threads. I think I understand the
>>>> goal. Still need to re-read this one
>>>> (http://archives.postgresql.org/message-id/6222.1253734019@sss.pgh.pa.us) and
>>>> completely understand it (will probably need to look at the code, at
>>>> least the PQconnectdb one). But I'm definitely working on this.
>>>>
>>>
>>> If I try to sum up my readings so far, this is what we still have to do:
>>>
>>> 1. try the one-array approach
>>>    PGconn *PQconnectParams(const char **params)
>>>
>>> 2. try the two-arrays approach
>>>    PGconn *PQconnectParams(const char **keywords, const char **values)
>>>
>>> Instead of doing a wrapper around PQconnectdb, we need to refactor the
>>> whole function, so that we can get rid of the parsing of the conninfo
>>> string (which is quite complicated).
>>>
>>> Using psql as an example would be a good idea, AFAICT.
>>>
>>> Am I right? did I misunderstand or forget something?
>>>
>>
>> I supposed I was right since noone yell at me :)
>>
>> I worked on this tonight. You'll find two patches attached, one for the
>> one-array approach, one for the two-arrays approach. I know some more
>> factoring can be done (at least, the "get the fallback resources..."
>> part). I'm OK to do them. I just need to know if I'm on the right track.
>>
>
> Hmmm... sorry but... can i have some comments on these two patches, please?

I would suggest adding your patch(es) to:

https://commitfest.postgresql.org/action/commitfest_view/open

Probably just one entry for the two of them would be most appropriate.

...Robert

  23. Re: Application name patch - v3

    Guillaume Lelarge <guillaume@lelarge.info> — 2010-01-08T22:22:34Z

    Le 07/01/2010 19:13, Robert Haas a écrit :
> On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>> Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
>>> Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
>>>> Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
>>>>> Le 28/12/2009 22:59, Tom Lane a écrit :
>>>>>> Guillaume Lelarge <guillaume@lelarge.info> writes:
>>>>>>> Le 28/12/2009 17:06, Tom Lane a écrit :
>>>>>>>> I think we were stalled on the question of whether to use one array
>>>>>>>> or two parallel arrays.  Do you want to try coding up a sample usage
>>>>>>>> of each possibility so we can see which one seems more useful?
>>>>>>
>>>>>>> I'm interested in working on this. But I don't find the thread that talk
>>>>>>> about this.
>>>>>>
>>>>>> Try here
>>>>>> http://archives.postgresql.org/message-id/4AAE8CCF.9070808@esilo.com
>>>>>>
>>>>>
>>>>> Thanks. I've read all the "new version of PQconnectdb" and "Determining
>>>>> client_encoding from client locale" threads. I think I understand the
>>>>> goal. Still need to re-read this one
>>>>> (http://archives.postgresql.org/message-id/6222.1253734019@sss.pgh.pa.us) and
>>>>> completely understand it (will probably need to look at the code, at
>>>>> least the PQconnectdb one). But I'm definitely working on this.
>>>>>
>>>>
>>>> If I try to sum up my readings so far, this is what we still have to do:
>>>>
>>>> 1. try the one-array approach
>>>>    PGconn *PQconnectParams(const char **params)
>>>>
>>>> 2. try the two-arrays approach
>>>>    PGconn *PQconnectParams(const char **keywords, const char **values)
>>>>
>>>> Instead of doing a wrapper around PQconnectdb, we need to refactor the
>>>> whole function, so that we can get rid of the parsing of the conninfo
>>>> string (which is quite complicated).
>>>>
>>>> Using psql as an example would be a good idea, AFAICT.
>>>>
>>>> Am I right? did I misunderstand or forget something?
>>>>
>>>
>>> I supposed I was right since noone yell at me :)
>>>
>>> I worked on this tonight. You'll find two patches attached, one for the
>>> one-array approach, one for the two-arrays approach. I know some more
>>> factoring can be done (at least, the "get the fallback resources..."
>>> part). I'm OK to do them. I just need to know if I'm on the right track.
>>>
>>
>> Hmmm... sorry but... can i have some comments on these two patches, please?
> 
> I would suggest adding your patch(es) to:
> 
> https://commitfest.postgresql.org/action/commitfest_view/open
> 
> Probably just one entry for the two of them would be most appropriate.
> 

Done. Thanks.


-- 
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com

  24. Re: Application name patch - v3

    Guillaume Lelarge <guillaume@lelarge.info> — 2010-01-15T17:53:57Z

    Le 08/01/2010 23:22, Guillaume Lelarge a écrit :
> Le 07/01/2010 19:13, Robert Haas a écrit :
>> On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
>> <guillaume@lelarge.info> wrote:
>>> Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
>>>> Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
>>>>> Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
>>>>>> Le 28/12/2009 22:59, Tom Lane a écrit :
>>>>>>> Guillaume Lelarge <guillaume@lelarge.info> writes:
>>>>>>>> Le 28/12/2009 17:06, Tom Lane a écrit :
>>>>>>>>> I think we were stalled on the question of whether to use one array
>>>>>>>>> or two parallel arrays.  Do you want to try coding up a sample usage
>>>>>>>>> of each possibility so we can see which one seems more useful?
>>>>>>>
>>>>>>>> I'm interested in working on this. But I don't find the thread that talk
>>>>>>>> about this.
>>>>>>>
>>>>>>> Try here
>>>>>>> http://archives.postgresql.org/message-id/4AAE8CCF.9070808@esilo.com
>>>>>>>
>>>>>>
>>>>>> Thanks. I've read all the "new version of PQconnectdb" and "Determining
>>>>>> client_encoding from client locale" threads. I think I understand the
>>>>>> goal. Still need to re-read this one
>>>>>> (http://archives.postgresql.org/message-id/6222.1253734019@sss.pgh.pa.us) and
>>>>>> completely understand it (will probably need to look at the code, at
>>>>>> least the PQconnectdb one). But I'm definitely working on this.
>>>>>>
>>>>>
>>>>> If I try to sum up my readings so far, this is what we still have to do:
>>>>>
>>>>> 1. try the one-array approach
>>>>>    PGconn *PQconnectParams(const char **params)
>>>>>
>>>>> 2. try the two-arrays approach
>>>>>    PGconn *PQconnectParams(const char **keywords, const char **values)
>>>>>
>>>>> Instead of doing a wrapper around PQconnectdb, we need to refactor the
>>>>> whole function, so that we can get rid of the parsing of the conninfo
>>>>> string (which is quite complicated).
>>>>>
>>>>> Using psql as an example would be a good idea, AFAICT.
>>>>>
>>>>> Am I right? did I misunderstand or forget something?
>>>>>
>>>>
>>>> I supposed I was right since noone yell at me :)
>>>>
>>>> I worked on this tonight. You'll find two patches attached, one for the
>>>> one-array approach, one for the two-arrays approach. I know some more
>>>> factoring can be done (at least, the "get the fallback resources..."
>>>> part). I'm OK to do them. I just need to know if I'm on the right track.
>>>>
>>>
>>> Hmmm... sorry but... can i have some comments on these two patches, please?
>>
>> I would suggest adding your patch(es) to:
>>
>> https://commitfest.postgresql.org/action/commitfest_view/open
>>
>> Probably just one entry for the two of them would be most appropriate.
>>
> 
> Done. Thanks.
> 

New patches because the old ones didn't apply anymore, due to recent CVS
commits.


-- 
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com

  25. Re: Application name patch - v3

    Guillaume Lelarge <guillaume@lelarge.info> — 2010-01-21T19:52:08Z

    Le 15/01/2010 18:53, Guillaume Lelarge a écrit :
> Le 08/01/2010 23:22, Guillaume Lelarge a écrit :
>> Le 07/01/2010 19:13, Robert Haas a écrit :
>>> On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
>>> <guillaume@lelarge.info> wrote:
>>>> Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
>>>>> Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
>>>>>> Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
>>>>>>> Le 28/12/2009 22:59, Tom Lane a écrit :
>>>>>>>> Guillaume Lelarge <guillaume@lelarge.info> writes:
>>>>>>>>> Le 28/12/2009 17:06, Tom Lane a écrit :
>>>>>>>>>> I think we were stalled on the question of whether to use one array
>>>>>>>>>> or two parallel arrays.  Do you want to try coding up a sample usage
>>>>>>>>>> of each possibility so we can see which one seems more useful?
>>>>>>>>
>>>>>>>>> I'm interested in working on this. But I don't find the thread that talk
>>>>>>>>> about this.
>>>>>>>>
>>>>>>>> Try here
>>>>>>>> http://archives.postgresql.org/message-id/4AAE8CCF.9070808@esilo.com
>>>>>>>>
>>>>>>>
>>>>>>> Thanks. I've read all the "new version of PQconnectdb" and "Determining
>>>>>>> client_encoding from client locale" threads. I think I understand the
>>>>>>> goal. Still need to re-read this one
>>>>>>> (http://archives.postgresql.org/message-id/6222.1253734019@sss.pgh.pa.us) and
>>>>>>> completely understand it (will probably need to look at the code, at
>>>>>>> least the PQconnectdb one). But I'm definitely working on this.
>>>>>>>
>>>>>>
>>>>>> If I try to sum up my readings so far, this is what we still have to do:
>>>>>>
>>>>>> 1. try the one-array approach
>>>>>>    PGconn *PQconnectParams(const char **params)
>>>>>>
>>>>>> 2. try the two-arrays approach
>>>>>>    PGconn *PQconnectParams(const char **keywords, const char **values)
>>>>>>
>>>>>> Instead of doing a wrapper around PQconnectdb, we need to refactor the
>>>>>> whole function, so that we can get rid of the parsing of the conninfo
>>>>>> string (which is quite complicated).
>>>>>>
>>>>>> Using psql as an example would be a good idea, AFAICT.
>>>>>>
>>>>>> Am I right? did I misunderstand or forget something?
>>>>>>
>>>>>
>>>>> I supposed I was right since noone yell at me :)
>>>>>
>>>>> I worked on this tonight. You'll find two patches attached, one for the
>>>>> one-array approach, one for the two-arrays approach. I know some more
>>>>> factoring can be done (at least, the "get the fallback resources..."
>>>>> part). I'm OK to do them. I just need to know if I'm on the right track.
>>>>>
>>>>
>>>> Hmmm... sorry but... can i have some comments on these two patches, please?
>>>
>>> I would suggest adding your patch(es) to:
>>>
>>> https://commitfest.postgresql.org/action/commitfest_view/open
>>>
>>> Probably just one entry for the two of them would be most appropriate.
>>>
>>
>> Done. Thanks.
>>
> 
> New patches because the old ones didn't apply anymore, due to recent CVS
> commits.
> 

New patches for same reason.


-- 
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com