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 &&
>
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 t
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
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 ver
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_c
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
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
* 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 addi
2013/2/1 Pavel Stehule :
> 2013/2/1 Tom Lane :
>> Andrew Dunstan 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 tw
2013/2/1 Tom Lane :
> Andrew Dunstan 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 entire
2013/2/1 Andrew Dunstan :
>
> On 02/01/2013 10:38 AM, Tom Lane wrote:
>>
>> Andrew Dunstan 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
Andrew Dunstan 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 l
On 02/01/2013 10:38 AM, Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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
14 matches
Mail list logo
