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
guilla...@lelarge.info wrote:
Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
Le 29/12/2009 14:12,
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
guilla...@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,
Le 07/01/2010 19:13, Robert Haas a écrit :
On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
guilla...@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,
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 guilla...@lelarge.info writes:
Le 28/12/2009 17:06, Tom Lane a écrit :
I think we were
On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
guilla...@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
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 guilla...@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
Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
Le 28/12/2009 22:59, Tom Lane a écrit :
Guillaume Lelarge guilla...@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
On Sun, Dec 27, 2009 at 11:15 PM, Guillaume Lelarge
guilla...@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
Le 28/12/2009 10:07, Dave Page a écrit :
On Sun, Dec 27, 2009 at 11:15 PM, Guillaume Lelarge
guilla...@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
Guillaume Lelarge guilla...@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
Le 28/12/2009 17:06, Tom Lane a écrit :
Guillaume Lelarge guilla...@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
Guillaume Lelarge guilla...@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
Le 28/12/2009 22:59, Tom Lane a écrit :
Guillaume Lelarge guilla...@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
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
On Wed, Nov 25, 2009 at 10:01 PM, Tom Lane t...@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?
Dave Page dp...@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.
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
On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund and...@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
On Wednesday 25 November 2009 14:28:14 Dave Page wrote:
On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund and...@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
Dave Page dp...@pgadmin.org writes:
On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund and...@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
On Wednesday 25 November 2009 23:01:35 Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund and...@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
Andres Freund and...@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
Hi Andres,
On Thu, Nov 12, 2009 at 11:32 PM, Andres Freund and...@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:
...
+
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
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
25 matches
Mail list logo
