Discussion:
Nested xmlagg doesn't give a result 9.2.3
(too old to reply)
Peter Kroon
2013-02-19 00:18:41 UTC
Permalink
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.
Michael Paquier
2013-02-19 01:03:51 UTC
Permalink
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
Peter Kroon
2013-02-19 07:59:25 UTC
Permalink
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
Post by Michael Paquier
Hi,
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);
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
Peter Kroon
2013-02-19 08:42:01 UTC
Permalink
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....
Post by Peter Kroon
Hi Michael,
-----------------------------------------------------------------------
<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
Post by Michael Paquier
Hi,
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);
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
Peter Kroon
2013-02-19 08:50:25 UTC
Permalink
Also no result with FROM __my_table LIMIT 1;
Post by Peter Kroon
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
"<el_name>1</el_name>"
"<el_name>2</el_name>"
"<el_name>3</el_name>"
etc....
Post by Peter Kroon
Hi Michael,
-----------------------------------------------------------------------
<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
Post by Michael Paquier
Hi,
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);
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
Michael Paquier
2013-02-19 11:27:28 UTC
Permalink
Post by Peter Kroon
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
Peter Kroon
2013-02-19 11:35:36 UTC
Permalink
Post by Michael Paquier
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.
Post by Michael Paquier
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either xmlagg or xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1;
xmlelement
----------------------
<el_name>1</el_name>
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
Peter Kroon
2013-02-19 11:52:37 UTC
Permalink
Post by Peter Kroon
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...
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Michael Paquier
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either xmlagg or xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1;
xmlelement
----------------------
<el_name>1</el_name>
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
Lou Picciano
2013-02-19 12:25:17 UTC
Permalink
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 <***@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...
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 <***@gmail.com>


On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <***@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
Peter Kroon
2013-02-19 12:50:26 UTC
Permalink
It appears to be a Windows issue only.
I'll try to post some code.
Post by Lou Picciano
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 -----
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Peter Kroon
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...
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Michael Paquier
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either xmlagg or xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1;
xmlelement
----------------------
<el_name>1</el_name>
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
Peter Kroon
2013-02-19 14:27:09 UTC
Permalink
When there are in __table_to_table more than 88 rows nothing gets returned,
otherwise the query rolls out fine.
Post by Peter Kroon
It appears to be a Windows issue only.
I'll try to post some code.
Post by Lou Picciano
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 -----
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Peter Kroon
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...
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Michael Paquier
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either xmlagg or xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1;
xmlelement
----------------------
<el_name>1</el_name>
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
Peter Kroon
2013-02-19 15:08:28 UTC
Permalink
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.
Post by Peter Kroon
When there are in __table_to_table more than 88 rows nothing gets
returned, otherwise the query rolls out fine.
Post by Peter Kroon
It appears to be a Windows issue only.
I'll try to post some code.
Post by Lou Picciano
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 -----
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Peter Kroon
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...
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Michael Paquier
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either xmlagg or xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1;
xmlelement
----------------------
<el_name>1</el_name>
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
Peter Kroon
2013-02-19 15:28:47 UTC
Permalink
Exceeding length 4679 is a problem. Query results(length) equal or below
this number succeed.
Post by Peter Kroon
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.
Post by Peter Kroon
When there are in __table_to_table more than 88 rows nothing gets
returned, otherwise the query rolls out fine.
Post by Peter Kroon
It appears to be a Windows issue only.
I'll try to post some code.
Post by Lou Picciano
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 -----
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Peter Kroon
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...
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Michael Paquier
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either xmlagg or xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1;
xmlelement
----------------------
<el_name>1</el_name>
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
Peter Kroon
2013-02-19 16:07:37 UTC
Permalink
Where can I check and/or alter this?
I wonder if there's a difference in the implementation(s) of readline
buffering?
----- Original Message -----
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.
Post by Peter Kroon
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.
Post by Peter Kroon
When there are in __table_to_table more than 88 rows nothing gets
returned, otherwise the query rolls out fine.
Post by Peter Kroon
It appears to be a Windows issue only.
I'll try to post some code.
Post by Lou Picciano
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 -----
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Peter Kroon
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...
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Michael Paquier
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either xmlagg or xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1;
xmlelement
----------------------
<el_name>1</el_name>
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
Pavel Stehule
2013-02-19 16:27:05 UTC
Permalink
Post by Peter Kroon
Where can I check and/or alter this?
try to use pgAdminIII

Regards

