There, all caught up on the email. I think I set a new record for many-emails-in-short-time to the lists earlier today, when I did the second pass through all email I saved and actually did something about it.
Seems Tom fixed most of the issues that turned up while I was gone already, but there are a couple of fairly minor win32 issues sitting there waiting for me. I hope to get the time in to work on a couple of small patches for those over the next couple of days. Then back to finishing off the Win32 VC build thingie, which apparantly didn't draw a single comment while I was gone...
and that's PostgreSQL related only. Yes, I'm back from my vacation. If you're expecting a response from me, and you see me answering other people but not you, just be patient for a while. This will take some time...
That said, vacation was great, now back to some serious postgresqling. And I guess regular work as well.
I have posted a first "almost complete" version of the vc build system to -patches. Those interested in building pg (everything, not just the client) with Visual C++ 2005 should check it out, and let me know of any issues.
For details, see -patches. Super-quick summary: VC++ patch will allow us to properly integrate with windows debuggers, profilers and such tools. And it will take away the dependency on mingw/msys to build. Hopefully, it will also be a nice path towards Win64 support.
And for those who're worried - no, mingw support is definitly not going away.
Along with this, I've also posted an initial port of pg_regress to C, which will be required to run the regression tests without mingw/msys. Feel free to check that one out as well...
Back home in Sweden, after a fairly uneventful trip and much faster than last time (one reason would be that this trip didn't include a stopover in San Francisco). Other than a long delayed connection flight in Philadelphia (isn't it just so much fun to hang around an airport for incremental values of "now delayed another 15 minutes"?), nothing bad. Interestingly enough, most of the delay was actually caught up before we arrived in Stockholm... I guess the wind-gods were on our side today.
Anyway. Post-conference code-sprint summary. I'll start by saying this was a brilliant idea - IMO it worked out really well. However, I'm not so sure I'd call it a codesprint. I had the vision of 30 guys tapping away like madmen on their keyboards trying to flood Bruce and Tom with as many patches as possible during two days, and that's not really what happened. Instead, there were plenty of time set aside for group discussions on separate topics (replications, dtrace etc), and the most important thing was the ability to talk to people before and around the coding. Tom, Bruce and other major coders were available all the time for questions and discussions about how to do things, which really helped. Writing the actual code can be done alone - especially with the good preparation you got here.
So. Maybe not a sprint, but still a very good "team-distance-running" or something. We've seen a few patches already come in, and I'd expect more over the next couple of weeks as people finish up the final parts when they get home.
For those interested, I spent most of the code time working on some of the final touches to the Visual C++ build system (thanks to David Fetter for helping me make my perl code actually look like proper perl), and also did some first stumbling steps on porting pg_regress to C. I definitly hope to have the VC++ stuff done in time for feature freeze, unfortunatly I'm not sure I'll have the time for pg_regress.
I read somewhere that real bloggers would always blog during a conference, preferrably getting at least one post in for each talk. Well, I'm not going to do that, but hey, here's at least one.
Very good day so far. Intro by Bruce talking about how things started. The PL/pgsql debugger presented by Korry (EnterpriseDB) looks really good. Plenty of interesting lightning-talks. And right now in the longest talk of the whole conference - "Introduction to Hacking PostgreSQL Workshop" with Neil Conway and Gavin Sherry (see picture). Given that I need to actually listen to that in order to understand it, this post took a while to write, so I'm just going to focus on listening now..
(apologies for bad quality image. That's what you get for forgetting your CF reader leading to the usage of a bad cellphone camera instead.. Better ones later, hopefully.)
The conference has pretty much kicked off, with the EnterpriseDB dinner cruise. Loads of interesting people to talk to... So far, this is shaping up to be a very good conference. Now let's see how it is tomorrow when the actual talks start - but my hopes are high, and I fully expect them to be fulfilled...
PostgreSQL documentation is in DocBook format. In my experience, this is far from trivial to get working on any platform where it isn't installed by the default packages - and even worse if it's installed by default but in the wrong version.
Turns out on Windows it's both better and worse - it's definitly harder than a pre-installed system, but a lot easier than one with the wrong version installed. Here are some step-by-step instructions for how to do it in a way that uses only pre-made binary packages of the required tools. It's a manual build not integrated with the pg Makefile, but it's a start... First of all, decide on a root for the docbook installation. In my case, I chose f:\docbook. Download and uncompress the following files:
With this done, some files in the docbook directory need renaming. Create a .bat file named r.bat (or whatever, really) in the docbook\docbook directory that looks like this:
@echo off
for %25%25f in (ISO*) do (
set foo=%25%25f
ren !foo! !foo:~0,3!-!foo:~3!.gml
)
And execute this file using:
cmd /v /c r.bat
That done, step into your PostgreSQL installation tree in doc\src\sgml. Run the following commands (beware of linebreaks!):
set SGML_CATALOG_FILES=f:\docbook\openjade-1.3.1\dsssl\catalog;f:\docbook\docbook\docbook.cat
perl f:\docbook\docbook-dsssl-1.79\bin\collateindex.pl -f -g -o bookindex.sgml -N
perl mk_feature_tables.pl YES ..\..\..\src\backend\catalog\sql_feature_packages.txt ..\..\..\src\backend\catalog\sql_features.txt > features-supported.sgml
perl mk_feature_tables.pl NO ..\..\..\src\backend\catalog\sql_feature_packages.txt ..\..\..\src\backend\catalog\sql_features.txt > features-unsupported.sgml
f:\docbook\openjade-1.3.1\bin\openjade -V draft-mode -wall -wno-unused-param -wno-empty -D . -c f:\docbook\docbook-dsssl-1.79\catalog -d stylesheet.dsl -i output-html -t sgml postgres.sgml
perl f:\docbook\docbook-dsssl-1.79\bin\collateindex.pl -f -g -i 'bookindex' -o bookindex.sgml HTML.index
f:\docbook\openjade-1.3.1\bin\openjade -V draft-mode -wall -wno-unused-param -wno-empty -D . -c f:\docbook\docbook-dsssl-1.79\catalog -d stylesheet.dsl -i output-html -t sgml postgres.sgml
Yes, it runs the build twice. That's to generate the indexes. If you have changed your docs, you usually don't need to re-run that part - just run the final openjade call over and over again.
This is all run outside of msys, with no requirements at all on either mingw or cygwin.
Not been doing too much PostgreSQL related stuff lately (thus no blog posts). Couple of reasons - lots to do at work before summer, and since it's now sailing season no (or at least a lot less) PostgreSQL in the weekends.
Quick status report on my current pg work: The win32-build-with-visual-c++ initial code patch has been applied. Still to do is a couple of minor things (there's a tiny patch for pl/perl for example), and then the actual build scripts. The build scripts work, but they are not cleaned up all the way yet. I also need to finish porting over things like gen_fmgroids that will be needed to be able to build from CVS.
Finally, I need to do something around the regression tests. Haven't decided yet if it might be easiest to just run the regression tests under msys against a VC++ built backend, or if I need to get them running outside it yet. And it does have to integrate with the buildfarm some way or other... (Currently running parts from msys and parts outside, and the backend does pass all the regression tests, but it's not trivial to run them)
But hopefully it'll all be worth it - we'd finally get things like proper debugger support on Windows! (And faster buildtimes, and judging by the results of other projects slightly better actual performance as well)
Right now I'm not particularly disappointed that I didn't get a slot at the conference, consdering that'd give me an even tighter schedule right now. Now I get to just listen and pick on others ;-)
And finally, happy midsummer to all those who celebrate it - and of course to those that don't as well.
Unix has readline. Or libedit. At least most of the time. Win32 has a much less capable commandline editor, but at least it has something. Unfortunatly, it's not something most people know about. There are a couple of nice features there that will help you out if you like using the commandline to work with your database. It does have the basic commandline editing and history functions, and also some (reasonably simple) macro handling.
First one of the main limitations - settings and data aren't persisted across sessions. Actually, they do survive a psql restart as long as it's restarted under the same cmd.exe, but if cmd is restarted, all is lost. This includes both history data, and macros. Very unfortunate, but you can learn to live with it...
Working with the commandline history is quite simple. The basic keys to use it are the usual: * Up/Down arrow - move to previous/next command * PgUp/PgDn - move to first/last command in current session * left/right/home/end - move around on the current line * ctrl-left/ctrl-right - move word left and right
There are also a couple of special keys to copy/paste parts of rows (same ones as on the commandprompt - which really goes for all these). Another very handy key is F7, which will bring up a list of all the commands in the history buffer in a popup window, where you can pick a command to paste in at the current line.
psql history screenshot
Finally, there is the macro functionality. Unfortunatly, your macros will be lost at restart of cmd, so if you just use the Start Menu icon for psql, you can't really use them. You can, however, create your own BAT file that will first register a bunch of macros, and then start psql. For the most basic form of macros, just run:
doskey /exename=psql.exe pgd=SELECT datname FROM pg_database;
To use this macro, simply type in the macro and hit enter. The macro has to be at the beginning of a line.
postgres=# pgd
datname
-----------
postgres
template1
template0
(3 rows)
You can also pass parameters to the macros, for example:
doskey /exename=psql.exe dbinfo=SELECT datname,pg_encoding_to_char(encoding) FROM pg_database WHERE datname='$1';
And then just pass a parameter on the commandline:
postgres=# dbinfo postgres
datname | pg_encoding_to_char
----------+---------------------
postgres | SQL_ASCII
(1 row)
Those of you who do a lot of hackery with the Windows commandprompt will recognise this as standard doskey macros and keys. Those who aren't might be interested in reference from Microsoft.
Trying to be the first to get this up on the planet ;-) Teodor has just committed a first version of GIN (Generalized Inverted iNdexes) to CVS HEAD. This promises even better performance and functionality for many things that previously used GiST, specifically fulltext-search! Yay! Great job, guys!
For much more information, see discussion on -hackers.