Hello
this is syntax column(table) necessary still?
postgres=# select a(x) from x;
a
10
(1 row)
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs wrote:
> On Thu, 2009-10-22 at 07:55 +0300, Heikki Linnakangas wrote:
>> Making some effort to transfer locks instead of acquiring+releasing
>> would eliminate the need for having extra lock space available when
>> switching from hot standby mode to normal operation.
>
> This isn't ver
On Thu, 2009-10-22 at 07:55 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2009-10-21 at 23:02 +0300, Heikki Linnakangas wrote:
> >> Hmm, dunno about that, but there is one problem with the "grant to dummy
> >> proc, then release in startup process" approach. What if there isn't
Simon Riggs wrote:
> On Wed, 2009-10-21 at 23:02 +0300, Heikki Linnakangas wrote:
>> Hmm, dunno about that, but there is one problem with the "grant to dummy
>> proc, then release in startup process" approach. What if there isn't
>> enough shared memory available to re-acquire the lock for the dumm
2009/10/22 Itagaki Takahiro :
>
> Tom Lane wrote:
>
>> 3. The pre-transform hook would have a signature like
>> Node *hook(ParseState *pstate, ColumnRef *cref)
>>
>> 4. The post-transform hook would have a signature like
>> Node *hook(ParseState *pstate, ColumnRef *cref, Node *var)
>
>
2009/10/21 Tom Lane :
> Josh Berkus writes:
>> Making this GUC suset would make it far less useful to users trying to
>> gradually upgrade their infrastructures, and make it more likely that
>> many/most of our users would just set it to backwards-compatible in
>> their postgresql.conf and not fix
Tom Lane wrote:
> 3. The pre-transform hook would have a signature like
> Node *hook(ParseState *pstate, ColumnRef *cref)
>
> 4. The post-transform hook would have a signature like
> Node *hook(ParseState *pstate, ColumnRef *cref, Node *var)
Are there any relationships between the
On Wed, Oct 21, 2009 at 5:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> I actually think that we should not have a GUC for this at all. We
>> should have a compiled-in default, and it should be error. If you
>> want some other behavior, decorate your functions with #option.
>
> We've agreed t
Josh Berkus writes:
>> That's what the #option alternative is for. Yes, it's a bit ugly, but
>> it's perfectly functional, and secure too.
> I still don't see why it's needed. If the function owner simply sets
> the option in the function definitions (as a userset), it doesn't matter
> what the
Robert Haas writes:
> I actually think that we should not have a GUC for this at all. We
> should have a compiled-in default, and it should be error. If you
> want some other behavior, decorate your functions with #option.
We've agreed that the factory default should be "error", but I don't
thi
Can't find it ... and it doesn't look like anyone has moved it ...
On Wed, 21 Oct 2009, Peter Eisentraut wrote:
Alpha2 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
Then, someone please move this to an appropriate place on
On Wed, Oct 21, 2009 at 4:28 PM, Merlin Moncure wrote:
> On Wed, Oct 21, 2009 at 3:09 PM, Josh Berkus wrote:
>> Tom has proposed some kind of odd special "options" syntax to get around
>> this, but I think that's unnecessary. So far on this thread, I haven't
>> seen anyone engineer an actual fun
On Wed, 2009-10-21 at 23:02 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2009-10-21 at 19:37 +0300, Heikki Linnakangas wrote:
> >
> >> So, I'm quite eager to just revert all those lock_twophase_recover()
> >> changes, and always rely on the "grant lock to dummy proc, then
> >>
On Wed, Oct 21, 2009 at 3:09 PM, Josh Berkus wrote:
> Tom has proposed some kind of odd special "options" syntax to get around
> this, but I think that's unnecessary. So far on this thread, I haven't
> seen anyone engineer an actual function exploit by using this setting; I
> personally can't com
Alpha2 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
Then, someone please move this to an appropriate place on the FTP server
and make an announcement. Josh Berkus is coordinating the announcement.
See http://wiki.postgresql.o
It is solved. I'll propose my work the next weeks. :-)
Regards,
Samuel.
Le mercredi 21 octobre 2009 à 17:31 +0200, Samuel ROZE a écrit :
> Hi,
>
> I'm writing two functions "parse_url_key" and "parse_url_record" which
> will have one text argument and will return a record or a specific
> column
On 10/21/09 1:02 PM, Josh Berkus wrote:
>> That's what the #option alternative is for. Yes, it's a bit ugly, but
>> it's perfectly functional, and secure too.
>
> I still don't see why it's needed. If the function owner simply sets
> the option in the function definitions (as a userset), it does
Simon Riggs wrote:
> On Wed, 2009-10-21 at 19:37 +0300, Heikki Linnakangas wrote:
>
>> So, I'm quite eager to just revert all those lock_twophase_recover()
>> changes, and always rely on the "grant lock to dummy proc, then
>> release
>> it in startup process" method. If we don't want to rely on th
> That's what the #option alternative is for. Yes, it's a bit ugly, but
> it's perfectly functional, and secure too.
I still don't see why it's needed. If the function owner simply sets
the option in the function definitions (as a userset), it doesn't matter
what the calling user sets, does it?
Josh Berkus writes:
> Making this GUC suset would make it far less useful to users trying to
> gradually upgrade their infrastructures, and make it more likely that
> many/most of our users would just set it to backwards-compatible in
> their postgresql.conf and not fix anything. In fact, I'd go
Robert,
>> H. I don't see any reason why this couldn't be set by any user at
>> runtime, really. From a security standpoint, it's less of a risk than
>> search_path, and we allow anyone to mess with that.
>
> That's like saying that it's less of a risk than a group of rabid
> tyrannosaurs i
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 Oct 21, 2009, at 11:37 AM, Robert Haas wrote:
That's like saying that it's less of a risk than a group of rabid
tyrannosaurs in a kindergarten classroom.
I'm not sure, but I kind of doubt that tyrannosaurs can get rabies. I
mean, if they were even around anymore. Which, you know, they're
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 1:59 PM, Josh Berkus wrote:
> Tom,
>
>> 1. Invent a GUC that has the settings backwards-compatible,
>> oracle-compatible, throw-error (exact spellings TBD). Factory default,
>> at least for a few releases, will be throw-error. Make it SUSET so that
>> unprivileged users c
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,
> 1. Invent a GUC that has the settings backwards-compatible,
> oracle-compatible, throw-error (exact spellings TBD). Factory default,
> at least for a few releases, will be throw-error. Make it SUSET so that
> unprivileged users can't break things by twiddling it; but it's still
> possible
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
Here's what I'm thinking of doing to enable plpgsql to resolve variable
references during the main SQL parser processing, instead of its current
hack of replacing references with $n in advance:
1. Add some fields to ParseState to carry hook function pointers as
well as "void *" passthrough argumen
Samuel ROZE wrote:
Le mercredi 21 octobre 2009 à 12:59 -0400, Andrew Dunstan a écrit :
On 8.3 you might need to put a #define for it directly in your C file.
I can't: cstring_to_text isn't defined.
I'll develop on 8.4.
or try:
#define CStringGetTextP(c) DatumGetTextP(DirectFun
Le mercredi 21 octobre 2009 à 12:59 -0400, Andrew Dunstan a écrit :
> On 8.3 you might need to put a #define for it directly in your C file.
I can't: cstring_to_text isn't defined.
I'll develop on 8.4.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
On Wed, 2009-10-21 at 19:37 +0300, Heikki Linnakangas wrote:
> So, I'm quite eager to just revert all those lock_twophase_recover()
> changes, and always rely on the "grant lock to dummy proc, then
> release
> it in startup process" method. If we don't want to rely on that,
> PostPrepare_Locks is
Samuel ROZE wrote:
I've done it but I had no results... strange.
I've a 8.3 version and this lines are NOT in the file:
You neglected to tell us you were in 8.3 before, I think.
On 8.3 you might need to put a #define for it directly in your C file.
cheers
andrew
--
Sent via pgsql
On Oct 21, 2009, at 9:48 AM, Tom Lane wrote:
I was wondering whether you could query pg_proc to look for functions
with the same name and different arguments/results. It's a bit tricky
though because you'd expect s/citext/text/ in at least some positions
(maybe not all)?
Yeah, almost all. I'l
Samuel ROZE writes:
> I've done it but I had no results... strange.
> I've a 8.3 version and this lines are NOT in the file:
Oh, it was changed in 8.4 IIRC. If you are thinking of submitting
code to the project you should not be developing against a back
release anyway ...
"David E. Wheeler" writes:
> Is there a straight-foward way to check such a thing
> programmatically, with a query perhaps? Or should I just put aside an
> hour to do an audit?
I was wondering whether you could query pg_proc to look for functions
with the same name and different arguments/res
I'm now using C strings. I don't need to use CStringGetTextDatum, but it
still don't works. There's the code:
---
PG_FUNCTION_INFO_V1(parse_url_record);
Datum parse_url_record (PG_FUNCTION_ARGS)
{
// Vars about the params
"David E. Wheeler" writes:
> FWIW, I think that this is a bug, and that the variation from the text
> version will be unexpected. I recommend fixing it for 8.4.2.
Well, it's certainly a bug, but I don't think it's back-patchable.
A back-patch will not affect existing installations anyway. What
On Oct 21, 2009, at 9:40 AM, David E. Wheeler wrote:
On Oct 21, 2009, at 9:37 AM, Tom Lane wrote:
Ooh, yeah, dunno how I missed that.
I think we're probably stuck in 8.4, but we should fix it going
forward. Would you make a quick check if any of the other citext
functions have the same bug?
On Oct 21, 2009, at 9:37 AM, Tom Lane wrote:
Ooh, yeah, dunno how I missed that.
I think we're probably stuck in 8.4, but we should fix it going
forward. Would you make a quick check if any of the other citext
functions have the same bug?
I've fixed it in my [version for 8.3](https://svn.ki
I've done it but I had no results... strange.
I've a 8.3 version and this lines are NOT in the file:
00668 /* varlena.c */
00669 extern text *cstring_to_text(const char *s);
00670 extern text *cstring_to_text_with_len(const char *s, int len);
00671 extern char *text_to_cstring(const text *t);
0067
The Hot Standby patch changes lock_twophase_recover() so that when we're
starting up from Hot Standby mode to normal operation, as opposed to
crash recovery, we assume that all AccessExcusiveLocks are already held
by the startup process and instead of acquiring them anew they are
transferred from t
"David E. Wheeler" writes:
> On Oct 21, 2009, at 7:27 AM, Tom Lane wrote:
>> Huh, it looks to me like that's an error in the declaration of the
>> citext versions of regexp_matches --- they should be declared to
>> return
>> setof text[], the same as the underlying text functions. David, do
>
Samuel ROZE wrote:
Le mercredi 21 octobre 2009 à 11:42 -0400, Tom Lane a écrit :
CStringGetTextDatum
Can you give me more precisions ?
I'm creating a "user C function", with shared library and
CStringGetTextDatum is in "varlena.h" file which is not in the
"src/include" dir... How ca
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 Oct 21, 2009, at 7:27 AM, Tom Lane wrote:
Huh, it looks to me like that's an error in the declaration of the
citext versions of regexp_matches --- they should be declared to
return
setof text[], the same as the underlying text functions. David, do
you
agree?
Ooh, yeah, dunno how I mis
Le mercredi 21 octobre 2009 à 11:42 -0400, Tom Lane a écrit :
> CStringGetTextDatum
Can you give me more precisions ?
I'm creating a "user C function", with shared library and
CStringGetTextDatum is in "varlena.h" file which is not in the
"src/include" dir... How can I include it ?
Thanks.
Samue
Dave Page wrote:
> Robert Haas wrote:
>
>> I also like PGAPPNAME better, for the same reasons as Tom.
>
> :-). Have to admit, I've mistyped it a few times too.
Well, it would seem we have consensus on that. :-)
I don't feel that the Java default issue reached the same level of
consensus, t
Thanks for your reply.
PG_FUNCTION_INFO_V1(parse_url_record);
Datum parse_url_record (PG_FUNCTION_ARGS)
{
// Vars about the params
//text *str2 = PG_GETARG_TEXT_P(0);
char str[] = "http://www.ovh.com/intenal.html";;
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'
Samuel ROZE wrote:
> PG_FUNCTION_INFO_V1(parse_url_record);
> Datum parse_url_record (PG_FUNCTION_ARGS)
> {
> // Vars about the params
> //text *str2 = PG_GETARG_TEXT_P(0);
> char str[] = "http://www.ovh.com/intenal.html";;
>
> // Some vars which will used to create the com
Samuel ROZE writes:
> The problem is that they don't work fine... :/
I think the problem is that you are passing C strings to code that
expects pointers to text datums --- which are not the same thing
at all. (text has a length word, not a null terminator byte.)
It's pure accident that your firs
On Wed, Oct 21, 2009 at 4:29 PM, Robert Haas wrote:
> I also like PGAPPNAME better, for the same reasons as Tom.
:-). Have to admit, I've mistyped it a few times too.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start
--
Sent via p
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
Hi,
I'm writing two functions "parse_url_key" and "parse_url_record" which
will have one text argument and will return a record or a specific
column of it. Theses functions are calling "parse_url_exec" which parse
the URL. When theses function will works, i'll purpose them to
PostgreSQL community.
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
We don't usually use abbreviations, so how about PGCLIENTNAME or some such?
Not sure I believe that argument. Among the set of existing libpq
On Wed, Oct 21, 2009 at 11:25 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Tom Lane wrote:
>>> FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
>
>> We don't usually use abbreviations, so how about PGCLIENTNAME or some such?
>
> Not sure I believe that argument. Among the se
Andrew Dunstan writes:
> Tom Lane wrote:
>> FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
> We don't usually use abbreviations, so how about PGCLIENTNAME or some such?
Not sure I believe that argument. Among the set of existing libpq
environment variables I see
PGHOSTADDR
Tom Lane wrote:
"Kevin Grittner" writes:
(or whatever name we choose for this in place of PGAPPNAME.)
FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
Dave has been using in his examples. The latter is too frickin
long, and the double N is a typo threat (I already
"Kevin Grittner" writes:
> (or whatever name we choose for this in place of PGAPPNAME.)
FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
Dave has been using in his examples. The latter is too frickin
long, and the double N is a typo threat (I already mistyped it in
composing thi
Alvaro Herrera writes:
> The reason it's an improvement of sorts is that there are now more
> possible attributes, and if we had kept adding columns it would have
> become wider than 80 columns.
Yeah, 8.4 has two more possible entries, and adding them as separate
columns would have guaranteed tha
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
Andrew Chernow wrote:
I'll hack the makefile and give it a shot.
No need to hack it, set CFLAGS during configure:
shell]# CFLAGS="-m64" ./configure (options)
I tried that and it still built a 32 bit version of perl. When I
checked the make file it didn't have CFLAGS anywhere. I manually ad
Alvaro Herrera writes:
> Magnus Hagander wrote:
>> From a quick look, it looks fine to me. I don't have time to do a
>> complete check right now, but I'll do that as soon as I can and then
>> commit it - unless people feel it's more urgent than maybe a week
>> worst case, in which case someone els
Rod Taylor writes:
> It is interesting that "citext" seems to be functional with exactly
> the same statements.
Huh, it looks to me like that's an error in the declaration of the
citext versions of regexp_matches --- they should be declared to return
setof text[], the same as the underlying text
Magnus Hagander wrote:
> From a quick look, it looks fine to me. I don't have time to do a
> complete check right now, but I'll do that as soon as I can and then
> commit it - unless people feel it's more urgent than maybe a week
> worst case, in which case someone else has to pick it up :-)
Are
> So, having dismissed my original off-the-cuff answer to Rod, the next
> question is what's really going wrong for him. I get this from
> a quick trial:
I wish I had kept specific notes on what I was actually trying to do.
I tried to_number first then the expression as seen below. I guess I
saw
Tom Lane wrote:
> [ scratches head... ] I thought the JDBC spec already said exactly
> how one would set this. Why would we go to significant effort to
> make it behave contrary to spec?
We certainly should allow it to be set as specified in the spec. The
only question is whether it makes s
Peter Eisentraut wrote:
> Could someone clarify why this (from PG 8.4)
>
> # \du
> List of roles
>Role name | Attributes | Member of
> ---+-+
> admin | Create role | {}
>: Create DB
> postgres | Superuser | {
Peter Eisentraut writes:
> On Tue, 2009-10-20 at 20:48 -0400, Tom Lane wrote:
>> So I went to see about making the changes to remove regex_flavor, and
>> was astonished to find that all the regex-related functions are already
>> marked immutable, and AFAICS always have been. This is clearly wrong
Peter Eisentraut wrote:
On Wed, 2009-10-21 at 13:11 +0900, Itagaki Takahiro wrote:
The attached patch replace BOM with while spaces, but it does not
change client encoding automatically. I think we can always ignore
client encoding at the replacement because SQL command cannot start
with BO
2009/10/21 Peter Eisentraut :
> Could someone clarify why this (from PG 8.4)
>
> # \du
> List of roles
> Role name | Attributes | Member of
> ---+-+
> admin | Create role | {}
> : Create DB
> postgres | Superuser |
Could someone clarify why this (from PG 8.4)
# \du
List of roles
Role name | Attributes | Member of
---+-+
admin | Create role | {}
: Create DB
postgres | Superuser | {}
: Create role
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, 2009-10-21 at 13:11 +0900, Itagaki Takahiro wrote:
> The attached patch replace BOM with while spaces, but it does not
> change client encoding automatically. I think we can always ignore
> client encoding at the replacement because SQL command cannot start
> with BOM sequence. If we don't
On Tue, 2009-10-20 at 20:48 -0400, Tom Lane wrote:
> So I went to see about making the changes to remove regex_flavor, and
> was astonished to find that all the regex-related functions are already
> marked immutable, and AFAICS always have been. This is clearly wrong,
> and we would have to fix it
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
91 matches
Mail list logo
