Обсуждение: Branch 1.14?
Hi, PostgreSQL already created a 9.1 branch, so that new features could be commited on head. Actually, there'll be a commitfest starting tomorrow. Should we also create a new branch, so that new features could be applied on head? I have no features right now to commit and push, but it could be interesting nevertheless. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Tue, Jun 14, 2011 at 11:21 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Hi, > > PostgreSQL already created a 9.1 branch, so that new features could be > commited on head. Actually, there'll be a commitfest starting tomorrow. > Should we also create a new branch, so that new features could be > applied on head? > > I have no features right now to commit and push, but it could be > interesting nevertheless. If there's nothing to commit, then all it means it that we'll have to start double-patching bugfixes for no gain. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, 2011-06-14 at 11:25 +0100, Dave Page wrote: > On Tue, Jun 14, 2011 at 11:21 AM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > > Hi, > > > > PostgreSQL already created a 9.1 branch, so that new features could be > > commited on head. Actually, there'll be a commitfest starting tomorrow. > > Should we also create a new branch, so that new features could be > > applied on head? > > > > I have no features right now to commit and push, but it could be > > interesting nevertheless. > > If there's nothing to commit, then all it means it that we'll have to > start double-patching bugfixes for no gain. > OK, so we open it as soon as we have a commit to push? -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Tue, Jun 14, 2011 at 2:59 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > On Tue, 2011-06-14 at 11:25 +0100, Dave Page wrote: >> On Tue, Jun 14, 2011 at 11:21 AM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >> > Hi, >> > >> > PostgreSQL already created a 9.1 branch, so that new features could be >> > commited on head. Actually, there'll be a commitfest starting tomorrow. >> > Should we also create a new branch, so that new features could be >> > applied on head? >> > >> > I have no features right now to commit and push, but it could be >> > interesting nevertheless. >> >> If there's nothing to commit, then all it means it that we'll have to >> start double-patching bugfixes for no gain. >> > > OK, so we open it as soon as we have a commit to push? Yes. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, 2011-06-14 at 15:25 +0100, Dave Page wrote: > On Tue, Jun 14, 2011 at 2:59 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > > On Tue, 2011-06-14 at 11:25 +0100, Dave Page wrote: > >> On Tue, Jun 14, 2011 at 11:21 AM, Guillaume Lelarge > >> <guillaume@lelarge.info> wrote: > >> > Hi, > >> > > >> > PostgreSQL already created a 9.1 branch, so that new features could be > >> > commited on head. Actually, there'll be a commitfest starting tomorrow. > >> > Should we also create a new branch, so that new features could be > >> > applied on head? > >> > > >> > I have no features right now to commit and push, but it could be > >> > interesting nevertheless. > >> > >> If there's nothing to commit, then all it means it that we'll have to > >> start double-patching bugfixes for no gain. > >> > > > > OK, so we open it as soon as we have a commit to push? > > Yes. > Seems good to me. I don't expect to have new features soon anyway, except the Luis's project. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
Excuse me? *g*
2011/6/14 Guillaume Lelarge <guillaume@lelarge.info>
On Tue, 2011-06-14 at 15:25 +0100, Dave Page wrote:Seems good to me. I don't expect to have new features soon anyway,
> On Tue, Jun 14, 2011 at 2:59 PM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
> > On Tue, 2011-06-14 at 11:25 +0100, Dave Page wrote:
> >> On Tue, Jun 14, 2011 at 11:21 AM, Guillaume Lelarge
> >> <guillaume@lelarge.info> wrote:
> >> > Hi,
> >> >
> >> > PostgreSQL already created a 9.1 branch, so that new features could be
> >> > commited on head. Actually, there'll be a commitfest starting tomorrow.
> >> > Should we also create a new branch, so that new features could be
> >> > applied on head?
> >> >
> >> > I have no features right now to commit and push, but it could be
> >> > interesting nevertheless.
> >>
> >> If there's nothing to commit, then all it means it that we'll have to
> >> start double-patching bugfixes for no gain.
> >>
> >
> > OK, so we open it as soon as we have a commit to push?
>
> Yes.
>
except the Luis's project.Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
On Tue, 2011-06-14 at 20:57 +0200, Jasmin Dizdarevic wrote: > Excuse me? *g* > Yeah, I don't think I'll have the time to work on new features now. Too much other things to do. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Tuesday, June 14, 2011, Guillaume Lelarge <guillaume@lelarge.info> wrote: > On Tue, 2011-06-14 at 20:57 +0200, Jasmin Dizdarevic wrote: >> Excuse me? *g* >> > > Yeah, I don't think I'll have the time to work on new features now. Too > much other things to do. I think Jasmine is alluding to the object search patch that's in progress :-) -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, 2011-06-14 at 22:00 +0100, Dave Page wrote: > On Tuesday, June 14, 2011, Guillaume Lelarge <guillaume@lelarge.info> wrote: > > On Tue, 2011-06-14 at 20:57 +0200, Jasmin Dizdarevic wrote: > >> Excuse me? *g* > >> > > > > Yeah, I don't think I'll have the time to work on new features now. Too > > much other things to do. > > I think Jasmine is alluding to the object search patch that's in progress :-) > Oops, sorry, forgot that patch. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
=)
BTW:
[...]The application may be used on Linux, FreeBSD, Solaris, Mac OSX and Windows platforms to manage PostgreSQL 7.3 and above running on any platform[...]
Is 7.3 really the current minimum version for pgAdmin 1.14 or 1.15?
Shouldn't the minimum version of pgAdmin reflect the minimum version supported/patched by PostgreSQL (currently 8.2.21)?
2011/6/14 Guillaume Lelarge <guillaume@lelarge.info>
On Tue, 2011-06-14 at 22:00 +0100, Dave Page wrote:Oops, sorry, forgot that patch.
> On Tuesday, June 14, 2011, Guillaume Lelarge <guillaume@lelarge.info> wrote:
> > On Tue, 2011-06-14 at 20:57 +0200, Jasmin Dizdarevic wrote:
> >> Excuse me? *g*
> >>
> >
> > Yeah, I don't think I'll have the time to work on new features now. Too
> > much other things to do.
>
> I think Jasmine is alluding to the object search patch that's in progress :-)
>
Yes, I think so. On Tuesday, June 14, 2011, Jasmin Dizdarevic <jasmin.dizdarevic@gmail.com> wrote: > =) > BTW: > [...]The application may be used on Linux, FreeBSD, Solaris, Mac OSX and Windows platforms to manage PostgreSQL 7.3 andabove running on any platform[...] > > Is 7.3 really the current minimum version for pgAdmin 1.14 or 1.15? > Shouldn't the minimum version of pgAdmin reflect the minimum version supported/patched by PostgreSQL (currently 8.2.21)? > > 2011/6/14 Guillaume Lelarge <guillaume@lelarge.info> > > On Tue, 2011-06-14 at 22:00 +0100, Dave Page wrote: >> On Tuesday, June 14, 2011, Guillaume Lelarge <guillaume@lelarge.info> wrote: >> > On Tue, 2011-06-14 at 20:57 +0200, Jasmin Dizdarevic wrote: >> >> Excuse me? *g* >> >> >> > >> > Yeah, I don't think I'll have the time to work on new features now. Too >> > much other things to do. >> >> I think Jasmine is alluding to the object search patch that's in progress :-) >> > > Oops, sorry, forgot that patch. > > > -- > Guillaume > http://blog.guillaume.lelarge.info > http://www.dalibo.com > > > > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Let's play jeopardy:
Is 7.3 really the current minimum version for pgAdmin 1.14 or 1.15?
OR
Shouldn't the minimum version of pgAdmin reflect the minimum version supported/patched by PostgreSQL (currently 8.2.21)?
Shouldn't the minimum version of pgAdmin reflect the minimum version supported/patched by PostgreSQL (currently 8.2.21)?
Which question matches your answer?
2011/6/14 Dave Page <dpage@pgadmin.org>
Yes, I think so.
On Tuesday, June 14, 2011, Jasmin Dizdarevic<jasmin.dizdarevic@gmail.com> wrote:
> =)
> BTW:
> [...]The application may be used on Linux, FreeBSD, Solaris, Mac OSX and Windows platforms to manage PostgreSQL 7.3 and above running on any platform[...]
>
> Is 7.3 really the current minimum version for pgAdmin 1.14 or 1.15?
> Shouldn't the minimum version of pgAdmin reflect the minimum version supported/patched by PostgreSQL (currently 8.2.21)?
>
> 2011/6/14 Guillaume Lelarge <guillaume@lelarge.info>
>
> On Tue, 2011-06-14 at 22:00 +0100, Dave Page wrote:
>> On Tuesday, June 14, 2011, Guillaume Lelarge <guillaume@lelarge.info> wrote:
>> > On Tue, 2011-06-14 at 20:57 +0200, Jasmin Dizdarevic wrote:
>> >> Excuse me? *g*
>> >>
>> >
>> > Yeah, I don't think I'll have the time to work on new features now. Too
>> > much other things to do.
>>
>> I think Jasmine is alluding to the object search patch that's in progress :-)
>>
>
> Oops, sorry, forgot that patch.
>
>
> --
> Guillaume
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com
>
>
>
>--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
The one about the versions :-p Seriously though, no, we don't support 7.3 - iirc we agreed to drop that a few years back. I'm fine with un-supporting 8.0 and 8.1 too. On Tuesday, June 14, 2011, Jasmin Dizdarevic <jasmin.dizdarevic@gmail.com> wrote: > Let's play jeopardy: > Is 7.3 really the current minimum version for pgAdmin 1.14 or 1.15? > > OR > > Shouldn't the minimum version of pgAdmin reflect the minimum version supported/patched by PostgreSQL (currently 8.2.21)? > > Which question matches your answer? > > 2011/6/14 Dave Page <dpage@pgadmin.org> > Yes, I think so. > > On Tuesday, June 14, 2011, Jasmin Dizdarevic > <jasmin.dizdarevic@gmail.com> wrote: >> =) >> BTW: >> [...]The application may be used on Linux, FreeBSD, Solaris, Mac OSX and Windows platforms to manage PostgreSQL 7.3 andabove running on any platform[...] >> >> Is 7.3 really the current minimum version for pgAdmin 1.14 or 1.15? >> Shouldn't the minimum version of pgAdmin reflect the minimum version supported/patched by PostgreSQL (currently 8.2.21)? >> >> 2011/6/14 Guillaume Lelarge <guillaume@lelarge.info> >> >> On Tue, 2011-06-14 at 22:00 +0100, Dave Page wrote: >>> On Tuesday, June 14, 2011, Guillaume Lelarge <guillaume@lelarge.info> wrote: >>> > On Tue, 2011-06-14 at 20:57 +0200, Jasmin Dizdarevic wrote: >>> >> Excuse me? *g* >>> >> >>> > >>> > Yeah, I don't think I'll have the time to work on new features now. Too >>> > much other things to do. >>> >>> I think Jasmine is alluding to the object search patch that's in progress :-) >>> >> >> Oops, sorry, forgot that patch. >> >> >> -- >> Guillaume >> http://blog.guillaume.lelarge.info >> http://www.dalibo.com >> >> >> >> > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
I absolutely agree. In this case, I think, we should remove old compatibility checks in the code from time to time. I was shocked when I saw BackendMinimumVersion(7,3) - I thought that I have to check the search-feature against 7.3 *g*
2011/6/15 Dave Page <dpage@pgadmin.org>
The one about the versions :-p
Seriously though, no, we don't support 7.3 - iirc we agreed to drop
that a few years back. I'm fine with un-supporting 8.0 and 8.1 too.--
On Tuesday, June 14, 2011, Jasmin Dizdarevic
<jasmin.dizdarevic@gmail.com> wrote:
> Let's play jeopardy:
> Is 7.3 really the current minimum version for pgAdmin 1.14 or 1.15?
>
> OR
>
> Shouldn't the minimum version of pgAdmin reflect the minimum version supported/patched by PostgreSQL (currently 8.2.21)?
>
> Which question matches your answer?
>
> 2011/6/14 Dave Page <dpage@pgadmin.org>
> Yes, I think so.
>
> On Tuesday, June 14, 2011, Jasmin Dizdarevic
> <jasmin.dizdarevic@gmail.com> wrote:
>> =)
>> BTW:
>> [...]The application may be used on Linux, FreeBSD, Solaris, Mac OSX and Windows platforms to manage PostgreSQL 7.3 and above running on any platform[...]
>>
>> Is 7.3 really the current minimum version for pgAdmin 1.14 or 1.15?
>> Shouldn't the minimum version of pgAdmin reflect the minimum version supported/patched by PostgreSQL (currently 8.2.21)?
>>
>> 2011/6/14 Guillaume Lelarge <guillaume@lelarge.info>
>>
>> On Tue, 2011-06-14 at 22:00 +0100, Dave Page wrote:
>>> On Tuesday, June 14, 2011, Guillaume Lelarge <guillaume@lelarge.info> wrote:
>>> > On Tue, 2011-06-14 at 20:57 +0200, Jasmin Dizdarevic wrote:
>>> >> Excuse me? *g*
>>> >>
>>> >
>>> > Yeah, I don't think I'll have the time to work on new features now. Too
>>> > much other things to do.
>>>
>>> I think Jasmine is alluding to the object search patch that's in progress :-)
>>>
>>
>> Oops, sorry, forgot that patch.
>>
>>
>> --
>> Guillaume
>> http://blog.guillaume.lelarge.info
>> http://www.dalibo.com
>>
>>
>>
>>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
>Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
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. On Tuesday, June 14, 2011, Jasmin Dizdarevic <jasmin.dizdarevic@gmail.com> wrote: > I absolutely agree. In this case, I think, we should remove old compatibility checks in the code from time to time. I wasshocked when I saw BackendMinimumVersion(7,3) - I thought that I have to check the search-feature against 7.3 *g* > > 2011/6/15 Dave Page <dpage@pgadmin.org> > > The one about the versions :-p > > Seriously though, no, we don't support 7.3 - iirc we agreed to drop > that a few years back. I'm fine with un-supporting 8.0 and 8.1 too. > > On Tuesday, June 14, 2011, Jasmin Dizdarevic > <jasmin.dizdarevic@gmail.com> wrote: >> Let's play jeopardy: >> Is 7.3 really the current minimum version for pgAdmin 1.14 or 1.15? >> >> OR >> >> Shouldn't the minimum version of pgAdmin reflect the minimum version supported/patched by PostgreSQL (currently 8.2.21)? >> >> Which question matches your answer? >> >> 2011/6/14 Dave Page <dpage@pgadmin.org> >> Yes, I think so. >> >> On Tuesday, June 14, 2011, Jasmin Dizdarevic >> <jasmin.dizdarevic@gmail.com> wrote: >>> =) >>> BTW: >>> [...]The application may be used on Linux, FreeBSD, Solaris, Mac OSX and Windows platforms to manage PostgreSQL 7.3 andabove running on any platform[...] >>> >>> Is 7.3 really the current minimum version for pgAdmin 1.14 or 1.15? >>> Shouldn't the minimum version of pgAdmin reflect the minimum version supported/patched by PostgreSQL (currently 8.2.21)? >>> >>> 2011/6/14 Guillaume Lelarge <guillaume@lelarge.info> >>> >>> On Tue, 2011-06-14 at 22:00 +0100, Dave Page wrote: >>>> On Tuesday, June 14, 2011, Guillaume Lelarge <guillaume@lelarge.info> wrote: >>>> > On Tue, 2011-06-14 at 20:57 +0200, Jasmin Dizdarevic wrote: >>>> >> Excuse me? *g* >>>> >> >>>> > >>>> > Yeah, I don't think I'll have the time to work on new features now. Too >>>> > much other things to do. >>>> >>>> I think Jasmine is alluding to the object search patch that's in progress :-) >>>> >>> >>> Oops, sorry, forgot that patch. >>> >>> >>> -- >>> Guillaume >>> http://blog.guillaume.lelarge.info >>> http://www.dalibo.com >>> >>> >>> >>> >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> >> >> > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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 http://blog.guillaume.lelarge.info http://www.dalibo.com
currently there are 10 versions of pgadmin for download (http://pgadmin.org/download/windows.php) 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 ta.oid=cls.reltablespace\n");
}
}
else
{
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 pn.oid=pr.pronamespace\n");
}
query = wxT("SELECT DISTINCT ON(cls.relname) cls.oid, cls.relname as idxname, indrelid, indkey, indisclustered, indisunique, indisprimary, n.nspname,\n")
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 description,\n")
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@lelarge.info>
On Tue, 2011-06-14 at 23:41 +0100, Dave Page wrote:I don't see why we should remove old code that still works. That we say
> 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.
>
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").
--
On Wed, 2011-06-15 at 08:34 +0200, Jasmin Dizdarevic wrote: > currently there are 10 versions of pgadmin for download > (http://pgadmin.org/download/windows.php) 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? > Because we don't fix bugs in older releases? and so, anyone not using the current stable release is almost sure to find bugs in it. You can't say to a user: "You've bumped into a bug? get the latest stable release... oh, wait, you're on 8.0, right? too bad, you're screwed." People don't like to manage old releases of PostgreSQL. They mostly don't have the choice. Sorry, still -1. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Wed, Jun 15, 2011 at 6:57 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > 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. Well we don't actually know that it does still work, as we haven't tested it. I regularly find myself refactoring code for old versions of Postgres because I need to add support for a new version, and if it's something old like 7.3, it doesn't get tested. Plus it make the code less readable, and harder to maintain. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, 2011-06-15 at 08:14 +0100, Dave Page wrote: > On Wed, Jun 15, 2011 at 6:57 AM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > > 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. > > Well we don't actually know that it does still work, as we haven't > tested it. I regularly find myself refactoring code for old versions > of Postgres because I need to add support for a new version, and if > it's something old like 7.3, it doesn't get tested. > No bug report doesn't mean no bug, but it also means no user pissed. And when I add new code, I try to check with older releases. Not all of them, but some. For example when I added 9.1 new features, I tried with 9.0 to see if my refactoring had an impact on 9.0. But I didn't check all the way to 7.3. And sometimes I even forgot testing on 9.0 (Jasmin reported some 9.0 bugs, due to 9.1 new features I coded). > Plus it make the code less readable, and harder to maintain. > Sure, I can't deny that. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
You're right. Patching very old releases will become more difficult. But those patches are rare and most of the time not very large, so the merge should not be a big problem.
Either one actual version of pgAdmin which supports everything back to 7.3. or different versions which targets different postgresql releases. Currently we have a hybrid - that's not very good, I think.
2011/6/15 Guillaume Lelarge <guillaume@lelarge.info>
On Wed, 2011-06-15 at 08:14 +0100, Dave Page wrote:No bug report doesn't mean no bug, but it also means no user pissed.
> On Wed, Jun 15, 2011 at 6:57 AM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
> > 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.
>
> Well we don't actually know that it does still work, as we haven't
> tested it. I regularly find myself refactoring code for old versions
> of Postgres because I need to add support for a new version, and if
> it's something old like 7.3, it doesn't get tested.
>
And when I add new code, I try to check with older releases. Not all of
them, but some. For example when I added 9.1 new features, I tried with
9.0 to see if my refactoring had an impact on 9.0. But I didn't check
all the way to 7.3. And sometimes I even forgot testing on 9.0 (Jasmin
reported some 9.0 bugs, due to 9.1 new features I coded).Sure, I can't deny that.
> Plus it make the code less readable, and harder to maintain.
>
On Wed, 2011-06-15 at 10:00 +0200, Jasmin Dizdarevic wrote: > You're right. Patching very old releases will become more difficult. > But those patches are rare and most of the time not very large, so the > merge should not be a big problem. I'm not sure I understand. Do you mean that users will have to backpatch some bugfixes and compile an old pgAdmin to be able to use old PostgreSQL releases? I sincerely hope you don't mean that. > Either one actual version of pgAdmin which supports everything back to > 7.3. or different versions which targets different postgresql > releases. Currently we have a hybrid - that's not very good, I think. We don't have both. We currently have a pgAdmin which supports everything back to 7.3. And you cannot say otherwise, unless you know some bugs you didn't report. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Wed, Jun 15, 2011 at 10:09 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > We don't have both. We currently have a pgAdmin which supports > everything back to 7.3. No we don't. We have a pgAdmin, which it says on the website supports back to 7.3. I know I haven't run anything older than 8.0 for *years*, and certainly the QA guys at EDB don't. I don't believe Erwin does either. Therefore I don't believe we can honestly say we support back to 7.3. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Jun 15, 2011 at 11:57, Dave Page <dpage@pgadmin.org> wrote: > On Wed, Jun 15, 2011 at 10:09 AM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> We don't have both. We currently have a pgAdmin which supports >> everything back to 7.3. > > No we don't. We have a pgAdmin, which it says on the website supports > back to 7.3. I know I haven't run anything older than 8.0 for *years*, > and certainly the QA guys at EDB don't. I don't believe Erwin does > either. Therefore I don't believe we can honestly say we support back > to 7.3. Didn't we at some point say it's reasonable to support as far back as the pg community support postgresql, which would mean 8.2 at this point? As long as we keep the downloads for the older versions around, people who are running an unsupported version of postgresql should be ok running an unsupported version of pgadmin,no? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Wed, Jun 15, 2011 at 11:03 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Wed, Jun 15, 2011 at 11:57, Dave Page <dpage@pgadmin.org> wrote:
>> On Wed, Jun 15, 2011 at 10:09 AM, Guillaume Lelarge
>> <guillaume@lelarge.info> wrote:
>>> We don't have both. We currently have a pgAdmin which supports
>>> everything back to 7.3.
>>
>> No we don't. We have a pgAdmin, which it says on the website supports
>> back to 7.3. I know I haven't run anything older than 8.0 for *years*,
>> and certainly the QA guys at EDB don't. I don't believe Erwin does
>> either. Therefore I don't believe we can honestly say we support back
>> to 7.3.
>
> Didn't we at some point say it's reasonable to support as far back as
> the pg community support postgresql, which would mean 8.2 at this
> point?
Yes, I'm pretty sure we did. And in fact, from pgAdmin3.h:
// Supported server minimum and maximum values.
const short SERVER_MIN_VERSION_N = 0x0802;
const wxString SERVER_MIN_VERSION_T = wxT("8.2");
const short SERVER_MAX_VERSION_N = 0x0901;
const wxString SERVER_MAX_VERSION_T = wxT("9.1");
> As long as we keep the downloads for the older versions around, people
> who are running an unsupported version of postgresql should be ok
> running an unsupported version of pgadmin,no?
Right.
I think what Guillaume is suggesting though is not that we keep saying
7.3 is supported, but that we don't remove code that's there to
support older versions than we don't currently support. On the other
hand, I'm saying we're not actively doing that, but if someone wants
to do so, or if we want to simplify things when working on a
particular piece of code, then removing the support for older versions
is acceptable.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
2011/6/15 Guillaume Lelarge <guillaume@lelarge.info>
On Wed, 2011-06-15 at 10:00 +0200, Jasmin Dizdarevic wrote:
> You're right. Patching very old releases will become more difficult.
> But those patches are rare and most of the time not very large, so the
> merge should not be a big problem.I'm not sure I understand. Do you mean that users will have to backpatch
some bugfixes and compile an old pgAdmin to be able to use old
PostgreSQL releases? I sincerely hope you don't mean that.
No, of course. I wanted to say, that if we change the current code to much, patching older versions with patches developed with the current head would become more complicated - because there will probably be more conflicts and so on.
> Either one actual version of pgAdmin which supports everything back to
> 7.3. or different versions which targets different postgresql
> releases. Currently we have a hybrid - that's not very good, I think.We don't have both. We currently have a pgAdmin which supports
everything back to 7.3. And you cannot say otherwise, unless you know
some bugs you didn't report.
You don't like the idea to remove the old code from pgAdmin, but we have older versions which are designed to work with older version of postgresql. If there are any poor souls working with < 8.2, in my opinion they should also use an older pgAdmin client - Dave described it in a later mail: they must! So removing the old code wouldn't be so bad and it wouldn't break any functionality.
I'm saying we're not actively doing that, but if someone wants
to do so, or if we want to simplify things when working on a
particular piece of code, then removing the support for older versions
is acceptable.
I agree to Dave's idea.
--
On Wed, 2011-06-15 at 11:11 +0100, Dave Page wrote:
> On Wed, Jun 15, 2011 at 11:03 AM, Magnus Hagander <magnus@hagander.net> wrote:
> > On Wed, Jun 15, 2011 at 11:57, Dave Page <dpage@pgadmin.org> wrote:
> >> On Wed, Jun 15, 2011 at 10:09 AM, Guillaume Lelarge
> >> <guillaume@lelarge.info> wrote:
> >>> We don't have both. We currently have a pgAdmin which supports
> >>> everything back to 7.3.
> >>
> >> No we don't. We have a pgAdmin, which it says on the website supports
> >> back to 7.3. I know I haven't run anything older than 8.0 for *years*,
> >> and certainly the QA guys at EDB don't. I don't believe Erwin does
> >> either. Therefore I don't believe we can honestly say we support back
> >> to 7.3.
> >
> > Didn't we at some point say it's reasonable to support as far back as
> > the pg community support postgresql, which would mean 8.2 at this
> > point?
>
> Yes, I'm pretty sure we did. And in fact, from pgAdmin3.h:
>
> // Supported server minimum and maximum values.
> const short SERVER_MIN_VERSION_N = 0x0802;
> const wxString SERVER_MIN_VERSION_T = wxT("8.2");
> const short SERVER_MAX_VERSION_N = 0x0901;
> const wxString SERVER_MAX_VERSION_T = wxT("9.1");
>
Yes, and I'm OK with this.
> > As long as we keep the downloads for the older versions around, people
> > who are running an unsupported version of postgresql should be ok
> > running an unsupported version of pgadmin,no?
>
> Right.
>
> I think what Guillaume is suggesting though is not that we keep saying
> 7.3 is supported, but that we don't remove code that's there to
> support older versions than we don't currently support.
Exactly my point.
> On the other
> hand, I'm saying we're not actively doing that, but if someone wants
> to do so, or if we want to simplify things when working on a
> particular piece of code, then removing the support for older versions
> is acceptable.
>
OK, let's put it another way. I don't support removing old code whose
only fault is to support older, even unsupported, PostgreSQL release. I
won't do any review of a patch whose sole purpose is to drop some code
that was interesting for support of old releases. And I won't
commit/push them.
--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com
On Wed, Jun 15, 2011 at 13:01, Guillaume Lelarge <guillaume@lelarge.info> wrote: > On Wed, 2011-06-15 at 11:11 +0100, Dave Page wrote: >> On Wed, Jun 15, 2011 at 11:03 AM, Magnus Hagander <magnus@hagander.net> wrote: >> On the other >> hand, I'm saying we're not actively doing that, but if someone wants >> to do so, or if we want to simplify things when working on a >> particular piece of code, then removing the support for older versions >> is acceptable. >> > > OK, let's put it another way. I don't support removing old code whose > only fault is to support older, even unsupported, PostgreSQL release. I > won't do any review of a patch whose sole purpose is to drop some code > that was interesting for support of old releases. And I won't > commit/push them. FWIW, I *am* in support of this, since the old branches and releases are still around for those people. For the sake of making the code easier to maintain. But since I'm not one of the biggest code contributors, I will happily defer judgement to those of you that are. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Jun 15, 11:57 am, dp...@pgadmin.org (Dave Page) wrote: > On Wed, Jun 15, 2011 at 10:09 AM, Guillaume Lelarge > > <guilla...@lelarge.info> wrote: > > We don't have both. We currently have a pgAdmin which supports > > everything back to 7.3. > > No we don't. We have a pgAdmin, which it says on the website supports > back to 7.3. I know I haven't run anything older than 8.0 for *years*, > and certainly the QA guys at EDB don't. I don't believe Erwin does > either. Therefore I don't believe we can honestly say we support back > to 7.3. My last contact with a pg < 8.2 is a couple of years back now. So, no, I don't test those older versions. After reading the thread, I would vote for something like this: - Officially support (and actively care for) versions that pg officially supports at release time. - That doesn't mean we have to actively rip out older stuff as long as it doesn't cause pain. - IF older stuff is cause for complications, remove it. - Communicate the policy to our users. Hint towards older versions for older versions of pg. Maybe even a little table with matching version numbers? Add something like this at http://pgadmin.org/index.php and http://pgadmin.org/docs "pgAdmin officially supports all officially supported versions of PostgreSQL at release time. Older versions of the database should mostly work, too. If you run into problems with an outdated version of PostgreSQL you may want try an older version of pgAdmin." Regards Erwin