Few days ago I read interesting article about non-trivial syntax of JavaScript.

And today I had the chance to met using of this kind magic in real practice. Let me show this small example.

I have a simple form with one field which always have to be filled for success submitting, to reduce a cycles of interaction between server and client browser I’d like to use JavaScript that will check form before submitting and prevent cause when user forgot fill value. Below I show the piece of code that we can solve this problem:

I think it’s cleae and doesn’t require any explanations. Now suggest hypothetical situation when we don’t like write special function for checking only one field and would like to put it directly in onchange attribute, how will code look in this case?

This code looks terrible and mixed, but I wouldn’t like to discuss it here, because my purpose here in other. I’d like to show way to use inline handlers function in general. That’s all.

Quote:

Note: The closing tag of a PHP block at the end of a file is optional, and in some cases omitting it is helpful when using include() or require(), so unwanted whitespace will not occur at the end of files, and you will still be able to add headers to the response later. It is also handy if you use output buffering, and would not like to see added unwanted whitespace at the end of the parts generated by the included files.

Source

So the answer is clear, if you are writing class or other library files it’s better not use closing PHP tag in other scrips it’s better to use I had near time ago this kind of problem when we deploy project into new hosting and suddenly warning appeared in one place. Fortunately, I found out the source of problem without much efforts, but as I see know it can be easy to exclude with help preventive actions.

I met some situations when old SQL queries don’t work under server v5.0.18. Of course I didn’t read before any migrations recommendations guides or something like this (I think, I’m not one like this). So I have just knew about this incompatibilities. I will fix here my experience with, that it help me to avoid errors like this in my sunny feature:

• Previously, the comma operator (,) and JOIN both had the same precedence, so the join expression t1, t2 JOIN t3 was interpreted as ((t1, t2) JOIN t3). Now JOIN has higher precedence, so the expression is interpreted as (t1, (t2 JOIN t3)). This change affects statements that use an ON clause, because that clause can refer only to columns in the operands of the join, and the change in precedence changes interpretation of what those operands are.

  Example:

  CREATE TABLE t1 (i1 INT, j1 INT);
  CREATE TABLE t2 (i2 INT, j2 INT);
  CREATE TABLE t3 (i3 INT, j3 INT);
  INSERT INTO t1 VALUES(1,1);
  INSERT INTO t2 VALUES(1,1);
  INSERT INTO t3 VALUES(1,1);
  SELECT * FROM t1, t2 JOIN t3 ON (t1.i1 = t3.i3);

  Previously, the SELECT was legal due to the implicit grouping of t1,t2 as (t1,t2). Now the JOIN takes precedence, so the operands for the ON clause are t2 and t3. Because t1.i1 is not a column in either of the operands, the result is an Unknown column 't1.i1' in 'on clause' error. To allow the join to be processed, group the first two tables explicitly with parentheses so that the operands for the ON clause are (t1,t2) and t3:

  SELECT * FROM (t1, t2) JOIN t3 ON (t1.i1 = t3.i3);

  Alternatively, avoid the use of the comma operator and use JOIN instead:

  SELECT * FROM t1 JOIN t2 JOIN t3 ON (t1.i1 = t3.i3);

  This change also applies to statements that mix the comma operator with INNER JOIN, CROSS JOIN, LEFT JOIN, and RIGHT JOIN, all of which now have higher precedence than the comma operator.

The piece was taken from official site of MySQL.

I met with subject problem. I wasted couple of hours before tried to find something about this problem in google and unfortunately I was success I told “unfortunately”, because it means that problem really exists, and while I didn’t find it I still thought that I just don’t understand something there and/or do something wrong.

Any way, I’d like fix now this experience in my blog (it is my electronic extension of usual memory

There guy describe the same problem and there I found mention about FAQ.

Other page with the same problem.

Link to section in FAQ.

Quote from FAQ:

4.19) Why do I get “relation with OID ##### does not exist” errors when accessing temporary tables in PL/PgSQL functions?

PL/PgSQL caches function scripts, and an unfortunate side effect is that if a PL/PgSQL function accesses a temporary table, and that table is later dropped and recreated, and the function called again, the function will fail because the cached function contents still point to the old temporary table. The solution is to use EXECUTE for temporary table access in PL/PgSQL. This will cause the query to be reparsed every time.