After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 595608 - Error while attempting to self-host a database
Error while attempting to self-host a database
Status: RESOLVED FIXED
Product: glom
Classification: Other
Component: general
1.10.x
Other Linux
: Normal normal
: ---
Assigned To: Murray Cumming
Murray Cumming
Depends on:
Blocks:
 
 
Reported: 2009-09-18 17:16 UTC by Fryderyk Dziarmagowski
Modified: 2009-09-25 08:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
adapt pg_hba.conf to work with newer postgresql (1011 bytes, patch)
2009-09-18 19:29 UTC, Fryderyk Dziarmagowski
none Details | Review

Description Fryderyk Dziarmagowski 2009-09-18 17:16:23 UTC
According to pg_hba.conf.sample included with postgresql 8.4 method "ident sameuser" is no longer supported.
Glom creates such method in config file what make impossible to create a new database:

[4-3] CONTEXT:  line 1 of configuration file "/home/users/fritz/tmp/glom1/glom_postgres_data/config/pg_hba.conf"
[5-1] LOG:  authentication option not in name=value format: sameuser

from .sample:
# DATABASE can be "all", "sameuser", "samerole", a database name, or                                                                     
# a comma-separated list thereof.

# METHOD can be "trust", "reject", "md5", "password", "gss", "sspi", "krb5",                                                             
# "ident", "pam", "ldap" or "cert".  Note that "password" sends passwords                                                                
# in clear text; "md5" is preferred since it sends encrypted passwords.

Expected behaviour:
Glom should support newer pgsql too :-)
Comment 1 Murray Cumming 2009-09-18 18:31:24 UTC
Is this on Ubuntu Karmic, maybe? I guess it's time for me to upgrade.
Comment 2 Fryderyk Dziarmagowski 2009-09-18 18:48:09 UTC
I've just adjusted postgres_self.cc and it seems to work well here. 

Ah, it's a custom distro, pld-linux based :-)
Comment 3 Murray Cumming 2009-09-18 19:07:28 UTC
Could you attach your patch then, please?
Comment 4 Fryderyk Dziarmagowski 2009-09-18 19:29:39 UTC
Created attachment 143467 [details] [review]
adapt pg_hba.conf to work with newer postgresql
Comment 5 Fryderyk Dziarmagowski 2009-09-18 19:31:28 UTC
I'm not sure about backward compatibility of above change...
Comment 6 Michael Hasselmann 2009-09-18 20:36:01 UTC
http://www.postgresql.org/about/press/features84#security says it is not backward-compatible to anything < 8.4
Comment 7 Murray Cumming 2009-09-18 20:48:14 UTC
We should be able to ifdef support for both versions, or possibly detect it at runtime.
Comment 8 Murray Cumming 2009-09-20 12:13:28 UTC
Daniel, do you know of any generic way to check a program's --version number in configure.ac so we can get something in config.h that we can use for an #ifdef?
Comment 9 Daniel Elstner 2009-09-21 22:25:05 UTC
I'm not aware of a generic way to do that. Generally, Autoconf encourages feature tests over version comparisons and the available macros reflect that.

In any case, I don't think it is a good idea at all to make this distinction at build time. The PostgreSQL version is a system property that could reasonably change without Glom being rebuilt. Distributions that provide multiple versions of PostgreSQL would have to provide multiple versions of Glom as well.

Given that the problem seems to be a configuration file, and thus inherently in the runtime domain, making this a build time decision is clearly inappropriate. I imagine a runtime check may actually be just as easy to implement.

On a side note, while looking at the patch I noticed that the Glom code contains escaped newlines within string literals. I don't think this is valid C nor C++, although I'm not completely sure whether it may be valid at the preprocessor level. In any case, it is unnecessary since adjacent string literals are concatenated by the compiler anyway. Also, it does not seem to be necessary for this to be a preprocessor macro.
Comment 10 Murray Cumming 2009-09-22 07:43:20 UTC
(In reply to comment #9)
> In any case, I don't think it is a good idea at all to make this distinction at
> build time. The PostgreSQL version is a system property that could reasonably
> change without Glom being rebuilt. Distributions that provide multiple versions
> of PostgreSQL would have to provide multiple versions of Glom as well.

Then we'd need some logic to choose the Postgresql path at runtime and we'd still need some way to specify a favoured default. We certainly wouldn't want UI for this.

It just wouldn't solve any real problem that we have - and as we've seen, it would create problems because postgresql versions act differently. So, no. And I don't want to argue back and forth about it.

> Given that the problem seems to be a configuration file, and thus inherently in
> the runtime domain, making this a build time decision is clearly inappropriate.
> I imagine a runtime check may actually be just as easy to implement.

But yes, we can check the version at runtime, using the path specified at build time.
Comment 11 Murray Cumming 2009-09-24 17:26:18 UTC
Here is my rather lengthy solution:
http://git.gnome.org/cgit/glom/commit/?id=27ae914f8856f97490573ae18ca3a464ebf8f5d1
though it doesn't seem to work yet in my Ubuntu Karmic.
Comment 12 Murray Cumming 2009-09-25 08:47:46 UTC
Actually, that did fix it. I just had a problem opening and old postgresql-8.3-based self-hosting .glom system. Of course that didn't work.

This fix will be in glom 1.12.0, to be released today.