Skip site navigation (1) Skip section navigation (2)

Re: Branch 1.14?

From: Jasmin Dizdarevic <jasmin(dot)dizdarevic(at)gmail(dot)com>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, "pgadmin-hackers(at)postgresql(dot)org" <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Branch 1.14?
Date: 2011-06-15 06:34:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
currently there are 10 versions of pgadmin for download ( available, which works with older
versions. if someone likes to manage an older version he can download an
older client.
there are no tests of current releases against older versions of postgresql,
so why we should keep the code?

the code would become more clear and readable, because we would not have to
check things which are a must. take these lines of code:

if (collection->GetConnection()->BackendMinimumVersion(7, 4))
proname = wxT("indnatts, ");
if (collection->GetConnection()->BackendMinimumVersion(7, 5))
proname += wxT("cls.reltablespace AS spcoid, spcname, ");
projoin = wxT("  LEFT OUTER JOIN pg_tablespace ta on
proname = wxT("proname, pn.nspname as pronspname, proargtypes, ");
projoin =   wxT("  LEFT OUTER JOIN pg_proc pr ON pr.oid=indproc\n")
            wxT("  LEFT OUTER JOIN pg_namespace pn ON
query = wxT("SELECT DISTINCT ON(cls.relname) cls.oid, cls.relname as
idxname, indrelid, indkey, indisclustered, indisunique, indisprimary,
        wxT("       ") + proname + wxT("tab.relname as tabname, indclass,
con.oid AS conoid, CASE contype WHEN 'p' THEN desp.description WHEN 'u' THEN
desp.description WHEN 'x' THEN desp.description ELSE des.description END AS
        wxT("       pg_get_expr(indpred, indrelid") +
collection->GetDatabase()->GetPrettyOption() + wxT(") as indconstraint,
contype, condeferrable, condeferred, amname\n");
if (collection->GetConnection()->BackendMinimumVersion(8, 2))
query += wxT(", substring(array_to_string(cls.reloptions, ',') from
'fillfactor=([0-9]*)') AS fillfactor \n");
query += wxT("  FROM pg_index idx\n")
         wxT("  JOIN pg_class cls ON cls.oid=indexrelid\n")
         wxT("  JOIN pg_class tab ON tab.oid=indrelid\n")
         + projoin +
         wxT("  JOIN pg_namespace n ON n.oid=tab.relnamespace\n")
         wxT("  JOIN pg_am am ON am.oid=cls.relam\n")
         wxT("  LEFT JOIN pg_depend dep ON (dep.classid = cls.tableoid AND
dep.objid = cls.oid AND dep.refobjsubid = '0' AND dep.refclassid=(SELECT oid
FROM pg_class WHERE relname='pg_constraint') AND dep.deptype='i')\n")
         wxT("  LEFT OUTER JOIN pg_constraint con ON (con.tableoid =
dep.refclassid AND con.oid = dep.refobjid)\n")
         wxT("  LEFT OUTER JOIN pg_description des ON des.objoid=cls.oid\n")
         wxT("  LEFT OUTER JOIN pg_description desp ON (desp.objoid=con.oid
AND desp.objsubid = 0)\n")
         wxT(" WHERE indrelid = ") + collection->GetOidStr()
         + restriction + wxT("\n")
         wxT(" ORDER BY cls.relname");

with a "supporting 8.2 and above" - policy, this would be just ONE statement
and it's done.

2011/6/15 Guillaume Lelarge <guillaume(at)lelarge(dot)info>

> On Tue, 2011-06-14 at 23:41 +0100, Dave Page wrote:
> > We don't tend to remove the old code as that can lead to painful
> > amounts of refactoring to make things look right afterwards. If you
> > feel so inclined though, go ahead and do some cleanup.
> >
> I don't see why we should remove old code that still works. That we say
> we don't "officially" support older versions than 8.2, that's one thing
> I would understand. Working on dropping code that should work to make
> sure no one can use it with older versions is something I can't
> understand.
> So, -1 for dropping any code, unless we have proof it contains a bug we
> don't want to fix because it's on some old unsupported PostgreSQL
> release.
> (and when I say "-1", I really want to say "-1000000").
> --
> Guillaume

In response to


pgadmin-hackers by date

Next:From: Guillaume LelargeDate: 2011-06-15 06:53:05
Subject: Re: Branch 1.14?
Previous:From: Guillaume LelargeDate: 2011-06-15 06:08:18
Subject: Re: Discussion - Search Objects

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group