Dimitris Halatsis

I also believe that this is a really important missing feature as also discussed in: - https://github.com/prisma/prisma/discussions/3929 - https://github.com/prisma/prisma/discussions/7480 I find it necessary in order to keep the DRY principle....

That would be really useful. Especially with applications like Zoom on Linux, where you have to manually switch the audio profile to connect to a Bluetooth headset in HSP mode....

it is as simple as just sending a date instance object to be logged. ex: ```js 'use strict'; const FluentLogger = require('fluent-logger'); const logger = FluentLogger.createFluentSender('SOME_PREFIX', { host: '127.0.0.1', port:...

So it is due to the inability of the actual FluentD daemon to understand the extension types that are not properly handled? Because the actual date packer just uses Number...

Hmmmm, I understand. I believe that since `Date` could be commonly logged in javascript since it is a native type, it should be logged as ISOString as a generic form...

I think just adding the extra packer as you did above is a good choice. I don't think the performance overhead is that limiting. Also if we convert it manually,...

Hi @FedericoMassaioli . Could you please give me some extra details about the problem you are facing since I am not extremely familiar with PostgreSQL? - Isn't `nlike` supposed to...

Ok nevermind, I saw how the `nlike` is translated to PostgreSQL [here](https://github.com/strongloop/loopback-connector-postgresql/blob/beedf56f171b86ffbedf412ec708916c351c9ef7/lib/postgresql.js#L509) So since the actual values in the `like`, `nlike`, etc.. are not expected to be RegExp in all...

@FedericoMassaioli you are right. My SQL was a bit rusty 😄 ... > After looking at the code you referenced, I devised the workaround of escaping with a double backslash...

> It works with the escape I added. When escapeRegEx() sanitized the original string it didn't return the same results, but this was discovered on a live DB, undergoing modifications...