Pavel
Post by Peter Kroon
Post by Lou Picciano
I wonder if there's a difference in the implementation(s) of readline buffering?
----- Original Message -----
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.
Post by Peter Kroon
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.
Post by Peter Kroon
When there are in __table_to_table more than 88 rows nothing gets
returned, otherwise the query rolls out fine.
Post by Peter Kroon
It appears to be a Windows issue only.
I'll try to post some code.
Post by Lou Picciano
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 -----
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Peter Kroon
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...
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Michael Paquier
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either xmlagg or xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1;
xmlelement
----------------------
<el_name>1</el_name>
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
--
Sent via pgsql-bugs mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Peter Kroon
2013-02-19 16:44:01 UTC
Permalink
Post by Pavel Stehule
try to use pgAdminIII
Could you be more specific?
Post by Pavel Stehule
Post by Peter Kroon
Where can I check and/or alter this?
try to use pgAdminIII
Regards
Pavel
Post by Peter Kroon
Post by Lou Picciano
I wonder if there's a difference in the implementation(s) of readline buffering?
----- Original Message -----
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.
Post by Peter Kroon
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.
Post by Peter Kroon
When there are in __table_to_table more than 88 rows nothing gets
returned, otherwise the query rolls out fine.
Post by Peter Kroon
It appears to be a Windows issue only.
I'll try to post some code.
Post by Lou Picciano
Seems your testing from different environments like that could
easily
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
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
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
built in, or Kerberos, or... This often happens after the client has
unwittingly modified his environment in some way, sometimes after
installing
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
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
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
versions of libpq don't present xmlagg output differently!
The experts here will weigh in.
Lou Picciano
----- Original Message -----
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Peter Kroon
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
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
I get no results.
Not sure what to think of this...
Post by Peter Kroon
Post by Michael Paquier
Don't you have for example problems with the client application
you
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Michael Paquier
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either xmlagg or
xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT
1;
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
xmlelement
----------------------
<el_name>1</el_name>
postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM
__table;
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
Don't you have for example problems with the client application
you
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
use?
--
Michael
Pavel Stehule
2013-02-19 16:48:13 UTC
Permalink
Post by Peter Kroon
Post by Pavel Stehule
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Where can I check and/or alter this?
try to use pgAdminIII
Regards
Pavel
Post by Peter Kroon
Post by Lou Picciano
I wonder if there's a difference in the implementation(s) of readline buffering?
----- Original Message -----
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.
Post by Peter Kroon
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.
Post by Peter Kroon
When there are in __table_to_table more than 88 rows nothing gets
returned, otherwise the query rolls out fine.
Post by Peter Kroon
It appears to be a Windows issue only.
I'll try to post some code.
Post by Lou Picciano
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 -----
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Peter Kroon
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...
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Michael Paquier
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either xmlagg or
xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT 1;
xmlelement
----------------------
<el_name>1</el_name>
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
--
Sent via pgsql-bugs mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Peter Kroon
2013-02-19 16:50:25 UTC
Permalink
Post by Pavel Stehule
you can test your queries from pgAdmin SQL executor
I have already done so.

I'll look into the logs.
Post by Pavel Stehule
Post by Peter Kroon
Post by Pavel Stehule
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Where can I check and/or alter this?
try to use pgAdminIII
Regards
Pavel
Post by Peter Kroon
I wonder if there's a difference in the implementation(s) of readline
buffering?
----- Original Message -----
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.
Post by Peter Kroon
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.
Post by Peter Kroon
When there are in __table_to_table more than 88 rows nothing gets
returned, otherwise the query rolls out fine.
Post by Peter Kroon
It appears to be a Windows issue only.
I'll try to post some code.
Post by Lou Picciano
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
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 -----
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Peter Kroon
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
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...
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Michael Paquier
On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either xmlagg
or
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table
LIMIT
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
1;
xmlelement
----------------------
<el_name>1</el_name>
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
Lou Picciano
2013-02-19 17:16:27 UTC
Permalink
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 <***@gmail.com>
To: Pavel Stehule <***@gmail.com>
Cc: Lou Picciano <***@comcast.net>, Michael Paquier <***@gmail.com>, pgsql-***@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.
Post by Pavel Stehule
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
Post by Pavel Stehule
Post by Peter Kroon
Where can I check and/or alter this?
try to use pgAdminIII
Regards
Pavel
Post by Peter Kroon
I wonder if there's a difference in the implementation(s) of readline
buffering?
----- Original Message -----
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.
Post by Peter Kroon
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.
Post by Peter Kroon
When there are in __table_to_table more than 88 rows nothing gets
returned, otherwise the query rolls out fine.
Post by Peter Kroon
It appears to be a Windows issue only.
I'll try to post some code.
Post by Lou Picciano
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 -----
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Peter Kroon
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...
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Michael Paquier
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either xmlagg or
xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table LIMIT
1;
xmlelement
----------------------
<el_name>1</el_name>
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
Peter Kroon
2013-02-20 14:20:54 UTC
Permalink
I've migrated everything to Linux and I'm able to continue my work.
I'll get back on this next week.
Post by Lou Picciano
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 -----
Sent: Tue, 19 Feb 2013 16:50:25 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Pavel Stehule
you can test your queries from pgAdmin SQL executor
I have already done so.
I'll look into the logs.
Post by Pavel Stehule
Post by Peter Kroon
Post by Pavel Stehule
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Where can I check and/or alter this?
try to use pgAdminIII
Regards
Pavel
Post by Peter Kroon
I wonder if there's a difference in the implementation(s) of
readline
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
buffering?
----- Original Message -----
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.
Post by Peter Kroon
When there are more then 88 rows in the table like 595 I can run
the
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
query with success when using: WHERE id BETWEEN 1 AND 88;
Using LIMIT 88 fails -> returns nothing
Selecting all fails as well.
Post by Peter Kroon
When there are in __table_to_table more than 88 rows nothing gets
returned, otherwise the query rolls out fine.
Post by Peter Kroon
It appears to be a Windows issue only.
I'll try to post some code.
Post by Lou Picciano
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
installing
software.
While the 'support libraries' issues above have no bearing on
your
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
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 -----
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Peter Kroon
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
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...
Post by Peter Kroon
Post by Michael Paquier
Don't you have for example problems with the client
application
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Michael Paquier
On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either xmlagg
or
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table
LIMIT
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
1;
xmlelement
----------------------
<el_name>1</el_name>
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
you
use?
--
Michael
Peter Kroon
2013-03-08 20:36:55 UTC
Permalink
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.
Post by Peter Kroon
I've migrated everything to Linux and I'm able to continue my work.
I'll get back on this next week.
Post by Lou Picciano
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 -----
Sent: Tue, 19 Feb 2013 16:50:25 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Pavel Stehule
you can test your queries from pgAdmin SQL executor
I have already done so.
I'll look into the logs.
Post by Pavel Stehule
Post by Peter Kroon
Post by Pavel Stehule
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Where can I check and/or alter this?
try to use pgAdminIII
Regards
Pavel
Post by Peter Kroon
I wonder if there's a difference in the implementation(s) of
readline
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
buffering?
----- Original Message -----
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.
Post by Peter Kroon
When there are more then 88 rows in the table like 595 I can run
the
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
query with success when using: WHERE id BETWEEN 1 AND 88;
Using LIMIT 88 fails -> returns nothing
Selecting all fails as well.
Post by Peter Kroon
When there are in __table_to_table more than 88 rows nothing gets
returned, otherwise the query rolls out fine.
Post by Peter Kroon
It appears to be a Windows issue only.
I'll try to post some code.
Post by Lou Picciano
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
unexpected version of the libpq client without, for example,
SSL
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
support
built in, or Kerberos, or... This often happens after the
client
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
has
unwittingly modified his environment in some way, sometimes
after
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
installing
software.
While the 'support libraries' issues above have no bearing on
your
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
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 -----
Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC)
Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Post by Peter Kroon
When I'm on the sql machine via localhost or 192.168.1.100
I'm
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
getting results.
I mean when I'm physically behind the machine and login via
pgadmin
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
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)
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
then
I get no results.
Not sure what to think of this...
Post by Peter Kroon
Post by Michael Paquier
Don't you have for example problems with the client
application
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
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.
Post by Michael Paquier
On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <
Post by Peter Kroon
Also no result with FROM __my_table LIMIT 1;
I'm having correct results with PG 9.2 by using either
xmlagg or
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
xmlelement.
postgres=# SELECT xmlelement(name el_name, id) FROM __table
LIMIT
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
1;
xmlelement
----------------------
<el_name>1</el_name>
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
Post by Peter Kroon
Post by Pavel Stehule
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Peter Kroon
Post by Lou Picciano
Post by Peter Kroon
Post by Michael Paquier
you
use?
--
Michael
Lou Picciano
2013-02-19 16:06:40 UTC
Permalink
I wonder if there's a difference in the implementation(s) of readline buffering?

----- Original Message -----
From: Peter Kroon <***@gmail.com>
To: Lou Picciano <***@comcast.net>
Cc: Michael Paquier <***@gmail.com>, pgsql-***@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 <***@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 nothingSelecting all fails as well.

2013/2/19 Peter Kroon <***@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 <***@gmail.com>
It appears to be a Windows issue only.I'll try to post some code.

2013/2/19 Lou Picciano <***@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 <***@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...
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 <***@gmail.com>


On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <***@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
Loading...