Re: Nested xmlagg doesn't give a result 9.2.3

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