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

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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>