Postgres Support Task Force

Events happening in the community are now at Drupal community events on www.drupal.org.
mailleux's picture

I have been using Drupal with Postgres for some time now. I actually choose Drupal because of it supported Postgres (I really like the database). Throughout this time I’ve helped fix several issues related to module’s support to Postgres. This is a kind of chicken and egg problem. Since not all modules support Postgres, a lot of people are forced to use MySQL, and thus never improve Postgres support. Drupal 6 Schema API promises to improve this very much.

However, after reading a lot of flames on dropping postgres supports from core, and how to fix it, I have come to the conclusion that we need a more coordinated effort to support Postgres. Fixing issues is not really hard, but you are normally focusing on your problems. I believe we need a team of user to help test and fix issues with postgres database support.

I’d suggest some actions:

  • Having a tag on the issues that indicates it’s a postgres problem (like the GOP and newbie tags);
  • Create and promote a Postgres taskforce of people that can help with patching and testing, maybe separate groups;

I really thing this could help, but am not sure how to do this in the “Drupal.org” way.

Comments

I've taken it upon myself to

jaydub's picture

I've taken it upon myself to help add PostgreSQL support to any contrib modules that I spend time working with and it's clear that many people have no experience with how to handle the differences in table definitions and compatible/incompatible queries.

Consider me on board to help out with this cause!

two lists

greggles's picture

There's two lists of issues that I know of: http://groups.drupal.org/node/6980 is one, but it's a wiki.

For Drupal Core you can do a search with the component tag set to postgresql - http://drupal.org/project/issues/search/drupal or here is a search for Drupal core for 6.* and 7.x for open issues with that component. This is not used much.

Aclight is working on tagging for issues on drupal.org. Once we have that we can tag issues as needing postgresql review which will help since the component solution is not very good...

Other than that, it just requires folks with postgresql knowledge and, better, the ability to make patches to help out reviewing issues and providing patches.

--
Open Prediction Markets | Drupal Dashboard

Watch out for problems with PostgreSQL 8.3

jaydub's picture

The latest PostgreSQL release 8.3 includes a new change in behaviour from previous versions regarding JOINS on columns that are not the same data type. See http://www.postgresql.org/docs/8.3/static/release-8-3.html

This issue has already been reported in the following Drupal issues:

http://drupal.org/node/220064
http://drupal.org/node/226503
http://drupal.org/node/229051

Non-character data types are no longer automatically cast to TEXT (Peter, Tom)

Previously, if a non-character value was supplied to an operator or function that requires text input, it was automatically cast to text, for most (though not all) built-in data types. This no longer happens: an explicit cast to text is now required for all non-character-string types. For example, these expressions formerly worked:

substr(current_date, 1, 4)
23 LIKE '2%'

but will now draw "function does not exist" and "operator does not exist" errors respectively. Use an explicit cast instead:

substr(current_date::text, 1, 4)
23::text LIKE '2%'

(Of course, you can use the more verbose CAST() syntax too.) The reason for the change is that these automatic casts too often caused surprising behavior. An example is that in previous releases, this expression was accepted but did not do what was expected:

current_date < 2017-11-17

This is actually comparing a date to an integer, which should be (and now is) rejected — but in the presence of automatic casts both sides were cast to text and a textual comparison was done, because the text < text operator was able to match the expression when no other < operator could.

Types char(n) and varchar(n) still cast to text automatically. Also, automatic casting to text still works for inputs to the concatenation (||) operator, so long as least one input is a character-string type.

General question: how to handle reverded keywords

grub3's picture

Dear Friends,

I would like to ask you what are Drupal guidelines,
when a module uses SQL reserved keywords that MySQL does not detect.

An example is http://drupal.org/project/l10n_server

Translation languages (fr, de, it) are stored in a table, each language being a seperate column. I would have imagined a separate table for supported languages. One of the language is Islandic (is), which is a PostgreSQL reserved keyword. So table creation fails.

I was wondering if we could modify Drupal 6.6 pgsql abstract layer (that should be discussed together)
OR
if we shloud upgrade every module that has reserved keywords.

I am opening a seperate issue for that and will report back.
Several modules use reserved keywords and this is a heck.

Kind regards,
Jean-Michel

Postgresql

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: