Re: [HACKERS] obsolete code in pg_upgrade

[Bruce Momjian]

On Tue, Aug 22, 2017 at 08:28:15PM -0400, Peter Eisentraut wrote:
> It seems to me that this code in pg_upgrade/check.c has been useless
> since at least version 9.1:
> 
> /* Is it 9.0 but without tablespace directories? */
> if (GET_MAJOR_VERSION(new_cluster.major_version) == 900 &&
> new_cluster.controldata.cat_ver < TABLE_SPACE_SUBDIRS_CAT_VER)
> pg_fatal("This utility can only upgrade to PostgreSQL version
> 9.0 after 2010-01-11\n"
>  "because of backend API changes made during
> development.\n");

Coming in late, but agreed.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] obsolete code in pg_upgrade

[Peter Eisentraut]

On 8/25/17 04:00, Christoph Berg wrote:
> Re: Peter Eisentraut 2017-08-24 
> <8aa00f15-144e-e793-750e-d1d6876d6...@2ndquadrant.com>
>> On 8/23/17 09:36, Robert Haas wrote:
>>> I think I agree.  It seems to me that the version of pg_upgrade
>>> shipped with release N only needs to support upgrades to release N,
>>> not older releases.  There's probably room for debate about whether a
>>> pg_upgrade needs to support direct upgrades FROM very old releases,
>>> but we need not decide anything about that right now.
>>>
>>> I think you could go ahead and rip out this code, but as it seems like
>>> a non-critical change, -1 for back-patching it.
>>
>> committed to PG10 and master
> 
> This #define seems to be obsolete now as well:
> src/bin/pg_upgrade/pg_upgrade.h:#define TABLE_SPACE_SUBDIRS_CAT_VER 20100

fixed, thanks

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] obsolete code in pg_upgrade

[Christoph Berg]

Re: Peter Eisentraut 2017-08-24 
<8aa00f15-144e-e793-750e-d1d6876d6...@2ndquadrant.com>
> On 8/23/17 09:36, Robert Haas wrote:
> > I think I agree.  It seems to me that the version of pg_upgrade
> > shipped with release N only needs to support upgrades to release N,
> > not older releases.  There's probably room for debate about whether a
> > pg_upgrade needs to support direct upgrades FROM very old releases,
> > but we need not decide anything about that right now.
> > 
> > I think you could go ahead and rip out this code, but as it seems like
> > a non-critical change, -1 for back-patching it.
> 
> committed to PG10 and master

This #define seems to be obsolete now as well:
src/bin/pg_upgrade/pg_upgrade.h:#define TABLE_SPACE_SUBDIRS_CAT_VER 20100

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] obsolete code in pg_upgrade

[Peter Eisentraut]

On 8/23/17 09:36, Robert Haas wrote:
> I think I agree.  It seems to me that the version of pg_upgrade
> shipped with release N only needs to support upgrades to release N,
> not older releases.  There's probably room for debate about whether a
> pg_upgrade needs to support direct upgrades FROM very old releases,
> but we need not decide anything about that right now.
> 
> I think you could go ahead and rip out this code, but as it seems like
> a non-critical change, -1 for back-patching it.

committed to PG10 and master

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] obsolete code in pg_upgrade

[Robert Haas]

On Tue, Aug 22, 2017 at 8:28 PM, Peter Eisentraut
 wrote:
> It seems to me that this code in pg_upgrade/check.c has been useless
> since at least version 9.1:
>
> /* Is it 9.0 but without tablespace directories? */
> if (GET_MAJOR_VERSION(new_cluster.major_version) == 900 &&
> new_cluster.controldata.cat_ver < TABLE_SPACE_SUBDIRS_CAT_VER)
> pg_fatal("This utility can only upgrade to PostgreSQL version
> 9.0 after 2010-01-11\n"
>  "because of backend API changes made during
> development.\n");

I think I agree.  It seems to me that the version of pg_upgrade
shipped with release N only needs to support upgrades to release N,
not older releases.  There's probably room for debate about whether a
pg_upgrade needs to support direct upgrades FROM very old releases,
but we need not decide anything about that right now.

I think you could go ahead and rip out this code, but as it seems like
a non-critical change, -1 for back-patching it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] obsolete code in pg_upgrade

