PostgreSQL Library

[ciozi137]

I put "everything PQ" into "PQ.lvlib"* and I was able to build the test PPL. When I added the existing PQ classes to PQ.lvlib I had to fix an error inside "Connection Record.vi" unbundle to get the DVR. Perhaps that was the root of the problem before, but creating "PQ.lvlib" let me fix the problem before building.

 

*thanks to @Francois Normandin for the lvlib hint

Edited January 15, 2025 by ciozi137

[drjdpowell]

1 hour ago, ciozi137 said:

When I added the existing PQ classes to PQ.lvlib I had to fix an error inside "Connection Record.vi" unbundle to get the DVR.

What was this error?  I can't seem to reproduce it.

[ciozi137]

Hi James, I can't seem to reproduce the error now either. Basically when I added the classes to "PQ.lvlib" LabVIEW had trouble finding the correct cluster element in this unbundle by name. I suspect the same problem was happening behind the scenes during the PPL build (?).

[Dpeter]

This is where the issue is.  The record of open connections has a type issue with DVR for whatever reason.  I've gotten the library working by making a packed library of all the commands that I need to use, and running diagram disables to remove all calls to Result Record.vi and Connection Record.vi (where the multi threading is handled).  I wonder if it is because the DVR section is not a type def or a strict type def.

[drjdpowell]

11 hours ago, Dpeter said:

I wonder if it is because the DVR section is not a type def or a strict type def.

Does making it a typedef prevent the problem?

[ciozi137]

@drjdpowell I’ve tried to reproduce the error with the DVR but so far unsuccessful. 
 

when you have a chance can you review or comment latest pull request? Targets mostly libpq install, threading, etc. thanks

[jyoung8711]

@drjdpowell -- I'm not sure how much use this library gets, or if there's a desire to continue maintaining it.  I had a need to integrate this into a common reuse library to replace the .NET API (Npgsql).

As part of that integration process I had a couple of support features I found a need for:

1. support for [null] data in both writing with parameters and in checking if a resulting element is null.
2. support for pulling out the datatype of columns when reading results.
3. pulling a result element back as a LV variant (rather than the explicit type) -- I believe the sqlite library supports this but postgresql did not.

I have a version that I've completed which includes these updates.  I'd be willing to integrate into the repo and make a pull request, but before going through that effort, I thought I'd check to see if that was of interest.  Let me know.

(I was going to log these things as issues/requests on bitbucket, but it appears that atlassian has migrated the "issues" interface to Jira, so that doesn't seem to work like it used to)

Thanks!