Thanks for this hint, I already got it to work in the meantime.
My approach now (based on the fact, that PointND is indeed a variable length type) is to have the following structure:
struct Range
{
int vl_len_;
struct PointND limits[1];
};
whereas now vl_len_ stores the total size of the structure (including the size of the limiting points) and the points themselves keep the layout contained in one of my previous mails.
I programmed some macros to access the lower point (limits[0]) and the upper point (limits[1]), respectively.
This approach works also when putting it into a table, whereas it will not be like this, if I will be doing the whole thing for productive implementation. Each of the two points contains a vl_len_ field and a dimension field whereas the dimensions have to be the same for each point. So, according the storage of the range structure, this would yield an overhead of 2 * vl_len_ and once the dimension field each of which is int32. So, in total, we would have an overhead of 12 Bytes for each Range stored somewhere compared to a Range that has just one-dimensional offsets to show the upper/lower bound, as seen in cube.
regards
Carsten Kropf
Am 11.02.2010 um 16:39 schrieb Tom Lane:
> Carsten Kropf <ckropf2@xxxxxxxxx> writes:
>> Thanks a lot so far. I adopted my structures and am now storing two fields (v_len_ and dimensions) and the storage is now working properly. If I now would try to combine two of these points to a range (like cube) including an upper and a lower bound n-dimensional point structure, I don't get the point how to achieve this.
>
> Well, you can either make that a separate data type with its own
> specialized functions for extracting the points, or you can make it into
> an array, or possibly a composite type (record). The example code seems
> to be headed towards the first of these but maybe you should consider
> the alternatives.
>
> The main problem with your example code seems to be that it's confusing
> a struct with a pointer to a struct. If you made the struct members
> be "struct PointND" rather than pointer to same, it would probably
> work, as long as points aren't actually variable-length. Otherwise
> you'd need to deal with the fact that "lower" isn't really at a fixed
> offset in the larger struct.
>
> regards, tom lane
>
> --
> Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
