Frankly speaking this situation is perfectly described in Joel’s Spolsky “Fire and motion”. We thought: “This just can’t be done in a sane time!”

However “you never know what you can do till you try” and “the devil is not so black as he is painted”. So we decided to port PostgresDAC first. The main reason was the using of libpq.dll client library, which may be built for a huge amount of target platforms.

Thus we don’t need to worry about low-level network routines and may pay the whole of the attention to the middle layer, have no idea how to name it.

As for Win64 platform, then were no problems at all. We’ve prepared x64 deploy libraries and we done with it. There were no dangerous places in our source code were address arithmetics may produce unsuspected behavior. This simplicity is understandable. We just stayed within one Windows platform in general.

Then it was Mac’s turn. When we started I have never seen MacOS before… That was scary move. Especially for my self-esteem.

We crossed the fingers, chose OS X as the target platform and the fun began. I knew our code was Windows-centric, but I was so far from the real understanding of the scope of the tragedy.

Here is the seven deadly sins for the cross-platform library written in Delphi:

1. Using of Windows unit is prohibited. The only things you have are System ans SysUtils. Deal with it!

2. Using of VCL units (Controls, StdVCL, ExtCtrls etc) is prohibited. There’s no VCL on Mac, FireMonkey only.

3. Using of forms is prohibited. So no custom dialogs, message boxes etc. You have no idea under which platform library is built. Well, this is so true for console application too. That’s why we’ve removed annoying trial screen.

4. Ignoring compiler directives is stupid. Remember the first sin? Yeah, sometimes you’ll need low-level OS’s functionality. If so, do it smart:

{$IFDEF MSWINDOWS}
Winapi.Windows,
{$ENDIF}
{$IFDEF MACOS}
Macapi.CoreServices,
{$ENDIF}
{$IFDEF POSIX}
Posix.SysTypes, Posix.Stdio, Posix.Stdlib
{$ENDIF}


5. Using of messages, window procedures, handles, file mappings and other Win-shit is prohibited. That’s why our TPSQLMonitor is still useless for Mac. We need to rewrite it from scratch. And we ready for it.

6. Use correct type naming, e.g. LongWord instead of DWORD.

7. Use proper functions or implement them for all platforms. No place for ZeroMemory, CopyMemory, GetTickCount on Mac etc.

You know, when I wrote the number of seven I didn’t think that I’m so damn write! Of course in your case there may be dozen of others incompatibilities. That was just a joke.

And the most pleasant surprise is PostgreSQL native support added in this minor release.

I remember messages by Lionel Elie Mamane sent to pgsql-hackers list. And the problems LibO community was faced with. Kudos guys!

BTW, how did you manage cross platform compilation of libpq library, especially for MacOS? And how do you provide libpq.so on Macs?

Today I had a conversation with one client about SQL in general and about PosgreSQL dialect in particular. We talked about SQL’s Turing completeness also. Well my opponent is sure that SQL (Postgres dialect either) is not Turing Complete. But I know for sure that if SQL supports CTE it is Turing Complete. Well, I’m sure about it because some time ago at Oscon 2009 David Fetter said so. And my confidence in this man is boundless.

Anyway, my client proposed to implement Factorial calculation on a pure SQL. I choose Postgres dialect. He agreed.

That was his first mistake! He didn’t know that Postgres has built in “!” and “!!” operators for this purpose.

But to be more convincing, I have wrote this code:

WITH RECURSIVE fact(i, f) AS (
    VALUES (2, 1)
UNION ALL
    SELECT i + 1, i * f FROM fact
)
SELECT f FROM fact LIMIT 10;

Joomla, one of the world’s most popular open source content management systems (CMS) used for everything from websites to blogs to Intranets, today announces the immediate availability of Joomla 2.5. Along with new features such as advanced search and automatic notification of Joomla core and extension updates, the Joomla CMS for the first time includes multi-database support with the addition of Microsoft SQL Server. Previous versions of Joomla were compatible exclusively with MySQL databases.

Way to go Joomla! But why don’t you guys mention PostgreSQL database in the main release story? Do you really think that MSSQL is more common choice for the database layer for any CMS? Seriously?

UPD Apparently I was a little rushed. PostgreSQL and Oracle support must be added in the shortest time. Waiting for explanations from Joomla!

When I do this

CREATE TABLE "T1"
(
"T1_ID" bigint NOT NULL,
CONSTRAINT "T1" PRIMARY KEY ("T1_ID" )
);

I get the following message:

NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "T1" for table "T1"
ERROR: relation "T1" already exists
********** Error **********
ERROR: relation "T1" already exists
SQL state: 42P07

It does NOT create either the table or the constraint, and the message is confusing because there is no relation by that name.

