[C] Basic libpq-based driver

[lidavidm]

The driver supports basic queries (int32 only) and toggling autocommit. It does not yet support bulk ingestion or prepared statements.

It hasn't been optimized for speed and the approach taken here will not be fast (it uses the per-row getters). In future PRs, we should set up some benchmarks and then see if DuckDB's approach makes more sense (use COPY). DuckDB also does multithreading (that might be hard for us). We may want to implement #61 first since then we will know whether it is safe to use COPY or not.

[paleolimbot]

Just musing at ways I could make this easier to do!

[paleolimbot]

This is redundant, no?

[lidavidm]

Fixed - thanks for catching that!

[paleolimbot]

I should probably add ArrowArrayInitFromSchema() (to match the recently added ArrowArrayViewInitFromSchema())

[paleolimbot]

After the last PR, calling ArrowArrayFinishBuilding() on the parent array will propagate to child arrays

[paleolimbot]

I think I have enough general infrastructure now to make a generic ArrowArrayReserve() that seems like it would cut down a bit of verbosity here

[lidavidm]

Rebased/updated. This now tries to use the COPY command, taking advantage of the changes in #69.

Things that need to happen next:

• Build a type mapping table on startup
• Handle null values, more types
• Work out some of the error handling details that were left as TODOs (and probably do some refactoring)
• Handle bulk ingestion
• Handle prepared statements
• Add tests for queries that don't return result sets
• Start adding benchmarks to help guide the rest of the design
• Make sure concurrent statements don't interfere with each other/internal locking

[paleolimbot]

This seems like it's going to be a common pattern...should nanoarrow provide a C++ header for this?

class ArrayHolder {
public:
  struct ArrowArray array;
  ArrayHolder() { array.release = nullptr; }
  ~ArrayHolder() { if (array.release) array.release(&array); }
}

[lidavidm]

Possibly, I was also going to file an issue/PR for stringifying type codes, etc. to use in error messages

[paleolimbot]

You may want to ArrowArrayViewInitFromSchema(&array_view, &schema) once on the top level and then do ArrowArrayViewSetArray(&array_view, &array) in the loop. (Then you can do array_view.children[i].stuff).

[paleolimbot]

I think you're missing a ArrowArrayViewReset(), too (although it won't leak memory unless the array has children).

[lidavidm]

Thanks, I also did a bit of templating and implemented the ArrayHolder above (slightly more generically)

[paleolimbot]

Is this line necessary?

[lidavidm]

I'm mostly trying to be defensive here

[paleolimbot]

I don't really mind either way, although I personally find it a bit confusing since it's a MUST in the spec that the release method has to take care of that.

[lidavidm]

Ah, right. I'll update it then.

[lidavidm]

I'm going to punt on most of the other tasks for now (see #81) so I can get this packaged in #57 before continuing to implement things.