- Development - lists.drupal.org

[drupal-devel] [bug] Wrong Login Error
by deekayen 20 Jun '05

20 Jun '05

Issue status update for http://drupal.org/node/3962 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: minor Assigned to: deekayen Reported by: dziemecki Updated by: deekayen Status: patch Attachment: http://drupal.org/files/issues/blockedusermessage_0.diff (3.14 KB) This patch uses "deactivated" instead of "blocked", but is otherwise not different from the previous patch. deekayen Previous comments: ------------------------------------------------------------------------ November 5, 2003 - 21:01 : dziemecki When a new user logs on after they're ID and password were sent to them, but before their account was "unblocked", they get the follwoing error: "Sorry. Unrecognized username or password. Have you forgotten your password?" That may or may not count as a bug, but it not entirely accurate, and might be a little confusing. ------------------------------------------------------------------------ June 14, 2005 - 03:19 : deekayen I don't mind assigning this one to myself, but I'm not familiar enough with the function of the access table to complete the patch. Should blocked users be entered into the access table? Right now, user.module has a drupal_deny check with the correct error message, but it doesn't get displayed because the only place a person gets blocked is in the users table. To be more normalized, I'd just leave the block in the users table, but does someone intend to move the user block to the access table? ------------------------------------------------------------------------ June 15, 2005 - 21:37 : deekayen Attachment: http://drupal.org/files/issues/blockedloginmessage.patch (1.26 KB) Right now when users are blocked, they're not added to the access table, so this patch just checks the users table for blocked logins. The check in user.module's user_login() should work now and give the correct error message that was there all along. ------------------------------------------------------------------------ June 15, 2005 - 21:45 : deekayen Attachment: http://drupal.org/files/issues/removeactivereset.patch (882 bytes) This patch goes with the previous one. Without it, when you edit a blocked user to make them active again, they remain blocked and the edit screen shows an error message about the user being blocked. I don't really know if that's the intended behavior to have blocks be permanent, but permanent blocks don't seem right to me. ------------------------------------------------------------------------ June 16, 2005 - 09:04 : moshe weitzman I'm not so sure about this one. We should continue to distinguish between a 'user block' and a 'host ban'. ------------------------------------------------------------------------ June 16, 2005 - 09:12 : killes(a)www.drop.org I agree with Moshe. I think we should test whether a user hasn't logged in before and then give a different message then when he got blocked later. ------------------------------------------------------------------------ June 17, 2005 - 00:37 : deekayen Attachment: http://drupal.org/files/issues/blockeduser.diff (1.29 KB) Just your comments made me see where I went wrong with the previous patches. I'd never used the access control rules before, so I thought blocked user == access controlled username. As far as I could tell, the only place to where a blocked username check was needed is at login. This patch adds a user_blocked() to just user.module and has a separate blocked error message from the access check. ------------------------------------------------------------------------ June 17, 2005 - 00:46 : deekayen Attachment: http://drupal.org/files/issues/blockeduser_0.diff (1.29 KB) I'm not used to the Drupal bracket formatting, yet. This is a spacing revision. ------------------------------------------------------------------------ June 19, 2005 - 02:28 : Dries I think this patch makes sense, however the difference between 'the name X has been denied access' and 'the name X has been blocked' is too subtle for the average Drupal user/administrator to grasp. I'd like to have us think about rewording the error messages so they are somewhat more descriptive to administrators without exposing internal/technical detail to the user. How about writing 'the name X is a reserved user name' for the former, and 'the user with name X is no longer allowed access' for the latter? (One could argue we need the drupal_deny() check at login time.) ------------------------------------------------------------------------ June 19, 2005 - 14:48 : deekayen Attachment: http://drupal.org/files/issues/blockedusermessage.diff (1.5 KB) What about "The username %s has been blocked." and "The name %s is a reserved username."? I think it's important that the user administration "blocked" status matches the error message. Otherwise perhaps the user administration "blocked" status should be changed to "Deactivated" or "Denied" with "The username %s has been deactivated." as the error message. The attached patch is revised to have the first two messages.