[Peter Eisentraut]

It seems to me that this code in pg_upgrade/check.c has been useless
since at least version 9.1:

/* Is it 9.0 but without tablespace directories? */
if (GET_MAJOR_VERSION(new_cluster.major_version) == 900 &&
new_cluster.controldata.cat_ver < TABLE_SPACE_SUBDIRS_CAT_VER)
pg_fatal("This utility can only upgrade to PostgreSQL version
9.0 after 2010-01-11\n"
 "because of backend API changes made during
development.\n");


-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] obsolete code

[Andrew Dunstan]

fmgr.c contains this:

   /*
 * !!! OLD INTERFACE !!!
 *
 * fmgr() is the only remaining vestige of the old-style caller support
 * functions.  It's no longer used anywhere in the Postgres
   distribution,
 * but we should leave it around for a release or two to ease the
   transition
 * for user-supplied C functions.  OidFunctionCallN() replaces it
   for new
 * code.
 *
 * DEPRECATED, DO NOT USE IN NEW CODE
 */

which git tells me dates from:

   48165ec2(  Tom Lane 2000-06-05 07:29:25 + 2080)


Should we just drop all support for the old interface now?

cheers

andrew


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] obsolete code

[Tom Lane]

Andrew Dunstan and...@dunslane.net writes:
 fmgr.c contains this:

   * DEPRECATED, DO NOT USE IN NEW CODE

 Should we just drop all support for the old interface now?

Is there any actual benefit to removing it?  I don't recall that
it's been the source of any maintenance burden.  I'd be fine with
dropping it if it were costing us something measurable, but ...

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] obsolete code

[Andrew Dunstan]

On 02/01/2013 10:38 AM, Tom Lane wrote:

Andrew Dunstan and...@dunslane.net writes:

fmgr.c contains this:
   * DEPRECATED, DO NOT USE IN NEW CODE
Should we just drop all support for the old interface now?

Is there any actual benefit to removing it?  I don't recall that
it's been the source of any maintenance burden.  I'd be fine with
dropping it if it were costing us something measurable, but ...





My hope was that if we got rid of the old stuff we wouldn't need to use

   PG_FUNCTION_INFO_V1(myfunc);



in external modules any more (I recently got bitten through forgetting 
this and it cost me an hour or two).


cheers

andrew



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] obsolete code

[Tom Lane]

Andrew Dunstan and...@dunslane.net writes:
 My hope was that if we got rid of the old stuff we wouldn't need to use
 PG_FUNCTION_INFO_V1(myfunc);
 in external modules any more (I recently got bitten through forgetting 
 this and it cost me an hour or two).

Oh.  Well, that's entirely unrelated to whether we leave fmgr() around.
fmgr() is the other end of the old call interface.

I'm not really thrilled with switching the default assumption to be V1,
especially not if we implement that by telling authors they can stop
bothering with the macros.  The pain will just come back sometime in the
future when we decide we need a function API V2.  (I'm actually a bit
surprised V1 has lived this long without changes.)

Here's a different straw-man proposal: let's start requiring *all*
external C functions to have an API-version block.  We can add a
PG_FUNCTION_INFO_V0(myfunc) macro for those people who are still using
V0 and don't feel like changing their code (and you know they're out
there).  For the rest of us, this would allow emitting an appropriate
error when we forget the macro.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] obsolete code

[Pavel Stehule]

2013/2/1 Andrew Dunstan and...@dunslane.net:

 On 02/01/2013 10:38 AM, Tom Lane wrote:

 Andrew Dunstan and...@dunslane.net writes:

 fmgr.c contains this:
* DEPRECATED, DO NOT USE IN NEW CODE
 Should we just drop all support for the old interface now?

 Is there any actual benefit to removing it?  I don't recall that
 it's been the source of any maintenance burden.  I'd be fine with
 dropping it if it were costing us something measurable, but ...





 My hope was that if we got rid of the old stuff we wouldn't need to use

PG_FUNCTION_INFO_V1(myfunc);


removing function descriptor should not be good idea - it can be used
for some annotation.

I had a similar issue - and can be nice, if it is solved with some assertions.

Regards

