Обсуждение: C function question
Hey folks
I am trying to write simple function, that would filter out a char
from text/string. It's being a while since I last time wrote c
function for postgresql (8.1), and few things are gone in API there.
Can someone tell me what's wrong with that function please ?
#include "postgres.h"
#include <string.h>
#include "fmgr.h"
#include "utils/builtins.h"
#include "libpq/pqformat.h"
PG_FUNCTION_INFO_V1(filter_text);
PG_MODULE_MAGIC;
// filter_text(text, char);
Datum
filter_text(PG_FUNCTION_ARGS)
{
text *arg1 = PG_GETARG_TEXT_P(0);
char c = PG_GETARG_CHAR(1);
int i, j;
text *new_text;
if (PG_ARGISNULL(0) || PG_ARGISNULL(1))
PG_RETURN_NULL();
new_text = (text *) palloc(VARSIZE(arg1)+VARHDRSZ);
SET_VARSIZE(new_text, VARSIZE(arg1)+VARHDRSZ);
for(i=0, j=0; i!=VARSIZE(arg1)-VARHDRSZ; i++)
{
if ( VARDATA(arg1)[i] != c )
{
VARDATA(new_text)[j++] = VARDATA(arg1)[i];
}
}
VARDATA(new_text)[j++] = '\0';
SET_VARSIZE(new_text, j+VARHDRSZ);
PG_RETURN_TEXT_P(new_text);
}
--
GJ
> char c = PG_GETARG_CHAR(1); > for whatever reason, taht doesn't return the real char that was passed in. -- GJ
Grzegorz Jaśkiewicz wrote:
> > char c = PG_GETARG_CHAR(1);
>
> for whatever reason, taht doesn't return the real char that was passed in.
Yeah ... try DatumGetBpCharP instead. PG_GETARG_CHAR is for type "char"
with quotes, which is a completely different thing.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
"The problem with the facetime model is not just that it's demoralizing, but
that the people pretending to work interrupt the ones actually working."
(Paul Graham)
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Grzegorz Jaśkiewicz wrote:
>> for whatever reason, taht doesn't return the real char that was passed in.
> Yeah ... try DatumGetBpCharP instead. PG_GETARG_CHAR is for type "char"
> with quotes, which is a completely different thing.
Or maybe the C code does just what he wants, and the problem is that he
needs to declare the function correctly at the SQL level (ie, with
second argument "char" not char(1)).
regards, tom lane
Grzegorz Jaśkiewicz wrote: > looks like it really has to be defined with "char" in double quotes. I > thought just char is enough... They're different types. -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ "Crear es tan difícil como ser libre" (Elsa Triolet)
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Grzegorz Jaśkiewicz wrote:
>> looks like it really has to be defined with "char" in double quotes. I
>> thought just char is enough...
> They're different types.
You know, maybe we should stop holding our noses and do something about
this old gotcha. That type's not going away anytime soon, but could we
rename it to char1 or something like that? (With some sort of backward
compatibility hack, like a domain named "char".)
On the other hand, that might be more trouble than it's worth. Even
with a domain alias, there'd be a nontrivial chance of breaking apps
that look at the char columns of the system catalogs.
regards, tom lane
On Tue, Feb 3, 2009 at 4:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: >> Grzegorz Jaśkiewicz wrote: >>> looks like it really has to be defined with "char" in double quotes. I >>> thought just char is enough... > >> They're different types. > > You know, maybe we should stop holding our noses and do something about > this old gotcha. That type's not going away anytime soon, but could we > rename it to char1 or something like that? (With some sort of backward > compatibility hack, like a domain named "char".) > > On the other hand, that might be more trouble than it's worth. Even > with a domain alias, there'd be a nontrivial chance of breaking apps > that look at the char columns of the system catalogs. domains are out, unless arrays of domains are addressed first. merlin
it's defined: create or replace function filter_text(text, char) returns text as 'test_proc.so' language 'c'; which leads me to another question. It seems that I have to leave psql and comeback, for new version to be loaded. (that's on 8.4 tho, I don't have 8.3 at home). And also that 'replace' bit doesn't seem to actually refresh it either.
looks like it really has to be defined with "char" in double quotes. I thought just char is enough...
On Tue, Feb 3, 2009 at 9:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > On the other hand, that might be more trouble than it's worth. Even > with a domain alias, there'd be a nontrivial chance of breaking apps > that look at the char columns of the system catalogs. I have to apologize, it is clearly written in quotes in docs - but obviously I couldn't believe that would make any difference. -- GJ
Merlin Moncure <mmoncure@gmail.com> writes:
> On Tue, Feb 3, 2009 at 4:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> You know, maybe we should stop holding our noses and do something about
>> this old gotcha. That type's not going away anytime soon, but could we
>> rename it to char1 or something like that? (With some sort of backward
>> compatibility hack, like a domain named "char".)
> domains are out, unless arrays of domains are addressed first.
[ raised eyebrow... ] You've got apps that depend on array of "char"?
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: >> Grzegorz Jaśkiewicz wrote: >>> looks like it really has to be defined with "char" in double quotes. I >>> thought just char is enough... > >> They're different types. > > You know, maybe we should stop holding our noses and do something about > this old gotcha. That type's not going away anytime soon, but could we > rename it to char1 or something like that? int1? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support!
On Tue, Feb 3, 2009 at 6:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Merlin Moncure <mmoncure@gmail.com> writes: >> On Tue, Feb 3, 2009 at 4:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> You know, maybe we should stop holding our noses and do something about >>> this old gotcha. That type's not going away anytime soon, but could we >>> rename it to char1 or something like that? (With some sort of backward >>> compatibility hack, like a domain named "char".) > >> domains are out, unless arrays of domains are addressed first. > > [ raised eyebrow... ] You've got apps that depend on array of "char"? yes. For example. I wrote a ISAM emulation wrapper for libpq a few years back that supported some cobol applicaitons. char(1) fields are common cobol (and were mapped to "char" for performance), as are arrays of records. since at the time there was no support for arrays of composites or domains, I had to use parallel arrays of POD types when mapping these types of records to PostgreSQL. This would now break. Anyways, why prefer domain to type alias (char1 : "char" :: bigint : int8)? Main advantage of domains is being able to add user level constraints, which is kinda weird for system provided type. merlin