portsnap patch to use fetch (instead of wget)

I did some review to my micro portsnap patch, thanks also to the suggestion on the FreeBSD forums and -stable mailing list.

In particular, as someone pointed out, using wget(1) is not a good idea because it is not part of the base system and requires an admin to manually install it from ports or packages. That is not a big deal in my opinion, and it is the reason why I made a change so that it was possible to configure, using /etc/portsnap.conf, a way to specify that wget(1) was required. To make it even clearer, I also created a function check_downloader that is used to check the presence of the program executable used to download stuff (either phttpget or wget).

I was not fully happy with such patch, but I have not a better idea until someone on the -stable mailing list pointed out that FreeBSD (of course!) has already a downloader: fetch(1).

The problem with fetch(1) is that it requires a full URL while portsnap was internally dealing with clean server names.

So I reverted the patch in order to avoid using wget(1) and to use fetch(1) by means of a flag in /etc/portsnap.conf and introduced a new variable in the internal portsnap implementation, SERVER_PROTOCOL, that simply handles "http" in the case of the usage of fetch(1).

The patch has moved into another path within my repository and is available here.

Do we really need UPDATE/DELETE with LIMIT?

Reading Planet PostgreSQL last day I found a strange poll about the need to place a LIMIT statement in an UPDATE/DELETE query.

My answer to such question is simply NO, and I placed also a comment on the blog of the proposing author, but I cannot find it anymore...

In order to better understand why I do not believe this feature is required, let's consider a sample query:

UPDATE accounts 

SET active = 'f' 

LIMIT 100;

The idea is to disable the first 100 accounts. This query is fully supported in MySQL.

What is clear to me is that such a query is defective by design: you are using a LIMIT statement on a wrong design of the data and or of the unique constraints on such data. 

The right way to do it is by using a WHERE statement that filters the data you are going to manipulate. While I see that LIMIT is a quick trick to do the job, it is the wrong one since it allows DBAs to implement data in any almost unstructered way being able to manipulate them later using a kind of indexing.

It is true, however, that such a scenario could be useful when importing and handling legacy data, that could come from other old systems and with wrong constraints, but once the database is fully reimplemented the need for such a feature is almost inutily in my opinion.