public inbox for [email protected]  

help / color / mirror / Atom feed

From: Dave Page <[email protected]>
To: George Gelashvili <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Ashesh Vashi <[email protected]>
Subject: Re: Driver Module
Date: Thu, 12 Jan 2017 09:37:37 +0530
Message-ID: <CA+OCxowafvQt7Cp1O=XSHt34Hr0bCjDCy4bnLdO5WPCXE=H9hw@mail.gmail.com> (raw)
In-Reply-To: <CAHowoHY+9h_=wpkGS3DUhey9ua+OVee6X+4OmifMH9cU6KiCug@mail.gmail.com>
References: <CAHowoHbaKvtMXqDjFT_xQjqo3FFhVYb_nV1v1NR=HT0U+hTPmg@mail.gmail.com>
	<CA+OCxoysm1Fw3axLN75Qy7d=1tFxMrQ142kREVLFTTOqqcmmTw@mail.gmail.com>
	<CAHowoHY+9h_=wpkGS3DUhey9ua+OVee6X+4OmifMH9cU6KiCug@mail.gmail.com>
List-Unsubscribe:  <mailto:[email protected]?body=unsub%20pgadmin-hackers>

Hi

On Wed, Jan 11, 2017 at 10:24 PM, George Gelashvili
<[email protected]> wrote:
> Hi Dave,
>
> Thanks for the pointer.
> We realized that many of the changes we would need to make for supporting
> Greenplum would need to go where there is pg version checking throughout the
> code. This is because unlike PPAS which mostly adds additional features,
> Greenplum is based on postgres 8.3.

Isn't Heikki fixing that for your next release?

> It looks like much of the version checking logic is repeated at points where
> the features are differentiated by postgres version.
>
> It might make sense at this point to refactor the way that feature flagging
> is done to be a little bit more unified between server types and postgres
> versions so that we could for example have logic along the lines of:
>
> feature_enablement = FeatureEnablement(postgres_flavor, postgres_version)
>
> #...
>
> if(feature_enablement.check_internal_triggers ):
>   # feature call here
>
> and then in a feature enablement class, reference the various versions and
> flavors of postgres.
>
> Any thoughts on this?

I worry that the list of features would end up being huge - we're not
just talking about basic things like whether DDL triggers are
supported, but the catalog schema (e.g. procpid vs. pid in
pg_stat_activity) and small things like whether a particular GUC can
be set on a tablespace.

Ultimately, you have to do a version check at some point though
(unless you're proposing to do something similar to probing the DOM in
a browser at runtime). Doesn't GP's version string contain additional
info beyond '8.3'? In pgAdmin 3 we had a EdbMinimumVersion(int major,
int minor) function in the connection class that basically did:

return isEdb && BackendMinimumVersion(x, y);

Something like that could check other elements of the GP version number.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgadmin-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

view thread (7+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Driver Module
  In-Reply-To: <CA+OCxowafvQt7Cp1O=XSHt34Hr0bCjDCy4bnLdO5WPCXE=H9hw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox