mpartel / postgres-protobuf Goto Github PK

Hello,

I get wrong results when fetching nested repeated fields. I'm not sure what I missed since this use case seems to be tested here

SELECT protobuf_query_multi(
  'pgpb.test.ExampleMessage:repeated_inner[*].inner_repeated[*]',
  '\x2a0a120361626312036465662a0a12036161611203626262'::BYTEA
) AS result;
result
abc
def
aaa
bbb
(4 rows)

I created a repo in order to reproduce it: https://github.com/Allsimon/postgres-protobuf/blob/bug/reproduction/bug/README.md

Hello,

Thank you for this library. I was following the instructions to make this library work to parse my Probuf data however, this is not compatible with Postgres-14.

There should be an easy and correct way to construct queries like some_map_field[?] where ? can be any string.

We are using protobuf to transmit real-time telemetry of watercraft over GSM. We'd be interested in storing the original protobuf messages rather than decoding so I'm curious if your lib supports the following:

1. is this mature enough to suggest for production use
2. can we query the protobuf columns for data?
3. can we avoid the serialiation to/from JSON and just export pure protobuf
4. we are considering using TimescaleDB and we'd like to rely on their aggregate functions... do you happen to now if this would be compatible?

Hi,

more an Info than an Issue...

To compile postgres-protobuf 0.2.0 to be used with a Postgres 11.7 compiled from source on Centos 8 (8.1.1911) with g++ (GCC) 8.3.1 20190507 (Red Hat 8.3.1-4) I needed to add the two arguments

-lz -lstdc++

to the PG_LDFLAGS line in the Makefile.

Otherwise I would get undefined symbols when executing CREATE EXTENSION.

Thanks,
Chris.

Hi,

thanks for the nice extension!

I've found a problem related to floats... When floats are decoded to text by protobuf_query() or
protobuf_query_array() precision is (heavily) lost.!

The floats appear to be decoded here:

using std::to_string(), which corresponds to sprintf("%f", ..) and would always print with six digits right to the decimal point.

So, for example a value like 1.0E-7 just get decoded to the text '0.000000' :(

I'm going to need to patch around this for my use case, maybe with a custom sprintf("%e", ..) for floats in particular.

Do you have any suggestion?

I would be willing to do a pull request...

-- Chris