Re: [pgsql-www] commitfest.postgresql.org
От | Robert Haas |
---|---|
Тема | Re: [pgsql-www] commitfest.postgresql.org |
Дата | |
Msg-id | 603c8f070907031203n67770c9aq5df4bda3c4a05c79@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [pgsql-www] commitfest.postgresql.org (Andrew Chernow <ac@esilo.com>) |
Ответы |
Re: [pgsql-www] commitfest.postgresql.org
|
Список | pgsql-hackers |
On Fri, Jul 3, 2009 at 3:00 PM, Andrew Chernow<ac@esilo.com> wrote: >>>>> The current URL seems to be >>>>> http://commitfest.postgresql.org/action/commitfest_view?id=2 >>>>> which is both opaque as can be and not looking like it's intended to >>>>> be stable over the long term. >>>> >>>> I'm not sure why you would think that it's not stable. >>> >>> Because it's exposing three or four details of your implementation, >>> which you might wish to change later. >>> >>>> I'm also not sure what you would think that it's not self-explanatory, >>>> since it looks pretty self explanatory to me. >>> >>> It's impossible to know that this is commitfest 2009-07. >>> >> >> commitfest.postgresql.org/2009/07 ? >> >> That, or any similar scheme, seems easily doable with a little apache >> rewrite magic and some programming. See my blog urls for one such example. > > I believe Tom wants details removed from the URL, so future implementation > changes don't either a) break bookmarks because more stuff is needed in the > URL or b) don't break bookmarks but be limited to existing sutff in the URL > (ie. hacky work arounds). If that's the case, your best best is to use some > kind of key, like 16 random bytes displayed in hex, that looks up the data. I *am* using some kind of key. Specifically, in integer derived from a serial column. It's just as stable as 16 random bytes displayed in hex, but a lot shorter and easier to remember, if you're the sort of person who likes to remember URLs. :-) > IMHO, I don't see much gain to encoding the date into the url either. This > is not a great way of telling the user when something occurred. A lookup is > going to occur either way, so why not get all data at once using a single > method? Sorry, I'm not following this part. ...Robet
В списке pgsql-hackers по дате отправления: