Andrew Dunstan wrote:
> > Are you suggesting we just delete the threads and let them die if they
> > don't submit a new version?
> >
> >
>
> My understanding was that all items in a commit-fest have one of these
> three dispositions:
>
> . committed
> . rejected
> . referred back to author fo
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > My understanding was that all items in a commit-fest have one of these
> > three dispositions:
>
> > . committed
> > . rejected
> > . referred back to author for more work
>
> Right. But Bruce's personal queue has got a different
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> My understanding was that all items in a commit-fest have one of these
> three dispositions:
> . committed
> . rejected
> . referred back to author for more work
Right. But Bruce's personal queue has got a different lifecycle:
items get removed when
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
This has been saved for the next commit-fest:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Er, why "saved"? Until there's a new patch submission there's not going
to be more work to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are you suggesting we just delete the threads and let them die if they
> don't submit a new version?
I am suggesting that they are not material for another commit fest until
some new work has been done. (And the appearance of that new work would
trigger
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > This has been saved for the next commit-fest:
> > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
> Er, why "saved"? Until there's a new patch submission there's not going
> to be more work to do on this in the next fest.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> This has been saved for the next commit-fest:
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Er, why "saved"? Until there's a new patch submission there's not going
to be more work to do on this in the next fest.
I think maybe you need to
This has been saved for the next commit-fest:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Gregory Stark wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark wrote:
> >> Attached is
Author unresponsive to request for updated patch.
This patch has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Gregory Stark wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]>
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Unless you have a better solution I think we'd better do that, though.
>
> I notice that the header is also included in command.c even though it doesn't
> use PGASYNC_IDLE.
>
> Are you going to make these fixes?
Yes, sorry, I started to already but g
Gregory Stark wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
if (pset.c->db->asyncStatus != PGASYNC_BUSY)
{
break;
}
There already is a defined API
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> if (pset.c->db->asyncStatus != PGASYNC_BUSY)
>> {
>> break;
>> }
>
> There already is a defined API for this, namely PQisBusy().
>
> In any case, I rather conc
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>
>>> if (pset.c->db->asyncStatus != PGASYNC_BUSY)
>>> {
>>> break;
>>> }
>>>
>>
>> There already is a defined API for this, namely PQis
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
if (pset.c->db->asyncStatus != PGASYNC_BUSY)
{
break;
}
There already is a defined API for this, namely PQisBusy().
In any case, I rather concur with the XXX comment: busy-
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> if (pset.c->db->asyncStatus != PGASYNC_BUSY)
> {
> break;
> }
There already is a defined API for this, namely PQisBusy().
In any case, I rather concur with the XXX comment: busy-waiting like
this suck
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
If there's more needed here, let's see an official API change,
not a hack.
Well, I guess the obvious API would be something like:
PGAsyncStatusType PQasyncStatus(const PGconn *conn);
Tha
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If there's more needed here, let's see an official API change,
>> not a hack.
> Well, I guess the obvious API would be something like:
> PGAsyncStatusType PQasyncStatus(const PGconn *conn);
That would mean exposing PGAsyncStatusT
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
If we're going to include libpq-int.h maybe we need to put it in
common.h. Is there a reason that our own client programs shouldn't use
our own library internals?
Seems like a really bad idea to me. I know I've cursed mysql
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> If we're going to include libpq-int.h maybe we need to put it in
> common.h. Is there a reason that our own client programs shouldn't use
> our own library internals?
Seems like a really bad idea to me. I know I've cursed mysql more than
once for doi
Gregory Stark wrote:
I expected there would be a few issues raised. For one about the need
to use PG_ASYNC from libpq-int.h.
Hmm, yes. Maybe we need to export that. I also see:
+ #if 0
+ #include "libpq-int.h" /* For PG_ASYNC */
+ #endif
+
which needs to disappear.
If we're going to in
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Greg,
>
> In general this looks quite reasonable. It's a very large patch for a feature
> of this size, but luckily it's mostly changes due to the new pset structure
> rather than new code.
Really? I expected there would be a few issues raised. For o
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> There are some places that it doesn't use PG style (e.g. no newline
> before brace after if) and some comments that need to be fixed (e.g. /*
> XXX get result */ )
Of course you both realize pgindent will take care of the former ;-).
But yes, bogus co
Gregory Stark wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
Gregory Stark wrote:
Attached is an updated patch.
This patch appears to add a nonexistent test to the regression schedules.
I must have forgotten to cvs add it. Sorry.
Also, I forgot to mention previo
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Gr
Am Montag, 21. Mai 2007 15:21 schrieb Gregory Stark:
> Also, I forgot to mention previously there is an unrelated trivial hunk in
> here. I noticed we free the password early, presumably for security
> reasons,
No, to save memory.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> Attached is an updated patch.
>>
>
> This patch appears to add a nonexistent test to the regression schedules.
I must have forgotten to cvs add it. Sorry.
Also, I forgot to mention previously there is an unrelated trivial hun
Gregory Stark wrote:
Attached is an updated patch.
This patch appears to add a nonexistent test to the regression schedules.
cheers
andrew
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
Pavan Deolasee wrote:
--- 1179,1189
dbname, user, password);
/* We can immediately discard the password -- no longer needed */
! if (password)
! {
! memset(password, '\0', strlen(password));
free(password);
+ }
Any
Hi Greg,
I looked at the patch briefly. I couldn't spot any issues and it looks good
to me. I've just couple of comments here.
The mvcc regression test files are missing in the patch.
--- 1179,1189
dbname, user, password);
/* We can immediately discard
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Gr
So based on the feedback and suggestions here this is the interface I suggest:
\connect& - to open a new connection keeping the existing one
\g& - to submit a command asynchronously (like & in the shell)
\S [Sess#] - to _S_witch to a different _S_ession
- if no connection #
On Mon, May 14, 2007 at 11:55:07AM -0500, Jim C. Nasby wrote:
> On Mon, May 14, 2007 at 11:03:52AM -0400, Tom Lane wrote:
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> > > But these kinds of inconsistent behaviours can be traps for users. It
> > > means
> > > "\c1" and "\c 1" do different things
On Mon, May 14, 2007 at 06:26:42PM +0100, Gregory Stark wrote:
>
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
> > Since this command will be getting used very frequently by anyone using
> > concurrent connections interactively, it'd be nice if it was lower-case.
> > It looks like that limits us
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Since this command will be getting used very frequently by anyone using
> concurrent connections interactively, it'd be nice if it was lower-case.
> It looks like that limits us to j, k, m, n, v, and y. In unix this idea
> is about jobs, what about us
On Mon, May 14, 2007 at 11:03:52AM -0400, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > But these kinds of inconsistent behaviours can be traps for users. It means
> > "\c1" and "\c 1" do different things even though "\cpostgres" and \c
> > postgres"
> > do the same thing. And it
On Mon, May 14, 2007 at 12:51:39PM +0100, Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> >> So would you prefer \g& as Jim Nasby suggested? I hadn't even considered
> >> that
> >> previously since I'm not accustomed to using \g but
Gregory Stark <[EMAIL PROTECTED]> writes:
> But these kinds of inconsistent behaviours can be traps for users. It means
> "\c1" and "\c 1" do different things even though "\cpostgres" and \c postgres"
> do the same thing. And it means "\c1" might connect to a database named "1"
> today but switch s
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Would \c# limit us to 9 concurrent connections? Might want
>
> \cs[witch] [session]
Hm, we kind of have a choice with \c#. Either we treat it as part of the
command in which case the way to connect to an integer-named database is to
include a space. W
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> So would you prefer \g& as Jim Nasby suggested? I hadn't even considered that
>> previously since I'm not accustomed to using \g but it does seem kind of
>> pretty. I normally use ; but I suppose there's nothing
Gregory Stark <[EMAIL PROTECTED]> writes:
> So would you prefer \g& as Jim Nasby suggested? I hadn't even considered that
> previously since I'm not accustomed to using \g but it does seem kind of
> pretty. I normally use ; but I suppose there's nothing wrong with just
> declaring that asynchronous
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "David Fetter" <[EMAIL PROTECTED]> writes:
>>> What's the reasoning behind \c&? Does it "send things into the
>>> background" the way & does in the shell?
>
>> Sort of. It sends the *subsequent* command to the b
Gregory Stark <[EMAIL PROTECTED]> writes:
> "David Fetter" <[EMAIL PROTECTED]> writes:
>> What's the reasoning behind \c&? Does it "send things into the
>> background" the way & does in the shell?
> Sort of. It sends the *subsequent* command to the background...
That sounds just bizarre. Existi
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Sun, May 13, 2007 at 02:39:45PM +0100, Gregory Stark wrote:
>>
>> I was originally thinking \c1, \c2, ... for \cswitch and \c& for \cnowait.
>> I'm
>> not sure if going for cryptic short commands is better or worse here.
>
> \c& sounds fine (as do
On Sun, May 13, 2007 at 02:39:45PM +0100, Gregory Stark wrote:
> "Jim Nasby" <[EMAIL PROTECTED]> writes:
>
> > I don't see how we could make the names shorter without moving away from a
> > backslash command (which I'm guessing would be painful).
> >
> > Assuming we're stuck with a backslash comma
"David Fetter" <[EMAIL PROTECTED]> writes:
>> I was originally thinking \c1, \c2, ... for \cswitch and \c& for
>> \cnowait. I'm not sure if going for cryptic short commands is better
>> or worse here.
>
> +1 for \c1, \c2, etc.
>
> What's the reasoning behind \c&? Does it "send things into the
> b
On Sun, May 13, 2007 at 02:39:45PM +0100, Gregory Stark wrote:
> "Jim Nasby" <[EMAIL PROTECTED]> writes:
>
> > I don't see how we could make the names shorter without moving
> > away from a backslash command (which I'm guessing would be
> > painful).
> >
> > Assuming we're stuck with a backslash c
"Jim Nasby" <[EMAIL PROTECTED]> writes:
> I don't see how we could make the names shorter without moving away from a
> backslash command (which I'm guessing would be painful).
>
> Assuming we're stuck with a backslash command \cs[witch] and \cn
> [owait] seem to be about as good as we could get.
On May 11, 2007, at 10:55 AM, Gregory Stark wrote:
Also, if anyone has any better ideas for names than \cswitch and
\cnowait
now's the time. I had intended them only as placeholders because I
couldn't
think of anything better but it doesn't sound like anyone else has
any better
ideas either.
Fixed the major omissions that made it incomplete.
- Added sgml documentation and \? usage
- Added basic mvcc regression tests using new functionality
- Fixed cursor-mode (FETCH_COUNT) functionality
- Removed \cwait in favour of psql variable ASYNC_DELAY
I'm still not sure it's quite polished en
49 matches
Mail list logo
