From: | Greg Mitchell <gmitchell(at)atdesk(dot)com> |
---|---|
To: | Tom Dunstan <pgsql(at)tomd(dot)cc> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Custom Data Type Question |
Date: | 2006-11-16 13:15:16 |
Message-ID: | 455C6464.7040202@atdesk.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> A simpler way to do this might be to only cache the list per query
> context. In your IO functions, you could whack a pointer to your cache
> onto fcinfo->flinfo->fn_extra, and the same flinfo gets passed in for
> e.g. all output function calls for that column for that query, IIRC.
> This was what I had in mind originally when I did the enum patch, but I
> ended up just using syscaches, which I think would be unavailable to you
> writing a UDT.
If my understanding is correct, if fn_extra is null, I would palloc() my
data cache and store the pointer in fn_extra? What about freeing this
pointer? Or is cleanup automatic?
Also, are there any ADTs like a hash-map or tree-map in the server
libraries (my background is C++ and am use to having std::map<>) or do I
need to role my own?
I am using enumkit for some true enums I have in the DB and like it very
much. Though I tend to customize the C-code to optimize it for my use.
Thanks,
Greg
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-11-16 14:00:48 | Re: Custom Data Type Question |
Previous Message | Tom Dunstan | 2006-11-15 22:15:29 | Re: Custom Data Type Question |