Thread: Nested xmlagg doesn't give a result 9.2.3
Query: SELECT xmlelement(name s_a, xmlagg( xmlelement(name s_b, xmlattributes( sq.id AS i ), (SELECT xmlagg( xmlelement(name s_c, xmlattributes( su.id AS i ) ) ORDER BY table_id,id ) FROM __table_to_table AS su WHERE su.table_id=sq.id ) ) ) ) FROM __table AS sq No result given in: "PostgreSQL 9.2.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52), 64-bit" A result is given in: "PostgreSQL 9.2.1, compiled by Visual C++ build 1600, 32-bit" Both installations tested with same DB.
Hi,
With your query and such tables:
create table __table (id int);
insert into __table values (1),(2);
create table __table_to_table (id int, table_id int);
insert into __table_to_table values (1, 1),(2, 2);
I am getting consistent results with 9.2.1 and 9.2.3 on my Linux box, hence:
xmlelement
-----------------------------------------------------------------------
<s_a><s_b i="1"><s_c i="1"/></s_b><s_b i="2"><s_c i="2"/></s_b></s_a>
(1 row)
Could you be more explicit about the result you expect and the output
differences you see between those versions?
Regards,
--
Michael
Hi Michael, This should have been the expected result on both machines: ----------------------------------------------------------------------- <s_a><s_b i="1"><s_c i="1"/></s_b><s_b i="2"><s_c i="2"/></s_b></s_a> (1 row) I've just rebooted "PostgreSQL 9.2.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52), 64-bit" and I'm getting the expected result. Thanks for helping. Best, Peter Kroon 2013/2/19 Michael Paquier <michael.paquier@gmail.com> > Hi, > > With your query and such tables: > create table __table (id int); > insert into __table values (1),(2); > create table __table_to_table (id int, table_id int); > insert into __table_to_table values (1, 1),(2, 2); > > I am getting consistent results with 9.2.1 and 9.2.3 on my Linux box, > hence: > xmlelement > ----------------------------------------------------------------------- > <s_a><s_b i="1"><s_c i="1"/></s_b><s_b i="2"><s_c i="2"/></s_b></s_a> > (1 row) > > Could you be more explicit about the result you expect and the output > differences you see between those versions? > Regards, > -- > Michael >
Mm.. The problem only occurs on a specific table in my DB. --__my_table has 512 rows SELECT * FROM __my_table; --gives me result SELECT --xmlagg( xmlelement(name el_name, id ) --) FROM __my_table;--gives me result When un-commenting the xmlagg I get no result. otherwise the output will look like: "<el_name>1</el_name>" "<el_name>2</el_name>" "<el_name>3</el_name>" etc.... 2013/2/19 Peter Kroon <plakroon@gmail.com> > Hi Michael, > > This should have been the expected result on both machines: > ----------------------------------------------------------------------- > <s_a><s_b i="1"><s_c i="1"/></s_b><s_b i="2"><s_c i="2"/></s_b></s_a> > (1 row) > > I've just rebooted "PostgreSQL 9.2.3 on x86_64-unknown-linux-gnu, > compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52), 64-bit" and I'm > getting the expected result. > > Thanks for helping. > > Best, > > Peter Kroon > > > 2013/2/19 Michael Paquier <michael.paquier@gmail.com> > >> Hi, >> >> With your query and such tables: >> create table __table (id int); >> insert into __table values (1),(2); >> create table __table_to_table (id int, table_id int); >> insert into __table_to_table values (1, 1),(2, 2); >> >> I am getting consistent results with 9.2.1 and 9.2.3 on my Linux box, >> hence: >> xmlelement >> ----------------------------------------------------------------------- >> <s_a><s_b i="1"><s_c i="1"/></s_b><s_b i="2"><s_c i="2"/></s_b></s_a> >> (1 row) >> >> Could you be more explicit about the result you expect and the output >> differences you see between those versions? >> Regards, >> -- >> Michael >> > >
Also no result with FROM __my_table LIMIT 1; 2013/2/19 Peter Kroon <plakroon@gmail.com> > Mm.. > The problem only occurs on a specific table in my DB. > > --__my_table has 512 rows > > SELECT * FROM __my_table; --gives me result > > SELECT > --xmlagg( > xmlelement(name el_name, > id > ) > --) > FROM __my_table;--gives me result > > When un-commenting the xmlagg I get no result. otherwise the output will > look like: > "<el_name>1</el_name>" > "<el_name>2</el_name>" > "<el_name>3</el_name>" > etc.... > > > 2013/2/19 Peter Kroon <plakroon@gmail.com> > >> Hi Michael, >> >> This should have been the expected result on both machines: >> ----------------------------------------------------------------------- >> <s_a><s_b i="1"><s_c i="1"/></s_b><s_b i="2"><s_c i="2"/></s_b></s_a> >> (1 row) >> >> I've just rebooted "PostgreSQL 9.2.3 on x86_64-unknown-linux-gnu, >> compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52), 64-bit" and I'm >> getting the expected result. >> >> Thanks for helping. >> >> Best, >> >> Peter Kroon >> >> >> 2013/2/19 Michael Paquier <michael.paquier@gmail.com> >> >>> Hi, >>> >>> With your query and such tables: >>> create table __table (id int); >>> insert into __table values (1),(2); >>> create table __table_to_table (id int, table_id int); >>> insert into __table_to_table values (1, 1),(2, 2); >>> >>> I am getting consistent results with 9.2.1 and 9.2.3 on my Linux box, >>> hence: >>> xmlelement >>> ----------------------------------------------------------------------- >>> <s_a><s_b i="1"><s_c i="1"/></s_b><s_b i="2"><s_c i="2"/></s_b></s_a> >>> (1 row) >>> >>> Could you be more explicit about the result you expect and the output >>> differences you see between those versions? >>> Regards, >>> -- >>> Michael >>> >> >> >
On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com> wrote:
> Also no result with FROM __my_table LIMIT 1;
>
I'm having correct results with PG 9.2 by using either xmlagg or xmlelement.
For example:
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1;
xmlelement
----------------------
<el_name>1</el_name>
Or:
postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table;
xmlagg
------------------------------------------
<el_name>1</el_name><el_name>2</el_name>
(1 row)
Btw, such simple tests would have failed on the buildfarm for regression
xml.sql, so this looks to be an error in your environment.
Don't you have for example problems with the client application you use?
--
Michael
>Don't you have for example problems with the client application you use? Yes, with 1 table only. I'm not getting any results. When I'm on the sql machine via localhost or 192.168.1.100 I'm getting results. 2013/2/19 Michael Paquier <michael.paquier@gmail.com> > > > On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com> wrote: > >> Also no result with FROM __my_table LIMIT 1; >> > I'm having correct results with PG 9.2 by using either xmlagg or > xmlelement. > For example: > postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1; > xmlelement > ---------------------- > <el_name>1</el_name> > Or: > postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; > xmlagg > ------------------------------------------ > > <el_name>1</el_name><el_name>2</el_name> > (1 row) > > Btw, such simple tests would have failed on the buildfarm for regression > xml.sql, so this looks to be an error in your environment. > Don't you have for example problems with the client application you use? > -- > Michael >
> When I'm on the sql machine via localhost or 192.168.1.100 I'm getting results. I mean when I'm physically behind the machine and login via pgadmin using localhost or 192.168.1.100 then I get results. When I'm on another machine and login via pgadmin(192.168.1.100) then I get no results. Not sure what to think of this... 2013/2/19 Peter Kroon <plakroon@gmail.com> > >Don't you have for example problems with the client application you use? > > Yes, with 1 table only. I'm not getting any results. > When I'm on the sql machine via localhost or 192.168.1.100 I'm getting > results. > > > 2013/2/19 Michael Paquier <michael.paquier@gmail.com> > >> >> >> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com> wrote: >> >>> Also no result with FROM __my_table LIMIT 1; >>> >> I'm having correct results with PG 9.2 by using either xmlagg or >> xmlelement. >> For example: >> postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1; >> xmlelement >> ---------------------- >> <el_name>1</el_name> >> Or: >> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; >> xmlagg >> ------------------------------------------ >> >> <el_name>1</el_name><el_name>2</el_name> >> (1 row) >> >> Btw, such simple tests would have failed on the buildfarm for regression >> xml.sql, so this looks to be an error in your environment. >> Don't you have for example problems with the client application you use? >> -- >> Michael >> > >
Seems your testing from different environments like that could easily add any mix of libpq client libraries into the
equation(??)
(Are both test machines running the same version of pgAdmin? and are both connecting using the libpq installed with
them?)
We have plenty of experience with clients reporting varying behavior from our 'applications', when it turns out they've
'hookedinto' an unexpected version of the libpq client without, for example, SSL support built in, or Kerberos, or...
Thisoften happens after the client has unwittingly modified his environment in some way, sometimes after installing
software.
While the 'support libraries' issues above have no bearing on your case, of course, I certainly don't know enough to
knowthat the different versions of libpq don't present xmlagg output differently!
The experts here will weigh in.
Lou Picciano
----- Original Message -----
From: Peter Kroon <plakroon@gmail.com>
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
> When I'm on the sql machine via localhost or 192.168.1.100 I'm getting results.
I mean when I'm physically behind the machine and login via pgadmin using localhost or 192.168.1.100 then I get
results.WhenI'm on another machine and login via pgadmin(192.168.1.100) then I get no results.Not sure what to think of
this...
2013/2/19 Peter Kroon <plakroon@gmail.com>
>Don't you have for example problems with the client application you use?
Yes, with 1 table only. I'm not getting any results.When I'm on the sql machine via localhost or 192.168.1.100 I'm
gettingresults.
2013/2/19 Michael Paquier <michael.paquier@gmail.com>
On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com> wrote:
Also no result with FROM __my_table LIMIT 1;I'm having correct results with PG 9.2 by using either xmlagg or
xmlelement.
For example:
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1;
xmlelement
----------------------
<el_name>1</el_name>
Or:
postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table;
xmlagg
------------------------------------------
<el_name>1</el_name><el_name>2</el_name>
(1 row)
Btw, such simple tests would have failed on the buildfarm for regression xml.sql, so this looks to be an error in your
environment.
Don't you have for example problems with the client application you use?
--
Michael
It appears to be a Windows issue only. I'll try to post some code. 2013/2/19 Lou Picciano <loupicciano@comcast.net> > Seems your testing from different environments like that could easily add > any mix of libpq client libraries into the equation (??) > (Are both test machines running the same version of pgAdmin? and are both > connecting using the libpq installed with them?) > > We have plenty of experience with clients reporting varying behavior from > our 'applications', when it turns out they've 'hooked into' an unexpected > version of the libpq client without, for example, SSL support built in, or > Kerberos, or... This often happens after the client has unwittingly > modified his environment in some way, sometimes after installing software. > > > While the 'support libraries' issues above have no bearing on your case, > of course, I certainly don't know enough to know that the different > versions of libpq don't present xmlagg output differently! > > The experts here will weigh in. > > Lou Picciano > > > ----- Original Message ----- > From: Peter Kroon <plakroon@gmail.com> > Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC) > Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 > > > When I'm on the sql machine via localhost or 192.168.1.100 I'm getting > results. > > I mean when I'm physically behind the machine and login via pgadmin using localhost > or 192.168.1.100 then I get results. > When I'm on another machine and login via pgadmin(192.168.1.100) then I > get no results. > Not sure what to think of this... > > > 2013/2/19 Peter Kroon <plakroon@gmail.com> > >> >Don't you have for example problems with the client application you use? >> >> Yes, with 1 table only. I'm not getting any results. >> When I'm on the sql machine via localhost or 192.168.1.100 I'm getting >> results. >> >> >> 2013/2/19 Michael Paquier <michael.paquier@gmail.com> >> >>> >>> >>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com> wrote: >>> >>>> Also no result with FROM __my_table LIMIT 1; >>>> >>> I'm having correct results with PG 9.2 by using either xmlagg or >>> xmlelement. >>> >>> >>> >>> For example: >>> postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1; >>> xmlelement >>> ---------------------- >>> <el_name>1</el_name> >>> Or: >>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; >>> >>> >>> >>> xmlagg >>> ------------------------------------------ >>> >>> <el_name>1</el_name><el_name>2</el_name> >>> (1 row) >>> >>> Btw, such simple tests would have failed on the buildfarm for regression >>> xml.sql, so this looks to be an error in your environment. >>> >>> >>> >>> Don't you have for example problems with the client application you use? >>> -- >>> Michael >>> >> >> > >
When there are in __table_to_table more than 88 rows nothing gets returned, otherwise the query rolls out fine. 2013/2/19 Peter Kroon <plakroon@gmail.com> > It appears to be a Windows issue only. > I'll try to post some code. > > > 2013/2/19 Lou Picciano <loupicciano@comcast.net> > >> Seems your testing from different environments like that could easily add >> any mix of libpq client libraries into the equation (??) >> (Are both test machines running the same version of pgAdmin? and are both >> connecting using the libpq installed with them?) >> >> We have plenty of experience with clients reporting varying behavior from >> our 'applications', when it turns out they've 'hooked into' an unexpected >> version of the libpq client without, for example, SSL support built in, or >> Kerberos, or... This often happens after the client has unwittingly >> modified his environment in some way, sometimes after installing software. >> >> >> While the 'support libraries' issues above have no bearing on your case, >> of course, I certainly don't know enough to know that the different >> versions of libpq don't present xmlagg output differently! >> >> The experts here will weigh in. >> >> Lou Picciano >> >> >> ----- Original Message ----- >> From: Peter Kroon <plakroon@gmail.com> >> Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC) >> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >> >> > When I'm on the sql machine via localhost or 192.168.1.100 I'm getting >> results. >> >> I mean when I'm physically behind the machine and login via pgadmin using localhost >> or 192.168.1.100 then I get results. >> When I'm on another machine and login via pgadmin(192.168.1.100) then I >> get no results. >> Not sure what to think of this... >> >> >> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >>> >Don't you have for example problems with the client application you >>> use? >>> >>> Yes, with 1 table only. I'm not getting any results. >>> When I'm on the sql machine via localhost or 192.168.1.100 I'm getting >>> results. >>> >>> >>> 2013/2/19 Michael Paquier <michael.paquier@gmail.com> >>> >>>> >>>> >>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com>wrote: >>>> >>>>> Also no result with FROM __my_table LIMIT 1; >>>>> >>>> I'm having correct results with PG 9.2 by using either xmlagg or >>>> xmlelement. >>>> >>>> >>>> >>>> For example: >>>> postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1; >>>> xmlelement >>>> ---------------------- >>>> <el_name>1</el_name> >>>> Or: >>>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; >>>> >>>> >>>> >>>> xmlagg >>>> ------------------------------------------ >>>> >>>> <el_name>1</el_name><el_name>2</el_name> >>>> (1 row) >>>> >>>> Btw, such simple tests would have failed on the buildfarm for >>>> regression xml.sql, so this looks to be an error in your environment. >>>> >>>> >>>> >>>> Don't you have for example problems with the client application you use? >>>> -- >>>> Michael >>>> >>> >>> >> >> >
When there are more then 88 rows in the table like 595 I can run the query with success when using: WHERE id BETWEEN 1 AND 88; Using LIMIT 88 fails -> returns nothing Selecting all fails as well. 2013/2/19 Peter Kroon <plakroon@gmail.com> > When there are in __table_to_table more than 88 rows nothing gets > returned, otherwise the query rolls out fine. > > > 2013/2/19 Peter Kroon <plakroon@gmail.com> > >> It appears to be a Windows issue only. >> I'll try to post some code. >> >> >> 2013/2/19 Lou Picciano <loupicciano@comcast.net> >> >>> Seems your testing from different environments like that could easily >>> add any mix of libpq client libraries into the equation (??) >>> (Are both test machines running the same version of pgAdmin? and are >>> both connecting using the libpq installed with them?) >>> >>> We have plenty of experience with clients reporting varying behavior >>> from our 'applications', when it turns out they've 'hooked into' an >>> unexpected version of the libpq client without, for example, SSL support >>> built in, or Kerberos, or... This often happens after the client has >>> unwittingly modified his environment in some way, sometimes after >>> installing software. >>> >>> While the 'support libraries' issues above have no bearing on your >>> case, of course, I certainly don't know enough to know that the different >>> versions of libpq don't present xmlagg output differently! >>> >>> The experts here will weigh in. >>> >>> Lou Picciano >>> >>> >>> ----- Original Message ----- >>> From: Peter Kroon <plakroon@gmail.com> >>> Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC) >>> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >>> >>> > When I'm on the sql machine via localhost or 192.168.1.100 I'm >>> getting results. >>> >>> I mean when I'm physically behind the machine and login via pgadmin >>> using localhost or 192.168.1.100 then I get results. >>> When I'm on another machine and login via pgadmin(192.168.1.100) then I >>> get no results. >>> Not sure what to think of this... >>> >>> >>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >>> >>>> >Don't you have for example problems with the client application you >>>> use? >>>> >>>> Yes, with 1 table only. I'm not getting any results. >>>> When I'm on the sql machine via localhost or 192.168.1.100 I'm getting >>>> results. >>>> >>>> >>>> 2013/2/19 Michael Paquier <michael.paquier@gmail.com> >>>> >>>>> >>>>> >>>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com>wrote: >>>>> >>>>>> Also no result with FROM __my_table LIMIT 1; >>>>>> >>>>> I'm having correct results with PG 9.2 by using either xmlagg or >>>>> xmlelement. >>>>> >>>>> >>>>> >>>>> For example: >>>>> postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1; >>>>> xmlelement >>>>> ---------------------- >>>>> <el_name>1</el_name> >>>>> Or: >>>>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; >>>>> >>>>> >>>>> >>>>> xmlagg >>>>> ------------------------------------------ >>>>> >>>>> <el_name>1</el_name><el_name>2</el_name> >>>>> (1 row) >>>>> >>>>> Btw, such simple tests would have failed on the buildfarm for >>>>> regression xml.sql, so this looks to be an error in your environment. >>>>> >>>>> >>>>> >>>>> Don't you have for example problems with the client application you >>>>> use? >>>>> -- >>>>> Michael >>>>> >>>> >>>> >>> >>> >> >
Exceeding length 4679 is a problem. Query results(length) equal or below this number succeed. 2013/2/19 Peter Kroon <plakroon@gmail.com> > When there are more then 88 rows in the table like 595 I can run the query > with success when using: WHERE id BETWEEN 1 AND 88; > Using LIMIT 88 fails -> returns nothing > Selecting all fails as well. > > > 2013/2/19 Peter Kroon <plakroon@gmail.com> > >> When there are in __table_to_table more than 88 rows nothing gets >> returned, otherwise the query rolls out fine. >> >> >> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >>> It appears to be a Windows issue only. >>> I'll try to post some code. >>> >>> >>> 2013/2/19 Lou Picciano <loupicciano@comcast.net> >>> >>>> Seems your testing from different environments like that could easily >>>> add any mix of libpq client libraries into the equation (??) >>>> (Are both test machines running the same version of pgAdmin? and are >>>> both connecting using the libpq installed with them?) >>>> >>>> We have plenty of experience with clients reporting varying behavior >>>> from our 'applications', when it turns out they've 'hooked into' an >>>> unexpected version of the libpq client without, for example, SSL support >>>> built in, or Kerberos, or... This often happens after the client has >>>> unwittingly modified his environment in some way, sometimes after >>>> installing software. >>>> >>>> While the 'support libraries' issues above have no bearing on your >>>> case, of course, I certainly don't know enough to know that the different >>>> versions of libpq don't present xmlagg output differently! >>>> >>>> The experts here will weigh in. >>>> >>>> Lou Picciano >>>> >>>> >>>> ----- Original Message ----- >>>> From: Peter Kroon <plakroon@gmail.com> >>>> Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC) >>>> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >>>> >>>> > When I'm on the sql machine via localhost or 192.168.1.100 I'm >>>> getting results. >>>> >>>> I mean when I'm physically behind the machine and login via pgadmin >>>> using localhost or 192.168.1.100 then I get results. >>>> When I'm on another machine and login via pgadmin(192.168.1.100) then >>>> I get no results. >>>> Not sure what to think of this... >>>> >>>> >>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >>>> >>>>> >Don't you have for example problems with the client application you >>>>> use? >>>>> >>>>> Yes, with 1 table only. I'm not getting any results. >>>>> When I'm on the sql machine via localhost or 192.168.1.100 I'm getting >>>>> results. >>>>> >>>>> >>>>> 2013/2/19 Michael Paquier <michael.paquier@gmail.com> >>>>> >>>>>> >>>>>> >>>>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com>wrote: >>>>>> >>>>>>> Also no result with FROM __my_table LIMIT 1; >>>>>>> >>>>>> I'm having correct results with PG 9.2 by using either xmlagg or >>>>>> xmlelement. >>>>>> >>>>>> >>>>>> >>>>>> For example: >>>>>> postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1; >>>>>> xmlelement >>>>>> ---------------------- >>>>>> <el_name>1</el_name> >>>>>> Or: >>>>>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; >>>>>> >>>>>> >>>>>> >>>>>> xmlagg >>>>>> ------------------------------------------ >>>>>> >>>>>> <el_name>1</el_name><el_name>2</el_name> >>>>>> (1 row) >>>>>> >>>>>> Btw, such simple tests would have failed on the buildfarm for >>>>>> regression xml.sql, so this looks to be an error in your environment. >>>>>> >>>>>> >>>>>> >>>>>> Don't you have for example problems with the client application you >>>>>> use? >>>>>> -- >>>>>> Michael >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >
Where can I check and/or alter this? 2013/2/19 Lou Picciano <loupicciano@comcast.net> > I wonder if there's a difference in the implementation(s) of readline > buffering? > > > ----- Original Message ----- > From: Peter Kroon <plakroon@gmail.com> > To: Lou Picciano <loupicciano@comcast.net> > Cc: Michael Paquier <michael.paquier@gmail.com>, pgsql-bugs@postgresql.org > Sent: Tue, 19 Feb 2013 15:28:47 -0000 (UTC) > Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 > > Exceeding length 4679 is a problem. Query results(length) equal or below > this number succeed. > > > 2013/2/19 Peter Kroon <plakroon@gmail.com> > >> When there are more then 88 rows in the table like 595 I can run the >> query with success when using: WHERE id BETWEEN 1 AND 88; >> >> Using LIMIT 88 fails -> returns nothing >> Selecting all fails as well. >> >> >> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >>> When there are in __table_to_table more than 88 rows nothing gets >>> returned, otherwise the query rolls out fine. >>> >>> >>> >>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >>> >>>> It appears to be a Windows issue only. >>>> I'll try to post some code. >>>> >>>> >>>> 2013/2/19 Lou Picciano <loupicciano@comcast.net> >>>> >>>>> Seems your testing from different environments like that could easily >>>>> add any mix of libpq client libraries into the equation (??) >>>>> (Are both test machines running the same version of pgAdmin? and are >>>>> both connecting using the libpq installed with them?) >>>>> >>>>> We have plenty of experience with clients reporting varying behavior >>>>> from our 'applications', when it turns out they've 'hooked into' an >>>>> unexpected version of the libpq client without, for example, SSL support >>>>> built in, or Kerberos, or... This often happens after the client has >>>>> unwittingly modified his environment in some way, sometimes after >>>>> installing software. >>>>> >>>>> While the 'support libraries' issues above have no bearing on your >>>>> case, of course, I certainly don't know enough to know that the different >>>>> versions of libpq don't present xmlagg output differently! >>>>> >>>>> The experts here will weigh in. >>>>> >>>>> Lou Picciano >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: Peter Kroon <plakroon@gmail.com> >>>>> >>>>> >>>>> >>>>> >>>>> Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC) >>>>> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >>>>> >>>>> > When I'm on the sql machine via localhost or 192.168.1.100 I'm >>>>> getting results. >>>>> >>>>> I mean when I'm physically behind the machine and login via pgadmin >>>>> using localhost or 192.168.1.100 then I get results. >>>>> When I'm on another machine and login via pgadmin(192.168.1.100) then >>>>> I get no results. >>>>> Not sure what to think of this... >>>>> >>>>> >>>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >>>>> >>>>>> >Don't you have for example problems with the client application you >>>>>> use? >>>>>> >>>>>> Yes, with 1 table only. I'm not getting any results. >>>>>> When I'm on the sql machine via localhost or 192.168.1.100 I'm >>>>>> getting results. >>>>>> >>>>>> >>>>>> 2013/2/19 Michael Paquier <michael.paquier@gmail.com> >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com>wrote: >>>>>>> >>>>>>>> Also no result with FROM __my_table LIMIT 1; >>>>>>>> >>>>>>> I'm having correct results with PG 9.2 by using either xmlagg or >>>>>>> xmlelement. >>>>>>> >>>>>>> >>>>>>> >>>>>>> For example: >>>>>>> postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1; >>>>>>> xmlelement >>>>>>> ---------------------- >>>>>>> <el_name>1</el_name> >>>>>>> Or: >>>>>>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; >>>>>>> >>>>>>> >>>>>>> >>>>>>> xmlagg >>>>>>> ------------------------------------------ >>>>>>> >>>>>>> <el_name>1</el_name><el_name>2</el_name> >>>>>>> (1 row) >>>>>>> >>>>>>> Btw, such simple tests would have failed on the buildfarm for >>>>>>> regression xml.sql, so this looks to be an error in your environment. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Don't you have for example problems with the client application you >>>>>>> use? >>>>>>> -- >>>>>>> Michael >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > >
I wonder if there's a difference in the implementation(s) of readline buffering?
----- Original Message -----
From: Peter Kroon <plakroon@gmail.com>
To: Lou Picciano <loupicciano@comcast.net>
Cc: Michael Paquier <michael.paquier@gmail.com>, pgsql-bugs@postgresql.org
Sent: Tue, 19 Feb 2013 15:28:47 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Exceeding length 4679 is a problem. Query results(length) equal or below this number succeed.
2013/2/19 Peter Kroon <plakroon@gmail.com>
When there are more then 88 rows in the table like 595 I can run the query with success when using: WHERE id BETWEEN 1
AND88;
Using LIMIT 88 fails -> returns nothingSelecting all fails as well.
2013/2/19 Peter Kroon <plakroon@gmail.com>
When there are in __table_to_table more than 88 rows nothing gets returned, otherwise the query rolls out fine.
2013/2/19 Peter Kroon <plakroon@gmail.com>
It appears to be a Windows issue only.I'll try to post some code.
2013/2/19 Lou Picciano <loupicciano@comcast.net>
Seems your testing from different environments like that could easily add any mix of libpq client libraries into the
equation(??)
(Are both test machines running the same version of pgAdmin? and are both connecting using the libpq installed with
them?)
We have plenty of experience with clients reporting varying behavior from our 'applications', when it turns out they've
'hookedinto' an unexpected version of the libpq client without, for example, SSL support built in, or Kerberos, or...
Thisoften happens after the client has unwittingly modified his environment in some way, sometimes after installing
software.
While the 'support libraries' issues above have no bearing on your case, of course, I certainly don't know enough to
knowthat the different versions of libpq don't present xmlagg output differently!
The experts here will weigh in.
Lou Picciano
----- Original Message -----
From: Peter Kroon <plakroon@gmail.com>
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
> When I'm on the sql machine via localhost or 192.168.1.100 I'm getting results.
I mean when I'm physically behind the machine and login via pgadmin using localhost or 192.168.1.100 then I get
results.WhenI'm on another machine and login via pgadmin(192.168.1.100) then I get no results.Not sure what to think of
this...
2013/2/19 Peter Kroon <plakroon@gmail.com>
>Don't you have for example problems with the client application you use?
Yes, with 1 table only. I'm not getting any results.When I'm on the sql machine via localhost or 192.168.1.100 I'm
gettingresults.
2013/2/19 Michael Paquier <michael.paquier@gmail.com>
On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com> wrote:
Also no result with FROM __my_table LIMIT 1;I'm having correct results with PG 9.2 by using either xmlagg or
xmlelement.
For example:
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1;
xmlelement
----------------------
<el_name>1</el_name>
Or:
postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table;
xmlagg
------------------------------------------
<el_name>1</el_name><el_name>2</el_name>
(1 row)
Btw, such simple tests would have failed on the buildfarm for regression xml.sql, so this looks to be an error in your
environment.
Don't you have for example problems with the client application you use?
--
Michael
2013/2/19 Peter Kroon <plakroon@gmail.com>: > Where can I check and/or alter this? try to use pgAdminIII Regards Pavel > > > 2013/2/19 Lou Picciano <loupicciano@comcast.net> >> >> I wonder if there's a difference in the implementation(s) of readline >> buffering? >> >> >> ----- Original Message ----- >> From: Peter Kroon <plakroon@gmail.com> >> To: Lou Picciano <loupicciano@comcast.net> >> Cc: Michael Paquier <michael.paquier@gmail.com>, pgsql-bugs@postgresql.org >> Sent: Tue, 19 Feb 2013 15:28:47 -0000 (UTC) >> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >> >> Exceeding length 4679 is a problem. Query results(length) equal or below >> this number succeed. >> >> >> 2013/2/19 Peter Kroon <plakroon@gmail.com> >>> >>> When there are more then 88 rows in the table like 595 I can run the >>> query with success when using: WHERE id BETWEEN 1 AND 88; >>> >>> Using LIMIT 88 fails -> returns nothing >>> Selecting all fails as well. >>> >>> >>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >>>> >>>> When there are in __table_to_table more than 88 rows nothing gets >>>> returned, otherwise the query rolls out fine. >>>> >>>> >>>> >>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >>>>> >>>>> It appears to be a Windows issue only. >>>>> I'll try to post some code. >>>>> >>>>> >>>>> 2013/2/19 Lou Picciano <loupicciano@comcast.net> >>>>>> >>>>>> Seems your testing from different environments like that could easily >>>>>> add any mix of libpq client libraries into the equation (??) >>>>>> (Are both test machines running the same version of pgAdmin? and are >>>>>> both connecting using the libpq installed with them?) >>>>>> >>>>>> We have plenty of experience with clients reporting varying behavior >>>>>> from our 'applications', when it turns out they've 'hooked into' an >>>>>> unexpected version of the libpq client without, for example, SSL support >>>>>> built in, or Kerberos, or... This often happens after the client has >>>>>> unwittingly modified his environment in some way, sometimes after installing >>>>>> software. >>>>>> >>>>>> While the 'support libraries' issues above have no bearing on your >>>>>> case, of course, I certainly don't know enough to know that the different >>>>>> versions of libpq don't present xmlagg output differently! >>>>>> >>>>>> The experts here will weigh in. >>>>>> >>>>>> Lou Picciano >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: Peter Kroon <plakroon@gmail.com> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC) >>>>>> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >>>>>> >>>>>> > When I'm on the sql machine via localhost or 192.168.1.100 I'm >>>>>> > getting results. >>>>>> >>>>>> I mean when I'm physically behind the machine and login via pgadmin >>>>>> using localhost or 192.168.1.100 then I get results. >>>>>> When I'm on another machine and login via pgadmin(192.168.1.100) then >>>>>> I get no results. >>>>>> Not sure what to think of this... >>>>>> >>>>>> >>>>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >>>>>>> >>>>>>> >Don't you have for example problems with the client application you >>>>>>> > use? >>>>>>> >>>>>>> Yes, with 1 table only. I'm not getting any results. >>>>>>> When I'm on the sql machine via localhost or 192.168.1.100 I'm >>>>>>> getting results. >>>>>>> >>>>>>> >>>>>>> 2013/2/19 Michael Paquier <michael.paquier@gmail.com> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Also no result with FROM __my_table LIMIT 1; >>>>>>>> >>>>>>>> I'm having correct results with PG 9.2 by using either xmlagg or >>>>>>>> xmlelement. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> For example: >>>>>>>> postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1; >>>>>>>> xmlelement >>>>>>>> ---------------------- >>>>>>>> <el_name>1</el_name> >>>>>>>> Or: >>>>>>>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> xmlagg >>>>>>>> ------------------------------------------ >>>>>>>> >>>>>>>> <el_name>1</el_name><el_name>2</el_name> >>>>>>>> (1 row) >>>>>>>> >>>>>>>> Btw, such simple tests would have failed on the buildfarm for >>>>>>>> regression xml.sql, so this looks to be an error in your environment. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Don't you have for example problems with the client application you >>>>>>>> use? >>>>>>>> -- >>>>>>>> Michael >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> >
>try to use pgAdminIII Could you be more specific? 2013/2/19 Pavel Stehule <pavel.stehule@gmail.com> > 2013/2/19 Peter Kroon <plakroon@gmail.com>: > > Where can I check and/or alter this? > > try to use pgAdminIII > > Regards > > Pavel > > > > > > > 2013/2/19 Lou Picciano <loupicciano@comcast.net> > >> > >> I wonder if there's a difference in the implementation(s) of readline > >> buffering? > >> > >> > >> ----- Original Message ----- > >> From: Peter Kroon <plakroon@gmail.com> > >> To: Lou Picciano <loupicciano@comcast.net> > >> Cc: Michael Paquier <michael.paquier@gmail.com>, > pgsql-bugs@postgresql.org > >> Sent: Tue, 19 Feb 2013 15:28:47 -0000 (UTC) > >> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 > >> > >> Exceeding length 4679 is a problem. Query results(length) equal or below > >> this number succeed. > >> > >> > >> 2013/2/19 Peter Kroon <plakroon@gmail.com> > >>> > >>> When there are more then 88 rows in the table like 595 I can run the > >>> query with success when using: WHERE id BETWEEN 1 AND 88; > >>> > >>> Using LIMIT 88 fails -> returns nothing > >>> Selecting all fails as well. > >>> > >>> > >>> 2013/2/19 Peter Kroon <plakroon@gmail.com> > >>>> > >>>> When there are in __table_to_table more than 88 rows nothing gets > >>>> returned, otherwise the query rolls out fine. > >>>> > >>>> > >>>> > >>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> > >>>>> > >>>>> It appears to be a Windows issue only. > >>>>> I'll try to post some code. > >>>>> > >>>>> > >>>>> 2013/2/19 Lou Picciano <loupicciano@comcast.net> > >>>>>> > >>>>>> Seems your testing from different environments like that could > easily > >>>>>> add any mix of libpq client libraries into the equation (??) > >>>>>> (Are both test machines running the same version of pgAdmin? and are > >>>>>> both connecting using the libpq installed with them?) > >>>>>> > >>>>>> We have plenty of experience with clients reporting varying behavior > >>>>>> from our 'applications', when it turns out they've 'hooked into' an > >>>>>> unexpected version of the libpq client without, for example, SSL > support > >>>>>> built in, or Kerberos, or... This often happens after the client has > >>>>>> unwittingly modified his environment in some way, sometimes after > installing > >>>>>> software. > >>>>>> > >>>>>> While the 'support libraries' issues above have no bearing on your > >>>>>> case, of course, I certainly don't know enough to know that the > different > >>>>>> versions of libpq don't present xmlagg output differently! > >>>>>> > >>>>>> The experts here will weigh in. > >>>>>> > >>>>>> Lou Picciano > >>>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>> From: Peter Kroon <plakroon@gmail.com> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC) > >>>>>> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 > >>>>>> > >>>>>> > When I'm on the sql machine via localhost or 192.168.1.100 I'm > >>>>>> > getting results. > >>>>>> > >>>>>> I mean when I'm physically behind the machine and login via pgadmin > >>>>>> using localhost or 192.168.1.100 then I get results. > >>>>>> When I'm on another machine and login via pgadmin(192.168.1.100) > then > >>>>>> I get no results. > >>>>>> Not sure what to think of this... > >>>>>> > >>>>>> > >>>>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> > >>>>>>> > >>>>>>> >Don't you have for example problems with the client application > you > >>>>>>> > use? > >>>>>>> > >>>>>>> Yes, with 1 table only. I'm not getting any results. > >>>>>>> When I'm on the sql machine via localhost or 192.168.1.100 I'm > >>>>>>> getting results. > >>>>>>> > >>>>>>> > >>>>>>> 2013/2/19 Michael Paquier <michael.paquier@gmail.com> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Also no result with FROM __my_table LIMIT 1; > >>>>>>>> > >>>>>>>> I'm having correct results with PG 9.2 by using either xmlagg or > >>>>>>>> xmlelement. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> For example: > >>>>>>>> postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT > 1; > >>>>>>>> xmlelement > >>>>>>>> ---------------------- > >>>>>>>> <el_name>1</el_name> > >>>>>>>> Or: > >>>>>>>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM > __table; > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> xmlagg > >>>>>>>> ------------------------------------------ > >>>>>>>> > >>>>>>>> <el_name>1</el_name><el_name>2</el_name> > >>>>>>>> (1 row) > >>>>>>>> > >>>>>>>> Btw, such simple tests would have failed on the buildfarm for > >>>>>>>> regression xml.sql, so this looks to be an error in your > environment. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Don't you have for example problems with the client application > you > >>>>>>>> use? > >>>>>>>> -- > >>>>>>>> Michael > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >> > > >
2013/2/19 Peter Kroon <plakroon@gmail.com>: >>try to use pgAdminIII > > Could you be more specific? you can test your queries from pgAdmin SQL executor but it is strange error - try to look to postgresql and system logs Pavel > > > 2013/2/19 Pavel Stehule <pavel.stehule@gmail.com> >> >> 2013/2/19 Peter Kroon <plakroon@gmail.com>: >> > Where can I check and/or alter this? >> >> try to use pgAdminIII >> >> Regards >> >> Pavel >> >> > >> > >> > 2013/2/19 Lou Picciano <loupicciano@comcast.net> >> >> >> >> I wonder if there's a difference in the implementation(s) of readline >> >> buffering? >> >> >> >> >> >> ----- Original Message ----- >> >> From: Peter Kroon <plakroon@gmail.com> >> >> To: Lou Picciano <loupicciano@comcast.net> >> >> Cc: Michael Paquier <michael.paquier@gmail.com>, >> >> pgsql-bugs@postgresql.org >> >> Sent: Tue, 19 Feb 2013 15:28:47 -0000 (UTC) >> >> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >> >> >> >> Exceeding length 4679 is a problem. Query results(length) equal or >> >> below >> >> this number succeed. >> >> >> >> >> >> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >>> >> >>> When there are more then 88 rows in the table like 595 I can run the >> >>> query with success when using: WHERE id BETWEEN 1 AND 88; >> >>> >> >>> Using LIMIT 88 fails -> returns nothing >> >>> Selecting all fails as well. >> >>> >> >>> >> >>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >>>> >> >>>> When there are in __table_to_table more than 88 rows nothing gets >> >>>> returned, otherwise the query rolls out fine. >> >>>> >> >>>> >> >>>> >> >>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >>>>> >> >>>>> It appears to be a Windows issue only. >> >>>>> I'll try to post some code. >> >>>>> >> >>>>> >> >>>>> 2013/2/19 Lou Picciano <loupicciano@comcast.net> >> >>>>>> >> >>>>>> Seems your testing from different environments like that could >> >>>>>> easily >> >>>>>> add any mix of libpq client libraries into the equation (??) >> >>>>>> (Are both test machines running the same version of pgAdmin? and >> >>>>>> are >> >>>>>> both connecting using the libpq installed with them?) >> >>>>>> >> >>>>>> We have plenty of experience with clients reporting varying >> >>>>>> behavior >> >>>>>> from our 'applications', when it turns out they've 'hooked into' an >> >>>>>> unexpected version of the libpq client without, for example, SSL >> >>>>>> support >> >>>>>> built in, or Kerberos, or... This often happens after the client >> >>>>>> has >> >>>>>> unwittingly modified his environment in some way, sometimes after >> >>>>>> installing >> >>>>>> software. >> >>>>>> >> >>>>>> While the 'support libraries' issues above have no bearing on your >> >>>>>> case, of course, I certainly don't know enough to know that the >> >>>>>> different >> >>>>>> versions of libpq don't present xmlagg output differently! >> >>>>>> >> >>>>>> The experts here will weigh in. >> >>>>>> >> >>>>>> Lou Picciano >> >>>>>> >> >>>>>> >> >>>>>> ----- Original Message ----- >> >>>>>> From: Peter Kroon <plakroon@gmail.com> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC) >> >>>>>> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >> >>>>>> >> >>>>>> > When I'm on the sql machine via localhost or 192.168.1.100 I'm >> >>>>>> > getting results. >> >>>>>> >> >>>>>> I mean when I'm physically behind the machine and login via pgadmin >> >>>>>> using localhost or 192.168.1.100 then I get results. >> >>>>>> When I'm on another machine and login via pgadmin(192.168.1.100) >> >>>>>> then >> >>>>>> I get no results. >> >>>>>> Not sure what to think of this... >> >>>>>> >> >>>>>> >> >>>>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >>>>>>> >> >>>>>>> >Don't you have for example problems with the client application >> >>>>>>> > you >> >>>>>>> > use? >> >>>>>>> >> >>>>>>> Yes, with 1 table only. I'm not getting any results. >> >>>>>>> When I'm on the sql machine via localhost or 192.168.1.100 I'm >> >>>>>>> getting results. >> >>>>>>> >> >>>>>>> >> >>>>>>> 2013/2/19 Michael Paquier <michael.paquier@gmail.com> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com> >> >>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> Also no result with FROM __my_table LIMIT 1; >> >>>>>>>> >> >>>>>>>> I'm having correct results with PG 9.2 by using either xmlagg or >> >>>>>>>> xmlelement. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> For example: >> >>>>>>>> postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT >> >>>>>>>> 1; >> >>>>>>>> xmlelement >> >>>>>>>> ---------------------- >> >>>>>>>> <el_name>1</el_name> >> >>>>>>>> Or: >> >>>>>>>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM >> >>>>>>>> __table; >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> xmlagg >> >>>>>>>> ------------------------------------------ >> >>>>>>>> >> >>>>>>>> <el_name>1</el_name><el_name>2</el_name> >> >>>>>>>> (1 row) >> >>>>>>>> >> >>>>>>>> Btw, such simple tests would have failed on the buildfarm for >> >>>>>>>> regression xml.sql, so this looks to be an error in your >> >>>>>>>> environment. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Don't you have for example problems with the client application >> >>>>>>>> you >> >>>>>>>> use? >> >>>>>>>> -- >> >>>>>>>> Michael >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>> >> >> >> >> >> > > >
>you can test your queries from pgAdmin SQL executor I have already done so. I'll look into the logs. 2013/2/19 Pavel Stehule <pavel.stehule@gmail.com> > 2013/2/19 Peter Kroon <plakroon@gmail.com>: > >>try to use pgAdminIII > > > > Could you be more specific? > > you can test your queries from pgAdmin SQL executor > > but it is strange error - try to look to postgresql and system logs > > Pavel > > > > > > > 2013/2/19 Pavel Stehule <pavel.stehule@gmail.com> > >> > >> 2013/2/19 Peter Kroon <plakroon@gmail.com>: > >> > Where can I check and/or alter this? > >> > >> try to use pgAdminIII > >> > >> Regards > >> > >> Pavel > >> > >> > > >> > > >> > 2013/2/19 Lou Picciano <loupicciano@comcast.net> > >> >> > >> >> I wonder if there's a difference in the implementation(s) of readline > >> >> buffering? > >> >> > >> >> > >> >> ----- Original Message ----- > >> >> From: Peter Kroon <plakroon@gmail.com> > >> >> To: Lou Picciano <loupicciano@comcast.net> > >> >> Cc: Michael Paquier <michael.paquier@gmail.com>, > >> >> pgsql-bugs@postgresql.org > >> >> Sent: Tue, 19 Feb 2013 15:28:47 -0000 (UTC) > >> >> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 > >> >> > >> >> Exceeding length 4679 is a problem. Query results(length) equal or > >> >> below > >> >> this number succeed. > >> >> > >> >> > >> >> 2013/2/19 Peter Kroon <plakroon@gmail.com> > >> >>> > >> >>> When there are more then 88 rows in the table like 595 I can run the > >> >>> query with success when using: WHERE id BETWEEN 1 AND 88; > >> >>> > >> >>> Using LIMIT 88 fails -> returns nothing > >> >>> Selecting all fails as well. > >> >>> > >> >>> > >> >>> 2013/2/19 Peter Kroon <plakroon@gmail.com> > >> >>>> > >> >>>> When there are in __table_to_table more than 88 rows nothing gets > >> >>>> returned, otherwise the query rolls out fine. > >> >>>> > >> >>>> > >> >>>> > >> >>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> > >> >>>>> > >> >>>>> It appears to be a Windows issue only. > >> >>>>> I'll try to post some code. > >> >>>>> > >> >>>>> > >> >>>>> 2013/2/19 Lou Picciano <loupicciano@comcast.net> > >> >>>>>> > >> >>>>>> Seems your testing from different environments like that could > >> >>>>>> easily > >> >>>>>> add any mix of libpq client libraries into the equation (??) > >> >>>>>> (Are both test machines running the same version of pgAdmin? and > >> >>>>>> are > >> >>>>>> both connecting using the libpq installed with them?) > >> >>>>>> > >> >>>>>> We have plenty of experience with clients reporting varying > >> >>>>>> behavior > >> >>>>>> from our 'applications', when it turns out they've 'hooked into' > an > >> >>>>>> unexpected version of the libpq client without, for example, SSL > >> >>>>>> support > >> >>>>>> built in, or Kerberos, or... This often happens after the client > >> >>>>>> has > >> >>>>>> unwittingly modified his environment in some way, sometimes after > >> >>>>>> installing > >> >>>>>> software. > >> >>>>>> > >> >>>>>> While the 'support libraries' issues above have no bearing on > your > >> >>>>>> case, of course, I certainly don't know enough to know that the > >> >>>>>> different > >> >>>>>> versions of libpq don't present xmlagg output differently! > >> >>>>>> > >> >>>>>> The experts here will weigh in. > >> >>>>>> > >> >>>>>> Lou Picciano > >> >>>>>> > >> >>>>>> > >> >>>>>> ----- Original Message ----- > >> >>>>>> From: Peter Kroon <plakroon@gmail.com> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC) > >> >>>>>> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 > >> >>>>>> > >> >>>>>> > When I'm on the sql machine via localhost or 192.168.1.100 I'm > >> >>>>>> > getting results. > >> >>>>>> > >> >>>>>> I mean when I'm physically behind the machine and login via > pgadmin > >> >>>>>> using localhost or 192.168.1.100 then I get results. > >> >>>>>> When I'm on another machine and login via pgadmin(192.168.1.100) > >> >>>>>> then > >> >>>>>> I get no results. > >> >>>>>> Not sure what to think of this... > >> >>>>>> > >> >>>>>> > >> >>>>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> > >> >>>>>>> > >> >>>>>>> >Don't you have for example problems with the client application > >> >>>>>>> > you > >> >>>>>>> > use? > >> >>>>>>> > >> >>>>>>> Yes, with 1 table only. I'm not getting any results. > >> >>>>>>> When I'm on the sql machine via localhost or 192.168.1.100 I'm > >> >>>>>>> getting results. > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> 2013/2/19 Michael Paquier <michael.paquier@gmail.com> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon < > plakroon@gmail.com> > >> >>>>>>>> wrote: > >> >>>>>>>>> > >> >>>>>>>>> Also no result with FROM __my_table LIMIT 1; > >> >>>>>>>> > >> >>>>>>>> I'm having correct results with PG 9.2 by using either xmlagg > or > >> >>>>>>>> xmlelement. > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> For example: > >> >>>>>>>> postgres=# SELECT xmlelement(name el_name, id) FROM __table > LIMIT > >> >>>>>>>> 1; > >> >>>>>>>> xmlelement > >> >>>>>>>> ---------------------- > >> >>>>>>>> <el_name>1</el_name> > >> >>>>>>>> Or: > >> >>>>>>>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM > >> >>>>>>>> __table; > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> xmlagg > >> >>>>>>>> ------------------------------------------ > >> >>>>>>>> > >> >>>>>>>> <el_name>1</el_name><el_name>2</el_name> > >> >>>>>>>> (1 row) > >> >>>>>>>> > >> >>>>>>>> Btw, such simple tests would have failed on the buildfarm for > >> >>>>>>>> regression xml.sql, so this looks to be an error in your > >> >>>>>>>> environment. > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> Don't you have for example problems with the client application > >> >>>>>>>> you > >> >>>>>>>> use? > >> >>>>>>>> -- > >> >>>>>>>> Michael > >> >>>>>>> > >> >>>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>> > >> >>>> > >> >>> > >> >> > >> >> > >> > > > > > >
Sorry, Peter - I think I'd suggest something different. Start at the beginning; do this testing directly from the CLI (psql)on each of the machines, and compare results... I'd be curious, specifically, to see if you see any of those stringlength restrictions you've alluded to when using the CLI. At this point, it's not clear whether you're testing (various versions?) of pgAdmin(?) or (various versions?) of libpq? Lou Picciano ----- Original Message ----- From: Peter Kroon <plakroon@gmail.com> To: Pavel Stehule <pavel.stehule@gmail.com> Cc: Lou Picciano <loupicciano@comcast.net>, Michael Paquier <michael.paquier@gmail.com>, pgsql-bugs@postgresql.org Sent: Tue, 19 Feb 2013 16:50:25 -0000 (UTC) Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >you can test your queries from pgAdmin SQL executorI have already done so. I'll look into the logs. 2013/2/19 Pavel Stehule <pavel.stehule@gmail.com> 2013/2/19 Peter Kroon <plakroon@gmail.com>: >>try to use pgAdminIII > > Could you be more specific? you can test your queries from pgAdmin SQL executor but it is strange error - try to look to postgresql and system logs Pavel > > > 2013/2/19 Pavel Stehule <pavel.stehule@gmail.com> >> >> 2013/2/19 Peter Kroon <plakroon@gmail.com>: >> > Where can I check and/or alter this? >> >> try to use pgAdminIII >> >> Regards >> >> Pavel >> >> > >> > >> > 2013/2/19 Lou Picciano <loupicciano@comcast.net> >> >> >> >> I wonder if there's a difference in the implementation(s) of readline >> >> buffering? >> >> >> >> >> >> ----- Original Message ----- >> >> From: Peter Kroon <plakroon@gmail.com> >> >> To: Lou Picciano <loupicciano@comcast.net> >> >> Cc: Michael Paquier <michael.paquier@gmail.com>, >> >> pgsql-bugs@postgresql.org >> >> Sent: Tue, 19 Feb 2013 15:28:47 -0000 (UTC) >> >> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >> >> >> >> Exceeding length 4679 is a problem. Query results(length) equal or >> >> below >> >> this number succeed. >> >> >> >> >> >> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >>> >> >>> When there are more then 88 rows in the table like 595 I can run the >> >>> query with success when using: WHERE id BETWEEN 1 AND 88; >> >>> >> >>> Using LIMIT 88 fails -> returns nothing >> >>> Selecting all fails as well. >> >>> >> >>> >> >>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >>>> >> >>>> When there are in __table_to_table more than 88 rows nothing gets >> >>>> returned, otherwise the query rolls out fine. >> >>>> >> >>>> >> >>>> >> >>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >>>>> >> >>>>> It appears to be a Windows issue only. >> >>>>> I'll try to post some code. >> >>>>> >> >>>>> >> >>>>> 2013/2/19 Lou Picciano <loupicciano@comcast.net> >> >>>>>> >> >>>>>> Seems your testing from different environments like that could >> >>>>>> easily >> >>>>>> add any mix of libpq client libraries into the equation (??) >> >>>>>> (Are both test machines running the same version of pgAdmin? and >> >>>>>> are >> >>>>>> both connecting using the libpq installed with them?) >> >>>>>> >> >>>>>> We have plenty of experience with clients reporting varying >> >>>>>> behavior >> >>>>>> from our 'applications', when it turns out they've 'hooked into' an >> >>>>>> unexpected version of the libpq client without, for example, SSL >> >>>>>> support >> >>>>>> built in, or Kerberos, or... This often happens after the client >> >>>>>> has >> >>>>>> unwittingly modified his environment in some way, sometimes after >> >>>>>> installing >> >>>>>> software. >> >>>>>> >> >>>>>> While the 'support libraries' issues above have no bearing on your >> >>>>>> case, of course, I certainly don't know enough to know that the >> >>>>>> different >> >>>>>> versions of libpq don't present xmlagg output differently! >> >>>>>> >> >>>>>> The experts here will weigh in. >> >>>>>> >> >>>>>> Lou Picciano >> >>>>>> >> >>>>>> >> >>>>>> ----- Original Message ----- >> >>>>>> From: Peter Kroon <plakroon@gmail.com> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC) >> >>>>>> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >> >>>>>> >> >>>>>> > When I'm on the sql machine via localhost or 192.168.1.100 I'm >> >>>>>> > getting results. >> >>>>>> >> >>>>>> I mean when I'm physically behind the machine and login via pgadmin >> >>>>>> using localhost or 192.168.1.100 then I get results. >> >>>>>> When I'm on another machine and login via pgadmin(192.168.1.100) >> >>>>>> then >> >>>>>> I get no results. >> >>>>>> Not sure what to think of this... >> >>>>>> >> >>>>>> >> >>>>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >>>>>>> >> >>>>>>> >Don't you have for example problems with the client application >> >>>>>>> > you >> >>>>>>> > use? >> >>>>>>> >> >>>>>>> Yes, with 1 table only. I'm not getting any results. >> >>>>>>> When I'm on the sql machine via localhost or 192.168.1.100 I'm >> >>>>>>> getting results. >> >>>>>>> >> >>>>>>> >> >>>>>>> 2013/2/19 Michael Paquier <michael.paquier@gmail.com> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon@gmail.com> >> >>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> Also no result with FROM __my_table LIMIT 1; >> >>>>>>>> >> >>>>>>>> I'm having correct results with PG 9.2 by using either xmlagg or >> >>>>>>>> xmlelement. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> For example: >> >>>>>>>> postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT >> >>>>>>>> 1; >> >>>>>>>> xmlelement >> >>>>>>>> ---------------------- >> >>>>>>>> <el_name>1</el_name> >> >>>>>>>> Or: >> >>>>>>>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM >> >>>>>>>> __table; >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> xmlagg >> >>>>>>>> ------------------------------------------ >> >>>>>>>> >> >>>>>>>> <el_name>1</el_name><el_name>2</el_name> >> >>>>>>>> (1 row) >> >>>>>>>> >> >>>>>>>> Btw, such simple tests would have failed on the buildfarm for >> >>>>>>>> regression xml.sql, so this looks to be an error in your >> >>>>>>>> environment. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Don't you have for example problems with the client application >> >>>>>>>> you >> >>>>>>>> use? >> >>>>>>>> -- >> >>>>>>>> Michael >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>> >> >> >> >> >> > > >
I've migrated everything to Linux and I'm able to continue my work. I'll get back on this next week. 2013/2/19 Lou Picciano <loupicciano@comcast.net> > Sorry, Peter - I think I'd suggest something different. Start at the > beginning; do this testing directly from the CLI (psql) on each of the > machines, and compare results... I'd be curious, specifically, to see if > you see any of those string length restrictions you've alluded to when > using the CLI. > > At this point, it's not clear whether you're testing (various versions?) > of pgAdmin(?) or (various versions?) of libpq? > > > Lou Picciano > > ----- Original Message ----- > From: Peter Kroon <plakroon@gmail.com> > To: Pavel Stehule <pavel.stehule@gmail.com> > Cc: Lou Picciano <loupicciano@comcast.net>, Michael Paquier < > michael.paquier@gmail.com>, pgsql-bugs@postgresql.org > Sent: Tue, 19 Feb 2013 16:50:25 -0000 (UTC) > Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 > > >you can test your queries from pgAdmin SQL executor > I have already done so. > > I'll look into the logs. > > > 2013/2/19 Pavel Stehule <pavel.stehule@gmail.com> > >> >> 2013/2/19 Peter Kroon <plakroon@gmail.com>: >> >>try to use pgAdminIII >> >> > >> >> > Could you be more specific? >> >> you can test your queries from pgAdmin SQL executor >> >> >> but it is strange error - try to look to postgresql and system logs >> >> >> Pavel >> >> >> > >> >> > >> >> > 2013/2/19 Pavel Stehule <pavel.stehule@gmail.com> >> >> >> >> >> >> 2013/2/19 Peter Kroon <plakroon@gmail.com>: >> >> >> > Where can I check and/or alter this? >> >> >> >> >> >> try to use pgAdminIII >> >> >> >> >> >> Regards >> >> >> >> >> >> Pavel >> >> >> >> >> >> > >> >> >> > >> >> >> > 2013/2/19 Lou Picciano <loupicciano@comcast.net> >> >> >> >> >> >> >> >> I wonder if there's a difference in the implementation(s) of >> readline >> >> >> >> buffering? >> >> >> >> >> >> >> >> >> >> >> >> ----- Original Message ----- >> >> >> >> From: Peter Kroon <plakroon@gmail.com> >> >> >> >> To: Lou Picciano <loupicciano@comcast.net> >> >> >> >> Cc: Michael Paquier <michael.paquier@gmail.com>, >> >> >> >> pgsql-bugs@postgresql.org >> >> >> >> Sent: Tue, 19 Feb 2013 15:28:47 -0000 (UTC) >> >> >> >> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >> >> >> >> >> >> >> >> Exceeding length 4679 is a problem. Query results(length) equal or >> >> >> >> below >> >> >> >> this number succeed. >> >> >> >> >> >> >> >> >> >> >> >> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >> >> >>> >> >> >> >>> When there are more then 88 rows in the table like 595 I can run >> the >> >> >> >>> query with success when using: WHERE id BETWEEN 1 AND 88; >> >> >> >>> >> >> >> >>> Using LIMIT 88 fails -> returns nothing >> >> >> >>> Selecting all fails as well. >> >> >> >>> >> >> >> >>> >> >> >> >>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >> >> >>>> >> >> >> >>>> When there are in __table_to_table more than 88 rows nothing gets >> >> >> >>>> returned, otherwise the query rolls out fine. >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >> >> >>>>> >> >> >> >>>>> It appears to be a Windows issue only. >> >> >> >>>>> I'll try to post some code. >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> 2013/2/19 Lou Picciano <loupicciano@comcast.net> >> >> >> >>>>>> >> >> >> >>>>>> Seems your testing from different environments like that could >> >> >> >>>>>> easily >> >> >> >>>>>> add any mix of libpq client libraries into the equation (??) >> >> >> >>>>>> (Are both test machines running the same version of pgAdmin? and >> >> >> >>>>>> are >> >> >> >>>>>> both connecting using the libpq installed with them?) >> >> >> >>>>>> >> >> >> >>>>>> We have plenty of experience with clients reporting varying >> >> >> >>>>>> behavior >> >> >> >>>>>> from our 'applications', when it turns out they've 'hooked >> into' an >> >> >> >>>>>> unexpected version of the libpq client without, for example, SSL >> >> >> >>>>>> support >> >> >> >>>>>> built in, or Kerberos, or... This often happens after the client >> >> >> >>>>>> has >> >> >> >>>>>> unwittingly modified his environment in some way, sometimes >> after >> >> >> >>>>>> installing >> >> >> >>>>>> software. >> >> >> >>>>>> >> >> >> >>>>>> While the 'support libraries' issues above have no bearing on >> your >> >> >> >>>>>> case, of course, I certainly don't know enough to know that the >> >> >> >>>>>> different >> >> >> >>>>>> versions of libpq don't present xmlagg output differently! >> >> >> >>>>>> >> >> >> >>>>>> The experts here will weigh in. >> >> >> >>>>>> >> >> >> >>>>>> Lou Picciano >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> ----- Original Message ----- >> >> >> >>>>>> From: Peter Kroon <plakroon@gmail.com> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC) >> >> >> >>>>>> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >> >> >> >>>>>> >> >> >> >>>>>> > When I'm on the sql machine via localhost or 192.168.1.100 I'm >> >> >> >>>>>> > getting results. >> >> >> >>>>>> >> >> >> >>>>>> I mean when I'm physically behind the machine and login via >> pgadmin >> >> >> >>>>>> using localhost or 192.168.1.100 then I get results. >> >> >> >>>>>> When I'm on another machine and login via pgadmin(192.168.1.100) >> >> >> >>>>>> then >> >> >> >>>>>> I get no results. >> >> >> >>>>>> Not sure what to think of this... >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >> >> >> >>>>>>> >> >> >> >>>>>>> >Don't you have for example problems with the client >> application >> >> >> >>>>>>> > you >> >> >> >>>>>>> > use? >> >> >> >>>>>>> >> >> >> >>>>>>> Yes, with 1 table only. I'm not getting any results. >> >> >> >>>>>>> When I'm on the sql machine via localhost or 192.168.1.100 I'm >> >> >> >>>>>>> getting results. >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> 2013/2/19 Michael Paquier <michael.paquier@gmail.com> >> >> >> >>>>>>>> >> >> >> >>>>>>>> >> >> >> >>>>>>>> >> >> >> >>>>>>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon < >> plakroon@gmail.com> >> >> >> >>>>>>>> wrote: >> >> >> >>>>>>>>> >> >> >> >>>>>>>>> Also no result with FROM __my_table LIMIT 1; >> >> >> >>>>>>>> >> >> >> >>>>>>>> I'm having correct results with PG 9.2 by using either xmlagg >> or >> >> >> >>>>>>>> xmlelement. >> >> >> >>>>>>>> >> >> >> >>>>>>>> >> >> >> >>>>>>>> >> >> >> >>>>>>>> For example: >> >> >> >>>>>>>> postgres=# SELECT xmlelement(name el_name, id) FROM __table >> LIMIT >> >> >> >>>>>>>> 1; >> >> >> >>>>>>>> xmlelement >> >> >> >>>>>>>> ---------------------- >> >> >> >>>>>>>> <el_name>1</el_name> >> >> >> >>>>>>>> Or: >> >> >> >>>>>>>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM >> >> >> >>>>>>>> __table; >> >> >> >>>>>>>> >> >> >> >>>>>>>> >> >> >> >>>>>>>> >> >> >> >>>>>>>> xmlagg >> >> >> >>>>>>>> ------------------------------------------ >> >> >> >>>>>>>> >> >> >> >>>>>>>> <el_name>1</el_name><el_name>2</el_name> >> >> >> >>>>>>>> (1 row) >> >> >> >>>>>>>> >> >> >> >>>>>>>> Btw, such simple tests would have failed on the buildfarm for >> >> >> >>>>>>>> regression xml.sql, so this looks to be an error in your >> >> >> >>>>>>>> environment. >> >> >> >>>>>>>> >> >> >> >>>>>>>> >> >> >> >>>>>>>> >> >> >> >>>>>>>> Don't you have for example problems with the client >> application >> >> >> >>>>>>>> you >> >> >> >>>>>>>> use? >> >> >> >>>>>>>> -- >> >> >> >>>>>>>> Michael >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>> >> >> >> >>>> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> > >> > > >
Just to let everyone know that I haven't forgotten this. I just don't have any time to spend on it. The problem still occurs. 2013/2/20 Peter Kroon <plakroon@gmail.com> > I've migrated everything to Linux and I'm able to continue my work. > I'll get back on this next week. > > > 2013/2/19 Lou Picciano <loupicciano@comcast.net> > >> Sorry, Peter - I think I'd suggest something different. Start at the >> beginning; do this testing directly from the CLI (psql) on each of the >> machines, and compare results... I'd be curious, specifically, to see if >> you see any of those string length restrictions you've alluded to when >> using the CLI. >> >> At this point, it's not clear whether you're testing (various versions?) >> of pgAdmin(?) or (various versions?) of libpq? >> >> >> Lou Picciano >> >> ----- Original Message ----- >> From: Peter Kroon <plakroon@gmail.com> >> To: Pavel Stehule <pavel.stehule@gmail.com> >> Cc: Lou Picciano <loupicciano@comcast.net>, Michael Paquier < >> michael.paquier@gmail.com>, pgsql-bugs@postgresql.org >> Sent: Tue, 19 Feb 2013 16:50:25 -0000 (UTC) >> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >> >> >you can test your queries from pgAdmin SQL executor >> I have already done so. >> >> I'll look into the logs. >> >> >> 2013/2/19 Pavel Stehule <pavel.stehule@gmail.com> >> >>> >>> 2013/2/19 Peter Kroon <plakroon@gmail.com>: >>> >>try to use pgAdminIII >>> >>> > >>> >>> > Could you be more specific? >>> >>> you can test your queries from pgAdmin SQL executor >>> >>> >>> but it is strange error - try to look to postgresql and system logs >>> >>> >>> Pavel >>> >>> >>> > >>> >>> > >>> >>> > 2013/2/19 Pavel Stehule <pavel.stehule@gmail.com> >>> >>> >> >>> >>> >> 2013/2/19 Peter Kroon <plakroon@gmail.com>: >>> >>> >> > Where can I check and/or alter this? >>> >>> >> >>> >>> >> try to use pgAdminIII >>> >>> >> >>> >>> >> Regards >>> >>> >> >>> >>> >> Pavel >>> >>> >> >>> >>> >> > >>> >>> >> > >>> >>> >> > 2013/2/19 Lou Picciano <loupicciano@comcast.net> >>> >>> >> >> >>> >>> >> >> I wonder if there's a difference in the implementation(s) of >>> readline >>> >>> >> >> buffering? >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> ----- Original Message ----- >>> >>> >> >> From: Peter Kroon <plakroon@gmail.com> >>> >>> >> >> To: Lou Picciano <loupicciano@comcast.net> >>> >>> >> >> Cc: Michael Paquier <michael.paquier@gmail.com>, >>> >>> >> >> pgsql-bugs@postgresql.org >>> >>> >> >> Sent: Tue, 19 Feb 2013 15:28:47 -0000 (UTC) >>> >>> >> >> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >>> >>> >> >> >>> >>> >> >> Exceeding length 4679 is a problem. Query results(length) equal or >>> >>> >> >> below >>> >>> >> >> this number succeed. >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> 2013/2/19 Peter Kroon <plakroon@gmail.com> >>> >>> >> >>> >>> >>> >> >>> When there are more then 88 rows in the table like 595 I can run >>> the >>> >>> >> >>> query with success when using: WHERE id BETWEEN 1 AND 88; >>> >>> >> >>> >>> >>> >> >>> Using LIMIT 88 fails -> returns nothing >>> >>> >> >>> Selecting all fails as well. >>> >>> >> >>> >>> >>> >> >>> >>> >>> >> >>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >>> >>> >> >>>> >>> >>> >> >>>> When there are in __table_to_table more than 88 rows nothing gets >>> >>> >> >>>> returned, otherwise the query rolls out fine. >>> >>> >> >>>> >>> >>> >> >>>> >>> >>> >> >>>> >>> >>> >> >>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >>> >>> >> >>>>> >>> >>> >> >>>>> It appears to be a Windows issue only. >>> >>> >> >>>>> I'll try to post some code. >>> >>> >> >>>>> >>> >>> >> >>>>> >>> >>> >> >>>>> 2013/2/19 Lou Picciano <loupicciano@comcast.net> >>> >>> >> >>>>>> >>> >>> >> >>>>>> Seems your testing from different environments like that could >>> >>> >> >>>>>> easily >>> >>> >> >>>>>> add any mix of libpq client libraries into the equation (??) >>> >>> >> >>>>>> (Are both test machines running the same version of pgAdmin? >>> and >>> >>> >> >>>>>> are >>> >>> >> >>>>>> both connecting using the libpq installed with them?) >>> >>> >> >>>>>> >>> >>> >> >>>>>> We have plenty of experience with clients reporting varying >>> >>> >> >>>>>> behavior >>> >>> >> >>>>>> from our 'applications', when it turns out they've 'hooked >>> into' an >>> >>> >> >>>>>> unexpected version of the libpq client without, for example, >>> SSL >>> >>> >> >>>>>> support >>> >>> >> >>>>>> built in, or Kerberos, or... This often happens after the >>> client >>> >>> >> >>>>>> has >>> >>> >> >>>>>> unwittingly modified his environment in some way, sometimes >>> after >>> >>> >> >>>>>> installing >>> >>> >> >>>>>> software. >>> >>> >> >>>>>> >>> >>> >> >>>>>> While the 'support libraries' issues above have no bearing on >>> your >>> >>> >> >>>>>> case, of course, I certainly don't know enough to know that the >>> >>> >> >>>>>> different >>> >>> >> >>>>>> versions of libpq don't present xmlagg output differently! >>> >>> >> >>>>>> >>> >>> >> >>>>>> The experts here will weigh in. >>> >>> >> >>>>>> >>> >>> >> >>>>>> Lou Picciano >>> >>> >> >>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>>> ----- Original Message ----- >>> >>> >> >>>>>> From: Peter Kroon <plakroon@gmail.com> >>> >>> >> >>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>>> Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC) >>> >>> >> >>>>>> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >>> >>> >> >>>>>> >>> >>> >> >>>>>> > When I'm on the sql machine via localhost or 192.168.1.100 >>> I'm >>> >>> >> >>>>>> > getting results. >>> >>> >> >>>>>> >>> >>> >> >>>>>> I mean when I'm physically behind the machine and login via >>> pgadmin >>> >>> >> >>>>>> using localhost or 192.168.1.100 then I get results. >>> >>> >> >>>>>> When I'm on another machine and login via >>> pgadmin(192.168.1.100) >>> >>> >> >>>>>> then >>> >>> >> >>>>>> I get no results. >>> >>> >> >>>>>> Not sure what to think of this... >>> >>> >> >>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>>> 2013/2/19 Peter Kroon <plakroon@gmail.com> >>> >>> >> >>>>>>> >>> >>> >> >>>>>>> >Don't you have for example problems with the client >>> application >>> >>> >> >>>>>>> > you >>> >>> >> >>>>>>> > use? >>> >>> >> >>>>>>> >>> >>> >> >>>>>>> Yes, with 1 table only. I'm not getting any results. >>> >>> >> >>>>>>> When I'm on the sql machine via localhost or 192.168.1.100 I'm >>> >>> >> >>>>>>> getting results. >>> >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> >>> >> >>>>>>> 2013/2/19 Michael Paquier <michael.paquier@gmail.com> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon < >>> plakroon@gmail.com> >>> >>> >> >>>>>>>> wrote: >>> >>> >> >>>>>>>>> >>> >>> >> >>>>>>>>> Also no result with FROM __my_table LIMIT 1; >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> I'm having correct results with PG 9.2 by using either >>> xmlagg or >>> >>> >> >>>>>>>> xmlelement. >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> For example: >>> >>> >> >>>>>>>> postgres=# SELECT xmlelement(name el_name, id) FROM __table >>> LIMIT >>> >>> >> >>>>>>>> 1; >>> >>> >> >>>>>>>> xmlelement >>> >>> >> >>>>>>>> ---------------------- >>> >>> >> >>>>>>>> <el_name>1</el_name> >>> >>> >> >>>>>>>> Or: >>> >>> >> >>>>>>>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM >>> >>> >> >>>>>>>> __table; >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> xmlagg >>> >>> >> >>>>>>>> ------------------------------------------ >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> <el_name>1</el_name><el_name>2</el_name> >>> >>> >> >>>>>>>> (1 row) >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> Btw, such simple tests would have failed on the buildfarm for >>> >>> >> >>>>>>>> regression xml.sql, so this looks to be an error in your >>> >>> >> >>>>>>>> environment. >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> Don't you have for example problems with the client >>> application >>> >>> >> >>>>>>>> you >>> >>> >> >>>>>>>> use? >>> >>> >> >>>>>>>> -- >>> >>> >> >>>>>>>> Michael >>> >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>> >>> >>> >> >>>> >>> >>> >> >>> >>> >>> >> >> >>> >>> >> >> >>> >>> >> > >>> >>> > >>> >>> > >>> >> >> >> >