[HACKERS] GiST, getting the record in table that the leaf entry points to
Hello, What I would like to do is to get the record in the table that a leaf GISTENTRY points to, if that is possible. I notice that GISTENTRY contains these members: Relation rel, Page page, and OffsetNumber offset, but are these referring to the table or the index? Thank you, Marios Vodas
[HACKERS] GIST_LEAF() causes error in GiST methods union and penalty
Hello all, I tried to use GIST_LEAF() macro in union and penalty methods of GiST and it fails with a terrible error when I run "CREATE INDEX" (in windows postgresql daemon shuts down). On the other hand, GIST_LEAF() works as expected in consistent, distance, and picksplit methods. My leaf nodes contain the indexed column data type whilst the non-leaf nodes have a different (internal) data type that is only known in C level (all types are fixed-length). I don't specify the "STORAGE" parameter in "CREATE OPERATOR CLASS ... USING gist" since the leaves are exactly of the same type as the column. Moreover, compress and decompress don't do anything just return the pointer they received (only compress checks for NULLs since there should be no NULLs in the column in my case).I also noticed in the documentation that in compress we determine if the page is leaf or not by using "if (entry->leafkey)" instead of GIST_LEAF() macro. What is the difference between "if (entry->leafkey)" and GIST_LEAF() and when should each one be used? I believe there are some conventions that GiST takes into account w.r.t. when it calls union and penalty and with what parameters, but I am not sure if they are right. So, I think that "union" is called only in leaf pages so the GistEntryVector parameter contains always leaf enties of my leaf data type (I am calling this an assumption because GIST_LEAF() breaks in union and "if (entry->leafkey)" always returns false which doesn't sound logical and makes me think that entry->leafkey should not be used). Also, the "GISTENTRY *origentry" of "penalty" is always of the non-leaf data type because it contains non-leaf entries whilst "GISTENTRY *newentry" is always of the leaf data type. Are the previous thoughts-assumptions correct? This is very important to me because I have to handle different leaf/non-leaf data types. And one last question, the two parameters of the "same" method are always of the non-leaf data type? Kind regards,Marios Vodas
Re: [HACKERS] Temporary tables and in-memory use
Thank you. The setup is intended for one user environment for complex queries and operations that's why I wrote 2GB temp_buffers! Thank you again, I really appreciate it. Marios On 29/9/2011 7:55 μμ, Tom Lane wrote: Marios Vodas writes: If I'm not wrong, temporary tables stay in memory if they do not go over temp_buffers limit (e.g. if temp_buffers is 2GB and the size of the table is 300MB the table will remain in memory). What if a column is variable length (e.g. text), how does this column stay in-memory since it should be stored in TOAST? Well, the toast table is also temp, so it'll get cached in temp_buffers as well, as long as it fits. When I build a GiST index on a temporary table does the index stay in memory as well? Same answer. Keep in mind that temp_buffers is per process, not global. Just as with work_mem, you need to be careful about setting it sky-high. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Temporary tables and in-memory use
Hello, If I'm not wrong, temporary tables stay in memory if they do not go over temp_buffers limit (e.g. if temp_buffers is 2GB and the size of the table is 300MB the table will remain in memory). What if a column is variable length (e.g. text), how does this column stay in-memory since it should be stored in TOAST? When I build a GiST index on a temporary table does the index stay in memory as well? Thank you, Marios
Re: [HACKERS] Perl 5.8 requirement for compiling on windows?
Yes, or at least change it by adding "or later". It is confusing without it... Thank you for your response. On 4/7/2011 7:33 μμ, Heikki Linnakangas wrote: On 04.07.2011 19:30, Marios Vodas wrote: Hello, I want to ask why is there a requirement for 5.8 version of Perl to compile under windows? In this page of the documentation http://www.postgresql.org/docs/9.0/static/install-windows-full.html#AEN23848it sais: "Note: version 5.8 is required". I was able to compile PostgreSQL 9.0.4 using Active Perl 5.14 (only some warnings but the build was successful). Should I necessarily use 5.8? Surely that means 5.8 or later. Given that 5.8 is very old by now, perhaps we should just remove that sentence. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Perl 5.8 requirement for compiling on windows?
Hello, I want to ask why is there a requirement for 5.8 version of Perl to compile under windows? In this page of the documentation http://www.postgresql.org/docs/9.0/static/install-windows-full.html#AEN23848it sais: "Note: version 5.8 is required". I was able to compile PostgreSQL 9.0.4 using Active Perl 5.14 (only some warnings but the build was successful). Should I necessarily use 5.8? Thank you
[HACKERS] Compile plPython for Python 3.2
I am trying to build plPython for Python 3.2 64bit under Windows 7 with Microsoft Windows SDK v7.0 (all tools are 64bit). I downloaded Python from python.org I get this error: "C:\Users\user\Desktop\postgresql-9.0.4\pgsql.sln" (default target) (1) -> (PLs\plpython target) -> .\src\pl\plpython\plpython.c(3210): error C2201: 'PyInit_plpy' : must have ex ternal linkage in order to be exported/imported "C:\Users\user\Desktop\postgresql-9.0.4\pgsql.sln" (default target) (1) -> (interfaces\ecpg target) -> Project : error PRJ0019: A tool returned an error code from "Running bison on src\interfaces\ecpg\preproc\preproc.y" How can I fix this?
[HACKERS] Why pfree(NULL) breaks execution?
C doesn't break on free(NULL) so why is pfree developed to break on NULL? Is there any way in PostgreSQL to overcome this so that it won't break, apart from checking if the pointer NULL?
Re: [HACKERS] Problem with composite type creation in C under Linux
Thank you! now I understand it...
On Wed, Mar 2, 2011 at 7:35 PM, Tom Lane wrote:
> Marios Vodas writes:
> > I have developed some custom composite and base types in PostgreSQL 9
> which
> > you can find in the code I provide below.
> > I compile my C library using GCC 4.5 under Linux and Visual Studio 2010
> > under Windows.
>
> > The problem is when I run this command: *SELECT to_composite('((1, 2),
> (3,
> > 4))'::m_segment_base)*.
> > This is the result I get in Windows and Linux respectively:
> > Windows: "("(1,2)","(3,4)")"
> > Linux: "("(1,)",)"
>
> You're passing a single isnull flag to heap_form_tuple calls that are
> expecting arrays of two flags ... and even the one value that's there
> according to the code isn't being initialized, so it's remarkable that
> this code works at all on any platform.
>
>regards, tom lane
>
[HACKERS] Problem with composite type creation in C under Linux
I have developed some custom composite and base types in PostgreSQL 9 which
you can find in the code I provide below.
I compile my C library using GCC 4.5 under Linux and Visual Studio 2010
under Windows.
The problem is when I run this command: *SELECT to_composite('((1, 2), (3,
4))'::m_segment_base)*.
This is the result I get in Windows and Linux respectively:
Windows: "("(1,2)","(3,4)")"
Linux: "("(1,)",)"
Probably the composite type is not created well in function "to_composite",
but I guess the code should be OK since it works under MSVC...
*So my question is why this doesn't work under Linux? And how can I fix it
of course.*
Here is my code in SQL and C:
***SQL code***
>
CREATE TYPE m_point_composite AS
> (
> x double precision,
> y double precision
> );
>
> CREATE TYPE m_segment_composite AS
> (
> i m_point_composite,
> e m_point_composite
> );
>
> CREATE TYPE m_point_base
> (
> INTERNALLENGTH = 16,
> INPUT = m_point_base_in,
> OUTPUT = m_point_base_out,
> RECEIVE = m_point_base_recv,
> SEND = m_point_base_send,
> ALIGNMENT = double
> );
>
> CREATE TYPE m_segment_base
> (
> INTERNALLENGTH = 32,
> INPUT = m_segment_base_in,
> OUTPUT = m_segment_base_out,
> RECEIVE = m_segment_base_recv,
> SEND = m_segment_base_send,
> ALIGNMENT = double
> );
> CREATE OR REPLACE FUNCTION to_composite(m_segment_base)
> RETURNS m_segment_composite AS
> '$libdir/myLib','to_composite'
> LANGUAGE 'C' IMMUTABLE STRICT;
>
> ***C code***
>
struct m_point_base {
> float8 x;
> float8 y;
> };
>
> struct m_segment_base {
> m_point_base i;
> m_point_base e;
> };
>
> PGDLLEXPORT Datum to_composite(PG_FUNCTION_ARGS) {
>
m_segment_base *in = (m_segment_base *) PG_GETARG_POINTER(0);
>
> TupleDesc tupdesc;
> bool isnull;
>
> Datum vi[2];
> HeapTuple i;
>
> Datum ve[2];
> HeapTuple e;
>
> Datum vout[2];
> HeapTuple out;
>
> TupleDesc tupdesc_m_point_composite =
> RelationNameGetTupleDesc("m_point_composite");
>
> vi[0] = Float8GetDatum(in->i.x);
> vi[1] = Float8GetDatum(in->i.y);
> i = heap_form_tuple(tupdesc_m_point_composite, vi, &isnull);
>
> ve[0] = Float8GetDatum(in->e.x);
> ve[1] = Float8GetDatum(in->e.y);
> e = heap_form_tuple(tupdesc_m_point_composite, ve, &isnull);
>
> vout[0] = HeapTupleGetDatum(i);
> vout[1] = HeapTupleGetDatum(e);
>
> if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
> {
> ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> errmsg("function returning record called in context that cannot accept type
> record")));
> }
>
> BlessTupleDesc(tupdesc);
> out = heap_form_tuple(tupdesc, vout, &isnull);
>
> PG_RETURN_DATUM(HeapTupleGetDatum(out));
>
}
> PG_FUNCTION_INFO_V1(to_composite)
> ;
>
Re: [HACKERS] gist DatumGetPointer returns pointer to corrupted data
2010/10/22 Teodor Sigaev > Type should have in/out function, at least dummy. If type is not present in > pg_type table then postgres can not operate with even on disk. > Yes, you are right. I did some tests and I found that in order for it to work correctly the type we specify in STORAGE parameter in create operator class has to have internallength same or bigger than the sizeof() struct that is stored in nodes of the tree. I didn't specify storage parameter at all so that was the problem. Thank you for helping.
Re: [HACKERS] gist DatumGetPointer returns pointer to corrupted data
On Tue, Oct 19, 2010 at 10:23 PM, Robert Haas wrote: > Is pg_type.typlen set correctly? > Are you refering to table pg_type? If yes, those type structures exist only in c I didn't write any in-out functions, so they don't exist in sql level. I pass a different data type (which exists in sql) to compress method which changes it to typ_s_flagged. The problem occurs in C code. I hope my explanation is clear.
[HACKERS] gist DatumGetPointer returns pointer to corrupted data
I index these structures in gist:
typedef struct {
> uint8 type_flag;
> float8 xi;
> float8 yi;
> Timestamp ti;
> float8 xe;
> float8 ye;
> Timestamp te;
> int32 id;
> } typ_s_flagged;
>
> typedef struct {
> uint8 type_flag;
> float8 xl;
> float8 yl;
> Timestamp tl;
> float8 xh;
> float8 yh;
> Timestamp th;
> } typ_b_flagged;
>
typ_s_flagged is the type of leaf entries and typ_b_flagged is for non-leaf
entries.
This is how I determine which type it is in functions union, picksplit,
penalty etc (I tried to use GIST_LEAF but it produced errors in execution
time!, anyway I know this might not be a best practice but it is not wrong).
GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0); //in penalty,
> consistent
>
//or GistEntryVector *entryvec = (GistEntryVector *) PG_GETARG_POINTER(0);
> entry = &entryvec->vector[i]; in union and picksplit
> uint8 *type_flag = (uint8 *) DatumGetPointer(entry->key);
> if (*type_flag == 0) {
> typ_s_flagged *p1 = (typ_s_flagged *) DatumGetPointer(entry->key);
> } else if(*type_flag == 1){
> typ_b_flagged *p2 = (typ_b_flagged *) DatumGetPointer(entry->key);
> }
>
The problem is that when I access *p1->te* or *p1->id* or *p2->th* the value
I get is zeros, for both. But I get correct values for variables before *
p1->te*.
I checked my code multiple times and I didn't found a mistake like bad size
in palloc or wrong variable assignment.
I checked compress function and it seems to accept and return correct
values.
*Does anyone have any idea on how to solve this? Or why it happens?
*
Re: [HACKERS] knngist plans
On Sat, Oct 16, 2010 at 8:42 PM, Oleg Bartunov wrote: > Marios, > > you're right. There are several reasons for poor documentation, but of > course, > no excuse, we do need good docs any way ! It's very nice you're willing to > write one, since it's always better seen from outside of development. > I think it'd be better to use wiki, so other people can join. > Pictures would be nice, but I don't know if there is consensus about using > pictures in documentation. > Wiki sounds good. Where can I find it? > Oleg > > btw, we're thinking in the background about new indexing infrastructure - > Spatial GiST, but it's rather big project, so we need sponsors. Is it related to SP-GIST (http://www.cs.purdue.edu/spgist/)?
Re: [HACKERS] knngist plans
Oleg as I said I do believe some things could get better in docs. Here are 4 main drawbacks in my opinion: 1. The docs lack example(s). There are some references to gistproc.c etc but this is not part of the docs and if I am someone that has just started this is hard and confusing (I shouldn't have to read the full technical solution to another problem in order to solve mine). 2. The 7 methods are poorly explained, at least theoretically. For example when I started I couldn't understand where each function was used. I had to read papers to understand the logic. 3. Describe situations that gist can be used. I am aware of spatial indexing because I worked on it, but I have the impression that there are more (e.g. computational biology). 4. Why not add some images/figures? (1 image = 1000 words) GiST is a very important and useful part of postgresql but it's hard to get started with it. Moreover, I am sure it has capabilities, other than the profound, that are not known to many people (including me). Plus knngist will give gist a boost, and I suggest that it shouldn't be delayed any more. We have some documentation already, Teodor will post soon. I would really like to see what Teodor has done. I could also prepare a document with the additions I would like to see in docs. Shall I do it? Of course it might take a while to finish it. On Fri, Oct 15, 2010 at 2:37 PM, Oleg Bartunov wrote: > On Fri, 15 Oct 2010, Marios Vodas wrote: > > Recently I worked a lot with gist and read about knngist. I have spotted >> weaknesses in docs. So I would be happy to help if you tell me how. >> > > We have some documentation already, Teodor will post soon. Marios, I'd > happy to help in writing docs. Do you have some plans ? > > > >> On Fri, Oct 15, 2010 at 5:57 AM, Robert Haas >> wrote: >> >> On Wed, Oct 13, 2010 at 7:07 PM, Marios Vodas wrote: >>> >>>> I would like to ask in which future version of postgresql knngist is >>>> >>> planned >>> >>>> to be included. Is there any possibility to be included in 9.1? >>>> >>> >>> There's a possibility, but I think the patch still needs some more >>> work. One thing that would help is if someone felt motivated to write >>> some documentation. >>> >>> -- >>> Robert Haas >>> EnterpriseDB: http://www.enterprisedb.com >>> The Enterprise PostgreSQL Company >>> >>> >> >Regards, >Oleg > _ > Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru), > Sternberg Astronomical Institute, Moscow University, Russia > Internet: o...@sai.msu.su, > http://www.sai.msu.su/~megera/<http://www.sai.msu.su/%7Emegera/> > phone: +007(495)939-16-83, +007(495)939-23-83 >
Re: [HACKERS] knngist plans
Recently I worked a lot with gist and read about knngist. I have spotted weaknesses in docs. So I would be happy to help if you tell me how. On Fri, Oct 15, 2010 at 5:57 AM, Robert Haas wrote: > On Wed, Oct 13, 2010 at 7:07 PM, Marios Vodas wrote: > > I would like to ask in which future version of postgresql knngist is > planned > > to be included. Is there any possibility to be included in 9.1? > > There's a possibility, but I think the patch still needs some more > work. One thing that would help is if someone felt motivated to write > some documentation. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
[HACKERS] knngist plans
I would like to ask in which future version of postgresql knngist is planned to be included. Is there any possibility to be included in 9.1?
[HACKERS] $libdir under linux
I want to create this function: CREATE OR REPLACE FUNCTION myfunction(cstring) RETURNS cstring AS '$libdir/mylib','myfunction' LANGUAGE 'C' IMMUTABLE STRICT; In windows this is working fine and $libdir is substituted by the actual path. In linux it is not substituted! This is the error I get: ERROR: could not access file "$libdir/mylib": No such file or directory SQL state: 58P01 How do I fix it?
Re: [HACKERS] compiling C library under mingw
It is an exe don't I need a dll? Can you get more specific on "either directly or by manually creating an import library"? What I understand by directly is that I should rename postgres.exe to postgres.dll. Thank you for responding so quickly. On Sat, Oct 9, 2010 at 12:44 PM, Magnus Hagander wrote: > You need to link to postgres.exe - either directly or by manually > creating an import library. > > //Magnus > > On Sat, Oct 9, 2010 at 11:40, Marios Vodas wrote: > > I did a little search and I found that probably there is a library (dll > or > > lib ???) that contains all these references. I could specify it by using > > -L/C/path/to/libraries -libraryname as an option to the second gcc > command, > > but I have no idea what the library is and where to find it (I used > > -L/C/PostgreSQL/9.0/lib -lpostgres -lpq, but it didn't work). > > All those references are declared as extern in postgres source code. > > Does anyone know what the library is? > > > > On Fri, Oct 8, 2010 at 12:27 PM, Marios Vodas wrote: > >> > >> I have a library that compiles fine under linux. > >> But when I try to compile it under mingw on windows 7 I get the > following > >> errors. > >> > >>> gcc.exe -c -O2 -I/C/PostgreSQL/9.0/include/server > >>> -I/C/PostgreSQL/9.0/include/server/utils > >>> -I/C/PostgreSQL/9.0/include/server/access > >>> -I/C/PostgreSQL/9.0/include/server/port/win32 > -I/C/PostgreSQL/9.0/include > >>> -MMD -MP -MF build/Release/MinGW-Windows/mylib.o.d -o > >>> build/Release/MinGW-Windows/mylib.o mylib.c > >> > >> The previous command is successful and produces .o files (only some > >> warnings here like: warning: 'pg_finfo_mytype_in' redeclared without > >> dllimport attribute: previous dllimport ignored). > >> The following though gives errors. > >> > >>> gcc.exe -shared -o dist/Release/MinGW-Windows/libMyLib.dll > >>> build/Release/MinGW-Windows/mylib.o > >> > >> Here is the log: > >> > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x128): undefined > >>> reference to `errstart' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x13d): undefined > >>> reference to `_imp__CurrentMemoryContext' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x147): undefined > >>> reference to `MemoryContextAlloc' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x17b): undefined > >>> reference to `timestamp_in' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x180): undefined > >>> reference to `DirectFunctionCall3' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x1be): undefined > >>> reference to `timestamp_in' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x1c3): undefined > >>> reference to `DirectFunctionCall3' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x1f4): undefined > >>> reference to `errmsg' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x202): undefined > >>> reference to `errcode' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x20e): undefined > >>> reference to `errfinish' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x230): undefined > >>> reference to `_imp__CurrentMemoryContext' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x23a): undefined > >>> reference to `MemoryContextAlloc' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x251): undefined > >>> reference to `Int64GetDatum' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x25c): undefined > >>> reference to `timestamp_out' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x261): undefined > >>> reference to `DirectFunctionCall1' > >>> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x284): undefined > >>> reference to `Int64GetDatum' > >> > > > > > > > > -- > Magnus Hagander > Me: http://www.hagander.net/ > Work: http://www.redpill-linpro.com/ >
Re: [HACKERS] compiling C library under mingw
I did a little search and I found that probably there is a library (dll or lib ???) that contains all these references. I could specify it by using -L/C/path/to/libraries -libraryname as an option to the second gcc command, but I have no idea what the library is and where to find it (I used -L/C/PostgreSQL/9.0/lib -lpostgres -lpq, but it didn't work). All those references are declared as extern in postgres source code. Does anyone know what the library is? On Fri, Oct 8, 2010 at 12:27 PM, Marios Vodas wrote: > I have a library that compiles fine under linux. > But when I try to compile it under mingw on windows 7 I get the following > errors. > > gcc.exe -c -O2 -I/C/PostgreSQL/9.0/include/server >> -I/C/PostgreSQL/9.0/include/server/utils >> -I/C/PostgreSQL/9.0/include/server/access >> -I/C/PostgreSQL/9.0/include/server/port/win32 -I/C/PostgreSQL/9.0/include >> -MMD -MP -MF build/Release/MinGW-Windows/mylib.o.d -o >> build/Release/MinGW-Windows/mylib.o mylib.c >> > > The previous command is successful and produces .o files (only some > warnings here like: warning: 'pg_finfo_mytype_in' redeclared without > dllimport attribute: previous dllimport ignored). > The following though gives errors. > > gcc.exe -shared -o dist/Release/MinGW-Windows/libMyLib.dll >> build/Release/MinGW-Windows/mylib.o >> > > Here is the log: > > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x128): undefined >> reference to `errstart' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x13d): undefined >> reference to `_imp__CurrentMemoryContext' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x147): undefined >> reference to `MemoryContextAlloc' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x17b): undefined >> reference to `timestamp_in' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x180): undefined >> reference to `DirectFunctionCall3' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x1be): undefined >> reference to `timestamp_in' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x1c3): undefined >> reference to `DirectFunctionCall3' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x1f4): undefined >> reference to `errmsg' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x202): undefined >> reference to `errcode' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x20e): undefined >> reference to `errfinish' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x230): undefined >> reference to `_imp__CurrentMemoryContext' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x23a): undefined >> reference to `MemoryContextAlloc' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x251): undefined >> reference to `Int64GetDatum' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x25c): undefined >> reference to `timestamp_out' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x261): undefined >> reference to `DirectFunctionCall1' >> build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x284): undefined >> reference to `Int64GetDatum' >> > >
[HACKERS] compiling C library under mingw
I have a library that compiles fine under linux. But when I try to compile it under mingw on windows 7 I get the following errors. gcc.exe -c -O2 -I/C/PostgreSQL/9.0/include/server > -I/C/PostgreSQL/9.0/include/server/utils > -I/C/PostgreSQL/9.0/include/server/access > -I/C/PostgreSQL/9.0/include/server/port/win32 -I/C/PostgreSQL/9.0/include > -MMD -MP -MF build/Release/MinGW-Windows/mylib.o.d -o > build/Release/MinGW-Windows/mylib.o mylib.c > The previous command is successful and produces .o files (only some warnings here like: warning: 'pg_finfo_mytype_in' redeclared without dllimport attribute: previous dllimport ignored). The following though gives errors. gcc.exe -shared -o dist/Release/MinGW-Windows/libMyLib.dll > build/Release/MinGW-Windows/mylib.o > Here is the log: build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x128): undefined > reference to `errstart' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x13d): undefined > reference to `_imp__CurrentMemoryContext' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x147): undefined > reference to `MemoryContextAlloc' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x17b): undefined > reference to `timestamp_in' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x180): undefined > reference to `DirectFunctionCall3' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x1be): undefined > reference to `timestamp_in' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x1c3): undefined > reference to `DirectFunctionCall3' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x1f4): undefined > reference to `errmsg' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x202): undefined > reference to `errcode' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x20e): undefined > reference to `errfinish' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x230): undefined > reference to `_imp__CurrentMemoryContext' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x23a): undefined > reference to `MemoryContextAlloc' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x251): undefined > reference to `Int64GetDatum' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x25c): undefined > reference to `timestamp_out' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x261): undefined > reference to `DirectFunctionCall1' > build/Release/MinGW-Windows/mylib.o:mylib.c:(.text+0x284): undefined > reference to `Int64GetDatum' >
[HACKERS] gist picksplit iteration
At this page in documentation http://www.postgresql.org/docs/9.0/static/gist-implementation.html and under "picksplit" the loop that iterates through entryvec->vector[] starts from 1 (since FirstOffsetNumber equals 1). for (i = FirstOffsetNumber; i <= maxoff; i = OffsetNumberNext(i)) I would expect it to start from 0, since C arrays are 0 based. So my question is why does this happen?
[HACKERS] timestamp_in DirectFunctionCall
Would this be correct?
DatumGetTimestamp(DirectFunctionCall3(timestamp_in, CStringGetDatum(time),
PointerGetDatum(0), Int32GetDatum(MAX_TIMESTAMP_PRECISION)));
This is how timestamp_in starts, *#ifdef NOT_USED* is a litle bit confusing.
Datum timestamp_in(PG_FUNCTION_ARGS)
{
char *str = PG_GETARG_CSTRING(0);
#ifdef NOT_USED
Oidtypelem = PG_GETARG_OID(1);
#endif
int32typmod = PG_GETARG_INT32(2);
Re: [HACKERS] gist access methods parameter types
Please can you answer the question of whether entry->key in compress should
be of delta3d sql type (composite type) and if not of what it should be
since the type I index is different from the type stored in tree?
Taking into consideration the types I described before this is my code for
compress.
Datum delta3d_compress(PG_FUNCTION_ARGS) {
GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
GISTENTRY *retval;
HeapTupleHeader in;
HeapTupleHeader i;
HeapTupleHeader e;
bool isnull;
if (entry->leafkey) {
in = DatumGetHeapTupleHeader(entry->key);
if (in != NULL) {
i = DatumGetHeapTupleHeader(GetAttributeByName(in, "i",
&isnull));
e = DatumGetHeapTupleHeader(GetAttributeByName(in, "e",
&isnull));
delta3d *compressed_data = (delta3d *) palloc(sizeof (delta3d));
compressed_data->xi = DatumGetFloat8(GetAttributeByName(i, "x",
&isnull));
compressed_data->yi = DatumGetFloat8(GetAttributeByName(i, "y",
&isnull));
compressed_data->ti = DatumGetTimestamp(GetAttributeByName(i,
"t", &isnull));
compressed_data->xe = DatumGetFloat8(GetAttributeByName(e, "x",
&isnull));
compressed_data->ye = DatumGetFloat8(GetAttributeByName(e, "y",
&isnull));
compressed_data->te = DatumGetTimestamp(GetAttributeByName(e,
"t", &isnull));
compressed_data->trajectory =
DatumGetInt32(GetAttributeByName(in, "trajectory", &isnull));
retval = palloc(sizeof (GISTENTRY));
gistentryinit(*retval, PointerGetDatum(compressed_data),
entry->rel, entry->page, entry->offset, FALSE);
} else {
retval = palloc(sizeof (GISTENTRY));
gistentryinit(*retval, (Datum) 0, entry->rel, entry->page,
entry->offset, FALSE);
}
} else {
retval = entry; *//does this have to change? I thing it is going to
be of C type delta3d_mbb, am I right?*
}
PG_RETURN_POINTER(retval);
}
Re: [HACKERS] gist access methods parameter types
> > Have you looked at PostGIS? > Yes ofcourse, I also read everything in postgresql official documentation plus http://gist.cs.berkeley.edu/pggist/opcltour.html. > Yeah, I still don't think that's the right way to do it. Storing the > bounding box seems right, but just do that for all the nodes. It's > probably worth looking at the implementation of these functions for, > say, the existing point, box, and polygon datatypes, which have > similar issues. > I intend to change the structure I describe in the future. So if it is not wrong and harmful to the implementation I want to keep that extra info in leaf node entries. I have read src/backend/access/gist/gistproc.c I am aware of what it does. According to the documentation, no. It takes a GISTENTRY and returns > a GISTENTRY. But you can extract the relevant key out of there. The > best way to do this, again, is to look at existing examples, like > gist_poly_compress. > Exactly what I am saying. I extract the key out of GISTENTRY of course but that key has to contain a value of some type. And my question is of what type if it is a leaf and of what if it is not a leaf entry? Thank you for helping.
Re: [HACKERS] gist access methods parameter types
Let me explain better what I want to do.
I want to have the types in sql level (composite types) like this:
--Spatio-Temporal Position in 3 Dimensions(cartessian x, cartessian y, time)
CREATE TYPE pos3d AS
(
x double precision,
y double precision,
t timestamp
);
--Spatio-Temporal Delta (comes from Δ, meaning alteration/change)
--i stands for (i)nitial position
--e stands for (e)nding position
--trajectory holds the id of the trajectory in which the current delta
belongs to
CREATE TYPE delta3d AS
(
i pos3d,
e pos3d,
trajectory integer
);
Having them in sql level eases my work much more than having them as base
types in C. But I need an index to speed up some operations. So I build two
types in C just for indexing purposes:
typedef struct {
float8 xi, yi;
Timestamp ti;
float8 xe, ye;
Timestamp te;
int32 trajectory;
} delta3d;
typedef struct {
float8 xl, yl;
Timestamp tl;
float8 xh, yh;
Timestamp th;
} delta3d_mbb;
As you see the first is a replica of my sql type in C and the second misses
some information (it is just the minimum bounding box which means that we
don't know initial/ending positions neither the trajectory id). The second
type is intended for non-leaf nodes while the first for leaf nodes.
My implementation of the tree is a kind of 3D-Rtree.
Now I am a little confused about the type of the arguments that each access
method (consistent, union, compress, decompress, penalty, picksplit, same)
requires in order to accomplish my goal.
Another black spot I have regarding compress.
If the entry passed to compress is a leaf entry then it is going to be of
sql type (composite type) delta3d (meaning I will get the values using
tuples etc). Correct? If not of what type is it going to be?
Assume it is a non-leaf entry. In that case of what type will it be? If it
is delta3d_mbb (C type) then I don't have to change it. But is it going to
be?
I am sorry if I seem importunate, but it has only been 2 weeks since I
started messing with postgresql C extensions, and I need help...
[HACKERS] gist access methods parameter types
If I have this sql composite type: CREATE TYPE d_type AS ( i integer, e integer, id integer ); and this table: CREATE TABLE my_tab ( d_col d_type NOT NULL ) CREATE INDEX my_tab_d_col_gist ON my_tab USING gist (d_col); I am implementing consistent, union, compress, decompress, penalty, picksplit and same. CREATE OPERATOR CLASS d_type_ops DEFAULT FOR TYPE d_type USING gist AS FUNCTION 1 d_type_consistent(internal, d_type, smallint, oid, internal), FUNCTION 2 d_type_union(internal, internal), FUNCTION 3 d_type_compress(internal), FUNCTION 4 d_type_decompress(internal), FUNCTION 5 d_type_penalty(internal, internal, internal), FUNCTION 6 d_type_picksplit(internal, internal), FUNCTION 7 d_type_same(internal, internal, internal); The problem is that some of these methods take as input parameters the d_type and some the struct type that I internally implemented in c (which will be saved to the tree). If I understand correctly consistent and compress are the only functions that will have input parameter of d_type. The others will have my c internal type. *Is this correct?* Something else, will a non-leaf node have one entry that will be produced by union? I am asking because I want the leaf node entries to be of different type from non-leaf node entries (the difference between them is that non-leaf entry will not keep the id attribute). Thank you in advance.
Re: [HACKERS] forming tuple as an attribute inside another tuple in c function
OK but what is the recommended way to get TupleDesc for p_type? I am aware
of RelationNameGetTupleDesc but I shouldn't use it since it is deprecated.
However by using it the code would look something like this (I tested it and
it works as expected):
Datum demo(PG_FUNCTION_ARGS) {
float8 xi = 1;
float8 yi = 2;
float8 xe = 3;
float8 ye = 4;
int32 id = 1;
bool isnull;
TupleDesc tupdesc;
TupleDesc tupdesc_p;
Datum values[3];
Datum vi[2];
Datum ve[2];
HeapTuple tuple;
HeapTuple i;
HeapTuple e;
tupdesc_p = *RelationNameGetTupleDesc*("p_type");
vi[0] = Float8GetDatum(xi);
vi[1] = Float8GetDatum(yi);
i = heap_form_tuple(tupdesc_p, vi, &isnull);
ve[0] = Float8GetDatum(xe);
ve[1] = Float8GetDatum(ye);
e = heap_form_tuple(tupdesc_p, ve, &isnull);
if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
{
ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function returning record called in context that cannot accept type
record")));
}
BlessTupleDesc(tupdesc);
* * values[0] = HeapTupleGetDatum(i);
values[1] = HeapTupleGetDatum(e);
values[2] = Int32GetDatum(id);
tuple = heap_form_tuple(tupdesc, values, &isnull);
PG_RETURN_DATUM(HeapTupleGetDatum(tuple));
}
On Mon, Sep 27, 2010 at 3:32 AM, Tom Lane wrote:
> You've omitted to tell us just
> what's going wrong for you.
>
>regards, tom lane
>
[HACKERS] forming tuple as an attribute inside another tuple in c function
Is it posible? Either by using heap_form_tuple or BuildTupleFromCStrings.
CREATE TYPE p_type AS
(
x double precision,
y double precision
);
CREATE TYPE d_type AS
(
i p_type,
e p_type,
id integer
);
CREATE OR REPLACE FUNCTION demo()
RETURNS d_type
AS '/home/user/PostgreSQL/9.0/lib/mylib','demo'
LANGUAGE C STRICT;
Datum demo(PG_FUNCTION_ARGS) {
float8 xi = 1;
float8 yi = 2;
float8 xe = 3;
float8 ye = 4;
int32 id = 1;
bool isnull;
TupleDesc tupdesc;
Datum values[3];
HeapTuple tuple;
if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
{
ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function returning record called in context that cannot accept type
record")));
}
BlessTupleDesc(tupdesc);
*values[0] = ?; //how?**
*
*values[1] = ?;** //how?*
values[2] = Int32GetDatum(id);
tuple = heap_form_tuple(tupdesc, values, &isnull);
PG_RETURN_DATUM(HeapTupleGetDatum(tuple));
}
Re: [HACKERS] C function to return tuple
Do you think it would be better to change d_type to this? CREATE TYPE d_type AS ( xi double precision, yi double precision, xe double precision, ye double precision, id integer ); *Note: This is NOT something I want to do but if there is no other way to form d_type tuple from the variables...* On Sun, Sep 26, 2010 at 8:29 PM, Marios Vodas wrote: > Suppose I had the data that form the returning tuple in 5 variables like > this: > float8 xi = 1; > float8 yi = 2; > float8 xe = 3; > float8 ye = 4; > int32 id = 1; > > In addition the function wouldn't have any input parameters. It just > returns a tuple of type d_type. > Can you tell me how it is possible to form the tuple? My problem here is > that I DON'T have HeapTupleHeaders i and e already formed (those two are > of p_type) so I have to form them somehow. >
Re: [HACKERS] C function to return tuple
Suppose I had the data that form the returning tuple in 5 variables like this: float8 xi = 1; float8 yi = 2; float8 xe = 3; float8 ye = 4; int32 id = 1; In addition the function wouldn't have any input parameters. It just returns a tuple of type d_type. Can you tell me how it is possible to form the tuple? My problem here is that I DON'T have HeapTupleHeaders i and e already formed (those two are of p_type) so I have to form them somehow. On Sun, Sep 26, 2010 at 7:52 PM, Tom Lane wrote: > Marios Vodas writes: > > //I need to get this working > > *values[0] = e;* > > *values[1] = i;* > > Maybe you're missing HeapTupleGetDatum() there? Just from a data type > cleanliness standpoint, you shouldn't ever assign something to Datum or > vice versa without applying the correct conversion macro. > >regards, tom lane >
Re: [HACKERS] C function to return tuple
I see what you mean and I changed the code BUT still my main problem is that
I want to know how to fill values array. I remind you that d_type contains
attributes of another composite type p_type.
I need a solution to that because I need to use it in other parts of the
code.
Datum d_swap(PG_FUNCTION_ARGS) {
HeapTupleHeader t = PG_GETARG_HEAPTUPLEHEADER(0);
HeapTupleHeader i;
HeapTupleHeader e;
bool isnull;
TupleDesc tupdesc;
Datum values[3];
HeapTuple tuple;
i = DatumGetHeapTupleHeader(GetAttributeByName(t, "i", &isnull));
e = DatumGetHeapTupleHeader(GetAttributeByName(t, "e", &isnull));
if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
{
ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function returning record called in context that cannot accept type
record")));
}
BlessTupleDesc(tupdesc);
//I need to get this working
*values[0] = e;*
*values[1] = i;*
*values[2] = GetAttributeByName(t, "id", &isnull);*
tuple = heap_form_tuple(tupdesc, values, &isnull);
PG_RETURN_DATUM(HeapTupleGetDatum(tuple));
}
On Sun, Sep 26, 2010 at 7:16 PM, Tom Lane wrote:
> Marios Vodas writes:
> > My problem is that I don't know how to construct the d_type tuple in the
> c
> > function.
>
> Seems like the main problem with that function is that you're passing
> an uninitialized "nulls" array to heap_form_tuple.
>
> I kinda wonder why you are using a fixed-length values array together
> with a variable-length, dynamically allocated nulls array, but that'
> just odd style not wrong in itself.
>
>regards, tom lane
>
[HACKERS] C function to return tuple
I have these types:
CREATE TYPE p_type AS
(
x double precision,
y double precision
);
CREATE TYPE d_type AS
(
i p_type,
e p_type,
id integer
);
CREATE OR REPLACE FUNCTION d_swap(d_type)
RETURNS d_type
AS '/home/user/PostgreSQL/9.0/lib/mylib','d_swap'
LANGUAGE C STRICT;
My problem is that I don't know how to construct the d_type tuple in the c
function. I read the documentation but it only explains how i could do that
for a more simple type like p_type.
The difficulty is that d_type has attributes of p_type.
Thank you in advance.
This is the c code I wrote until now:
Datum d_swap(PG_FUNCTION_ARGS) {
HeapTupleHeader t = PG_GETARG_HEAPTUPLEHEADER(0);
HeapTupleHeader i;
HeapTupleHeader e;
bool isnull;
TupleDesc tupdesc;
Datum values[3];
HeapTuple tuple;
int tuplen;
bool *nulls;
i = DatumGetHeapTupleHeader(GetAttributeByName(t, "i", &isnull));
e = DatumGetHeapTupleHeader(GetAttributeByName(t, "e", &isnull));
if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
{
ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function returning record called in context that cannot accept type
record")));
}
BlessTupleDesc(tupdesc);
values[0] = e;
values[1] = i;
values[2] = GetAttributeByName(t, "id", &isnull);
tuplen = tupdesc->natts;
nulls = palloc(tuplen * sizeof (bool));
tuple = heap_form_tuple(tupdesc, values, nulls);
pfree(nulls);
PG_RETURN_DATUM(HeapTupleGetDatum(tuple));
}
