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
>>> wrote:
Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
> Le 29/12/2009 14:12, Guill
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
>> 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, Guilla
Le 07/01/2010 19:13, Robert Haas a écrit :
> On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
> 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 Lan
On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
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 writes:
>>
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 writes:
> Le 28/12/2009 17:06, Tom Lane a écrit :
>> I think we were st
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 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
>
Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
> Le 28/12/2009 22:59, Tom Lane a écrit :
>> Guillaume Lelarge 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
Le 28/12/2009 22:59, Tom Lane a écrit :
> Guillaume Lelarge 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 whic
Guillaume Lelarge 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
Le 28/12/2009 17:06, Tom Lane a écrit :
> Guillaume Lelarge 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 para
Guillaume Lelarge 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 u
Le 28/12/2009 10:07, Dave Page a écrit :
> On Sun, Dec 27, 2009 at 11:15 PM, Guillaume Lelarge
> 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 A
On Sun, Dec 27, 2009 at 11:15 PM, Guillaume Lelarge
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 utilit
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 (
Dave Page 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
On Wed, Nov 25, 2009 at 10:01 PM, Tom Lane 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-p
Andres Freund 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
On Wednesday 25 November 2009 23:01:35 Tom Lane wrote:
> Dave Page writes:
> > On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund 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
> >> applica
Dave Page writes:
> On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund 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 even
On Wednesday 25 November 2009 14:28:14 Dave Page wrote:
> On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund 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 s
On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund 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 instea
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
> setu
Hi Andres,
On Thu, Nov 12, 2009 at 11:32 PM, Andres Freund 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:
> ...
> +
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
> se
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
25 matches
Mail list logo
