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 <t...@sss.pgh.pa.us>

> Werner Echezuria <werc...@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.
>

Reply via email to