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
66 matches
Mail list logo
