[HACKERS] About debug means ---How to debug a function seperately in an easy way?

[汪琦]

Hello, pgsql-hackers:

I want to debug one function in postgre backend.

for example, I want to debug the following function :

array_set(ArrayType *array,
  int nSubscripts,
  int *indx,
  Datum dataValue,
  bool isNull,
  int arraytyplen,
  int elmlen,
  bool elmbyval,
  char elmalign)

What I want is to set various inputs, and see the corresponding result.

Meanwhile , I don't know how to design the test case from the regular 
process, from TCOP, parser, analyzer,... and finally to array_set()

I just want to take it in an easy way, for example , I write some code 
somewhere in postgre backend source
code, and make up many different inputs and see the result returned by this 
function array_set.

Is there some convenient way to do it?

Thanks a lot ^_^



yours sincerely
　bill...@163.com
　　　2008-12-15




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] why copy tuple in the end of trigger when nothing changed in NEW, OLD record variable

[汪琦]

hello, everyone:

version 8.3.0 in function plpgsql_exec_trigger.

in a trigger, if NEW is returned as the result and we do nothing to NEW.


for example, we have a table like this:

create table test (a int);
insert into test values(1);

and a trigger like:

create or replace function test_trigger() returns trigger as $$
begin
return new;
end; $$language plpgsql;

create trigger before_update_test before update
on test for each row execute procedure test_trigger();


in this trigger, we don't change the value of NEW.

than execute:

update test set a = 3;



after execution:

   /* Copy tuple to upper executor memory */
   rettup = SPI_copytuple((HeapTuple) (estate.retval));

we come to function ExecUpdate():

HeapTuple newtuple;
newtuple = ExecBRUpdateTriggers(estate, resultRelInfo,
  tupleid, tuple);



Since the trigger's return value is copied to another memory address, 
the newtuple is impossible equal to the oldtuple.

so the following condition:

  if (newtuple != tuple) /* modified by Trigger(s) */
  {

is FALSE for ever.



I think we can add some judgment conditions in function 
plpgsql_exec_trigger() to avoid this problem.


[EMAIL PROTECTED]
　　2008-06-10




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] a question about exec_simple_query()

[汪琦]

Hi, everyone:

In functin exec_simple_query(), why we run a simple query 
wrapped in a portal.

For instance:

version 8.3.0 ,postgres.c, Line 908

/*
 * Create unnamed portal to run the query or queries in. If 
there
 * already is one, silently drop it.
 */
portal = CreatePortal(, true, true);

..


In other words, what's the benifit we use a portal to run a 
simple query?


Thanks for your help!  :)




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers