SQL: fix function definition of ticket_dependee_missing

[a-tze]

SQL: fix function definition of ticket_dependee_missing, fixes #199

[pegro]

I guess the patch fixes the issue, but somehow I feel it would be more obvious to have "tbl_ticket dependee" as the FROM clause (and all the joins in reverse order), since dependee is used in SELECT, not depender (which is the now the FROM clause). If I'm not mistaken this should result in fewer LEFT JOINS, or am I missing something?

[a-tze]

Interesting suggesstion... I'll try to refactor the function and EXPLAIN it.

[a-tze]

Maybe you missed that "ep" and "epv" are also SELECTed, even before "tbl_ticket dependee" (of course this is only the view of an imperative programmer with the concept of lazy evaluation in mind and doesn't actually apply here).
However, if the order of joins is reversed, then "ep" and "epv" are at the end of the JOIN chain, nothing gained. The execution plan is almost identical for both versions, and the estimated costs are completely equal on my system (4.43..24.75).
I'm not sure if PostgreSQL would use some shortcuts when doing the actual query.

For me it was more obvious to "crawl" from the given depending ticket to the unknown dependee ticket.

Another approach to get rid of all those JOINS (in multiple places) would be to keep track of the dependee via a dedicated column in tbl_ticket. It is seldomly changed but read extremely often (view_servicable_tickets etc.)

[jjeising]

Another approach to get rid of all those JOINS (in multiple places) would be to keep track of the dependee via a dedicated column in tbl_ticket.

If we do that we should combine the effort with other planed cached values and columns, see #167.

[a-tze]

If we do that we should combine the effort with other planed cached values and columns, see #167.

Of course, but the intention of this PR was bugfixing.

[a-tze]

Turns out, the actual bugfix comes from not returning null, but changing the default return value to true was indeed wrong.

[pegro]

Should be fine