On Fri, Jul 3, 2009 at 3:15 PM, Andrew Chernow<a...@esilo.com> wrote: >> 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. :-) >> > > Wasn't aware of exately what you were doing. It sounded like multiple > things were in the query_string. If its already a single key, than there is > no need to use a different key. And no, I don't like remebering URLs ... > thus all the fuss about breaking bookmarks ;-)
Right. The current system has exactly ZERO chance of breaking any bookmarks, and all of the proposed alternatives are much more likely to do so. >>>>> 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. >>> >>> 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. > > Using a URL to encode when something occurred was being offered as a > solution to know what commitfest it is. I'm not sure where your confusion > is? The suggestion was to encode the start date of the CommitFest in the URL, instead of using a non-natural key. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
