Обсуждение: 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