The SQLSTATE 42P07 is described in the manual as only as “table undefined”, and it is not clear if the intent is to allow or
disallow the creation of a constraint called the same as the table in Postgresql. Oracle 11g allows this, but my feeling is that
doing this should not be allowed, just as Postgresql handles it.

I am complaining about the confusing error message which IMO is off-topic, not about how the DB handles this.

The quick answer is PRIMARY KEY constraint always has underlying system index with the same name. Thus to implement CREATE statement above PostgreSQL should create table with the name “T1″ and the index with the same name. This is impossible, because tables and indexes are stored in the same system catalog pg_class (they share the same namespace). That is where ambiguity appears. The same is true for UNIQUE constraint.

On the other hand you may freely create CHECK constraint under such conditions:

CREATE TABLE "T1"
(
"T1_ID" bigint NOT NULL,
CONSTRAINT "T1" CHECK ("T1_ID" > 0 )
);


A leap year (or intercalary or bissextile year) is a year containing one extra day (or, in the case of lunisolar calendars, a month) in order to keep the calendar year synchronized with the astronomical or seasonal year. Because seasons and astronomical events do not repeat in a whole number of days, a calendar that had the same number of days in each year would, over time, drift with respect to the event it was supposed to track. By occasionally inserting (or intercalating) an additional day or month into the year, the drift can be corrected. A year that is not a leap year is called a common year.

So to determine whether a year is a leap year or not in either the Gregorian calendar we need to check such condition:

This dirty query does the trick then:

I prefer to have function for this task. First I thought it must be written in plpgsql to be fast enough. Yeah, I’m to lazy for C functions. However after tests I saw that SQL function has the same productivity. Don’t know why. Here the sources for both of them:

P.S. Some funny traditions:

• On the British isles, it is a tradition that women may propose marriage only on leap years.
• In Denmark, the tradition is that women may propose on the bissextile leap day, February 24, and that refusal must be compensated with 12 pairs of gloves.
• In Finland, the tradition is that if a man refuses a woman’s proposal on leap day, he should buy her the fabrics for a skirt.

Everybody is welcome to use “Christmas” coupon code till January 14 for 20% discount on any product from MicroOLAP Technologies including the most robust Database Designer for PostgreSQL and PostgresDAC component suite.

From all of us at MicroOLAP, we wish you happy holidays and a prosperous new year!

As before, MySQL is still the leader. PosgreSQL takes second place of honor, followed by MariaDB. Only one of the NoSQL databases MongoDB showed very good results in November.

If compare current data with the October, we can conclude that the number of fans did not change.

Current numbers:

According to the table we need PgConf.eu twice a year.

Wednesday, October 19

11:10 - 12:00
PostgreSQL 9.1 - what's new
Magnus Hagander

Despite the fact I read a lot about new Pg 9.1 features, it’s always interesting to get overview by someone who knows system very well and spent a lot of time developing it.

12:10 - 13:00
Look Out The Window Functions (and free your SQL)
Gianni Ciolli

It’s a shame, but I really know a little about this powerful functionality.

Lunch!

It goes without saying!

14:00 - 14:50
Explaining the Postgres Query Optimizer
Bruce Momjian

I hope index-only scans will be presented here also.

15:20 - 16:10
Asynchronous Notifications for Fun and Profit
Marc Balmer

I like NOTIFY\LISTEN functionality a lot, but sometimes it’s hard to find really useful use case for demonstration to clients.

16:20 - 17:10
Review of Patch Reviewing
Stephen Frost

Development process! What else to say?!

Thursday, October 20

09:30 - 10:20
Improving VACUUM Suction
Greg Smith

I liked the title.

10:50 - 11:40
Extensions are good for business logic
Dimitri Fontaine

Had no time to give extensions a chance. This time I will.

11:50 - 12:40
Fast GiST index build
Alexander Korotkov

Want to know more about techniques used.

13:40 - 14:30
More Mistakes Were Made
Selena Deckelmann

Have no idea what all of this is about, but I need to see Selena.

14:40 - 15:30
Port databases from MySQL to PostgreSQL
Andreas Scherbaum

Want to know what’s new in this area appeared.

Friday, October 21

09:30 - 10:20
Relational Database Designer for pgAdmin
Guillaume Lelarge, Luis Ochoa

Frankly speaking this is the first hard choice for me. I would like to listen Simon’s roadmap for PostgreSQL too. But ER-designer is my proffesional interest. So without a chance.

10:50 - 11:40
Bottom-up Database Benchmarking
Greg Smith

Benchmarking is so elusive subject, but exciting at the same time.

11:50 - 12:40
Mission impossible? Can I replace my most important databases with PostgreSQL?
Michael Meskes

Holy war detected!

13:40 - 14:30
Managing Terabytes
Selena Deckelmann

Never had deal with such huge databases, but need to know how it is.

Meet me at the PGConf.EU soon!