On Tue, Feb 8, 2011 at 7:14 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Tue, Feb 8, 2011 at 11:10, Dave Page <dpage@pgadmin.org> wrote:
>> On 2/8/11, Magnus Hagander <magnus@hagander.net> wrote:
>>> On Tue, Feb 8, 2011 at 11:01, Dave Page <dpage@pgadmin.org> wrote:
>>>> On 2/8/11, Magnus Hagander <magnus@hagander.net> wrote:
>>>>> On Tue, Feb 8, 2011 at 08:22, Nikhil S <nixmisc@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Well, the SQL does get fired against a PG database in the EDBAS mode
>>>>>>> for
>>>>>>> me. I too was puzzled about the minimum version check being EDBAS
>>>>>>> specific.
>>>>>>>
>>>>>>
>>>>>> Just checked. The version checker function checks for the version number
>>>>>> and
>>>>>> also for a bool which is set to true in EDBAS mode. So yeah, this will
>>>>>> not
>>>>>> be repro in pure Postgresql mode operations. Sorry for indicating so.
>>>>>> But
>>>>>> the issue defo comes if you try to browse a PG database in EDBAS mode.
>>>>>
>>>>> Why would you browse a PG database in EDBAS mode? Isn't there a whole
>>>>> lot of other things that would break in that case as well?
>>>>>
>>>>> Or maybe I'm misunderstanding what you mean with "EDBAS mode"?
>>>>>
>>>>
>>>> He means when edbas is running in PG mode instead of Oracle mode.
>>>
>>> Ah, that makes more sense.
>>>
>>> And pgadmin incorrectly identifies that as an oracle-mode ebas server?
>>> In that case, isn't the actual problem that it's identified as edbas
>>> and not pg?
>>>
>>
>> It doesn't actually care.
>
> Pre this report doesn't it sound like it should?
It *shouldn't*. PG/Oracle mode in PPAS is really just about whether
certain oracle compatibility functions and packages are installed, and
I think the date/time defaults. Oh, and possibly the default casts.
But not the catalog schema.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company