It turns out i have been **years** doing this wrong: you are supposed to
pass that value as a text, like 'CURRENT_TIMESTAMP', not like the
keyword so that it returns the current timestamp as a timestamptz.
However, i have been doing it wrong because of a bug in previous
versions of pgTAP[0], that did not take into account keywords such as
CURRENT_TIMESTAMP or CURRENT_DATE and was comparing their actual values,
not the names, therefore i thought that i misread the documentation.
Only now have discovered this because Debian 12 upgraded pgTAP version
to 1.2.0.
[0]: https://github.com/theory/pgtap/issues/244
It all started when i wanted to try to filter invoices by multiple tags
using an “AND”, instead of “OR” as it was doing until now. But
something felt off and seemed to me that i was doing thing much more
complex than needed, all to be able to list the tags as a suggestion
in the input field—which i am not doing yet.
I found this article series[0] exploring different approaches for
tagging, which includes the one i was using, and comparing their
performance. I have not actually tested it, but it seems that i have
chosen the worst option, in both query time and storage.
I attempted to try using an array attribute to each table, which is more
or less the same they did in the articles but without using a separate
relation for tags, and i found out that all the queries were way easier
to write, and needed two joins less, so it was a no-brainer.
[0]: http://www.databasesoup.com/2015/01/tag-all-things.html
I had to use a deferrable foreign key because the payment methods have
a reference to the company, and the company now a circular reference to
payment method.
jordi fita mas