Re: Extending SQL in C using VARIABLE length type

From: Carsten Kropf <ckropf2(at)fh-hof(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Extending SQL in C using VARIABLE length type
Date: 2010-02-11 16:38:21
Message-ID: 3212D811-1E14-4D8F-B2F0-BF3B47774E2D@fh-hof.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)fh-hof(dot)de> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Moe 2010-02-11 16:42:00 Re: Searching a DB index.. possible?
Previous Message Greg Sabino Mullane 2010-02-11 16:28:51 Re: Versions RSS page is missing version(s)