PostgreSQL error with SVN 31757: calendar/setup/tables_update.inc.php

Old eGW-developers
1

Need explicit casts for PostgreSQL or the upgrade doesn’t succeed.

diff --git a/calendar/setup/tables_update.inc.php b/calendar/setup/tables_update.inc.php
index c7d06e6…3fcd419 100644
— a/calendar/setup/tables_update.inc.php
+++ b/calendar/setup/tables_update.inc.php
@@ -2145,7 +2145,7 @@ function calendar_upgrade1_9_001()
),array(
‘cal_deleted’ => 'CASE cal_deleted WHEN ‘.$GLOBALS[‘egw_setup’]->db->quote(true,‘bool’).’ THEN ‘.
’(SELECT '.$GLOBALS[‘egw_setup’]->db->unix_timestamp(‘sync_deleted’).

  •                   " FROM egw_api_content_history WHERE sync_appname='calendar' AND sync_contentid=cal_id)".

  •                   " FROM egw_api_content_history WHERE sync_appname='calendar' AND sync_contentid::integer=cal_id)".
                  ' ELSE NULL END',
  ));

Thanks. -A

–
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E

2

Hi Anthony,

this one is fixed now too.

What are - in your opinion the most pressing PostgreSQL problems in
Trunk or our new 1.8 branch?

Ralf

Need explicit casts for PostgreSQL or the upgrade doesn’t succeed.

diff --git a/calendar/setup/tables_update.inc.php b/calendar/setup/tables_update.inc.php
index c7d06e6…3fcd419 100644
— a/calendar/setup/tables_update.inc.php
+++ b/calendar/setup/tables_update.inc.php
@@ -2145,7 +2145,7 @@ function calendar_upgrade1_9_001()
),array(
‘cal_deleted’ => 'CASE cal_deleted WHEN ‘.$GLOBALS[‘egw_setup’]->db->quote(true,‘bool’).’ THEN ‘.
’(SELECT '.$GLOBALS[‘egw_setup’]->db->unix_timestamp(‘sync_deleted’).

  •                   " FROM egw_api_content_history WHERE sync_appname='calendar' AND sync_contentid=cal_id)".

  •                   " FROM egw_api_content_history WHERE sync_appname='calendar' AND sync_contentid::integer=cal_id)".
                  ' ELSE NULL END',
  ));

Thanks. -A

Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful,
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance.
http://p.sf.net/sfu/dell-sfdev2dev

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

–
Ralf Becker
Director Software Development

Stylite GmbH
[open style of IT]

Morschheimer Strasse 15
67292 Kirchheimbolanden

fon +49 (0) 6352 70629-0
fax +49 (0) 6352 70629-30
mailto: rb@stylite.de

www.stylite.de
www.egroupware.org

Geschäftsführer Andre Keller,
Gudrun Müller, Ralf Becker
Registergericht Kaiserslautern HRB 30575
Umsatzsteuer-Id / VAT-Id: DE214280951

Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful,
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance.
http://p.sf.net/sfu/dell-sfdev2dev

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

3

this one is fixed now too.

What are - in your opinion the most pressing PostgreSQL problems in
Trunk or our new 1.8 branch?

So far, with just a few exceptions that have already been reported back to
you, everything seems to work fine.

Most of the PostgreSQL errors that I’ve reported in the past have been about
explicit type casting, so I guess that’s something to look out for while
coding.

A warning that I get constantly in my PostgreSQL log is:

WARNING: nonstandard use of \ in a string literal at character 88
HINT: Use the escape string syntax for backslashes, e.g., E’\’.

but I haven’t been able to track down where it’s coming from. It doesn’t seem
to affect general function as far as I can tell. -A

–
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E

4

Hi Anthony,

this one is fixed now too.

What are - in your opinion the most pressing PostgreSQL problems in
Trunk or our new 1.8 branch?

So far, with just a few exceptions that have already been reported back to
you, everything seems to work fine.

It might help, if you feed me PostgreSQL errors one by one (in order of
priority), instead pointing to all currently reported 14 issues :wink:

Most of the PostgreSQL errors that I’ve reported in the past have been about
explicit type casting, so I guess that’s something to look out for while
coding.

A warning that I get constantly in my PostgreSQL log is:

WARNING: nonstandard use of \ in a string literal at character 88
HINT: Use the escape string syntax for backslashes, e.g., E’\’.

I had a look for the current ADOdb version 5.11, it changed the quoting
to use pg_escape_string now. I imported that into Trunk, let’s see if
you still get these warnings.

Let me know, so I can import it in the other EGroupware versions too.

Best would be to update ADOdb, but we have some many - probably parallel

  • fixes specially for PostgreSQL in our version, so it’s a) a lot of
    work to merge and check and b) might break in various areas. Our version
    is derived from ADOdb 4.65 while the current one is 5.11.

but I haven’t been able to track down where it’s coming from. It doesn’t seem
to affect general function as far as I can tell. -A

Ralf

Ralf Becker
Director Software Development

Stylite GmbH
[open style of IT]

Morschheimer Strasse 15
67292 Kirchheimbolanden

fon +49 (0) 6352 70629-0
fax +49 (0) 6352 70629-30
mailto: rb@stylite.de

www.stylite.de
www.egroupware.org

Geschäftsführer Andre Keller,
Gudrun Müller, Ralf Becker
Registergericht Kaiserslautern HRB 30575
Umsatzsteuer-Id / VAT-Id: DE214280951

Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

5

this one is fixed now too.

What are - in your opinion the most pressing PostgreSQL problems in
Trunk or our new 1.8 branch?

So far, with just a few exceptions that have already been reported back
to you, everything seems to work fine.

It might help, if you feed me PostgreSQL errors one by one (in order of
priority), instead pointing to all currently reported 14 issues :wink:

Ok. What I meant to say is, as of last night, every PostgreSQL error that I
reported over time has already been fixed by you guys.

I do have a new error however, also related to explicit type casting:
http://www.egroupware.org/egroupware/index.php?menuaction=tracker.tracker_ui.edit&tr_id=2725

Most of the PostgreSQL errors that I’ve reported in the past have been
about explicit type casting, so I guess that’s something to look out
for while coding.

A warning that I get constantly in my PostgreSQL log is:

WARNING: nonstandard use of \ in a string literal at character 88
HINT: Use the escape string syntax for backslashes, e.g., E’\’.

I had a look for the current ADOdb version 5.11, it changed the quoting
to use pg_escape_string now. I imported that into Trunk, let’s see if
you still get these warnings.

Let me know, so I can import it in the other EGroupware versions too.

Best would be to update ADOdb, but we have some many - probably parallel

  • fixes specially for PostgreSQL in our version, so it’s a) a lot of
    work to merge and check and b) might break in various areas. Our version
    is derived from ADOdb 4.65 while the current one is 5.11.

I updated to the latest trunk with this fix and cannot say that it has "fixed"
the errors:

http://www.egroupware.org/egroupware/index.php?menuaction=tracker.tracker_ui.edit&tr_id=2726

but I haven’t been able to track down where it’s coming from. It doesn’t
seem to affect general function as far as I can tell. -A

Ralf

If it’s more convenient, I’ll report these on the Tracker.

Also, I use Git for most of my development things. Do you know of anyone or
any proper way to use git-svn with upstream eGW? The svn:externals seem to
make that quite difficult. It’s not critical, I was just wondering if you had
any suggestions.

Again, thanks for all the work on this!

–
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E