Re: [HACKERS] single bit integer (TINYINT) revisited for 8.5
On Fri, 2009-07-03 at 13:38 -0400, Robert Treat wrote: On Thursday 02 July 2009 12:40:49 Simon Riggs wrote: On Wed, 2009-07-01 at 11:19 -0400, Caleb Cushing wrote: A couple of times I've been told you don't need tinyint, use boolean which is not true, several projects I've worked on I've needed and integer field that supports number within a small range 0-5 1-10 1-100 or something similar. I end up using smallint but it's range is huge for the actual requirements. Completely agree. Blech. More often than not, I find people using all these granular types to be nothing more than premature optimization. And if you really do need a single byte type, you can use char (though again I'm not a big fan of that) I agree that many optimizations are used inappropriately. Another reason for making it an add-on module. I'm aware of char and it doesn't do all I would wish. I'm most or the way through working on this as an add-on module, rather than a new datatype in core. I don't see much reason to include it in core: its not an SQL standard datatype, it complicates catalog entries and most people don't need or want it. That's too bad. I'd much rather see someone implement something closer to Oracle's number type. Please explain what you mean? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Jul 3, 2009, at 11:56 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 4:00 PM, Tom Lanet...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: It seems to be inconsistent. Probably because everything wound up with the same date, the order is probably more-or-less random. Yeah, I think that's what I'm seeing. I think what you guys must be seeing is that the topics are not in quite the same order. As far as I can tell, the ordering of patches within topics is absolutely identical. No, what we're complaining about is the ordering of comments for a single patch. If you look at http://commitfest.postgresql.org/action/commitfest_view?id=2 in some cases there are Comments before the Patch itself, and in some cases after, but more often than not the original Patch is at the bottom. Oh, duh. I totally missed that. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
On Fri, Jul 3, 2009 at 8:19 PM, Tom Lanet...@sss.pgh.pa.us wrote: The main reason contrib still has the alternate method is that PGXS doesn't really work until after you've installed the core build. For modules distributed separately from core, it doesn't seem that exciting to be able to build using the contrib method. Now, having said that, I'm personally interested in being able to build pg_migrator against an uninstalled source tree, because I foresee needing to do that for RPM packaging purposes. But I could easily patch the makefiles if needed to make that happen. I don't think this case should drive the choice of what's the default or common method. Couldn't we provide a special pg_config and makefiles in the source tree which know the right paths and does the right thing for in-tree builds? -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ECPG support for string pseudo-type
Hi,
in a continued effort for better Informix ESQL/C compatibility,
we added the string pseudo-type handling to ECPG.
This type in ESQL/C is documented as:
--
The string Data Type
The string data type is an ESQL/C data type that holds character data
that is
null terminated and does not contain trailing blanks. When an application
reads a value from a CHAR column into a host variable of data type
string, it
strips the value of any trailing blanks and appends a null terminator. The
behavior is the same if an application reads a value from a VARCHAR column
into a host variable of data type string.
Declare the string data type with a length of [n+1] (where n is the size
of the
column with values that you want read) to allow for the null terminator. Use
the following syntax to declare a host variable of the string data type:
EXEC SQL BEGIN DECLARE SECTION;
string str_name[n + 1];
EXEC SQL END DECLARE SECTION;
--
So, we added it accordingly. This means the following:
- string has become a type name, reserved word in ECPG.
- When ECPG encounters string, it will be transparently replaced by
char in the generated C source, but ECPGt_string will be passed
to ECPGdo()
- ecpg_get_data() right-trims the string value if ECPGt_string was passed.
Two regression tests had to be modified because string is now
a type name: preproc/define.pgc and preproc/type.pgc.
The attached patch is built upon our previous patch supporting
dynamic cursor and SQLDA.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil. (Matthew 5:37) - basics of digital technology.
May your kingdom come - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
diff -dcrpN postgresql-8.4.0-sqlda/src/interfaces/ecpg/ecpglib/data.c postgresql-8.4.0-string/src/interfaces/ecpg/ecpglib/data.c
*** postgresql-8.4.0-sqlda/src/interfaces/ecpg/ecpglib/data.c 2009-01-15 12:52:55.0 +0100
--- postgresql-8.4.0-string/src/interfaces/ecpg/ecpglib/data.c 2009-07-04 12:27:57.0 +0200
*** ecpg_get_data(const PGresult *results, i
*** 138,143
--- 138,144
case ECPGt_char:
case ECPGt_unsigned_char:
case ECPGt_varchar:
+ case ECPGt_string:
break;
default:
*** ecpg_get_data(const PGresult *results, i
*** 389,394
--- 390,396
case ECPGt_char:
case ECPGt_unsigned_char:
+ case ECPGt_string:
if (pval)
{
if (varcharsize == 0 || varcharsize size)
*** ecpg_get_data(const PGresult *results, i
*** 426,431
--- 428,454
sqlca-sqlwarn[0] = sqlca-sqlwarn[1] = 'W';
}
}
+ /* Do the rtrim() */
+ if (type == ECPGt_string)
+ {
+ char *str = (char *) ((long) var + offset * act_tuple);
+ char *last;
+ int len = strlen(str);
+
+ last = str + len;
+ while (last str)
+ {
+ if (*last == '\0')
+ last--;
+ else if (*last == ' ')
+ {
+ *last = '\0';
+ last--;
+ }
+ else
+ break;
+ }
+ }
pval += size;
}
break;
diff -dcrpN postgresql-8.4.0-sqlda/src/interfaces/ecpg/ecpglib/descriptor.c postgresql-8.4.0-string/src/interfaces/ecpg/ecpglib/descriptor.c
*** postgresql-8.4.0-sqlda/src/interfaces/ecpg/ecpglib/descriptor.c 2009-07-04 10:42:50.0 +0200
--- postgresql-8.4.0-string/src/interfaces/ecpg/ecpglib/descriptor.c 2009-07-04 12:12:02.0 +0200
*** get_char_item(int lineno, void *var, enu
*** 201,206
--- 201,207
{
case ECPGt_char:
case ECPGt_unsigned_char:
+ case ECPGt_string:
strncpy((char *) var, value, varcharsize);
break;
case ECPGt_varchar:
diff -dcrpN postgresql-8.4.0-sqlda/src/interfaces/ecpg/ecpglib/execute.c postgresql-8.4.0-string/src/interfaces/ecpg/ecpglib/execute.c
*** postgresql-8.4.0-sqlda/src/interfaces/ecpg/ecpglib/execute.c 2009-07-04 10:42:50.0 +0200
--- postgresql-8.4.0-string/src/interfaces/ecpg/ecpglib/execute.c 2009-07-04 12:12:02.0 +0200
*** ecpg_store_result(const PGresult *result
*** 360,365
--- 360,366
{
case ECPGt_char:
case ECPGt_unsigned_char:
+ case ECPGt_string:
if (!var-varcharsize !var-arrsize)
{
/* special mode for handling char**foo=0 */
*** ecpg_store_result(const PGresult *result
*** 419,425
/* fill the variable with the tuple(s) */
if (!var-varcharsize !var-arrsize
! (var-type == ECPGt_char || var-type == ECPGt_unsigned_char))
{
/* special mode for handling char**foo=0 */
--- 420,426
/*
Re: [HACKERS] ECPG support for string pseudo-type
Boszormenyi Zoltan z...@cybertec.at writes: in a continued effort for better Informix ESQL/C compatibility, we added the string pseudo-type handling to ECPG. ... - string has become a type name, reserved word in ECPG. This seems like a sufficient reason to reject the patch. Who knows what that will break? (I observe that it already broke a few of the ecpg regression tests, suggesting that using string as a variable name is hardly uncommon.) 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
Re: [HACKERS] ECPG support for string pseudo-type
Hi,
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
in a continued effort for better Informix ESQL/C compatibility,
we added the string pseudo-type handling to ECPG.
...
- string has become a type name, reserved word in ECPG.
This seems like a sufficient reason to reject the patch. Who knows
what that will break? (I observe that it already broke a few of the
ecpg regression tests, suggesting that using string as a variable
name is hardly uncommon.)
regards, tom lane
OK, let me retry. This version treats string as a non-reserved word,
and also discovers whether the PGC contains this construct below,
as in ecpg/tests/preproc/type.pgc:
exec sql type string is char[11];
typedef char string[11];
Now all regression tests pass unchanged and ECPG also accepts
string *string;
and
string string[N];
without typedef, replacing string with char.
I think it's acceptable.
Thanks in advance,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil. (Matthew 5:37) - basics of digital technology.
May your kingdom come - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
diff -dcrpN postgresql-8.4.0-sqlda/src/interfaces/ecpg/ecpglib/data.c postgresql-8.4.0-string/src/interfaces/ecpg/ecpglib/data.c
*** postgresql-8.4.0-sqlda/src/interfaces/ecpg/ecpglib/data.c 2009-01-15 12:52:55.0 +0100
--- postgresql-8.4.0-string/src/interfaces/ecpg/ecpglib/data.c 2009-07-04 12:27:57.0 +0200
*** ecpg_get_data(const PGresult *results, i
*** 138,143
--- 138,144
case ECPGt_char:
case ECPGt_unsigned_char:
case ECPGt_varchar:
+ case ECPGt_string:
break;
default:
*** ecpg_get_data(const PGresult *results, i
*** 389,394
--- 390,396
case ECPGt_char:
case ECPGt_unsigned_char:
+ case ECPGt_string:
if (pval)
{
if (varcharsize == 0 || varcharsize size)
*** ecpg_get_data(const PGresult *results, i
*** 426,431
--- 428,454
sqlca-sqlwarn[0] = sqlca-sqlwarn[1] = 'W';
}
}
+ /* Do the rtrim() */
+ if (type == ECPGt_string)
+ {
+ char *str = (char *) ((long) var + offset * act_tuple);
+ char *last;
+ int len = strlen(str);
+
+ last = str + len;
+ while (last str)
+ {
+ if (*last == '\0')
+ last--;
+ else if (*last == ' ')
+ {
+ *last = '\0';
+ last--;
+ }
+ else
+ break;
+ }
+ }
pval += size;
}
break;
diff -dcrpN postgresql-8.4.0-sqlda/src/interfaces/ecpg/ecpglib/descriptor.c postgresql-8.4.0-string/src/interfaces/ecpg/ecpglib/descriptor.c
*** postgresql-8.4.0-sqlda/src/interfaces/ecpg/ecpglib/descriptor.c 2009-07-04 10:42:50.0 +0200
--- postgresql-8.4.0-string/src/interfaces/ecpg/ecpglib/descriptor.c 2009-07-04 12:12:02.0 +0200
*** get_char_item(int lineno, void *var, enu
*** 201,206
--- 201,207
{
case ECPGt_char:
case ECPGt_unsigned_char:
+ case ECPGt_string:
strncpy((char *) var, value, varcharsize);
break;
case ECPGt_varchar:
diff -dcrpN postgresql-8.4.0-sqlda/src/interfaces/ecpg/ecpglib/execute.c postgresql-8.4.0-string/src/interfaces/ecpg/ecpglib/execute.c
*** postgresql-8.4.0-sqlda/src/interfaces/ecpg/ecpglib/execute.c 2009-07-04 10:42:50.0 +0200
--- postgresql-8.4.0-string/src/interfaces/ecpg/ecpglib/execute.c 2009-07-04 12:12:02.0 +0200
*** ecpg_store_result(const PGresult *result
*** 360,365
--- 360,366
{
case ECPGt_char:
case ECPGt_unsigned_char:
+ case ECPGt_string:
if (!var-varcharsize !var-arrsize)
{
/* special mode for handling char**foo=0 */
*** ecpg_store_result(const PGresult *result
*** 419,425
/* fill the variable with the tuple(s) */
if (!var-varcharsize !var-arrsize
! (var-type == ECPGt_char || var-type == ECPGt_unsigned_char))
{
/* special mode for handling char**foo=0 */
--- 420,426
/* fill the variable with the tuple(s) */
if (!var-varcharsize !var-arrsize
! (var-type == ECPGt_char || var-type == ECPGt_unsigned_char || var-type == ECPGt_string))
{
/* special mode for handling char**foo=0 */
*** ecpg_store_input(const int lineno, const
*** 758,763
--- 759,765
case ECPGt_char:
case ECPGt_unsigned_char:
+ case ECPGt_string:
{
/* set slen to string length if type is char * */
int slen = (var-varcharsize == 0) ? strlen((char *) var-value) : (unsigned int) var-varcharsize;
*** ecpg_execute(struct statement * stmt)
*** 1196,1201
[HACKERS] problem with varlena and extended type
Hello, I can't to find reason of my problem. I have a varlena type. This type works well with plain storage, but this raise some random exception with extended storage. It finish on Assert((data - start) == data_size)[heaptuple.c]; I checked - when I return varlena from in function, then it has correct size, but in this function VARSIZE returns different value. some log NOTICE: KOKES SIZE 36242, pointer: 149948300 -- varlena check NOTICE: heap_fill_tuple [size: 36250, bits -1, tupleesc: 150141444, attrs: 3 NOTICE: iteration 0 NOTICE: attbyval 1, attlen 4 NOTICE: [data: 150208808d, data length: 4] NOTICE: iteration 1 NOTICE: attbyval 1, attlen 4 NOTICE: [data: 150208812d, data length: 4] NOTICE: iteration 2 NOTICE: attbyval 0, attlen -1 NOTICE: FULL VARLENA 149948300 36242 -- correct size in heap_fill_tuple but NOTICE: KOKES SIZE 55966, pointer: 150029636, -- varlena size NOTICE: heap_fill_tuple [size: 55974, bits -1, tupleesc: 149930464, attrs: 3 NOTICE: iteration 0 NOTICE: attbyval 1, attlen 4 NOTICE: [data: 150029680d, data length: 4] NOTICE: iteration 1 NOTICE: attbyval 1, attlen 4 NOTICE: [data: 150029684d, data length: 4] NOTICE: iteration 2 NOTICE: attbyval 0, attlen -1 NOTICE: FULL VARLENA 150029636 13999 -- wrong size, why? NOTICE: 14007 [55974] psql83:/home/pavel/src/postgresql-8.3.7/contrib/kokes/objerr1.sql:4: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. any idea, why size of varlena is broken? thank you Pavel Stehule p.s. I use macros SET_VARSIZE and VARSIZE define DatumGetKokesData(x)--((KokesData*)DatumGetPointer(x)) #define PG_GETARG_KokesData(x)DatumGetKokesData( PG_DETOAST_DATUM(PG_GETARG_DATUM(x)) ) #define PG_RETURN_KokesData(x)PG_RETURN_POINTER(x) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] problem with varlena and extended type
It's pretty hard to guess where your bug is sitting here with no code and no idea even what you've done to trigger it. At a guess there someplace you haven't detoasted a datum that had to be detoasted. But like I said that's just a guess. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] problem with varlena and extended type
On Sat, Jul 4, 2009 at 10:31 PM, Greg Starkgsst...@mit.edu wrote: It's pretty hard to guess where your bug is sitting here with no code and no idea even what you've done to trigger it. At a guess there someplace you haven't detoasted a datum that had to be detoasted. But like I said that's just a guess. Actually on further thought I think this smells like a memory management bug. Maybe you've either you've prematurely freed this data structure or realloc'd it without tracking the new pointer and have returned a pointer to the freed object. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] commitfest.postgresql.org
On Saturday 04 July 2009 01:19:23 Joshua D. Drake wrote: On Fri, 2009-07-03 at 17:57 -0400, Robert Haas wrote: I guess I'm not really seeing why that particular thing should be a button rather than a link. It would mess up the formatting for no obvious benefit. Not arguing one way or the other, a button says, I am about to perform X. A link *always* says, I am about to go to a new web page. That was my feeling. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] commitfest.postgresql.org
Le 5 juil. 09 à 00:13, Peter Eisentraut a écrit : On Saturday 04 July 2009 01:19:23 Joshua D. Drake wrote: Not arguing one way or the other, a button says, I am about to perform X. A link *always* says, I am about to go to a new web page. That was my feeling. And bots (google etc) will follow links. -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] commitfest.postgresql.org
On Jul 4, 2009, at 5:18 PM, Dimitri Fontaine dfonta...@hi-media.com wrote: Le 5 juil. 09 à 00:13, Peter Eisentraut a écrit : On Saturday 04 July 2009 01:19:23 Joshua D. Drake wrote: Not arguing one way or the other, a button says, I am about to perform X. A link *always* says, I am about to go to a new web page. That was my feeling. And bots (google etc) will follow links. They won't log in, though. :-) Someone want to write a patch, then? ..Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator mention in documentation
Joe Conway wrote: Bruce Momjian wrote: Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Consistency here is pointless. IIRC the dual method is used in contrib because people did not trust the PGXS stuff enough to rip the original Make code out; or maybe because people did not want PGXS to become the default build method, but they allowed it to be used in contrib as a test bed that PGXS worked. The main reason contrib still has the alternate method is that PGXS doesn't really work until after you've installed the core build. For modules distributed separately from core, it doesn't seem that exciting to be able to build using the contrib method. Now, having said that, I'm personally interested in being able to build pg_migrator against an uninstalled source tree, because I foresee needing to do that for RPM packaging purposes. But I could easily patch the makefiles if needed to make that happen. I don't think this case should drive the choice of what's the default or common method. Well, PGXS is now the recommended install method in the pg_migrator INSTALL file. What other changes should I make? Since PGXS does not work under Windows, I think the only way to build non-contrib extensions on Windows is the contrib way (i.e. place in contrib folder and use contrib style Makefile). I assume this work too: gmake top_builddir=/usr/src/pgsql install -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] problem with varlena and extended type
2009/7/4 Greg Stark gsst...@mit.edu:
On Sat, Jul 4, 2009 at 10:31 PM, Greg Starkgsst...@mit.edu wrote:
It's pretty hard to guess where your bug is sitting here with no code
and no idea even what you've done to trigger it.
see attachment - sorry, comments are czech
At a guess there someplace you haven't detoasted a datum that had to
be detoasted. But like I said that's just a guess.
I have a problem with in function. So I have not a control over
process. I return a varlena value, that's all.
Actually on further thought I think this smells like a memory
management bug. Maybe you've either you've prematurely freed this data
structure or realloc'd it without tracking the new pointer and have
returned a pointer to the freed object.
I'll look on it. It looks strange. I don't use pfree. 2x or 3x use repalloc.
regards
Pavel Stehule
--
greg
http://mit.edu/~gsstark/resume.pdf
#include postgres.h
#include float.h
#include math.h
#include kokes.h
#include access/gist.h
#include access/skey.h
#include lib/stringinfo.h
#include utils/array.h
#include utils/builtins.h
#include libpq/pqformat.h
PG_MODULE_MAGIC;
PG_FUNCTION_INFO_V1(kokes_in);
PG_FUNCTION_INFO_V1(kokes_out);
PG_FUNCTION_INFO_V1(kokes_send);
PG_FUNCTION_INFO_V1(kokes_recv);
Datum kokes_in(PG_FUNCTION_ARGS);
Datum kokes_out(PG_FUNCTION_ARGS);
Datum kokes_send(PG_FUNCTION_ARGS);
Datum kokes_recv(PG_FUNCTION_ARGS);
extern int kokes_yyparse();
extern void kokes_scanner_init(const char *str);
extern void kokes_scanner_finish(void);
static void print_double_list(StringInfo str, double *data, unsigned long
cntpnt);
static void print_short_list(StringInfo str, short int *data, unsigned long
cntpnt);
static char *print_info(StringInfo str, char *buf);
static char *print_infos(StringInfo str, char *buf);
static char *print_atrs(StringInfo str, char *buf);
KokesData *kokes;
#define PORTABLE_SERIALIZATION
Datum
kokes_in(PG_FUNCTION_ARGS)
{
char*str;
str = PG_GETARG_CSTRING(0);
kokes_scanner_init(str);
if (kokes_yyparse() != 0)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg(bogus input)));
elog(NOTICE, KOKES SIZE %d, pointer: %d, LEN: %d, VARSIZE( kokes), kokes,
kokes-vl_len_);
kokes_scanner_finish();
PG_RETURN_KokesData(kokes);
}
Datum
kokes_out(PG_FUNCTION_ARGS)
{
Kokes kokes;
StringInfoData buf;
char*readbuf;
initStringInfo(buf);
kokes = PG_GETARG_KokesData(0);
elog(NOTICE, 1);
appendStringInfo(buf, ((%u , kokes-status);
elog(NOTICE, 2);
appendStringInfo(buf, (%ld %ld %ld %ld) , kokes-OOO[0], kokes-OOO[1],
kokes-OOO[2], kokes-OOO[3]);
appendStringInfo(buf, %lu %lu %d %d), kokes-key, kokes-cntpnt,
kokes-layer, kokes-alias);
elog(NOTICE, %s, buf.data);
print_double_list(buf, KOKES_X_ARRAY(kokes), kokes-cntpnt);
print_double_list(buf, KOKES_Y_ARRAY(kokes), kokes-cntpnt);
print_short_list(buf, KOKES_SP_ARRAY(kokes), kokes-cntpnt);
readbuf = print_infos(buf, KOKES_INF_ARRAY(kokes));
print_atrs(buf, readbuf);
elog(NOTICE, 3);
appendStringInfoChar(buf, ')');
PG_FREE_IF_COPY(kokes, 0);
PG_RETURN_CSTRING(buf.data);
}
static void
print_double_list(StringInfo str, double *data, unsigned long cntpnt)
{
int i;
appendStringInfo(str, ();
for (i = 0; i cntpnt; i++)
if (i 0)
appendStringInfo(str, %g, data[i]);
else
appendStringInfo(str, %g, data[i]);
appendStringInfoChar(str, ')');
}
static void
print_short_list(StringInfo str, short int *data, unsigned long cntpnt)
{
int i;
appendStringInfo(str, ();
for (i = 0; i cntpnt; i++)
if (i 0)
appendStringInfo(str, %d, data[i]);
else
appendStringInfo(str, %d, data[i]);
appendStringInfoChar(str, ')');
}
static char *
print_info(StringInfo str, char *buf)
{
GINFLEN ginflen = *((GINFLEN *) buf);
int processed_chars = 0;
buf += sizeof(GINFLEN);
appendStringInfoChar(str, '(');
/* pokud ma bod informace zobraz je */
if (*buf != '\0')
{
while (processed_chars ginflen)
{
if (processed_chars != 0)
appendStringInfoChar(str, ' ');
appendStringInfo(str, %c=', *buf++);
processed_chars += 1;
while (*buf != '\t' *buf != '\0')
{
appendStringInfoChar(str, *buf++);
processed_chars += 1;
}
appendStringInfoChar(str, '\'');
if
