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

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