Done.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

The Elixir.Normalizer lets us feed any arbitrary AST to the formatter, but if the user provides a list, and an element is a 2-tuple that is not one of the last elements, and the first element is a wrapped atom with format: :keyword metadata, then the formatter will happily print it as a keyword list element, despite it being invalid syntax, for example:

iex> opts = [literal_encoder: &{:ok, {:__block__, &2, [&1]}}]
iex> {_, _, [[tuple]]} = Code.string_to_quoted("[a: b]", opts)
iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[a: b, :not_a_tuple, a: b]"

With this PR we would get the expected output:

iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[{:a, b}, :not_a_tuple, a: b]"

The Elixir.Normalizer lets us feed any arbitrary AST to the formatter, but if the user provides a list, and an element is a 2-tuple that is not one of the last elements, and the first element is a wrapped atom with format: :keyword metadata, then the formatter will happily print it as a keyword list element, despite it being invalid syntax, for example:

iex> opts = [literal_encoder: &{:ok, {:__block__, &2, [&1]}}]
iex> {_, _, [[tuple]]} = Code.string_to_quoted("[a: b]", opts)
iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[a: b, :not_a_tuple, a: b]"

With this PR we would get the expected output:

iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[{:a, b}, :not_a_tuple, a: b]"

@ericmj Yeah that sounds fine to me. As stated, just trying to get some clarity. So what I'm hearing and off-topic from this PR, but worth aligning on now I think is that we don't any granular validations (this includes meta validations that were going to go in hex_tarball). Does that sound right?

Maybe the same change should be done for the streaming of a prepared query?

I will review this soon but I just want to say the answer to this question is yes. :)

ok will do :)

Describe the bug

It's impossible to call this copy constructor. The reason is that the color constructor above it matches a four element tuple (for {r, g, b, a}) and a wx_ref is also a four element tuple. Possible solutions might be to put record pattern matches above colors or to have color pattern matching check that at least their first element is a number.

To Reproduce

1> wx:new().
{wx_ref,0,wx,[]}
2> T = wxTextAttr:new().
{wx_ref,35,wxTextAttr,[]}
3> wxTextAttr:new(T).
** exception error: {{badarg,"colText"},{wxTextAttr,new,2}}
     in function  wxe_util:rec/1 (wxe_util.erl, line 110)

Expected behavior

It should not crash. It should return a reference to a new wxTextAttr instance.

Affected versions

OTP 24

Maybe the same change should be done for the streaming of a prepared query?

I will review this soon but I just want to say the answer to this question is yes. :)

@lukebakken Published

Yeah there’s tension between docs/specs and what the server allows. Good point about the downsides.

It is tangentially related but we have some validations in hex_tarball module but eventually we want to have more. I feel like there it is more appropriate given hex_tarball hopes to encapsulate whatever we’d ever need to do with tarballs. For Hex HTTP API, as far as hex_core is concerned, we only implement the client side of things and we don’t have plans to implement the server side of things anytime soon or ever. So relying on the server to do validations seems appropriate here.

I don't have strong feelings. Months and months backs we discussed doing this as a way to save trips to the server for a few reasons, and we were all in agreement then, despite the con of having to update both. That said, I'm quite ok with ripping it out.

I'd say keep atom keys IMO, the issue I ran into was atom values, not keys. Of course, having some context on why the server rejects binary values such as <<"api">> but accepts atom keys might help here.

Yeah, I agree. I suppose I have bias in that in rebar3_hex we would simply dump this to stdout. Other options would be :

1. Return an atom, but wouldn't be very descriptive, but maybe it really doesn't have to be.
2. Return a binary, still would be a little weird.
3. Return a string or a binary that's not as descriptive, but doesn't end up as an io list.

Yeah, the other day I was wondering why some stuff was written as Shell script vs JavaScript, myself. I think it should only be so when execution is needed in the target platform (e.g. I want to get the Elixir version from Elixir to make sure the installation process was Ok) - but most other stuff could be converted to JS... anyway, I've linked this to the newer issue, so your comments will be ported over also. Thanks for the help.

This PR fixes https://github.com/elixir-ecto/postgrex/issues/550

The change to recv_parse_describe ensures that in case the Protocol & Query's types differ, the Query gets a new ref (to trigger an update to the Ecto cache) and gets the Protocol's types (both of these are done in describe_result/4).

Todo:

• [ ] Maybe the same change should be done for the streaming of a prepared query?

Makes sense. I pushed a change for that.

Good, so this can be resolved.

So far I was not able to reproduce this issue.

I think it may be explained by the fact that voluntarily I can break connection between nodes only in a predictable and conventional way. My user rights in the environment where I observed this situation are limited: I'm not able to kill docker container neither with erl process (my application) nor with istio (networking).

I tried to reproduce the issue just by killing erl process on one of cluster nodes from inside the docker container shell, but this is handled correctly, and I observed only expected behavior.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

Since https://github.com/elixir-ecto/postgrex/pull/547, Postgrex requires elixir v11 or superior.

Since https://github.com/elixir-ecto/postgrex/pull/547, Postgrex requires elixir v11 or superior.

It's my understanding that defined macros are bound to {none,[Expr]} in that map, so there should be no issue.

No, the value for your dummy macro would be represented as [{atom,Anno,undefined}], which is different from undefined used to mark a pre-defined macro currently without a value.