Michael Dyrynda

Yeah, I thought as much.

I'm happy to accept a PR for this, but as I don't use PG myself, I've no mechanism to test it.

@tpetry Is the right path forward here that we: * Just document how to use the appropriate field type with existing migration methods, * Update the `typeEfficientUuid` macro to use...

I've opened a PR against the [laravel-model-uuid](https://github.com/michaeldyrynda/laravel-model-uuid/pull/116) repo, but haven't been able to come up with a failing test case. I've been unable to reproduce this in my [testing](https://github.com/michaeldyrynda/laravel-model-uuid/pull/116/files#diff-3485df8feaec79aefc94ca92069ffd2c92c73a673113b899e67b4c32a2900975R289-R334), so...

It's a horrible cyclic dependency I hope to solve in the next major version 😅

Hmm, that’s curious. I wonder if the nullable package was causing the binary `template_id` to be cast to a string when it was being checked for `null`.

I'd much rather document this and provide one concrete way to address it. Providing an exception handler is tricky because users of the package possibly won't be able to just...

I think I’m going to merge the efficient uuid package into this one, release a new major, and EOL the other. I have no end of trouble with the interdependency...

The tricky thing I found with aligning of the comments, is that Laravel uses two spaces to separate the annotation, the type, and the variable name - they're not aligned...

Does that add a blank line before the `@return` annotation? Is there a separate config setting to prevent this?