Re: Nested xmlagg doesn't give a result 9.2.3 - Mailing list pgsql-bugs
| From | Peter Kroon |
|---|---|
| Subject | Re: Nested xmlagg doesn't give a result 9.2.3 |
| Date | |
| Msg-id | CAOh+DO=zM_V-RW3qmJE6=1N5PgBQXuhByZVoAc9duzoykx6xRg@mail.gmail.com Whole thread Raw |
| In response to | Re: Nested xmlagg doesn't give a result 9.2.3 (Lou Picciano <loupicciano@comcast.net>) |
| Responses |
Re: Nested xmlagg doesn't give a result 9.2.3
|
| List | pgsql-bugs |
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 >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>> >> >> >> >>>> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> > >> > > >
pgsql-bugs by date: