[HACKERS] Decimal values in
Dear Dev-List, inside execProcnode.c's ExecProcNode method we want to extract the value of a tuple for a specific attribute. This works great for integers and strings, but we are not able to figure out how to do this for floating point numbers. Below is some example code snippet to show our problem: TupleTableSlot * ExecProcNode(PlanState *node) { TupleTableSlot *result; ... bool isNull; Datum datum = slot_getattr(result,0, isNull); Form_pg_attribute *attrList = result-tts_tupleDescriptor-attrs; if(attrList[0]-atttypid==INT4OID){ int value = (int) (datum); ... } else if(attrList[0]-atttypid==VARCHAROID){ char* value = TextDatumGetCString(datum); ... //this does not work :( } else if(attrList[0]-atttypid==DECIMAL_OID /*what is the right OID*/){ //the value does not seem to be stored in the datum float value = (float) (datum); ... } ... } How can we get those values? Yours sincerely, Fabian Tschirschnitz.
[HACKERS] identify table oid for an AggState during plan tree initialization
Hi, during the initialization of the nodes in the plan tree (in ExecInitNode in the file execProcnode.c) I want to find out for a node with the type T_Agg which table will be aggregated. I tried the following: resultAsAggState = ExecInitAgg((Agg *) node, estate, eflags); if (resultAsAggState) { //tableOid = rel-rd_id; //tableOid = resultAsAggState-ss.ss_currentRelation-rd_id; } It would be great to get the Oid of the table, but I would also be satisfied if I could get at least the name of the table. Does anyone know if it is possible to gather these information? Best regards Cathleen
Re: [HACKERS] identify table oid for an AggState during plan tree initialization
2014/1/15 Masterprojekt Naumann1 mpws201...@gmail.com Hi, during the initialization of the nodes in the plan tree (in ExecInitNode in the file execProcnode.c) I want to find out for a node with the type T_Agg which table will be aggregated. I tried the following: resultAsAggState = ExecInitAgg((Agg *) node, estate, eflags); if (resultAsAggState) { //tableOid = rel-rd_id; //tableOid = resultAsAggState-ss.ss_currentRelation-rd_id; } It would be great to get the Oid of the table, but I would also be satisfied if I could get at least the name of the table. Does anyone know if it is possible to gather these information? Best regards Cathleen Sorry my mail program send the mail to early. Please ignore the line tableOid = rel-rd_id. I was just deleting the line when google send the mail :( resultAsAggState is of the type AggState. As you can see I tried to get the Oid with the ScanState inside of the AggState, but its Relation ss_currentRelation is not set already. Is there another way to get the Oid?
Re: [HACKERS] identify table oid for an AggState during plan tree initialization
2014/1/15 Ashutosh Bapat ashutosh.ba...@enterprisedb.com Hi Cathleen, An aggregate can be working on more than one table e.g. select count(*) from a, b, c where a.c1 = b.c1 and b.c1 = c.c1; In such a case, which table would you like to be reported? IOW, it doesn't look to be sensible to attach and aggregate with a table. If you can explain what you intend to do with that information, there might be other ways to solve your problem. On Wed, Jan 15, 2014 at 3:29 PM, Masterprojekt Naumann1 mpws201...@gmail.com wrote: 2014/1/15 Masterprojekt Naumann1 mpws201...@gmail.com Hi, during the initialization of the nodes in the plan tree (in ExecInitNode in the file execProcnode.c) I want to find out for a node with the type T_Agg which table will be aggregated. I tried the following: resultAsAggState = ExecInitAgg((Agg *) node, estate, eflags); if (resultAsAggState) { //tableOid = rel-rd_id; //tableOid = resultAsAggState-ss.ss_currentRelation-rd_id; } It would be great to get the Oid of the table, but I would also be satisfied if I could get at least the name of the table. Does anyone know if it is possible to gather these information? Best regards Cathleen Sorry my mail program send the mail to early. Please ignore the line tableOid = rel-rd_id. I was just deleting the line when google send the mail :( resultAsAggState is of the type AggState. As you can see I tried to get the Oid with the ScanState inside of the AggState, but its Relation ss_currentRelation is not set already. Is there another way to get the Oid? -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company Hi, maybe I should clarify what I want to achieve: At the moment I only handle special aggregations with a filter that compares values with a constant. An exampe query would be select sum(c_custkey), c_nationkey from customer group by c_nationkey having sum(c_custkey) = 445820473; This query can be run on TPCH. For such special queries I want to find out, on which column in the query result will be filtered and what is the filtered value. For the columnid, it is sufficient, if I get the table OID and the columnid of the original column, i.e. the table OID of customer und the columnid of c_custkey in the original table. I know that the expression is represented by an OpExpr, that has an opno and operators. I would like to find such expression in an AggState. Additionally, I need the table OID, which may be elsewhere. Where can I find this information? Best regards, Cathleen
[HACKERS] Convert Datum* to char*
Hi, I want to read an attribute value from a TupleTableSlot. When I try to convert an attribute of SQL type varchar from Datum* to char* with the help of the method TextDatumGetCString(...), sometimes there is a segmentation fault. The segmentation fault comes from the method TextDatumGetCString(...), which is defined in utils/builtins.h. Unfortunately, the fault is not always reproducible. I debugged the code and figured out that the value of result-tts_values[i] sometimes is random. It may be uninitialized memory. In other cases, the variable value is NULL. Then, I can just skip the conversion from Datum* to char*, so that there is no segmentation fault. I attached a patch with the code. The relevant line is: char *value = TextDatumGetCString(result-tts_values[i]); The SQL-Query is a simple SELECT * from ... on the TPC-H table customer. About every third execution leads to a segmentation fault. Why is the memory of the variable uninitialized? I am not very familiar with Postgres. Is there another method to get a varchar attribute out of a TupleTableSlot as string? Best regards Maria diff --git a/src/backend/executor/execProcnode.c b/src/backend/executor/execProcnode.c index 76dd62f..be05ad0 100644 --- a/src/backend/executor/execProcnode.c +++ b/src/backend/executor/execProcnode.c @@ -77,6 +77,7 @@ */ #include postgres.h +#include catalog/pg_attribute.h #include executor/executor.h #include executor/nodeAgg.h #include executor/nodeAppend.h @@ -112,6 +113,7 @@ #include executor/nodeWindowAgg.h #include executor/nodeWorktablescan.h #include miscadmin.h +#include utils/builtins.h /* @@ -509,6 +511,17 @@ ExecProcNode(PlanState *node) if (node-instrument) InstrStopNode(node-instrument, TupIsNull(result) ? 0.0 : 1.0); + int i; + for(i = 0; i result-tts_tupleDescriptor-natts; i++) { + if (1042 == result-tts_tupleDescriptor-attrs[i]-atttypid) { + if (0 == result-tts_values[i]) { +printf(null found\n); + } else { +char *value = TextDatumGetCString(result-tts_values[i]); + } + } + } + return result; } -- 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] Convert Datum* to char*
Yes, in some cases, Datum is 0, which I test before conversion. Additionally, I looked at tts_isnull but it does not prevent the segmentation fault in some cases. The problem is. that sometimes the value is random, but I don't know why and how I can detect that case. 2014/1/6 Heikki Linnakangas hlinnakan...@vmware.com On 01/06/2014 03:09 PM, Masterprojekt Naumann1 wrote: I want to read an attribute value from a TupleTableSlot. When I try to convert an attribute of SQL type varchar from Datum* to char* with the help of the method TextDatumGetCString(...), sometimes there is a segmentation fault. The segmentation fault comes from the method TextDatumGetCString(...), which is defined in utils/builtins.h. Unfortunately, the fault is not always reproducible. I debugged the code and figured out that the value of result-tts_values[i] sometimes is random. It may be uninitialized memory. In other cases, the variable value is NULL. Then, I can just skip the conversion from Datum* to char*, so that there is no segmentation fault. I attached a patch with the code. The relevant line is: char *value = TextDatumGetCString(result-tts_values[i]); The SQL-Query is a simple SELECT * from ... on the TPC-H table customer. About every third execution leads to a segmentation fault. Maybe the field is NULL? By convention, we normally set the Datum to 0 on an SQL NULL, but you're supposed to check tts_isnull first, and ignore tts_values[x] when tts_isnull[x] is true. - Heikki
Re: [HACKERS] Convert Datum* to char*
2014/1/6 Craig Ringer cr...@2ndquadrant.com On 01/06/2014 09:09 PM, Masterprojekt Naumann1 wrote: Why is the memory of the variable uninitialized? Are there any other patches you've made to the running PostgreSQL instance? I'd want to run under Valgrind and see what turned up. This might be a bit tricky with an intermittent fault during something like a TPC-H run, though. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services I am on the latest commit of the master branch of the GitHub repository (commit 10a82cda67731941c18256e009edad4a784a2994) and I only applied the attached patch. I hope that you can reproduce the fault. Thanks, Maria
Re: [HACKERS] Convert Datum* to char*
2014/1/6 Thomas Fanghaenel tfanghae...@salesforce.com On Mon, Jan 6, 2014 at 8:09 AM, Masterprojekt Naumann1 mpws201...@gmail.com wrote: Why is the memory of the variable uninitialized? Are you checking that i = slot-tts_nvalid before accessing the tts_values and tts_isnull arrays? Thanks for your ideas! I could fix the segmentation fault. I have to check both, slot-tts_isnull and 0 == slot-tts_values[i]. If both are false, I can convert the value with the method TextDatumGetCString(...). Nevertheless, slot-tts_nvalid is always 0. I hope that there is no other problem.