On 10 June 2013 20:07, pba <p...@mailme.dk> wrote:
>
> I use the Postgis quite a lot for a couple of projects.
Welcome to the club :)
> In the backend/psotgresql/statement.cpp describe_column function the typeoid
> is used for determining actual soci type. This works fine for the built-in
> PostgreSQL types since the OID's are hard coded.
>
> However for user defined types this will not work. As far as I understand we
> are not guaranteed that they will remain static.
In general, they are not guaranteed, but in practice, they usually work.
However, I agree it's that kind of assumption which is week.
> Again as far as I
> understand these user defined types are usually handled as strings.
I'm not sure what you mean as "user defined types".
What types? C++ user-defined types with type conversion enabled for SOCI,
or DBMS user-defined types?
>From your previous paragraph, I suppose you mean the DBMS one like
GEOMETRY or RASTER in PostgreSQL, is that right?
For PostgreSQL, currently, we always use text-mode transfer, so it is safe to
fallback to dt_string indeed, but I wouldn't say there is such rule saying
that DBMS user-defined types are always handled as strings.
> A proposal could be something like the following where we check for a string
> representation with an undefined size and take a "guess" that this will be a
> dt_string type.
>
> Does anybody know if this is a valid assumption ?
>
> default:
> {
>
> int form = PQfformat(result_, pos);
> int size = PQfsize(result_, pos);
> if (form == 0 && size == -1)
It means: textual data representation of variable length
> {
> type = dt_string;
> }
> else
> {
> std::stringstream message;
> message << "unknown data type with typelem: " << typeOid << "
> for colNum: " << colNum << " with name: " << PQfname(result_, pos);
> throw soci_error(message.str());
> }
> }
I think it's sensible.
By the way, I have been prototyping binary data support with relation to data
types like GEOMETRY or RASTER in PostgreSQL/PostGIS.
You take a look at it here, in dedicated branch
https://github.com/mloskot/soci/tree/soci-type-binary
If you simply grep for "binary", you will see not-so-many changes really.
I'm aiming to update Boost support with Boost.Geometry conversions;
https://github.com/mloskot/soci/blob/soci-type-binary/src/core/boost-geometry.h
Here you can see examples:
https://github.com/mloskot/soci/blob/soci-type-binary/src/examples/example1.cpp
I have been neglecting this work for a while now and I haven't caught up with
some recent discussions I had with other developers i.e. on use of std::string
or std::vector<char> for stream of bytes, instead of custom binary_string type
I use. So, this part needs to be updated.
There are also a few other things like PostgreSQL transfer mode
(binary and textual).
As you will see, hardcoded switch to binary:
https://github.com/mloskot/soci/blob/soci-type-binary/src/backends/postgresql/statement.cpp#L38
Generally, binary transfer is fast for stuff like large geometries or
rasters, but very difficult to handle right.
Alternative is to stick to textual transfer and encode/decode.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
soci-devel mailing list
soci-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-devel
