Added FORMAT(binary) copy capability and example

[cpiker]

Hi Denizzzka

The dpq2 library met most of my needs, but a small update was added to assist with fast binary copy-in. The changes are:

1. The function Connection.putCopyData was overloaded to take const(ubyte[]) values since these are common for raw data.
2. The example.d file was updated to include an explicit binary copy-in example for variable length BYTEA types in a tight loop
3. example.d was given a dub --single recipe to make it easier to build.

I certainly don't expect you to accept these changes upstream, but wanted to offer them in case they are useful.

Thanks for creating dpq2!

[denizzzka]

Maybe it makes sense to hide this predefined constant in a separate method?

[cpiker]

Oh it certainly does.

This code is an extract of essential features from my application code that uses dpq2. I just wanted to get a working example to you and others for polishing. Preferably by someone who understands the guiding principles of dpq2 better than I.

[denizzzka]

In the dpq2.conv.from_d_types module we have converter for (almost) all supported types. Actually, it converts D values into Value struct, but it is possible to extract needed code into a separate codeblock

[denizzzka]

Hello! Thank you very much!

I think this is a good improvement because sometimes it is very necessary to quickly fill a database with a large amount of data. Usually this is a rare operation, but if you need it then there are no workarounds.

[cpiker]

Thanks for the encouraging comments :-)

Would it be possible to accept the pull and then convert it right away to a more canonical example? I'm much more confident in your ability than my own in this regard. For example when reading the library I didn't quite understand the BSON features, but I'm guessing they are applicable here?

If this sounds reasonable, then maybe it would make more sense for me to send a pull request to a different branch.

[denizzzka]

Would it be possible to accept the pull and then convert it right away to a more canonical example?

I find it hard to write code "for the drawer", because I don't need this functionality now.
You know better what is required. Just start - I will help.

I'm much more confident in your ability than my own in this regard. For example when reading the library I didn't quite understand the BSON features, but I'm guessing they are applicable here?

No, we can decide to not support it at first.

BSON support was added to dpq2 primarely to support displaying of "any type value" - for example, for debugging purposes, etc. Something like Value.as!Bson.toString.

It was later replaced in this capacity by std.variant.Variant (

dpq2/src/dpq2/value.d

Line 105 in ac6057c

return this.as!Variant.toString~"::"~oidType.to!string~"("~(format == ValueFormat.TEXT? "t" : "b")~")";

).

It is high time to make Bson support by optional dependency.

[cpiker]

I find it hard to write code "for the drawer", because I don't need this functionality now. You know better what is required. Just start - I will help.

Sounds good, will do. Feel free to ignore this pull request. I'll submit another much later this evening.

Also, I'm also seeing issues when building under GDC-13. Namely:

src/dpq2/result.d:749:5: error: alias this for classes/interfaces is deprecated [-Werror=deprecated]
  749 |     alias result this;

I can of course add a compile flag, but would prefer not to if possible. I presume you'd want updates for this issue in a separate pull request? If not I can try to address both topics at once.

It is high time to make Bson support by optional dependency.

Looking over the recursive dependency list for dpq2 I see:

 |-dpq2
    |-derelict-pq
    |  |-libpq   [System Lib]
    |  |    
    |  |-derelict-util
    |
    |-money
    |
    |-vibe-serialization
       |-vibe-container
          |-stdx-allocator
            |-mir-core

as well as Phobos of course. Since I'm carefully tracking dependencies as my project moves into production, how many of these dependencies would no longer be required if I were to use a "no-BSON" version of dpq2?

[denizzzka]

I can of course add a compile flag, but would prefer not to if possible. I presume you'd want updates for this issue in a separate pull request?

Yes, that would be great!

as well as Phobos of course. Since I'm carefully tracking dependencies as my project moves into production, how many of these dependencies would no longer be required if I were to use a "no-BSON" version of dpq2?

vibe-serialization and its children, I think

Also, money module... It is possible to try to get rid of d-money package too. It will be a similar approach, but smaller