Обсуждение: hstore extension version screwup

When adding json support to hstore, I made a major blunder and added the
new functionality to the existing sql script instead of bumping the
version, renaming the script and adding an update script.

This was lazy and there's no real excuse, although I will note that it
was a mistake far too easy to make. Perhaps as a warning indicator we
should remove write permissions from these files.

Anyway, I have had some discussions with Dimitri, and the best idea
seems to be that we should do all the above, but in the update script
use conditional logic that only adds the functions if they aren't
already there and dependent on the extension. In the release notes we
should advise anyone who has loaded hstore to run 'ALTER EXTENSION
hstore UPDATE TO '1.2';"

The minor downside of this is that the upgrade script will depend on
plpgsql be available. We'll need to note that too, although I don't
recall the last time I came across a site that didn't have it loaded.

See attached for details of what's proposed.

cheers

andrew

On Fri, 2013-09-27 at 13:23 -0400, Andrew Dunstan wrote:
> This was lazy and there's no real excuse, although I will note that it 
> was a mistake far too easy to make. Perhaps as a warning indicator we 
> should remove write permissions from these files.

What do you mean by that?

> See attached for details of what's proposed.

see broken builds on build farm

On 09/29/2013 09:58 PM, Peter Eisentraut wrote:
> On Fri, 2013-09-27 at 13:23 -0400, Andrew Dunstan wrote:
>> This was lazy and there's no real excuse, although I will note that it
>> was a mistake far too easy to make. Perhaps as a warning indicator we
>> should remove write permissions from these files.
> What do you mean by that?

Well if these are not meant to be changed then not being able to write 
them in your git repo might be a clue to that.

Just a thought.

>
>> See attached for details of what's proposed.
> see broken builds on build farm
>
>
>

Yeah, looks like I forgot about the make file. I did test this but with 
a manual install. Will fix.


cheers

andrew

On Sun, 2013-09-29 at 22:33 -0400, Andrew Dunstan wrote:
> Well if these are not meant to be changed then not being able to write 
> them in your git repo might be a clue to that.

Git doesn't support setting file permissions other than the executable
bit, so this is a nonstarter.

On 09/29/2013 10:38 PM, Peter Eisentraut wrote:
> On Sun, 2013-09-29 at 22:33 -0400, Andrew Dunstan wrote:
>> Well if these are not meant to be changed then not being able to write
>> them in your git repo might be a clue to that.
> Git doesn't support setting file permissions other than the executable
> bit, so this is a nonstarter.
>

Oh, didn't know that, I've certainly know other SCM systems that do.

cheers

andrew

On 9/29/13 9:41 PM, Andrew Dunstan wrote:
>
> On 09/29/2013 10:38 PM, Peter Eisentraut wrote:
>> On Sun, 2013-09-29 at 22:33 -0400, Andrew Dunstan wrote:
>>> Well if these are not meant to be changed then not being able to write
>>> them in your git repo might be a clue to that.
>> Git doesn't support setting file permissions other than the executable
>> bit, so this is a nonstarter.
>>
>
> Oh, didn't know that, I've certainly know other SCM systems that do.

We could potentially do it with git commit hooks, but the problem is that there's no way to force use of those on
clients(a huge deficiency in git, imho).
 

The best alternative I've been able to come up with is having hooks in a standard location in the repo and then there's
onefile that people would need to put into their home directory (under ~/.git I think) that would pull all of that
stuffin.
 
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net

On Wed, Oct 2, 2013 at 7:17 PM, Jim Nasby <jim@nasby.net> wrote:
> On 9/29/13 9:41 PM, Andrew Dunstan wrote:
>>
>>
>> On 09/29/2013 10:38 PM, Peter Eisentraut wrote:
>>>
>>> On Sun, 2013-09-29 at 22:33 -0400, Andrew Dunstan wrote:
>>>>
>>>> Well if these are not meant to be changed then not being able to write
>>>> them in your git repo might be a clue to that.
>>>
>>> Git doesn't support setting file permissions other than the executable
>>> bit, so this is a nonstarter.
>>>
>>
>> Oh, didn't know that, I've certainly know other SCM systems that do.
>
>
> We could potentially do it with git commit hooks, but the problem is that
> there's no way to force use of those on clients (a huge deficiency in git,
> imho).

We could also use git receive hooks, but those would be very hard to
override when you *do* need to modify the files (which you might
within a release).

What we could also do is just have the make all target, or the
configure script, (or something else a developer runs often) chmod the
file. It's not bulletproof in any way, but it would give a decent hint
in most cases.

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

On Wed, Oct 2, 2013 at 1:17 PM, Jim Nasby <jim@nasby.net> wrote:
> On 9/29/13 9:41 PM, Andrew Dunstan wrote:
>> On 09/29/2013 10:38 PM, Peter Eisentraut wrote:
>>>
>>> On Sun, 2013-09-29 at 22:33 -0400, Andrew Dunstan wrote:
>>>>
>>>> Well if these are not meant to be changed then not being able to write
>>>> them in your git repo might be a clue to that.
>>>
>>> Git doesn't support setting file permissions other than the executable
>>> bit, so this is a nonstarter.
>>>
>>
>> Oh, didn't know that, I've certainly know other SCM systems that do.
>
>
> We could potentially do it with git commit hooks, but the problem is that
> there's no way to force use of those on clients (a huge deficiency in git,
> imho).
>
> The best alternative I've been able to come up with is having hooks in a
> standard location in the repo and then there's one file that people would
> need to put into their home directory (under ~/.git I think) that would pull
> all of that stuff in.

ISTM that what we need here is less a git-hook and more of a
regression test, so that if you do the wrong thing, the buildfarm
turns exciting colors.  I'm not sure exactly how to write a regression
test for this, but I bet we can dream up something...

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

On 10/3/13 12:49 PM, Magnus Hagander wrote:
> We could also use git receive hooks, but those would be very hard to
> override when you*do*  need to modify the files (which you might
> within a release).

You can have the receive hook ignore the condition on existence of a file. It's kinda kludgey, but effective. Of course
youneed to remember to remove the override file when you're done overriding...
 
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net

Jim Nasby <jim@nasby.net> writes:
> On 10/3/13 12:49 PM, Magnus Hagander wrote:
>> We could also use git receive hooks, but those would be very hard to
>> override when you*do*  need to modify the files (which you might
>> within a release).

> You can have the receive hook ignore the condition on existence of a file. It's kinda kludgey, but effective. Of
courseyou need to remember to remove the override file when you're done overriding...
 

An important point here is that we don't want to lock down version m.n
of an extension *until it's shipped in a release*.  If we make several
changes in a given extension during a development cycle (some of them
possibly just bugfixes to a previous change), we don't want our tools
forcing us to treat each of those as an upgrade scenario.

This means that any restriction should only apply in the _STABLE branches,
not in master.  Not sure how to do that.
        regards, tom lane