1 0

[drupal-devel] [bug] Wrong Login Error
by deekayen 19 Jun '05

19 Jun '05

Issue status update for http://drupal.org/node/3962 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: minor Assigned to: deekayen Reported by: dziemecki Updated by: deekayen Status: patch Attachment: http://drupal.org/files/issues/blockedusermessage.diff (1.5 KB) What about "The username %s has been blocked." and "The name %s is a reserved username."? I think it's important that the user administration "blocked" status matches the error message. Otherwise perhaps the user administration "blocked" status should be changed to "Deactivated" or "Denied" with "The username %s has been deactivated." as the error message. The attached patch is revised to have the first two messages. deekayen Previous comments: ------------------------------------------------------------------------ November 5, 2003 - 21:01 : dziemecki When a new user logs on after they're ID and password were sent to them, but before their account was "unblocked", they get the follwoing error: "Sorry. Unrecognized username or password. Have you forgotten your password?" That may or may not count as a bug, but it not entirely accurate, and might be a little confusing. ------------------------------------------------------------------------ June 14, 2005 - 03:19 : deekayen I don't mind assigning this one to myself, but I'm not familiar enough with the function of the access table to complete the patch. Should blocked users be entered into the access table? Right now, user.module has a drupal_deny check with the correct error message, but it doesn't get displayed because the only place a person gets blocked is in the users table. To be more normalized, I'd just leave the block in the users table, but does someone intend to move the user block to the access table? ------------------------------------------------------------------------ June 15, 2005 - 21:37 : deekayen Attachment: http://drupal.org/files/issues/blockedloginmessage.patch (1.26 KB) Right now when users are blocked, they're not added to the access table, so this patch just checks the users table for blocked logins. The check in user.module's user_login() should work now and give the correct error message that was there all along. ------------------------------------------------------------------------ June 15, 2005 - 21:45 : deekayen Attachment: http://drupal.org/files/issues/removeactivereset.patch (882 bytes) This patch goes with the previous one. Without it, when you edit a blocked user to make them active again, they remain blocked and the edit screen shows an error message about the user being blocked. I don't really know if that's the intended behavior to have blocks be permanent, but permanent blocks don't seem right to me. ------------------------------------------------------------------------ June 16, 2005 - 09:04 : moshe weitzman I'm not so sure about this one. We should continue to distinguish between a 'user block' and a 'host ban'. ------------------------------------------------------------------------ June 16, 2005 - 09:12 : killes(a)www.drop.org I agree with Moshe. I think we should test whether a user hasn't logged in before and then give a different message then when he got blocked later. ------------------------------------------------------------------------ June 17, 2005 - 00:37 : deekayen Attachment: http://drupal.org/files/issues/blockeduser.diff (1.29 KB) Just your comments made me see where I went wrong with the previous patches. I'd never used the access control rules before, so I thought blocked user == access controlled username. As far as I could tell, the only place to where a blocked username check was needed is at login. This patch adds a user_blocked() to just user.module and has a separate blocked error message from the access check. ------------------------------------------------------------------------ June 17, 2005 - 00:46 : deekayen Attachment: http://drupal.org/files/issues/blockeduser_0.diff (1.29 KB) I'm not used to the Drupal bracket formatting, yet. This is a spacing revision. ------------------------------------------------------------------------ June 19, 2005 - 02:28 : Dries I think this patch makes sense, however the difference between 'the name X has been denied access' and 'the name X has been blocked' is too subtle for the average Drupal user/administrator to grasp. I'd like to have us think about rewording the error messages so they are somewhat more descriptive to administrators without exposing internal/technical detail to the user. How about writing 'the name X is a reserved user name' for the former, and 'the user with name X is no longer allowed access' for the latter? (One could argue we need the drupal_deny() check at login time.)

1 0

[drupal-devel] [bug] Improved internal/external referrer differentiation
by Dries 19 Jun '05

19 Jun '05

Issue status update for http://drupal.org/node/9508 Project: Drupal Version: cvs Component: statistics.module Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: njivy Updated by: Dries Status: patch Not sure but it might be shorter/better to use PHP's parse_url()? Dries Previous comments: ------------------------------------------------------------------------ July 25, 2004 - 19:32 : njivy Attachment: http://drupal.org/files/issues/statistics.http_host.patch (2.34 KB) Some PHP setups return $_SERVER['HTTP_HOST'] with a port designation -- e.g. http://domain.tld:80. With this patch, statistics.module removes the port designation before distinguishing between internal and external referrers. Without this patch, all referrers will be labeled as external in PHP setups where the port designation is included in HTTP_HOST. ------------------------------------------------------------------------ July 25, 2004 - 20:43 : Anonymous I have provided a patch before which also enabled stats module to treat more domain names as local ones, since a site might be accessible via multiple domain names (like www.drupal.org and drupal.org) That was not accepted. It is not just port numbers that are problems. ------------------------------------------------------------------------ October 10, 2004 - 20:24 : killes(a)www.drop.org Doesn't apply anymore- ------------------------------------------------------------------------ June 14, 2005 - 01:22 : Robin Monks Attachment: http://drupal.org/files/issues/incorrect.external.fix.patch (1.73 KB) Updated patch to work with latest HEAD. Tested to work with CVS HEAD. I'll take over any further problems that this patch may incur. Robin

1 0

[drupal-devel] [bug] Category selection does not work with Movable Type blogapi
by Dries 19 Jun '05

19 Jun '05

Issue status update for http://drupal.org/node/24030 Project: Drupal Version: 4.6.1 Component: blogapi.module Category: bug reports Priority: normal Assigned to: walkah Reported by: mrmachine Updated by: Dries Status: patch Actually, this is an annoying property of node_save() ... I guess you can't use node_invoke_nodeapi($node, 'insert') or node_invoke_nodeapi($node, 'update')? Dries Previous comments: ------------------------------------------------------------------------ June 1, 2005 - 00:38 : mrmachine Using a blog client (linux - either Drivel or BlogTK) and the Moveable Type api, you can retrieve categories and select one for your post, but once the post is submitted, it fails to allocate the category - making the use of a blog tool pretty useless. ------------------------------------------------------------------------ June 1, 2005 - 00:45 : laura s I use ecto, set to MoveableType API,but so far I'm not able to repeat this problem. Could it be the client? I was also able to set Drupal's BlogAPI to the MetaWeblog setting and it seemed to work fine -- even with ecto set to MoveableType API. You might be able to try that as a workaround. ------------------------------------------------------------------------ June 2, 2005 - 14:04 : mrmachine I tried ecto on my son's Windows box, and yes - it does set categories correctly ... too bad there's no linux version but anyway, i tried changing Drupal's blogapi to Metaweblog, and kept Drivel and BlogTK set to Moveable Type API. It didn't work for Drivel, but it did for BlogTK ... thanx for the hint! ------------------------------------------------------------------------ June 5, 2005 - 16:36 : fflewddur I've been trouble-shooting this issue using w.bloggar on Windows and Drivel on Linux. w.bloggar is able to post using the Movable Type API, but the category selection only works if you click "Post", not "Post and Publish". Drivel, by default, publishes all posts, which is why the category never shows up when using Drivel with Drupal. To post entries with categories to an official Movable Type implementation, the client must first post the entry, then call mt.setPostCategories, and then call mt.publishPost. The mt.publishPost call is what seems to be confusing Drupal, as it doesn't appear to differentiate between a post that has been published with one which has. Movable Type does not publicly display posts which have not been published; it considers them as drafts which the author has not yet finished. Thus, Movable Type servers require the mt.publishPost call. I have Ethereal traces of several example posts to Drupal using both w.bloggar in "post" and "post and publish" mode, as well as Drivel. If you think they'd be useful in debugging, let me know and I'll forward them on to you. Cheers, Todd ------------------------------------------------------------------------ June 9, 2005 - 05:57 : mrmachine has anyone had a chance to look at this since Todd debugged it? ------------------------------------------------------------------------ June 13, 2005 - 22:56 : mrmachine can someone have a look at this? ------------------------------------------------------------------------ June 14, 2005 - 02:05 : walkah Attachment: http://drupal.org/files/issues/blogapi-publish-post.patch (634 bytes) having a look - it seems that mt.publishPost may well have been wiping the term info set by setCategory. As I only have ecto available to me currently, I can't test this patch... but if I understand the debugging work correctly - this should fix it. (the difference being ecto and MarsEdit - the two that I have access to currently - don't call publishPost). please confirm this fixes things... thanks. (I'll test more when I'm home again at the end of the week). ------------------------------------------------------------------------ June 15, 2005 - 01:06 : mrmachine beauty! this has fixed it for me! thanx shayne ------------------------------------------------------------------------ June 15, 2005 - 06:29 : baudolino This is not fixed until a decision about whether to commit this patch is made. Reverting this to patch status.

1 0

Re: [drupal-devel] forum module query optimisation
by Gabor Hojtsy 19 Jun '05

19 Jun '05

Cheers Dries, Replying on the development list. > did you had the chance to look into that forum.module SQL cleanup? Yes, indeed. The problem is that the logic buried in the forum code for handling shadow copies turns up too often, and I cannot get the picture. As far as I see, the whole code is too much reliant on having a $node->tid, which needs a query to become a property of the node object (thanks to forum_load()), and it is probbaly only possible to omit this query with deep overthinking of how forums work. The hook_link() and hook_view() implementations both need this tid. True, there is no need to have this tid just to display a list of forum topics, or some other metadata, but the whole node_load() concept is built upon the fact that you will need the data loaded in. So maybe those list displays need to use some light load mechanism. Oterwise there is no performance penalty of supporting shadow copies, since we would only replace {forum} with {term_node} in the often used queries, and would only remove some administrative (insert, update, delete) queries with dropping the shadow copy feature. Gabor

1 0

[drupal-devel] inline checkbox for attachements
by Bèr Kessels 19 Jun '05

19 Jun '05

Hi there, I am about to propose a solution to a client of mine for the attachments. She thinks the current system is **** horrible (well, in fact she said much more, but that is not poilite over the mailinglist) Amoungst the various options of additional modules (inline, img assist etc) I want to propose the Simple Solution too. Which would be another column in the attchements table for "inline". That would then call a theme function that gets a $node pointer passed along. y default all it will do is append image tags (if it is an image) or link tags, if it is a file to the article. That would be at filter time, so one will not see the HTML. I am: * Looking around first to find out how much chance that this makes it into core, since I will not "sell" a hacked core to this client. We have no proper hook to change that table, so maybe a third solution would be to introduce one. * Looking for additional ideas, on how to enlarge the chance this gets in core. * Thinking of how this will conflict with modules such as inline module. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

3 7

[drupal-devel] [SimpleTest] The Idea of new test working on WWW Layer
by Kuba Zygmunt 19 Jun '05

19 Jun '05

Hi, I would like to write below how I imagine a test, which acts like browser and checks accessibility of the contents. I've succesfully logged in Drupal, using SimpleTest class, so now I put my ideas and go to code. :-) We don't have access to the users existing in database, so we have to create 3 new test's users who will be deleted after finishing the test. 1. Creating users (3 steps) * insert in table {permission} 3 new perm. ( '', 'access content', 'access content, create stories, edit own stories' ) [ I'm working on story module :-) ] * insert in table {role} new roles (is this step is necessary? ) * insert in table {user} 3 new users * insert data in table {users_roles} to make a connection between users and roles. 2. Creating node (for example with uid = 1) I perform this because I will need this to check access of editing not own node. For each created user I will do : 3. Log into Drupal and check on access to: * content page * editing form * submit data for create node * submit data for editing node * submit data for deleting node and I will check access when node->uid != user->uid * editing form * submit data for editing node * submit data for deleting node -------- 4. Delete node 5. Delete users So, do you think that any additional tests need to be added ? Or Is my way of testing right? Regards, Kuba Zygmunt

