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