Re: Nested xmlagg doesn't give a result 9.2.3

From: Peter Kroon <plakroon(at)gmail(dot)com>
To: Lou Picciano <loupicciano(at)comcast(dot)net>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Nested xmlagg doesn't give a result 9.2.3
Date: 2013-02-19 12:50:26
Message-ID: CAOh+DO=HQYM7s6G4UTaO_NfO3P_xdA5AL6a1TUyFigmGP=+GnA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

It appears to be a Windows issue only.
I'll try to post some code.

2013/2/19 Lou Picciano <loupicciano(at)comcast(dot)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(at)gmail(dot)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(at)gmail(dot)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(dot)paquier(at)gmail(dot)com>
>>
>>>
>>>
>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon <plakroon(at)gmail(dot)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
>>>
>>
>>
>
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Pavel Stehule 2013-02-19 13:00:07 Re: BUG #7873: pg_restore --clean tries to drop tables that don't exist
Previous Message Heikki Linnakangas 2013-02-19 12:42:34 Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on