Robert Haas writes:
> On Wed, Oct 21, 2009 at 2:41 PM, Tom Lane 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 we're not saying that was good? I p
On Wed, Oct 21, 2009 at 2:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Oct 21, 2009 at 12:27 PM, Tom Lane 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 su
Robert Haas writes:
> On Wed, Oct 21, 2009 at 12:27 PM, Tom Lane 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 (to
> paraphrase yourself)? That d
On Wed, Oct 21, 2009 at 12:27 PM, Tom Lane wrote:
> Dave Page 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
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 Pro
Dave Page 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 like the best
On Wed, Oct 21, 2009 at 4:39 PM, Dave Page wrote:
> On Wed, Oct 21, 2009 at 3:49 PM, Tom Lane wrote:
>> Dave Page writes:
>> This might be a good argument for changing that going forward, but
>> it will be *years* before we can rely on it for anything.
>
> That's what I meant by 'a few releases'
On Wed, Oct 21, 2009 at 3:49 PM, Tom Lane wrote:
> Dave Page 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 al
Dave Page 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
to behave that w
On Wed, Oct 21, 2009 at 12:01 PM, Simon Riggs 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 name also.
I
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 p
On Wed, Oct 21, 2009 at 12:45, Simon Riggs wrote:
> On Wed, 2009-10-21 at 11:20 +0100, Dave Page wrote:
>> On Wed, Oct 21, 2009 at 11:06 AM, Simon Riggs wrote:
>>
>> > The SET seems sufficient for me. All interfaces currently support it.
>>
>> SET alone will not allow what I see as one of the mos
On Wed, Oct 21, 2009 at 11:49, Dave Page 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 of thos
On Wed, 2009-10-21 at 11:20 +0100, Dave Page wrote:
> On Wed, Oct 21, 2009 at 11:06 AM, Simon Riggs 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:
>
> PGAPPLICATIONNA
Dave Page wrote:
> On Wed, Oct 21, 2009 at 10:14 AM, Heikki Linnakangas
> 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 valu
On Wed, Oct 21, 2009 at 11:06 AM, Simon Riggs 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
PGAPPLICATIONNAME="Sensor data impo
On Wed, 2009-10-21 at 10:45 +0100, Dave Page wrote:
> On Wed, Oct 21, 2009 at 10:40 AM, Simon Riggs wrote:
> > On Wed, 2009-10-21 at 10:19 +0100, Dave Page wrote:
> >> On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs
> >> wrote:
> >>
> >> > ISTM much of the complexity discussed relates to this seco
On Wed, Oct 21, 2009 at 10:14 AM, Heikki Linnakangas
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 value overrides the first one.
On Wed, Oct 21, 2009 at 10:40 AM, Simon Riggs wrote:
> On Wed, 2009-10-21 at 10:19 +0100, Dave Page wrote:
>> On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs wrote:
>>
>> > ISTM much of the complexity discussed relates to this second feature.
>> > Let's just concentrate on getting the connection-po
On Wed, 2009-10-21 at 10:19 +0100, Dave Page wrote:
> On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs 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 ma
On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs 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 the patch works fine
On Wed, 2009-10-14 at 18:44 +0200, Magnus Hagander wrote:
> On Wed, Oct 14, 2009 at 18:39, Dave Page wrote:
> > On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge 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
Dave Page wrote:
> On Tue, Oct 20, 2009 at 8:55 PM, Tom Lane wrote:
>> Dave Page 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
>>> stri
On Tue, Oct 20, 2009 at 8:55 PM, Tom Lane wrote:
> Dave Page 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 versi
Dave Page 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 is no way tha
On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan 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 PQsetApplicati
Dave Page 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 environment and the p
On Thu, Oct 15, 2009 at 4:37 PM, Tom Lane 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 round. That seem
Dave Page writes:
> On Thu, Oct 15, 2009 at 3:50 PM, Tom Lane 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 we're talking about is some
On Thu, Oct 15, 2009 at 3:50 PM, Tom Lane wrote:
> Dave Page writes:
>> On Thu, Oct 15, 2009 at 3:28 PM, Tom Lane 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 a
Dave Page writes:
> On Thu, Oct 15, 2009 at 3:28 PM, Tom Lane 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 the environment
>> variabl
On Thu, Oct 15, 2009 at 3:28 PM, Tom Lane wrote:
> Dave Page 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 vi
Dave Page 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 something very mu
Dave Page escreveu:
> On Wed, Oct 14, 2009 at 3:42 PM, Tom Lane 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,
>> PGCLIENTENCODI
On Wed, Oct 14, 2009 at 3:42 PM, Tom Lane 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 -> client_encoding.
So
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:
log_line_p
Dave Page writes:
> On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge 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 enough already?
Given
On Wed, Oct 14, 2009 at 18:39, Dave Page wrote:
> On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge 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
On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge 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 server
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 ment
On Wed, Oct 14, 2009 at 3:42 PM, Tom Lane wrote:
> Dave Page writes:
>> On Tue, Oct 13, 2009 at 10:25 PM, Tom Lane 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
Dave Page writes:
> On Tue, Oct 13, 2009 at 10:25 PM, Tom Lane 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
>> adequate for this?
> Err, yes
On Tue, Oct 13, 2009 at 10:25 PM, Tom Lane wrote:
> Dave Page writes:
>> On Tue, Oct 13, 2009 at 9:13 PM, Jaime Casanova
>> 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.
>
>
Dave Page writes:
> On Tue, Oct 13, 2009 at 9:13 PM, Jaime Casanova
> 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 already that can be fed either from an
On Tue, Oct 13, 2009 at 9:13 PM, Jaime Casanova
wrote:
> On Tue, Oct 13, 2009 at 1:07 PM, Dave Page 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 m
On Tue, Oct 13, 2009 at 1:07 PM, Dave Page 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...
besides, as Ro
On Tue, Oct 13, 2009 at 6:38 PM, Tom Lane wrote:
> Dave Page writes:
>> On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane wrote:
>>> Dave Page 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 :-)
>
Dave Page writes:
> On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane wrote:
>> Dave Page 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 previous discussion of this, which I am too
On Tue, Oct 13, 2009 at 11:55 AM, Robert Haas 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 Casanova
Soporte y c
Robert Haas 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 lane
--
Sent via p
On Tue, Oct 13, 2009 at 12:05 PM, Tom Lane wrote:
> Dave Page 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
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 Environ
>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 logge
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 s
On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane wrote:
> Dave Page 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 PGCLIENTENCODING for example.
Tom Lane wrote:
Dave Page writes:
On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan 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 someo
Dave Page writes:
> On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan 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 to know about trigger context.
Dave Page writes:
> On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera
> 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 pgsql-hackers mailing list (pgsql-hackers@postg
Dave Page 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, there definitely
On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan 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 entry
> ('pg_varia
Dave Page wrote:
On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan 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 flexib
Dave Page wrote:
> On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera
> 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 the solution would b
On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan 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 of being able to
On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera
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 unless overridden?
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 fee
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
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 sysadmin
67 matches
Mail list logo
