Alvaro Herrera írta:
> Boszormenyi Zoltan escribió:
>
>> Alvaro Herrera írta:
>>
>>> I have applied this patch after some tinkering. I mainly added support
>>> for "fetch_args: FORWARD opt_from_in name" and "BACKWARD opt_from_in
>>> name" in ecpg.addons which apparently you forgot.
>>>
2009/11/13 Hans-Jürgen Schönig :
>
> On Nov 13, 2009, at 8:06 AM, Michael Meskes wrote:
>
>> On Thu, Nov 12, 2009 at 03:07:27PM -0500, Robert Haas wrote:
If you want to submit patches in a series like this one, they need to be
considered standalone, I think. The Linux kernel devs wo
On Nov 13, 2009, at 8:06 AM, Michael Meskes wrote:
On Thu, Nov 12, 2009 at 03:07:27PM -0500, Robert Haas wrote:
If you want to submit patches in a series like this one, they need
to be
considered standalone, I think. The Linux kernel devs work
differently
than us here.
Zoltan broke them
On Thu, Nov 12, 2009 at 03:07:27PM -0500, Robert Haas wrote:
> > If you want to submit patches in a series like this one, they need to be
> > considered standalone, I think. The Linux kernel devs work differently
> > than us here.
>
> Zoltan broke them up because Michael asked him to do so.
Actu
On Thu, Nov 12, 2009 at 2:49 PM, Alvaro Herrera
wrote:
> Boszormenyi Zoltan escribió:
>> Alvaro Herrera írta:
>
>> > I have applied this patch after some tinkering. I mainly added support
>> > for "fetch_args: FORWARD opt_from_in name" and "BACKWARD opt_from_in
>> > name" in ecpg.addons which app
Boszormenyi Zoltan escribió:
> Alvaro Herrera írta:
> > I have applied this patch after some tinkering. I mainly added support
> > for "fetch_args: FORWARD opt_from_in name" and "BACKWARD opt_from_in
> > name" in ecpg.addons which apparently you forgot.
>
> Thanks. Your fix is correct if this pa
Alvaro Herrera írta:
> Boszormenyi Zoltan escribió:
>
>
>> 2) 1b-cursor_name-ctxdiff.patch
>>
>> "name" -> "cursor_name" transition in core grammar
>> and ecpg grammar. Currently it does nothing, it's a
>> preparation phase. Depends on patch 1.
>>
>
> Applied this part too.
>
> I cannot app
Alvaro Herrera írta:
> Boszormenyi Zoltan escribió:
>
>
>> I have split up (and cleaned up a little) the dynamic
>> cursorname patch into smaller logical, easier-to-review
>> pieces. Descriptions below.
>>
>> 1) 1a-unified-optfromin-fetch-ctxdiff.patch
>>
>> ecpg supports optional FROM/IN in FET
Boszormenyi Zoltan escribió:
> 2) 1b-cursor_name-ctxdiff.patch
>
> "name" -> "cursor_name" transition in core grammar
> and ecpg grammar. Currently it does nothing, it's a
> preparation phase. Depends on patch 1.
Applied this part too.
I cannot apply the other ones -- they belong to the ECPG ma
Tom Lane escribió:
> Alvaro Herrera writes:
> > I have applied this patch after some tinkering.
>
> Shouldn't there be a docs change in that commit?
True -- fixed.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Alvaro Herrera writes:
> I have applied this patch after some tinkering.
Shouldn't there be a docs change in that commit?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
Boszormenyi Zoltan escribió:
> I have split up (and cleaned up a little) the dynamic
> cursorname patch into smaller logical, easier-to-review
> pieces. Descriptions below.
>
> 1) 1a-unified-optfromin-fetch-ctxdiff.patch
>
> ecpg supports optional FROM/IN in FETCH and
> MOVE statements (mainly b
On Thu, Oct 15, 2009 at 2:27 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas
>> wrote:
Do you
have any sense of how soon you'll feel confident to commit either
patch?
>>> I'm bad at estimating. Not this week for sure, and
Robert Haas wrote:
> On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas
> wrote:
>>> Do you
>>> have any sense of how soon you'll feel confident to commit either
>>> patch?
>> I'm bad at estimating. Not this week for sure, and next week I'm
>> traveling and won't be able to spend as much time o
2009/10/14 KaiGai Kohei :
> Robert Haas wrote:
>> On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas
>> wrote:
Do you
have any sense of how soon you'll feel confident to commit either
patch?
>>> I'm bad at estimating. Not this week for sure, and next week I'm
>>> traveling and wo
Robert Haas wrote:
> On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas
> wrote:
>>> Do you
>>> have any sense of how soon you'll feel confident to commit either
>>> patch?
>> I'm bad at estimating. Not this week for sure, and next week I'm
>> traveling and won't be able to spend as much time o
On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas
wrote:
>> Do you
>> have any sense of how soon you'll feel confident to commit either
>> patch?
>
> I'm bad at estimating. Not this week for sure, and next week I'm
> traveling and won't be able to spend as much time on it as I am right
> now.
Itagaki Takahiro wrote:
> The point is *memory leak* in dblink when a query is canceled or
> become time-out. I think it is a bug, and my patch could fix it.
Please see if this works for you.
Joe
Index: dblink.c
===
RCS file: /opt/s
On Thu, Oct 1, 2009 at 7:48 AM, Magnus Hagander wrote:
> On Thu, Oct 1, 2009 at 04:11, Itagaki Takahiro
> wrote:
>>
>> Magnus Hagander wrote:
>>
>>> I can certainly review the win32 encoding patch, but I was rather
>>> hoping for some comments from others on if we're interested in a win32
>>> on
Robert Haas írta:
> On Fri, Oct 2, 2009 at 9:01 PM, Boszormenyi Zoltan wrote:
>
>> Hi,
>>
>> Michael Meskes írta:
>>
>>> It is accepted either way. I was just pointing out that it might be easier
>>> to
>>> review/commit at least parts of your patches if they can be applied
>>> seperatel
On Fri, Oct 2, 2009 at 9:01 PM, Boszormenyi Zoltan wrote:
> Hi,
>
> Michael Meskes írta:
>> It is accepted either way. I was just pointing out that it might be easier to
>> review/commit at least parts of your patches if they can be applied
>> seperately.
>>
>
> I have split up (and cleaned up a
Michael Meskes írta:
> On Thu, Oct 01, 2009 at 09:05:55PM +0200, Boszormenyi Zoltan wrote:
>
>> Yes, but technical problems and solutions do. ECPG claims
>> to be ESQL/C compatible, but at places it's only half compatible.
>>
>
> Where does it claim to be fully compatible?
>
I didn't sa
On Thu, Oct 01, 2009 at 09:05:55PM +0200, Boszormenyi Zoltan wrote:
> Yes, but technical problems and solutions do. ECPG claims
> to be ESQL/C compatible, but at places it's only half compatible.
Where does it claim to be fully compatible?
> This comment is misleading and reflects quite a narrow
Michael Meskes írta:
> On Thu, Oct 01, 2009 at 07:21:54PM +0200, Boszormenyi Zoltan wrote:
>
>> Please, accept my apologies, I only tried to express my
>> frustration, this is not a good situation for either of us.
>>
>
> Apologies accepted, email is a difficult means of communication anywa
On Thu, Oct 01, 2009 at 07:21:54PM +0200, Boszormenyi Zoltan wrote:
> Please, accept my apologies, I only tried to express my
> frustration, this is not a good situation for either of us.
Apologies accepted, email is a difficult means of communication anyway. It
leads to misunderstanding IMO.
> Y
Michael Meskes írta:
> On Thu, Oct 01, 2009 at 03:47:07PM +0200, Boszormenyi Zoltan wrote:
>
>> You're not being fair with me. The dependencies are quite
>> technical.
>>
>
> I'm sorry that you interpreted my email this way, it wasn't at all meant to
> offend you.
>
Please, accept my ap
On Thu, Oct 01, 2009 at 03:47:07PM +0200, Boszormenyi Zoltan wrote:
> You're not being fair with me. The dependencies are quite
> technical.
I'm sorry that you interpreted my email this way, it wasn't at all meant to
offend you.
> First, Tom Lane suggested to unify core and ecpg FETCH
> syntaxes
Boszormenyi Zoltan escribió:
> First, Tom Lane suggested to unify core and ecpg FETCH
> syntaxes so both will accept optional FROM/IN, which I did.
> SQLDA support adds new FETCH forms (Informix-specific
> ones) so naturally these patches clash. There's no simple way
> to make they separately appl
Michael Meskes írta:
> On Wed, Sep 30, 2009 at 12:34:23PM -0400, Tom Lane wrote:
>
>> qualified to review them. (I don't actually think we have anybody
>> except Michael who's really familiar with ecpg.)
>>
>
> I'm afraid I'm simply not able to spend much time on this in the near future
>
On Wed, Sep 30, 2009 at 12:34:23PM -0400, Tom Lane wrote:
> qualified to review them. (I don't actually think we have anybody
> except Michael who's really familiar with ecpg.)
I'm afraid I'm simply not able to spend much time on this in the near future as
I'm simply too busy atm. I spend some ti
On Thu, Oct 1, 2009 at 04:11, Itagaki Takahiro
wrote:
>
> Magnus Hagander wrote:
>
>> I can certainly review the win32 encoding patch, but I was rather
>> hoping for some comments from others on if we're interested in a win32
>> only solution, or if we want something more generic. Should we just
Magnus Hagander wrote:
> I can certainly review the win32 encoding patch, but I was rather
> hoping for some comments from others on if we're interested in a win32
> only solution, or if we want something more generic. Should we just go
> with the win32-only one for now?
Yes, because Windows is
Joe Conway wrote:
> The patch basically forces all use of libpq by dblink to be asynchronous
> (internally) so that a cancel can be sensed and passed down to the
> remote side and everything cleaned up. Possibly the right thing to do,
> but dblink already allows the use of async queries, and the
Joe Conway writes:
> The issue is not so much technical as it is philosophical.
> The patch basically forces all use of libpq by dblink to be asynchronous
> (internally) so that a cancel can be sensed and passed down to the
> remote side and everything cleaned up. Possibly the right thing to do,
On Wed, Sep 30, 2009 at 21:38, Tom Lane wrote:
> Magnus Hagander writes:
>> I can certainly review the win32 encoding patch, but I was rather
>> hoping for some comments from others on if we're interested in a win32
>> only solution, or if we want something more generic. Should we just go
>> with
Magnus Hagander writes:
> I can certainly review the win32 encoding patch, but I was rather
> hoping for some comments from others on if we're interested in a win32
> only solution, or if we want something more generic. Should we just go
> with the win32-only one for now?
That was actually the on
Magnus Hagander escribió:
> On Wed, Sep 30, 2009 at 18:34, Tom Lane wrote:
> > Robert Haas writes:
> >> ... (and many of the more
> >> significant remaining patches look like they are right up Tom's alley
> >> anyway).
> >
> > FWIW, if left to my own devices I will eventually get to everything
>
On Wed, Sep 30, 2009 at 18:34, Tom Lane wrote:
> Robert Haas writes:
>> ... (and many of the more
>> significant remaining patches look like they are right up Tom's alley
>> anyway).
>
> FWIW, if left to my own devices I will eventually get to everything
> except the dblink, ecpg, and encoding/wi
Robert Haas wrote:
> On Wed, Sep 30, 2009 at 12:27 PM, Tom Lane wrote:
>> Joe Conway writes:
>>> Robert Haas wrote:
- There is one dblink pach left over from last CommitFest. Joe Conway
was going to review it the weekend of July 18th-19th, but that didn't
end up happening and so t
Robert Haas wrote:
On Wed, Sep 30, 2009 at 12:34 PM, Tom Lane wrote:
Robert Haas writes:
... (and many of the more
significant remaining patches look like they are right up Tom's alley
anyway).
FWIW, if left to my own devices I will eventually get to everything
except the db
On Wed, Sep 30, 2009 at 12:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... (and many of the more
>> significant remaining patches look like they are right up Tom's alley
>> anyway).
>
> FWIW, if left to my own devices I will eventually get to everything
> except the dblink, ecpg, and encoding
On Wed, Sep 30, 2009 at 12:27 PM, Tom Lane wrote:
> Joe Conway writes:
>> Robert Haas wrote:
>>> - There is one dblink pach left over from last CommitFest. Joe Conway
>>> was going to review it the weekend of July 18th-19th, but that didn't
>>> end up happening and so that patch is still waiting
Robert Haas writes:
> ... (and many of the more
> significant remaining patches look like they are right up Tom's alley
> anyway).
FWIW, if left to my own devices I will eventually get to everything
except the dblink, ecpg, and encoding/win32 patches. I don't intend
to touch any of those because
Joe Conway writes:
> Robert Haas wrote:
>> - There is one dblink pach left over from last CommitFest. Joe Conway
>> was going to review it the weekend of July 18th-19th, but that didn't
>> end up happening and so that patch is still waiting. We might be able
>> to find someone else to review it,
Robert Haas wrote:
> On Wed, Sep 30, 2009 at 11:36 AM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> OTOH, I'd hate to hold the commitfest hostage for that. Perhaps it
>>> should be returned to author at this point, I should move on to other
>>> patches to get the commitfest closed ASAP, and
Robert Haas wrote:
> - There is one dblink pach left over from last CommitFest. Joe Conway
> was going to review it the weekend of July 18th-19th, but that didn't
> end up happening and so that patch is still waiting. We might be able
> to find someone else to review it, but I'm not sure whether
On Wed, Sep 30, 2009 at 11:36 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> OTOH, I'd hate to hold the commitfest hostage for that. Perhaps it
>> should be returned to author at this point, I should move on to other
>> patches to get the commitfest closed ASAP, and continue reviewing and
>>
Heikki Linnakangas writes:
> OTOH, I'd hate to hold the commitfest hostage for that. Perhaps it
> should be returned to author at this point, I should move on to other
> patches to get the commitfest closed ASAP, and continue reviewing and
> polishing that right after the commitfest.
FWIW, I'd ra
Robert Haas wrote:
> - Hot Standby and Streaming Replication are both huge new features in
> this CommitFest, and there seems to be a fair amount of activity
> around both patches. Heikki previously expressed optimism about
> getting Hot Standby done this CommitFest, but I am not sure whether he
>
49 matches
Mail list logo
