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
<tgl@sss.pgh.pa.us>Werner Echezuria <
wercool@gmail.com> 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.