Pavel



 in external modules any more (I recently got bitten through forgetting this
 and it cost me an hour or two).

 cheers

 andrew




 --
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] obsolete code

[Pavel Stehule]

2013/2/1 Tom Lane t...@sss.pgh.pa.us:
 Andrew Dunstan and...@dunslane.net writes:
 My hope was that if we got rid of the old stuff we wouldn't need to use
 PG_FUNCTION_INFO_V1(myfunc);
 in external modules any more (I recently got bitten through forgetting
 this and it cost me an hour or two).

 Oh.  Well, that's entirely unrelated to whether we leave fmgr() around.
 fmgr() is the other end of the old call interface.

 I'm not really thrilled with switching the default assumption to be V1,
 especially not if we implement that by telling authors they can stop
 bothering with the macros.  The pain will just come back sometime in the
 future when we decide we need a function API V2.  (I'm actually a bit
 surprised V1 has lived this long without changes.)

 Here's a different straw-man proposal: let's start requiring *all*
 external C functions to have an API-version block.  We can add a
 PG_FUNCTION_INFO_V0(myfunc) macro for those people who are still using
 V0 and don't feel like changing their code (and you know they're out
 there).  For the rest of us, this would allow emitting an appropriate
 error when we forget the macro.

I like this idea,

Pavel


 regards, tom lane


 --
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] obsolete code

[Pavel Stehule]

2013/2/1 Pavel Stehule pavel.steh...@gmail.com:
 2013/2/1 Tom Lane t...@sss.pgh.pa.us:
 Andrew Dunstan and...@dunslane.net writes:
 My hope was that if we got rid of the old stuff we wouldn't need to use
 PG_FUNCTION_INFO_V1(myfunc);
 in external modules any more (I recently got bitten through forgetting
 this and it cost me an hour or two).

 Oh.  Well, that's entirely unrelated to whether we leave fmgr() around.
 fmgr() is the other end of the old call interface.

 I'm not really thrilled with switching the default assumption to be V1,
 especially not if we implement that by telling authors they can stop
 bothering with the macros.  The pain will just come back sometime in the
 future when we decide we need a function API V2.  (I'm actually a bit
 surprised V1 has lived this long without changes.)

 Here's a different straw-man proposal: let's start requiring *all*
 external C functions to have an API-version block.  We can add a
 PG_FUNCTION_INFO_V0(myfunc) macro for those people who are still using
 V0 and don't feel like changing their code (and you know they're out
 there).  For the rest of us, this would allow emitting an appropriate
 error when we forget the macro.

 I like this idea,


but some users uses V0 for glibc functions - it is probably ugly hack,
but it allows using external libraries - and should be possible still
use it

Regards

Pavel



 Pavel


 regards, tom lane


 --
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] obsolete code

[Stephen Frost]

* Pavel Stehule (pavel.steh...@gmail.com) wrote:
 but some users uses V0 for glibc functions - it is probably ugly hack,
 but it allows using external libraries - and should be possible still
 use it

No, I don't think we need or want to continue to support such an ugly,
ugly, hack.

+1 for adding a V0 and requiring it.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] obsolete code

[Andrew Dunstan]

On 02/01/2013 11:20 AM, Tom Lane wrote:


I'm not really thrilled with switching the default assumption to be V1,
especially not if we implement that by telling authors they can stop
bothering with the macros.  The pain will just come back sometime in the
future when we decide we need a function API V2.  (I'm actually a bit
surprised V1 has lived this long without changes.)

Here's a different straw-man proposal: let's start requiring *all*
external C functions to have an API-version block.  We can add a
PG_FUNCTION_INFO_V0(myfunc) macro for those people who are still using
V0 and don't feel like changing their code (and you know they're out
there).  For the rest of us, this would allow emitting an appropriate
error when we forget the macro.



Sounds like a good plan.

cheers

andrew


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] obsolete code

[Peter Eisentraut]

On 2/1/13 11:06 AM, Andrew Dunstan wrote:
 My hope was that if we got rid of the old stuff we wouldn't need to use
 
PG_FUNCTION_INFO_V1(myfunc);

 in external modules any more

My fear with that would be that people would start forgetting this and
modules won't work with older PG versions anymore.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers