Hi,
Well, I use TextDatumGetCString in the main file, but it remains with the
weird characters.
this is the main file:
#include "postgres.h"
#include "fmgr.h"
#include "gram.h"
#include "sqlf.h"
#include "utils/builtins.h"
extern Datum sqlf(PG_FUNCTION_ARGS);
PG_MODULE_MAGIC;
PG_FUNCTION_INFO_V1(sqlf);
Datum
sqlf(PG_FUNCTION_ARGS){
char *query = TextDatumGetCString(PG_GETARG_DATUM(0));
const char *parse_str;
char *result;
parse_query(query,&parse_str);
result=parse_str;
PG_RETURN_TEXT_P(cstring_to_text(result));
}
About the PS: Ok, I understand that if I want that you include this as a
contrib module I need to use bison/flex, I never thought about it, but I now
have a couple of questions:
What are the chances to really include it in PostgreSQL as a contrib module?
Are there any requirement I have to follow?
2009/8/6 Tom Lane <[email protected]>
> Werner Echezuria <[email protected]> writes:
> > I'm trying to develop a contrib module in order to parse sqlf queries,
> I'm
> > using lemon as a LALR parser generator (because I think it's easier than
> > bison) and re2c (because I think it's easier than flex) but when I try to
> > split the string into words postgres add some weird characters (this
> works
> > in pure gcc), I write something like "CREATE FUZZY PREDICATE joven ON
> 0..120
> > AS (0,0,35,120);", but postgresql adds a character like at the end of
> > "joven" and the others words.
>
> Maybe you are expecting 'text' values to be null-terminated? They are
> not. You might look into using TextDatumGetCString or related functions
> to convert.
>
> regards, tom lane
>
> PS: the chances of us accepting a contrib module that requires
> significant unusual infrastructure to build seem pretty low from
> where I sit. You're certainly free to do whatever you want for
> private work, or even for a pgfoundry project --- but if you do
> have ambitions of this eventually becoming contrib, "it's easier"
> is not going to be sufficient rationale to not use bison/flex.
>
