[HACKERS] code documentation
Hi all I wonder if there is a PostgreSQL code documentation that may help in understanding the code. Regards Islam Hegazy ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] adding operators
Thanks for this information. It was really helpful. Another problem that is facing me is altering existing functions. For example, what if I want to change the execution of the SUM function to work as follows: select sum(a) from mytable w(5); which means to sum only 5 records or records that arrived in the last 5 minutes. Do I need to change the core code of PostgreSQL to implement such thing? Regards Islam Hegazy - Original Message - From: Brendan Jurd [EMAIL PROTECTED] To: Islam Hegazy [EMAIL PROTECTED] Cc: pgsql-hackers@postgresql.org Sent: Sunday, September 30, 2007 8:38 PM Subject: Re: [HACKERS] adding operators On 10/1/07, Islam Hegazy [EMAIL PROTECTED] wrote: I am a graduate student in the University of Calgary. I want to add some new operators to PostgreSQL to perform some specific tasks in a project I am working in. My problem is that I cannot find my way into the code, where should I start and where to find the documentation for the code. There's no need to hack Postgres to add operators. You can do so by defining functions using CREATE FUNCTION, and then hooking operators up to them using CREATE OPERATOR. http://www.postgresql.org/docs/8.2/static/xoper.html http://www.postgresql.org/docs/8.2/static/sql-createoperator.html Regards, BJ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] adding operators
Dear PostgreSQL developers I am a graduate student in the University of Calgary. I want to add some new operators to PostgreSQL to perform some specific tasks in a project I am working in. My problem is that I cannot find my way into the code, where should I start and where to find the documentation for the code. Regards Islam Hegazy
[HACKERS] initializing the database cluster
Hi all I installed the source of PostgreSQL 8.2.3 on a linux machine. The installation process ended successfully but when I try to create the database cluster using the initdb command I get the following error: creating conversions ... sh: line 1: 1838 Segmentation fault (core dumped) /home/grads/imehegaz/MyPostgreSQL/bin/postgres --single -F -O -c search_path=pg_catalog -c exit_on_error=true template1 /dev/null child process exited with exit code 139 I installed the same source code before several time but this is the first time to get this error. Any idea of what could be the problem? Regards Islam Hegazy
Re: [HACKERS] modifying the table function
Hi again It seems now that I am one step away from the end. So far I have succeeded in returing row by row from the backend to the frontend, knew this from debugging. Now comes the point of displaying them directly not to wait till the end of the query. These are the steps I took: 1) redefined 'PrintQueryResults' in common.c to be extern (not static as the initial definition) to be able to use it elsewhere 2) added a declaration for ''PrintQueryResults' in common.h, to tell other files about it 3) removed 'PrintQueryResults' invocation from 'SendQuery' common.c 4) added #include ../bin/psql/common.h to fe-exec.c 5) called 'PrintQueryResults' from within 'PQexecFinish', last statment in the while loop when I gmake the project I receive the following error: ../../../src/interfaces/libpq/libpq.so: undefined reference to `PrintQueryTuples' collect2: ld returned 1 exit status gmake[3]: *** [initdb] Error 1 gmake[3]: Leaving directory `/home/grads/imehegaz/postgresql-8.2.3-b/src/bin/initdb' I wonder what does this error mean and how to solve it? Regards Islam Hegazy - Original Message - From: Tom Lane [EMAIL PROTECTED] To: Islam Hegazy [EMAIL PROTECTED] Cc: pgsql-hackers@postgresql.org Sent: Wednesday, April 18, 2007 6:38 PM Subject: Re: [HACKERS] modifying the table function Islam Hegazy [EMAIL PROTECTED] writes: I wonder if I am on the right track or not and how to know such kind of message sent from the server? Seems like you're doing it the hard way. Wouldn't it be easier to fix the client to display data before it's received the whole query result? regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] modifying the table function
Thanks for the documentation link. It helped me to understand how data are passed back to the client. I figured out that data is sent back to the client using the 'printtup' function. It is called by ExecSelect, called by ExecutorRun, etc. What I understand now is that the data is sent to the client and stored there until the client receives a message from the server to display it. The server sends the display message from within 'ReadyForQuery' but I can't figure it out. What I expect is that when I call 'exec_simple_query' several times, the server sends one row only for each call. But since they are separate calls, the client overwrites the previous results or saves the new row in a new place in memory such that it displays the last row only when the server invokes 'ReadyForQuery'. I wonder if I am on the right track or not and how to know such kind of message sent from the server? Regards Islam Hegazy - Original Message - From: Tom Lane [EMAIL PROTECTED] To: Islam Hegazy [EMAIL PROTECTED] Cc: pgsql-hackers@postgresql.org Sent: Tuesday, April 17, 2007 1:44 AM Subject: Re: [HACKERS] modifying the table function Islam Hegazy [EMAIL PROTECTED] writes: My question is how to inform the client that there is a tuple to display = and return back to the backend to continue the query execution? I'd suggest you start by reading http://developer.postgresql.org/pgdocs/postgres/protocol.html and then develop a clear specification at that level of what you think should happen. Perhaps after that exercise it will be clearer how to change the code. Think first, program later. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] modifying the table function
Hi there I made some changes in postgresql source code to let the table function work in iteration fashion rather than materialization fashion. My main modifications are in 'exec_simple_query' function, I changed 'portalRunSelect' to return just one tuple instead of 'FETCH_ALL'. I made other variables static as the 'portal', 'receiver', etc. so that the program returns to them to continue execution from the last point. Then I added more calls to 'exec_simple_query' and it worked correctly. For example, if I added 4 calls to 'exec_simple_query' the 4th tuple is returned. My problem lies now in how to display the 1st, 2nd, 3rd tuples not just the 4th. I tried to call 'pq_flush' after each 'exec_simple_query' but nothing is displayed. I replaced 'pq_flush' with 'ReadyForQuery' but it gives the following error 'error 0x54 message received while system is idle'. My question is how to inform the client that there is a tuple to display and return back to the backend to continue the query execution? Regards Islam Hegazy
Re: [HACKERS] modifying the tbale function
So, I understood from all those opinions that much of the work is to be done in the interface language interpreter not postgresql code itself. Am I right or I missed something? Regards Islam Hegazy - Original Message - From: Andrew Dunstan [EMAIL PROTECTED] To: Florian G. Pflug [EMAIL PROTECTED] Cc: Gregory Stark [EMAIL PROTECTED]; Richard Huxton dev@archonet.com; Heikki Linnakangas [EMAIL PROTECTED]; Tom Lane [EMAIL PROTECTED]; Neil Conway [EMAIL PROTECTED]; Martijn van Oosterhout kleptog@svana.org; Islam Hegazy [EMAIL PROTECTED]; pgsql-hackers@postgresql.org Sent: Monday, March 19, 2007 12:18 PM Subject: Re: [HACKERS] modifying the tbale function Florian G. Pflug wrote: Just a thought - I believe that there are portable user-space thread implementations that contain little or no machine-specific code. What if postgres used one of those to switch from the PL into the executor and back after, say, 1000 rows were returned by the SFR? What would be needed is basically some enhanced version of setjmp/longjmp that actually saves the stack, and not just resets the stackpointer. Since context switching would occur only at two well-defined places (Some return_next_row function that PLs call when a SFR returns a row, and in the executor if no more previously returned rows from that SFR are available), this wouldn't introduce the usual multithreading headache, but still allow to switch in and out of the PL interpreter. This just sounds horribly fragile. Are we really sure that this isn't a solution in search of a problem? cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] modifying the table function
Hi there I am trying to modify the execution of the table function to work in iterator fashion instead of materializing the output. I have been digging the Postgresql code source for about a month now and I can figure out where the execution of the table function works. I will be very grateful if anyone tell where to begin as my project due is after 10 days only. Regards Islam Hegazy
[HACKERS] modifying the tbale function
Hi there I am trying to modify the execution of the table function to work in iterator fashion instead of materializing the output. I have been digging the Postgresql code source for about a month now and I can figure out where the execution of the table function works. I will be very grateful if anyone tell where to begin as my project due is after 10 days only. Regards Islam Hegazy
Re: [HACKERS] modifying the tbale function
Returning k rows would be a reasonable solution but which functions need to be modified to achieve this. - Original Message - From: Neil Conway [EMAIL PROTECTED] To: Andrew Dunstan [EMAIL PROTECTED] Cc: Martijn van Oosterhout kleptog@svana.org; Islam Hegazy [EMAIL PROTECTED]; pgsql-hackers@postgresql.org Sent: Sunday, March 18, 2007 4:57 PM Subject: Re: [HACKERS] modifying the tbale function Andrew Dunstan wrote: I'm not convinced it would be a huge gain anyway. Switching madly in and out of the perl interpreter at least is a known performance problem, IIRC Returning control to the backend for every row returned would likely be excessive, but you could return once every k rows and get most of the benefits of both approaches (k might be on the order of 1000). The problem with the current approach is that it makes returning large result sets from PL functions very expensive, since they need to be spooled to disk. As for using threads, that's pretty much a non-starter: we can't safely allow calls into the backend from multiple concurrent threads, and I doubt that will chance any time soon. -Neil ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
