Re: Nested xmlagg doesn't give a result 9.2.3

Поиск
Список
Период
Сортировка
От Peter Kroon
Тема Re: Nested xmlagg doesn't give a result 9.2.3
Дата
Msg-id CAOh+DO=HQYM7s6G4UTaO_NfO3P_xdA5AL6a1TUyFigmGP=+GnA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Nested xmlagg doesn't give a result 9.2.3  (Lou Picciano <loupicciano@comcast.net>)
Ответы Re: Nested xmlagg doesn't give a result 9.2.3  (Peter Kroon <plakroon@gmail.com>)
Список pgsql-bugs
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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: BUG #7873: pg_restore --clean tries to drop tables that don't exist