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 wrote: Robert Haas writes: On Fri, Jul 3, 2009 at 4:00 PM, Tom Lane wrote: "Kevin Grittner" 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 Lane 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 */
Re: [HACKERS] ECPG support for string pseudo-type
Boszormenyi Zoltan 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 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
[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 Stark 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 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 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 http://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 :
> On Sat, Jul 4, 2009 at 10:31 PM, Greg Stark 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
#include
#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;
}
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
2009/7/3 Robert Haas : > The application stamps comments with the > community login of the person who left them, but the import stamped > them with names instead. This is actually of some significance, since > the app will allow you to edit your own comments but not those of > other people. We could probably fix this if someone can give us > access to (or a dump of) the realname to username mappings from the > community login DB. Nobody came forward with a mapping of real names to community logins, so I went ahead and did this the dumb, slow way (eyeballing the wiki history and manually creating a mapping for the names we have in the commitfest app so far). I've updated the patch comment creator field with the login names I was able to map, but there are a few contributors who either don't have a community login, or haven't used the wiki. In those cases I left the name as-is. You should now be able to edit comments that you created. If you think you should be able to edit a comment, but you can't because the login name is wrong, let me know and I'll fix it up. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
