PostgreSQL & MS SQL Server: PDO error on forum administration interface first access

I cannot reproduce this problem.

What is the module that requires ACL on your site? What exactly are you doing that produces this error?

What database are you using?

We have thousands of sites that are running the FA+ACL combo without any problems...

Ah, that explains it...

Is it pgsql blowing up if the $subselect returns an empty set?

No, we won't turn one query into two to accommodate pgsql's quirks. What we can do is special-case pgsql and count the records, and skip the existing query if there's none.

As I wrote above: We have thousands of sites that are running the FA+ACL combo without any problems...

Your site is the only one that has this problem, and I attribute it to pgsql. pgsql will give you headaches wherever you go in the Drupal world...

From here, the query doesn't even reach the database layer, is the PDO stopping the action as the tid parameter is lost when the query is constructed.

My interpretation of the error message is that the database is complaining that the result of the subselect is empty ("Array( )"). I don't see any other "parameter number" that could be "invalid".

What do you mean with "the tid parameter is lost"?

BTW, there certainly are tests, the testbot must have had a bad day.

#4: pdoerror-1815158.patch queued for re-testing.

Always use HEAD...

#4: pdoerror-1815158.patch queued for re-testing.

Similar pgsql issues:
#1807356: PostgreSQL: "Object not in prerequisite state" error when trying to create a user
#1320148: Install error on PostgreSQL

Needs work as per #11.

Same problem on MS SQL Server.

same problem here on PostgreSQL

See #11 — we need a patch that does not punish MySQL and does not risk retrieving and feeding back a huge number of nids.

I was able to at least successfully apply the patch in #4, as I too am using Postgresql with the access_forum module.

As for this working with other DB's, it's not an issue of taking into account other DB's idiosyncrosies, but doing proper testing and coding to make sure that your module isn't going to break because someone's not using the most popular DB. Drupal supports several DB's and therefore the modules should be properly coded and tested to work with those. If a module developer doesn't want to take that extra step, then they should state so in their description, not take someone to task for using a less popular DB.

I hit this exact same issue on a new build using Postgres. As people have said, the patch in #4 works.

I've come up with a change to it that will hopefully limit the number of nids coming back from the database. I think it is easier this way than to try to sniff all the possible database types from $database.

I'd also like to echo the sentiments of #23, an open source developer should help the community have choice in the stack they run on rather than just blame the stack if it is not the majority choice.

doing proper testing and coding

It's easy to say what others should do, especially when you don't pay for their work. I'm not "taking anyone to task for using a less popular DB." PostgreSQL is a marginal database in the Drupal world. If YOU choose to use it, then YOU have to provide for testing and coding, unless someone else happens to do it for you. In the case at hand, no one has done it yet, so...

We have 5 people in this thread with this issue, compared to 20'000 known sites apparently running ACL without this problem, 13'000 under D7. The time wasted to discuss who should do what already far outweighs your fair share of the maintenance effort.

The patch in #24 changes the behavior of the function for 13'000 sites, IOW you're potentially breaking 13'000 sites in your attempt to fix a problem on 5 sites!

The first step towards a solution is to analyze the problem. So far no one has cared to find out and explain what exactly pgsql is complaining about...

make that 6 people. just ran into the same problem.

have these patches been integrated into the -dev version?

re: PostgreSQL, my drupal 7.latest-on-postgresql site has dozens and dozens of modules and they all work just fine. I just added ACL so I could use forum_access, now noone can post to the advanced forum.

again, the error appears to be in the PDO layer

PDOException: SQLSTATE[HY093]: Invalid parameter number: parameter was not defined: INSERT INTO acl_node (nid, acl_id, grant_view, grant_update, grant_delete, priority) SELECT n.nid AS nid, 4 AS acl_id, 1 AS grant_view, 1 AS grant_update, 1 AS grant_delete, 0 AS priority FROM taxonomy_index n WHERE (n.tid = :db_condition_placeholder_1) ; Array ( ) in acl_add_nodes() (line 115 of /home/observers/drupal-7.28/sites/all/modules/acl/acl.module).

Thats being thrown from this code, but I don't understand this php/drupal abstraction stuff, there's no SQL there.

function acl_add_nodes($subselect, $acl_id, $view, $update, $delete, $priority = 0) {
  db_delete('acl_node')
    ->condition('acl_id', $acl_id)
    ->condition('nid', $subselect, 'IN')
    ->execute();
  $subselect->addExpression($acl_id, 'acl_id');
  $subselect->addExpression((int) $view, 'grant_view');
  $subselect->addExpression((int) $update, 'grant_update');
  $subselect->addExpression((int) $delete, 'grant_delete');
  $subselect->addExpression($priority, 'priority');
  db_insert('acl_node')
    ->from($subselect)
    ->execute();
}

If you can't fix this, please post in big giant letters on your ACL home page that THIS MODULE IS MYSQL ONLY.

I outlined the type of patch that I'd accept in #11, #18, and #22. The code for MySQL must not change.

I'm not saying that I can't fix this, but that I'm waiting for a viable patch plus reviewing/testing from the pgsql subcommunity...

Still no one who is willing to find out what pgsql is really complaining about and to provide a patch that keeps MySQL safe?

This might work...