Re: [HACKERS] Release note bloat is getting out of hand
searchable version of the release notes. Would be a wonderful thing if it happened. Segregating the content by version would help -- finding lots of notes about version 7 8 when I'm running 9.3/4 helps not at all. -- Steven Lembark 3646 Flora Pl Workhorse Computing St Louis, MO 63110 lemb...@wrkhors.com +1 888 359 3508 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Release note bloat is getting out of hand
-1. I find it very useful to be able to go back through all the release notes using grep, and have done so on multiple occasions. It sounds like this policy would make that harder, and I don't see what we get out of of it. It doesn't bother me that the SGML documentation of the release notes is big; disk space is cheap. Put the full release notes in a tarball on the website, distribute the relevant portions with the distro? A single wget ftp://foo/bar-current.tar.gz; will pull the whole thing for full history; through if you're grepping it having a set of files with version-speicific changes works equaly well. -- Steven Lembark 3646 Flora Pl Workhorse Computing St Louis, MO 63110 lemb...@wrkhors.com +1 888 359 3508 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Release note bloat is getting out of hand
Disk space isn't the only consideration here; if it were I'd not be concerned about this. Processing time is an issue, and so is distribution size, and so is the length of the manual if someone decides to print it on dead trees. I also live in fear of the day that we hit some hard-to- change internal limit in TeX. Personally, what I grep when I'm looking for historical info is git log output, which will certainly not be getting any shorter. Fifteen years ago distributing it all made sense: not everyone had access to get the doc's and they were manageable and didn't take too long to download at 9600Kb (N71...). Today most users will have direct internet access and the whole content is intimidating (let alone heavy if you try to print it); Searching the doc's actually becomes more difficult due to the sheer volume of matches from outdated packages. A majority of users these days will look up anything they need via Google (Duck, Y!...) rather than search the original content anyway: having it available via web actually makes it more searchable in that case. Left to my own devices I'd rather have the current major version locally for the rare times my connection is down when I have to restore a database and be able to search version-specific content via the net otherwise. -- Steven Lembark 3646 Flora Pl Workhorse Computing St Louis, MO 63110 lemb...@wrkhors.com +1 888 359 3508 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/pgSQL 2
On Mon, 1 Sep 2014 15:19:41 +0200 Joel Jacobson j...@trustly.com wrote: The fatal problems with Python3 and Perl6 was the inability to mix code between Python2/3 and Perl5/6. We don't have that problem with pl-languages in postgres, so please don't make that comparison, as it's incorrect. Actually Perl6 can include Perl5 code allows you to use v5.6 or use v6.0 to regulate how the code in any one block is compiled w/in the program. Even Perl 5 allows mixing blocks/modules with different version syntax w/in the same compiler. The mistake Python made was not allowing the Python 3 compiler to gracefully handle Pythin 2 input. -- Steven Lembark 3646 Flora Pl Workhorse Computing St Louis, MO 63110 lemb...@wrkhors.com +1 888 359 3508 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DDL Damage Assessment
EXPLAIN ALTER TABLE ? Good thing: People recognize it. Bad thing: People might not be able to tell the difference between a DDL and DML result. What about EXPLAIN DDL ...? The extra keyword (DDL) makes it a bit more explicit that the results are not comparable to the standard explain output. -- Steven Lembark 3646 Flora Pl Workhorse Computing St Louis, MO 63110 lemb...@wrkhors.com +1 888 359 3508 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/pgSQL 2
On Mon, 01 Sep 2014 12:00:48 +0200 Marko Tiikkaja ma...@joh.to wrote: create a new language. There are enough problems with SQL in general, enough alternatives proposed over time that it might be worth coming up with something that Just Works. -- Steven Lembark 3646 Flora Pl Workhorse Computing St Louis, MO 63110 lemb...@wrkhors.com +1 888 359 3508 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/pgSQL 2
Python2 - Python3 would've been a lot less painful if you could mark, on a module-by-module basis, whether a module was python2 or python3 code. It wasn't very practical for Python because python code can reach deep into the guts of unrelated objects discovered at runtime - it can add/replace member functions, even hot-patch bytecode. That's not something we allow in PL/PgSQL, though; from the outside a PL/PgSQL function is pretty opaque to callers. Perl does this with use version. Currently this guarantees that the compiler is a minimum version and also turns OFF later version's keywords. At that point someone could turn on/off the appropriate syntax with by module or code block. If you never turn on v2.0 you never get the new behavior; after that people can adjust the amount and location of later code to their own taste. -- Steven Lembark 3646 Flora Pl Workhorse Computing St Louis, MO 63110 lemb...@wrkhors.com +1 888 359 3508 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] Mentors needed urgently for SoC PostgreSQL Student Internships
Note that since the Internships are not required to be project code, we can also take student projects to contribute to our WWW infrastructure and other areas the project needs some work. Would introducing a Duration (i.e., time-series a'la Date, et al)) data type be considered useful? I'd be happy to mentor someone doing it instead of having to write the entire thing myself. -- Steven Lembark85-09 90th St. Workhorse Computing Woodhaven, NY, 11421 lemb...@wrkhors.com +1 888 359 3508 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] What in the world is happening on spoonbill?
Are we in the business of excluding text-based browsers? Or obsolete ones, for that matter? I don't think we would want to be in the business of dealing successfully with every quirk of every browser ever released. Another way to look at it is supporting standards: If graphical browsers support at least HTML and CSS, maybe ecmascript, then they are supportable. If text based ones can handle the necessary alt tags then we can also support them. Beyond that, do you really want to document and code around every quirk in MSIE 1.0, Netscape 0.50, or any of the now-extinct text-based browsers for MSDOS? -- Steven Lembark85-09 90th St. Workhorse Computing Woodhaven, NY, 11421 [EMAIL PROTECTED] +1 888 359 3508 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
