PgAgent is a basic scheduling agent that comes packaged with PgAdmin III (since pre-8.0 or so) and that can be managed by PgAdmin III.
PgAdmin III is the database administration tool that comes packaged with PostgreSQL.
For those familiar with
unix/linux cronjobs and crontab structure, PgAgent's scheduling structure should look very familiar.
For those familiar with using Microsoft SQL Server Scheduling Agent or Windows Scheduling Tasks, but not used to crontab structure,
the PgAdmin III Job Agent interface to PgAgent should look very welcoming, but the schedule tab may look a little unfamiliar.
PgAgent can run both PostgreSQL stored functions and sql statements as well as OS shell commands and batch tasks.
First, better Sun than Oracle. The thought of Oracle eating up MySQL has always been rather disturbing to us especially since we do a fair amount of MySQL consulting and don't care much for Oracle as a company. I suppose it could still happen.
Given the fact that Sun is a large contributor to the PostgreSQL project, does this mean PostgreSQL fans can't make fun of
MySQL anymore? Are we like friends now? This could take away some fun and add a little fun at the same time.
Will this mean MySQL will have no qualms of using PostgreSQL underlying storage engine and what would it be called? - MyPost
Overall we think the move should prove positive for both camps.
We've been playing around with the 8.3 betas and RCs and really like the integrated Full Text Indexing and XML features. The new features
make it possible to do a quickie REST service-based application. In the next issue of this journal, we hope
to demonstrate creating REST services using 8.3 with server side - (PHP and/or ASP.NET) and front-end Adobe FLEX. We would have liked to demonstrate SilverLight/MoonLight as well, but
we want to wait till Silverlight 2.0 hits release. We'll try to use the Pagila
demo database for the upcoming demo app as Robert Treat has suggested.
Answer: In integer math, it is 1. A lot of people especially those coming from MySQL or MS Access backgrounds are surprised to find out that in PostgreSQL
3/2 = 1. They view this as some sort of bug.
In actuality, the fact that 3/2 = 1 and 1/3 = 0 is part of the ANSI/ISO-SQL standard
that states mathematical operations between two values must be of the same data type of one of the values (not necessarily the same scale and precision though). This is not some idiosyncracy specific to PostgreSQL.
If you try the same operation in SQL Server, SQLite,FireBird, and some other ANSI/ISO SQL compliant databases, you will get the same results. So it seems MySQL and MS Access are the odd-balls in this arena, but arguably more practical.