Обсуждение: [pgadmin-hackers] Driver Module

Hi there,

We are working on connecting Greenplum to pgAdmin4. Currently we are exploring how modules work in pgAdmin. In an earlier off-thread email it was suggested we look at "the EDB PPAS" as an example of a driver class. We are not entirely clear on what that means.

We found:

- the BaseDriver in web/pgadmin/utils/driver, documented: https://www.pgadmin.org/docs4/1.x/code_snippets.html?highlight=driver#basedriver

- things that look EDB-related in web/pgadmin/utils/driver/psycopg2/__init__.py

Is it a good idea to keep looking for EDB PPAS as an example of a driver?

Does anyone know exactly where it lives?

Hi

On Wed, Jan 11, 2017 at 10:24 PM, George Gelashvili
<ggelashvili@pivotal.io> 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

Hi

On Thu, Jan 12, 2017 at 8:18 PM, George Gelashvili
<ggelashvili@pivotal.io> wrote:
> Hi Dave,
>
> We looked through the places where there is existing version checking and
> there isn't a ton of it.

That's because we went to great lengths to minimise it in pgAdmin 4.
It's mostly confined to template selection for SQL now.

> Our current plan for supporting Greenplum in
> pgAdmin4 was not necessarily to support all the features of pgAdmin4, but to
> at least get the core functionality working.
> I'm not too concerned about there being a ton of switches, because I don't
> think most features will need to be disabled. We will also likely make
> changes to Greenplum to support certain features like query plans rather
> than doing all the changes on the pgAdmin4 side.

OK. From my perspective though, I have to ensure that what we offer in
the community is a good experience. If it's not appropriate or
necessary to support a feature in GP, that's fine - but it needs to be
disabled to prevent users reporting bugs to us

> What I would like to see though is version checking that happens in one
> place and is not tied exclusively to either flavor or version, but to a
> combination of the two. E.g. Greenplum 5.0 might support a feature that is
> not supported in 8.3 postgres.

Can you do a rough assessment of how many 'features' we'd be likely to
need to have the PG driver advertise? That would give a better idea of
the extent of the work involved.

In principal I'm not against the idea of having a function in each
driver that allows us to check for the presence of a given feature,
including by-version as required. What I'm against is that becoming a
mess of spaghetti...

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

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