Re: Nested xmlagg doesn't give a result 9.2.3 - Mailing list pgsql-bugs

From Peter Kroon
Subject Re: Nested xmlagg doesn't give a result 9.2.3
Date
Msg-id CAOh+DOmm6FhP5cNXuv482iBwZ3V0BnqGYcbDgiceYsiRp26fUA@mail.gmail.com
Whole thread Raw
In response to Re: Nested xmlagg doesn't give a result 9.2.3  (Peter Kroon <plakroon@gmail.com>)
Responses Re: Nested xmlagg doesn't give a result 9.2.3  (Peter Kroon <plakroon@gmail.com>)
List pgsql-bugs
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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>

pgsql-bugs by date:

Previous
From: Peter Kroon
Date:
Subject: Re: Nested xmlagg doesn't give a result 9.2.3
Next
From: Peter Kroon
Date:
Subject: Re: Nested xmlagg doesn't give a result 9.2.3