Applied. Thanks.
---
Bruce Momjian wrote:
> Boszormenyi Zoltan wrote:
> > >>> Ah, I didn't even see that that section needed to be updated. Good
> > >>> catch. I'd suggest the following wording:
> > >>>
> > >>> For a SELE
On Sat, Feb 13, 2010 at 10:15 PM, Bruce Momjian wrote:
> Boszormenyi Zoltan wrote:
>> >>> Ah, I didn't even see that that section needed to be updated. Good
>> >>> catch. I'd suggest the following wording:
>> >>>
>> >>> For a SELECT or CREATE TABLE AS
>> >>> command, the tag is SELECT rows... [a
Boszormenyi Zoltan wrote:
> >>> Ah, I didn't even see that that section needed to be updated. Good
> >>> catch. I'd suggest the following wording:
> >>>
> >>> For a SELECT or CREATE TABLE AS
> >>> command, the tag is SELECT rows... [and the rest as you have it]
> >>>
> >>> We should probably also
On Fri, Feb 12, 2010 at 1:55 PM, Boszormenyi Zoltan wrote:
> Okay, new patch is attached. Please read the docs changes, and comment.
I like it. I'll mark it as Ready for Committer.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
Robert Haas írta:
> On Fri, Feb 12, 2010 at 1:22 PM, Boszormenyi Zoltan wrote:
>
>> Robert Haas írta:
>>
>>> On Fri, Feb 12, 2010 at 10:48 AM, Boszormenyi Zoltan
>>> wrote:
>>>
>>>
I added a small change to protocol.sgml for the
"CommandComplete" message describing the c
On Fri, Feb 12, 2010 at 1:22 PM, Boszormenyi Zoltan wrote:
> Robert Haas írta:
>> On Fri, Feb 12, 2010 at 10:48 AM, Boszormenyi Zoltan
>> wrote:
>>
>>> I added a small change to protocol.sgml for the
>>> "CommandComplete" message describing the change.
>>> Is it enough?
>>>
>>
>> Ah, I didn't ev
Robert Haas írta:
> On Fri, Feb 12, 2010 at 10:48 AM, Boszormenyi Zoltan wrote:
>
>> I added a small change to protocol.sgml for the
>> "CommandComplete" message describing the change.
>> Is it enough?
>>
>
> Ah, I didn't even see that that section needed to be updated. Good
> catch. I'd
Robert Haas írta:
> On Fri, Feb 12, 2010 at 10:48 AM, Boszormenyi Zoltan wrote:
>
>> I added a small change to protocol.sgml for the
>> "CommandComplete" message describing the change.
>> Is it enough?
>>
>
> Ah, I didn't even see that that section needed to be updated. Good
> catch. I'd
On Fri, Feb 12, 2010 at 10:48 AM, Boszormenyi Zoltan wrote:
> I added a small change to protocol.sgml for the
> "CommandComplete" message describing the change.
> Is it enough?
Ah, I didn't even see that that section needed to be updated. Good
catch. I'd suggest the following wording:
For a SE
Robert Haas írta:
> On Mon, Feb 8, 2010 at 5:53 AM, Boszormenyi Zoltan wrote:
>
>> New patch is attached with the discussed changes.
>>
>
> This looks OK to me now, but it lacks docs.
>
> I'll set it to Waiting on Author.
>
> ...Robert
>
I added a small change to protocol.sgml for the
Alvaro Herrera írta:
> Robert Haas escribió:
>
>> On Thu, Feb 11, 2010 at 2:38 PM, Alvaro Herrera
>> wrote:
>>
>>> Robert Haas escribió:
>>>
>>>
I was all prepared to admit that I hadn't actually looked at the patch
carefully enough, but I just looked at (and CVS HEAD) aga
Alvaro Herrera írta:
> Boszormenyi Zoltan escribió:
>
>> Robert Haas írta:
>>
>>> ...
>>> OK, please change it.
>>>
>>>
>> New patch is attached with the discussed changes.
>>
>
> This looks all wrong. PORTAL_ONE_SELECT is now being passed through
> FillPortalStore,
Where d
On Thu, Feb 11, 2010 at 2:47 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Thu, Feb 11, 2010 at 2:38 PM, Alvaro Herrera
>> wrote:
>> > Robert Haas escribió:
>> >
>> >> I was all prepared to admit that I hadn't actually looked at the patch
>> >> carefully enough, but I just looked at (an
Robert Haas escribió:
> On Thu, Feb 11, 2010 at 2:38 PM, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
> >
> >> I was all prepared to admit that I hadn't actually looked at the patch
> >> carefully enough, but I just looked at (and CVS HEAD) again and what
> >> you've written here doesn't appe
On Thu, Feb 11, 2010 at 2:38 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> I was all prepared to admit that I hadn't actually looked at the patch
>> carefully enough, but I just looked at (and CVS HEAD) again and what
>> you've written here doesn't appear to describe what I'm seeing in th
Robert Haas escribió:
> I was all prepared to admit that I hadn't actually looked at the patch
> carefully enough, but I just looked at (and CVS HEAD) again and what
> you've written here doesn't appear to describe what I'm seeing in the
> code:
>
> if ((portal->stra
On Thu, Feb 11, 2010 at 2:04 PM, Alvaro Herrera
wrote:
> Boszormenyi Zoltan escribió:
>> Robert Haas írta:
>> > ...
>> > OK, please change it.
>> >
>>
>> New patch is attached with the discussed changes.
>
> This looks all wrong. PORTAL_ONE_SELECT is now being passed through
> FillPortalStore, wh
Boszormenyi Zoltan escribió:
> Robert Haas írta:
> > ...
> > OK, please change it.
> >
>
> New patch is attached with the discussed changes.
This looks all wrong. PORTAL_ONE_SELECT is now being passed through
FillPortalStore, which runs it to completion, whereas it was previously
passed via P
On Mon, Feb 8, 2010 at 5:53 AM, Boszormenyi Zoltan wrote:
> New patch is attached with the discussed changes.
This looks OK to me now, but it lacks docs.
I'll set it to Waiting on Author.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
Robert Haas írta:
> ...
> OK, please change it.
>
New patch is attached with the discussed changes.
>>> Someone who knows the overall structure of the code better than I do
>>> will have to comment on whether there are any code paths to worry
>>> about that do not go through PortalRun().
>>>
>
On Sun, Feb 7, 2010 at 12:46 PM, Boszormenyi Zoltan wrote:
>> 1. Looks like you've falsified the last comment block in PortalRunMulti().
> You mean the "fake something up" part? Will fix the comment.
Yes.
>> 2. I don't like the duplication of code in PortalRun() between the
>> first and second b
Robert Haas írta:
> On Tue, Feb 2, 2010 at 4:03 AM, Boszormenyi Zoltan wrote:
>
>> Thanks for testing it, with the attached patch your test case also
>> returns SELECT N.
>>
>
> Thoughts:
>
> 1. Looks like you've falsified the last comment block in PortalRunMulti().
>
You mean the "fak
On Tue, Feb 2, 2010 at 4:03 AM, Boszormenyi Zoltan wrote:
> Thanks for testing it, with the attached patch your test case also
> returns SELECT N.
Thoughts:
1. Looks like you've falsified the last comment block in PortalRunMulti().
2. I don't like the duplication of code in PortalRun() between t
Robert Haas írta:
> 2010/1/12 Boszormenyi Zoltan :
>
>> Tom Lane írta:
>>
>>> Alvaro Herrera writes:
>>>
>>>
But it would be broken in very obvious ways, no? It's not like it would
be silently broken and thus escape testing ...
>>> Well, if we wanted to
2010/1/12 Boszormenyi Zoltan :
> Tom Lane írta:
>> Alvaro Herrera writes:
>>
>>> But it would be broken in very obvious ways, no? It's not like it would
>>> be silently broken and thus escape testing ...
>>>
>>
>> Well, if we wanted to adopt that approach, we should add the count to
>> *all* SELE
Tom Lane írta:
> Alvaro Herrera writes:
>
>> But it would be broken in very obvious ways, no? It's not like it would
>> be silently broken and thus escape testing ...
>>
>
> Well, if we wanted to adopt that approach, we should add the count to
> *all* SELECT tags not just a small subset.
Alvaro Herrera writes:
> But it would be broken in very obvious ways, no? It's not like it would
> be silently broken and thus escape testing ...
Well, if we wanted to adopt that approach, we should add the count to
*all* SELECT tags not just a small subset. As the patch stands it
seems entirel
Tom Lane escribió:
> Boszormenyi Zoltan writes:
> > Tom Lane �rta:
> >> It's more the possibility of doing strcmp(tag, "SELECT") on the command
>
> > Actually it's strncmp(tag, "SELECT ", 7), so when you mix old server
> > with new clients or new server with old client, it will just work as
> > b
On Mon, Dec 28, 2009 at 12:10 PM, Tom Lane wrote:
> Boszormenyi Zoltan writes:
>> attached is a small patch that makes it possible for clients
>> to receive row count for SELECT ... INTO ... and CREATE TABLE ... AS ...
>
>> Comments?
>
> This doesn't look tremendously well thought out to me.
>
>
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> attached is a small patch that makes it possible for clients
>> to receive row count for SELECT ... INTO ... and CREATE TABLE ... AS ...
>>
>
>
>> Comments?
>>
>
> This doesn't look tremendously well thought out to me.
>
> 1. As give
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Tom Lane írta:
>>
>>> It's more the possibility of doing strcmp(tag, "SELECT") on the command
>>>
>
>
>> Actually it's strncmp(tag, "SELECT ", 7), so when you mix old server
>> with new clients or new server with old client, it wil
Boszormenyi Zoltan writes:
> Tom Lane írta:
>> It's more the possibility of doing strcmp(tag, "SELECT") on the command
> Actually it's strncmp(tag, "SELECT ", 7), so when you mix old server
> with new clients or new server with old client, it will just work as
> before, i.e. return "".
Are you d
Tom Lane írta:
> Peter Eisentraut writes:
>
>> On mĂĽn, 2009-12-28 at 11:08 -0500, Tom Lane wrote:
>>
>>> And, by the same token, the scope for possibly breaking clients is nearly
>>> unlimited ...
>>>
>
>
>> Why is that? Are there programs out there that expect PQcmdTuples() to
Boszormenyi Zoltan writes:
> attached is a small patch that makes it possible for clients
> to receive row count for SELECT ... INTO ... and CREATE TABLE ... AS ...
> Comments?
This doesn't look tremendously well thought out to me.
1. As given, the patch changes the result not only for SELECT I
Peter Eisentraut writes:
> On mån, 2009-12-28 at 11:08 -0500, Tom Lane wrote:
>> And, by the same token, the scope for possibly breaking clients is nearly
>> unlimited ...
> Why is that? Are there programs out there that expect PQcmdTuples() to
> return something that is *not* the tuple count f
On mån, 2009-12-28 at 11:08 -0500, Tom Lane wrote:
> Boszormenyi Zoltan writes:
> > Hans-Juergen Schoenig írta:
> >> just as a background info: this will have some positive side effects
> >> on embedded C programs which should be portable.
>
> > Not just embedded C programs, every driver that's
>
Boszormenyi Zoltan writes:
> Hans-Juergen Schoenig Ãrta:
>> just as a background info: this will have some positive side effects
>> on embedded C programs which should be portable.
> Not just embedded C programs, every driver that's
> based on libpq and used PQcmdTuples() will
> automatically se
Hans-Juergen Schoenig írta:
> hello ...
>
> just as a background info: this will have some positive side effects
> on embedded C programs which should be portable.
Not just embedded C programs, every driver that's
based on libpq and used PQcmdTuples() will
automatically see the benefit.
> informi
hello ...
just as a background info: this will have some positive side effects on
embedded C programs which should be portable.
informix, for instance, will also return a row count on those commands.
regards,
hans
Pavel Stehule wrote:
2009/12/28 Boszormenyi Zoltan :
Hi,
atta
2009/12/28 Boszormenyi Zoltan :
> Hi,
>
> attached is a small patch that makes it possible for clients
> to receive row count for SELECT ... INTO ... and CREATE TABLE ... AS ...
>
> Comments?
>
good idea
+1
Pavel
> Best regards,
> Zoltán Böszörményi
>
> --
> Bible has answers for everything. Pr
Hi,
attached is a small patch that makes it possible for clients
to receive row count for SELECT ... INTO ... and CREATE TABLE ... AS ...
Comments?
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is
41 matches
Mail list logo
