2013/2/19 Peter Kroon <plakr...@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.steh...@gmail.com> >> >> 2013/2/19 Peter Kroon <plakr...@gmail.com>: >> > Where can I check and/or alter this? >> >> try to use pgAdminIII >> >> Regards >> >> Pavel >> >> > >> > >> > 2013/2/19 Lou Picciano <loupicci...@comcast.net> >> >> >> >> I wonder if there's a difference in the implementation(s) of readline >> >> buffering? >> >> >> >> >> >> ----- Original Message ----- >> >> From: Peter Kroon <plakr...@gmail.com> >> >> To: Lou Picciano <loupicci...@comcast.net> >> >> Cc: Michael Paquier <michael.paqu...@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 <plakr...@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 <plakr...@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 <plakr...@gmail.com> >> >>>>> >> >>>>> It appears to be a Windows issue only. >> >>>>> I'll try to post some code. >> >>>>> >> >>>>> >> >>>>> 2013/2/19 Lou Picciano <loupicci...@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 <plakr...@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 <plakr...@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.paqu...@gmail.com> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakr...@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 >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>> >> >> >> >> >> > > > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
