postgresql/src/interfaces/ecpg/ecpglib/typename.c

145 lines
3.0 KiB
C
Raw Normal View History

2010-09-20 22:08:53 +02:00
/* src/interfaces/ecpg/ecpglib/typename.c */
2003-06-15 06:07:58 +02:00
#define POSTGRES_ECPG_INTERNAL
#include "postgres_fe.h"
#include "catalog/pg_type_d.h"
#include "ecpglib.h"
#include "ecpglib_extern.h"
#include "ecpgtype.h"
#include "sql3types.h"
#include "sqltypes.h"
/*
* This function is used to generate the correct type names.
*/
const char *
ecpg_type_name(enum ECPGttype typ)
{
switch (typ)
{
case ECPGt_char:
case ECPGt_string:
return "char";
case ECPGt_unsigned_char:
return "unsigned char";
case ECPGt_short:
return "short";
case ECPGt_unsigned_short:
return "unsigned short";
case ECPGt_int:
return "int";
case ECPGt_unsigned_int:
return "unsigned int";
case ECPGt_long:
return "long";
case ECPGt_unsigned_long:
return "unsigned long";
case ECPGt_long_long:
return "long long";
case ECPGt_unsigned_long_long:
return "unsigned long long";
case ECPGt_float:
return "float";
case ECPGt_double:
return "double";
case ECPGt_bool:
return "bool";
case ECPGt_varchar:
return "varchar";
case ECPGt_bytea:
return "bytea";
case ECPGt_char_variable:
return "char";
case ECPGt_decimal:
return "decimal";
case ECPGt_numeric:
return "numeric";
2003-03-20 16:56:50 +01:00
case ECPGt_date:
return "date";
2003-03-20 16:56:50 +01:00
case ECPGt_timestamp:
return "timestamp";
case ECPGt_interval:
return "interval";
2003-06-20 14:01:46 +02:00
case ECPGt_const:
2003-06-20 14:00:59 +02:00
return "Const";
default:
abort();
}
return ""; /* keep MSC compiler happy */
}
int
ecpg_dynamic_type(Oid type)
{
switch (type)
{
case BOOLOID:
return SQL3_BOOLEAN; /* bool */
case INT2OID:
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
return SQL3_SMALLINT; /* int2 */
case INT4OID:
return SQL3_INTEGER; /* int4 */
case TEXTOID:
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
return SQL3_CHARACTER; /* text */
case FLOAT4OID:
return SQL3_REAL; /* float4 */
case FLOAT8OID:
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
return SQL3_DOUBLE_PRECISION; /* float8 */
case BPCHAROID:
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
return SQL3_CHARACTER; /* bpchar */
case VARCHAROID:
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
return SQL3_CHARACTER_VARYING; /* varchar */
case DATEOID:
return SQL3_DATE_TIME_TIMESTAMP; /* date */
case TIMEOID:
return SQL3_DATE_TIME_TIMESTAMP; /* time */
case TIMESTAMPOID:
return SQL3_DATE_TIME_TIMESTAMP; /* datetime */
case NUMERICOID:
return SQL3_NUMERIC; /* numeric */
default:
return 0;
}
}
int
sqlda_dynamic_type(Oid type, enum COMPAT_MODE compat)
{
switch (type)
{
case CHAROID:
case VARCHAROID:
case BPCHAROID:
case TEXTOID:
return ECPGt_char;
case INT2OID:
return ECPGt_short;
case INT4OID:
return ECPGt_int;
case FLOAT8OID:
return ECPGt_double;
case FLOAT4OID:
return ECPGt_float;
case NUMERICOID:
return INFORMIX_MODE(compat) ? ECPGt_decimal : ECPGt_numeric;
case DATEOID:
return ECPGt_date;
case TIMESTAMPOID:
case TIMESTAMPTZOID:
return ECPGt_timestamp;
case INTERVALOID:
return ECPGt_interval;
case INT8OID:
#ifdef HAVE_LONG_LONG_INT_64
return ECPGt_long_long;
#endif
#ifdef HAVE_LONG_INT_64
return ECPGt_long;
#endif
2010-02-26 03:01:40 +01:00
/* Unhandled types always return a string */
default:
return ECPGt_char;
}
}