2 1

[drupal-devel] Back from Chicago
by Dries Buytaert 19 Jun '05

19 Jun '05

Hello world, just a quick note to let you know I'm back from Chicago, and that I'll be working my way through the patch queue / e-mails in the next day or two. I already reviewed/committed some patches earlier this morning, and sent out several "pressing" e-mails. If something needs my attention, and I haven't got back to you by Wednesday evening, feel free to send me a reminder. Some Chicago pictures at http://www.buytaert.net/albums/chicago-2005/9/. -- Dries Buytaert :: http://www.buytaert.net/

2 1

[drupal-devel] [bug] if postgresql function
by igrcic 19 Jun '05

19 Jun '05

Issue status update for http://drupal.org/node/23499 Project: Drupal Version: 4.6.0 Component: forum.module Category: bug reports Priority: normal Assigned to: patrickslee Reported by: cchamilt Updated by: igrcic Status: patch Oops, maybe I screwed up something with formatting my post :( Hope you can fix it, sorry igrcic Previous comments: ------------------------------------------------------------------------ May 24, 2005 - 04:32 : cchamilt Postgresql function "if" is defined to return a boolean value, yet forum requests an integer - last_comment_uid. user error: query: SELECT n.nid, l.last_comment_timestamp, IF(l.last_comment_uid, cu.name, l.last_comment_name) as last_comment_name, l.last_comment_uid FROM node n, node_comment_statistics l /*! USE INDEX (node_comment_timestamp) */, users cu, term_node r WHERE n.nid = r.nid AND r.tid = 1 AND n.status = 1 AND n.type = 'forum' AND l.last_comment_uid = cu.uid AND n.nid = l.nid ORDER BY l.last_comment_timestamp DESC LIMIT 1 OFFSET 0 in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 62. warning: pg_query() [function.pg-query]: Query failed: ERROR: function if(integer, character varying, character varying) does not exist HINT: No function matches the given name and argument types. You may need to add explicit type casts. in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 45. ------------------------------------------------------------------------ May 24, 2005 - 22:07 : patrickslee Attachment: http://drupal.org/files/issues/forum.module_3.patch (2.69 KB) I have also encountered this bug and made a possible patch by replacing IF statements to CASE. A patch file is attached. ------------------------------------------------------------------------ May 24, 2005 - 22:28 : adrian There is an IF function defined in the database.pgsql function. On what page is this happening, as what might be happening is that the type isn't being picked up correctly. It's defined as IF(anyelement, anyelement, text) returns anyelement. IIRC. What I have seen happen is that it wants the text field to return integer, or vice versa. ------------------------------------------------------------------------ May 24, 2005 - 22:32 : patrickslee I found the definition in database.pgsql. It is like this: CREATE FUNCTION "if"(boolean, anyelement, anyelement) RETURNS anyelement AS ' SELECT CASE WHEN $1 THEN $2 ELSE $3 END; ' LANGUAGE 'sql'; So it is actually wanting boolean. ------------------------------------------------------------------------ May 24, 2005 - 22:43 : patrickslee So my patch will work, and we can make it easier by replacing the IF function to: IF(l.last_comment_uid 0 AND l.last_comment_uid NULL, cu.name, l.last_comment_name) BTW there is another place in forum.module use IF like this. ------------------------------------------------------------------------ May 24, 2005 - 22:45 : patrickslee Oops... my <>s are stolen. IF(l.last_comment_uid <> 0 AND l.last_comment_uid <> NULL, cu.name, l.last_comment_name) ------------------------------------------------------------------------ May 25, 2005 - 05:20 : cchamilt Yes that line works great. Thanks for your help! ------------------------------------------------------------------------ May 25, 2005 - 05:52 : patrickslee This patch shows another problem. The last post user will always show "Anonymous" or whatever you defined. Looking for solution... ------------------------------------------------------------------------ May 25, 2005 - 06:00 : patrickslee Use this line instead: IF(l.last_comment_uid <> 0 AND l.last_comment_uid <> NULL, cu.name, l.last_comment_name) Don't forget there are two places in forum.module need to be changed. ------------------------------------------------------------------------ May 25, 2005 - 06:10 : patrickslee Oh what have I done! I changed nothing! IF(l.last_comment_uid <> 0 AND l.last_comment_uid IS NOT NULL, cu.name, l.last_comment_name) ------------------------------------------------------------------------ May 25, 2005 - 10:12 : adrian perhaps we could also just add more wrapper functions for the specific types ? create or replace function IF (integer, anyelement, anyelement) returns anyelement as ' SELECT if (($1 0) AND NOT nullvalue($1), $2, $3); ' LANGUAGE 'sql'; Or something. ------------------------------------------------------------------------ May 25, 2005 - 10:41 : plj '' was missing. So what adrian actually means is this: CREATE OR REPLACE FUNCTION IF (integer, anyelement, anyelement) RETURNS anyelement AS ' SELECT if (($1 <> 0) AND NOT nullvalue($1), $2, $3); ' LANGUAGE 'sql'; I applied that and now forums work -- no module patches. PostgreSQL 7.4.7. ------------------------------------------------------------------------ May 25, 2005 - 10:45 : plj Sheesh. I meant that '<>' was missing. Gotta learn to use that preview button... ------------------------------------------------------------------------ May 25, 2005 - 21:53 : patrickslee Is nullvalue() a function? I cannot find it in neither postgres manual nor mysql manual. Use "IS NOT NULL" would be better as it is more standard-compatible. SO we have this: CREATE OR REPLACE FUNCTION IF (integer, anyelement, anyelement) RETURNS anyelement AS ' SELECT IF(($1 <> 0) AND $1 IS NOT NULL, $2, $3); ' LANGUAGE 'sql'; Looks we have a satisfying fix here. Is this fix going to be committed in CVS for next release? ------------------------------------------------------------------------ May 26, 2005 - 00:26 : adrian hostmaster=# \df nullvalue List of functions Result data type | Schema | Name | Argument data types ------------------+------------+-----------+--------------------- boolean | pg_catalog | nullvalue | "any" But it doesn't matter to me =) ------------------------------------------------------------------------ May 26, 2005 - 19:21 : Dries Can you guys provide a patch? I don't have a PostgreSQL setup to test it against. Will commit to DRUPAL-4-6 and HEAD. ------------------------------------------------------------------------ May 26, 2005 - 20:29 : patrickslee Attachment: http://drupal.org/files/issues/database.pgsql_3.patch (363 bytes) Here you have it. ------------------------------------------------------------------------ June 15, 2005 - 10:18 : igrcic Dont know about you guys but that patch doesnt work for me in drupal 4.6.1!? Im using PostgreSQL. Instead im using following function that works just fine if(integer,text,text) BEGIN IF $1 THEN RETURN $2; END IF; IF NOT $1 THEN RETURN $3; END IF; END; ------------------------------------------------------------------------ June 19, 2005 - 08:55 : Dries Just so you know: I'm not committing this patch yet because one user commented that it didn't work. Waiting for a follow-up from the PostgreSQL front. ------------------------------------------------------------------------ June 19, 2005 - 11:28 : igrcic Ok, here how it is now. First of all, forget my previous if FUNCTION :) Currenty im using drupal 4.6.1 and I had that problems with forums. Now Im using two if functions, because one is required for forums and I forgot for another another one, but I know that it was called because of different function parameters (bool, int). So one for the forum is : CREATE OR REPLACE FUNCTION "if"(integer, text, text) RETURNS text AS ' BEGIN IF $1 IS NOT NULL AND $1 > 0 THEN RETURN $2; ELSE RETURN $3; END IF; END; ' LANGUAGE 'plpgsql'; The another one is standard function that comes with drupal database.inc.pgsql file CREATE FUNCTION "if"(boolean, anyelement, anyelement) RETURNS anyelement AS ' SELECT CASE WHEN $1 THEN $2 ELSE $3 END; ' LANGUAGE 'sql'; Im using it for a while and everything works nice! Before I posted this topic I replaced function with that one in patch and it worked nice with this one too. But I know that once I had some error with it (didn't write it down grrr), so im stickin with the first function, because it work perfectly for me! And we have to have 2 functions, one for boolean and one for integer! In mysql it isnt so. Hope everything's clear now!

1 0

[drupal-devel] [bug] if postgresql function
by igrcic 19 Jun '05

19 Jun '05

Issue status update for http://drupal.org/node/23499 Project: Drupal Version: 4.6.0 Component: forum.module Category: bug reports Priority: normal Assigned to: patrickslee Reported by: cchamilt Updated by: igrcic Status: patch Ok, here how it is now. First of all, forget my previous if FUNCTION :) Currenty im using drupal 4.6.1 and I had that problems with forums. Now Im using two if functions, because one is required for forums and I forgot for another another one, but I know that it was called because of different function parameters (bool, int). So one for the forum is : CREATE OR REPLACE FUNCTION "if"(integer, text, text) RETURNS text AS ' BEGIN IF $1 IS NOT NULL AND $1 > 0 THEN RETURN $2; ELSE RETURN $3; END IF; END; ' LANGUAGE 'plpgsql'; The another one is standard function that comes with drupal database.inc.pgsql file CREATE FUNCTION "if"(boolean, anyelement, anyelement) RETURNS anyelement AS ' SELECT CASE WHEN $1 THEN $2 ELSE $3 END; ' LANGUAGE 'sql'; Im using it for a while and everything works nice! Before I posted this topic I replaced function with that one in patch and it worked nice with this one too. But I know that once I had some error with it (didn't write it down grrr), so im stickin with the first function, because it work perfectly for me! And we have to have 2 functions, one for boolean and one for integer! In mysql it isnt so. Hope everything's clear now! igrcic Previous comments: ------------------------------------------------------------------------ May 24, 2005 - 04:32 : cchamilt Postgresql function "if" is defined to return a boolean value, yet forum requests an integer - last_comment_uid. user error: query: SELECT n.nid, l.last_comment_timestamp, IF(l.last_comment_uid, cu.name, l.last_comment_name) as last_comment_name, l.last_comment_uid FROM node n, node_comment_statistics l /*! USE INDEX (node_comment_timestamp) */, users cu, term_node r WHERE n.nid = r.nid AND r.tid = 1 AND n.status = 1 AND n.type = 'forum' AND l.last_comment_uid = cu.uid AND n.nid = l.nid ORDER BY l.last_comment_timestamp DESC LIMIT 1 OFFSET 0 in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 62. warning: pg_query() [function.pg-query]: Query failed: ERROR: function if(integer, character varying, character varying) does not exist HINT: No function matches the given name and argument types. You may need to add explicit type casts. in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 45. ------------------------------------------------------------------------ May 24, 2005 - 22:07 : patrickslee Attachment: http://drupal.org/files/issues/forum.module_3.patch (2.69 KB) I have also encountered this bug and made a possible patch by replacing IF statements to CASE. A patch file is attached. ------------------------------------------------------------------------ May 24, 2005 - 22:28 : adrian There is an IF function defined in the database.pgsql function. On what page is this happening, as what might be happening is that the type isn't being picked up correctly. It's defined as IF(anyelement, anyelement, text) returns anyelement. IIRC. What I have seen happen is that it wants the text field to return integer, or vice versa. ------------------------------------------------------------------------ May 24, 2005 - 22:32 : patrickslee I found the definition in database.pgsql. It is like this: CREATE FUNCTION "if"(boolean, anyelement, anyelement) RETURNS anyelement AS ' SELECT CASE WHEN $1 THEN $2 ELSE $3 END; ' LANGUAGE 'sql'; So it is actually wanting boolean. ------------------------------------------------------------------------ May 24, 2005 - 22:43 : patrickslee So my patch will work, and we can make it easier by replacing the IF function to: IF(l.last_comment_uid 0 AND l.last_comment_uid NULL, cu.name, l.last_comment_name) BTW there is another place in forum.module use IF like this. ------------------------------------------------------------------------ May 24, 2005 - 22:45 : patrickslee Oops... my <>s are stolen. IF(l.last_comment_uid <> 0 AND l.last_comment_uid <> NULL, cu.name, l.last_comment_name) ------------------------------------------------------------------------ May 25, 2005 - 05:20 : cchamilt Yes that line works great. Thanks for your help! ------------------------------------------------------------------------ May 25, 2005 - 05:52 : patrickslee This patch shows another problem. The last post user will always show "Anonymous" or whatever you defined. Looking for solution... ------------------------------------------------------------------------ May 25, 2005 - 06:00 : patrickslee Use this line instead: IF(l.last_comment_uid <> 0 AND l.last_comment_uid <> NULL, cu.name, l.last_comment_name) Don't forget there are two places in forum.module need to be changed. ------------------------------------------------------------------------ May 25, 2005 - 06:10 : patrickslee Oh what have I done! I changed nothing! IF(l.last_comment_uid <> 0 AND l.last_comment_uid IS NOT NULL, cu.name, l.last_comment_name) ------------------------------------------------------------------------ May 25, 2005 - 10:12 : adrian perhaps we could also just add more wrapper functions for the specific types ? create or replace function IF (integer, anyelement, anyelement) returns anyelement as ' SELECT if (($1 0) AND NOT nullvalue($1), $2, $3); ' LANGUAGE 'sql'; Or something. ------------------------------------------------------------------------ May 25, 2005 - 10:41 : plj '' was missing. So what adrian actually means is this: CREATE OR REPLACE FUNCTION IF (integer, anyelement, anyelement) RETURNS anyelement AS ' SELECT if (($1 <> 0) AND NOT nullvalue($1), $2, $3); ' LANGUAGE 'sql'; I applied that and now forums work -- no module patches. PostgreSQL 7.4.7. ------------------------------------------------------------------------ May 25, 2005 - 10:45 : plj Sheesh. I meant that '<>' was missing. Gotta learn to use that preview button... ------------------------------------------------------------------------ May 25, 2005 - 21:53 : patrickslee Is nullvalue() a function? I cannot find it in neither postgres manual nor mysql manual. Use "IS NOT NULL" would be better as it is more standard-compatible. SO we have this: CREATE OR REPLACE FUNCTION IF (integer, anyelement, anyelement) RETURNS anyelement AS ' SELECT IF(($1 <> 0) AND $1 IS NOT NULL, $2, $3); ' LANGUAGE 'sql'; Looks we have a satisfying fix here. Is this fix going to be committed in CVS for next release? ------------------------------------------------------------------------ May 26, 2005 - 00:26 : adrian hostmaster=# \df nullvalue List of functions Result data type | Schema | Name | Argument data types ------------------+------------+-----------+--------------------- boolean | pg_catalog | nullvalue | "any" But it doesn't matter to me =) ------------------------------------------------------------------------ May 26, 2005 - 19:21 : Dries Can you guys provide a patch? I don't have a PostgreSQL setup to test it against. Will commit to DRUPAL-4-6 and HEAD. ------------------------------------------------------------------------ May 26, 2005 - 20:29 : patrickslee Attachment: http://drupal.org/files/issues/database.pgsql_3.patch (363 bytes) Here you have it. ------------------------------------------------------------------------ June 15, 2005 - 10:18 : igrcic Dont know about you guys but that patch doesnt work for me in drupal 4.6.1!? Im using PostgreSQL. Instead im using following function that works just fine if(integer,text,text) BEGIN IF $1 THEN RETURN $2; END IF; IF NOT $1 THEN RETURN $3; END IF; END; ------------------------------------------------------------------------ June 19, 2005 - 08:55 : Dries Just so you know: I'm not committing this patch yet because one user commented that it didn't work. Waiting for a follow-up from the PostgreSQL front.

1 0