I read the information on the official PostgreSQL site that the first commercial OLEDB provider for PotgreSQL is available now. I estimate this news as very good.

I have been working with PostgreSQL very closely for one year and I found that this server is very powerful and as now .NET framework will have OLEDB provider for a supporting of that, it can be a good alternative of the MS SQL and Oracle servers, licenses of which cost much money.

I have downloaded th trial version of it from the author’s site and have checked how it works. Of course trial version has serious limitation here:

TRIAL VERSION

The trial version has the following limitations:

- SELECT statements return up to 100 rows.
- DB conversion in DTS/SSIS Wizard handles only first 100 rows in every table.

Also I proud that the its developer is Russian programmer, who works and lives in USA now. Thank him very much for his good job. And if I will have .NET project where by some reasons will choose PostgreSQL server I obviously can play with its not trial version also, which doubtless will be interesting.

I met some situations when old SQL queries don’t work under server v5.0.18. Of course I didn’t read before any migrations recommendations guides or something like this (I think, I’m not one like this). So I have just knew about this incompatibilities. I will fix here my experience with, that it help me to avoid errors like this in my sunny feature:

• Previously, the comma operator (,) and JOIN both had the same precedence, so the join expression t1, t2 JOIN t3 was interpreted as ((t1, t2) JOIN t3). Now JOIN has higher precedence, so the expression is interpreted as (t1, (t2 JOIN t3)). This change affects statements that use an ON clause, because that clause can refer only to columns in the operands of the join, and the change in precedence changes interpretation of what those operands are.

  Example:

  CREATE TABLE t1 (i1 INT, j1 INT);
  CREATE TABLE t2 (i2 INT, j2 INT);
  CREATE TABLE t3 (i3 INT, j3 INT);
  INSERT INTO t1 VALUES(1,1);
  INSERT INTO t2 VALUES(1,1);
  INSERT INTO t3 VALUES(1,1);
  SELECT * FROM t1, t2 JOIN t3 ON (t1.i1 = t3.i3);

  Previously, the SELECT was legal due to the implicit grouping of t1,t2 as (t1,t2). Now the JOIN takes precedence, so the operands for the ON clause are t2 and t3. Because t1.i1 is not a column in either of the operands, the result is an Unknown column 't1.i1' in 'on clause' error. To allow the join to be processed, group the first two tables explicitly with parentheses so that the operands for the ON clause are (t1,t2) and t3:

  SELECT * FROM (t1, t2) JOIN t3 ON (t1.i1 = t3.i3);

  Alternatively, avoid the use of the comma operator and use JOIN instead:

  SELECT * FROM t1 JOIN t2 JOIN t3 ON (t1.i1 = t3.i3);

  This change also applies to statements that mix the comma operator with INNER JOIN, CROSS JOIN, LEFT JOIN, and RIGHT JOIN, all of which now have higher precedence than the comma operator.

The piece was taken from official site of MySQL.

I met with subject problem. I wasted couple of hours before tried to find something about this problem in google and unfortunately I was success I told “unfortunately”, because it means that problem really exists, and while I didn’t find it I still thought that I just don’t understand something there and/or do something wrong.

Any way, I’d like fix now this experience in my blog (it is my electronic extension of usual memory

There guy describe the same problem and there I found mention about FAQ.

Other page with the same problem.

Link to section in FAQ.

Quote from FAQ:

4.19) Why do I get “relation with OID ##### does not exist” errors when accessing temporary tables in PL/PgSQL functions?

PL/PgSQL caches function scripts, and an unfortunate side effect is that if a PL/PgSQL function accesses a temporary table, and that table is later dropped and recreated, and the function called again, the function will fail because the cached function contents still point to the old temporary table. The solution is to use EXECUTE for temporary table access in PL/PgSQL. This will cause the query to be reparsed every time.