Re: [PATCHES] Implemented current_query

2008-04-04 Thread Bruce Momjian

I have applied a modified version of this patch, attached.  I made a few
changes:

o  You had current_query() returning 'void' so it didn't work
o  I removed the dblink regression tests for current_query() as
   it is now a backend function
o  Update documentation to mention the possibility of multiple
   statements
o  Used the new cstring_to_text() usage that Tom had updated in
   CVS for this function
o  The pg_proc.h oids and number of columns didn't match CVS

Thanks for the patch.

---

Tomas Doran wrote:
 
 On 10 May 2007, at 03:09, Alvaro Herrera wrote:
  FWIW I think you should still provide dblink_current_query, even if  
  it's
  only a wrapper over current_query(), for backwards compatibility.
 
 Good point. Done as suggested (I think, or did you mean also the  
 change of instances to use current_query()?). Replaced  
 dblink_current_query with an SQL procedure wrapper, I assume that's  
 the most efficient way of doing it?
 
  Also, typically we don't remove items from the TODO list.  We mark  
  them
  as done prepending them with a dash.  Patch authors are not expected
  to do it either (though I don't see it be a problem if they did).
 
 Not quite sure what you're suggesting (which way round), so I just  
 didn't do it (as you said I'm not expected to).
 
  Doesn't matter ... just make sure duplicate_oids doesn't report a
  problem.  unused_oids is useful to find, err, unused OIDs.
 
 Ahh, hadn't found those, thanks. They're in the dev FAQ too, *blush*.  
 I need this for something I'm doing at $ork, and thought I'd  
 implement it in the backend, as well as a .so, it's been a learning  
 experience :)

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: contrib/dblink/dblink.c
===
RCS file: /cvsroot/pgsql/contrib/dblink/dblink.c,v
retrieving revision 1.71
diff -c -c -r1.71 dblink.c
*** contrib/dblink/dblink.c	26 Mar 2008 21:10:36 -	1.71
--- contrib/dblink/dblink.c	4 Apr 2008 16:45:36 -
***
*** 1631,1653 
  	PG_RETURN_TEXT_P(cstring_to_text(sql));
  }
  
- /*
-  * dblink_current_query
-  * return the current query string
-  * to allow its use in (among other things)
-  * rewrite rules
-  */
- PG_FUNCTION_INFO_V1(dblink_current_query);
- Datum
- dblink_current_query(PG_FUNCTION_ARGS)
- {
- 	if (debug_query_string)
- 		PG_RETURN_TEXT_P(cstring_to_text(debug_query_string));
- 	else
- 		PG_RETURN_NULL();
- }
- 
- 
  /*
   * internal functions
   */
--- 1631,1636 
Index: contrib/dblink/dblink.h
===
RCS file: /cvsroot/pgsql/contrib/dblink/dblink.h,v
retrieving revision 1.19
diff -c -c -r1.19 dblink.h
*** contrib/dblink/dblink.h	1 Jan 2008 19:45:45 -	1.19
--- contrib/dblink/dblink.h	4 Apr 2008 16:45:36 -
***
*** 56,61 
  extern Datum dblink_build_sql_insert(PG_FUNCTION_ARGS);
  extern Datum dblink_build_sql_delete(PG_FUNCTION_ARGS);
  extern Datum dblink_build_sql_update(PG_FUNCTION_ARGS);
- extern Datum dblink_current_query(PG_FUNCTION_ARGS);
  
  #endif   /* DBLINK_H */
--- 56,60 
Index: contrib/dblink/dblink.sql.in
===
RCS file: /cvsroot/pgsql/contrib/dblink/dblink.sql.in,v
retrieving revision 1.14
diff -c -c -r1.14 dblink.sql.in
*** contrib/dblink/dblink.sql.in	13 Nov 2007 04:24:27 -	1.14
--- contrib/dblink/dblink.sql.in	4 Apr 2008 16:45:36 -
***
*** 163,173 
  AS 'MODULE_PATHNAME','dblink_build_sql_update'
  LANGUAGE C STRICT;
  
- CREATE OR REPLACE FUNCTION dblink_current_query ()
- RETURNS text
- AS 'MODULE_PATHNAME','dblink_current_query'
- LANGUAGE C;
- 
  CREATE OR REPLACE FUNCTION dblink_send_query(text, text)
  RETURNS int4
  AS 'MODULE_PATHNAME', 'dblink_send_query'
--- 163,168 
Index: contrib/dblink/uninstall_dblink.sql
===
RCS file: /cvsroot/pgsql/contrib/dblink/uninstall_dblink.sql,v
retrieving revision 1.5
diff -c -c -r1.5 uninstall_dblink.sql
*** contrib/dblink/uninstall_dblink.sql	13 Nov 2007 04:24:27 -	1.5
--- contrib/dblink/uninstall_dblink.sql	4 Apr 2008 16:45:36 -
***
*** 3,10 
  -- Adjust this setting to control where the objects get dropped.
  SET search_path = public;
  
- DROP FUNCTION dblink_current_query ();
- 
  DROP FUNCTION dblink_build_sql_update (text, int2vector, int4, _text, _text);
  
  DROP FUNCTION dblink_build_sql_delete (text, int2vector, int4, _text);
--- 3,8 
Index: contrib/dblink/expected/dblink.out

Re: [PATCHES] Implemented current_query

2007-05-16 Thread Bruce Momjian

This has been saved for the 8.4 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---

 Tomas Doran wrote:
 
 On 10 May 2007, at 03:09, Alvaro Herrera wrote:
  FWIW I think you should still provide dblink_current_query, even if  
  it's
  only a wrapper over current_query(), for backwards compatibility.
 
 Good point. Done as suggested (I think, or did you mean also the  
 change of instances to use current_query()?). Replaced  
 dblink_current_query with an SQL procedure wrapper, I assume that's  
 the most efficient way of doing it?
 
  Also, typically we don't remove items from the TODO list.  We mark  
  them
  as done prepending them with a dash.  Patch authors are not expected
  to do it either (though I don't see it be a problem if they did).
 
 Not quite sure what you're suggesting (which way round), so I just  
 didn't do it (as you said I'm not expected to).
 
  Doesn't matter ... just make sure duplicate_oids doesn't report a
  problem.  unused_oids is useful to find, err, unused OIDs.
 
 Ahh, hadn't found those, thanks. They're in the dev FAQ too, *blush*.  
 I need this for something I'm doing at $ork, and thought I'd  
 implement it in the backend, as well as a .so, it's been a learning  
 experience :)
 
  * AFAIK debug_query_string() still does the wrong thing when the  
  user
 
  Should that be added to the TODO list?
 
  Probably ...
 
 Done!
 
 Cheers
 Tom
 

[ Attachment, skipping... ]

 
 ---(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

-- 
  Bruce Momjian  [EMAIL PROTECTED]  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
 

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [PATCHES] Implemented current_query

2007-05-11 Thread Tomas Doran


On 10 May 2007, at 03:09, Alvaro Herrera wrote:
FWIW I think you should still provide dblink_current_query, even if  
it's

only a wrapper over current_query(), for backwards compatibility.


Good point. Done as suggested (I think, or did you mean also the  
change of instances to use current_query()?). Replaced  
dblink_current_query with an SQL procedure wrapper, I assume that's  
the most efficient way of doing it?


Also, typically we don't remove items from the TODO list.  We mark  
them

as done prepending them with a dash.  Patch authors are not expected
to do it either (though I don't see it be a problem if they did).


Not quite sure what you're suggesting (which way round), so I just  
didn't do it (as you said I'm not expected to).



Doesn't matter ... just make sure duplicate_oids doesn't report a
problem.  unused_oids is useful to find, err, unused OIDs.


Ahh, hadn't found those, thanks. They're in the dev FAQ too, *blush*.  
I need this for something I'm doing at $ork, and thought I'd  
implement it in the backend, as well as a .so, it's been a learning  
experience :)


* AFAIK debug_query_string() still does the wrong thing when the  
user


Should that be added to the TODO list?


Probably ...


Done!

Cheers
Tom



pgsql-current_query.patch
Description: Binary data

---(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


Re: [PATCHES] Implemented current_query

2007-05-09 Thread Tomas Doran


On 7 May 2007, at 23:25, Neil Conway wrote:


On Mon, 2007-07-05 at 19:48 +0100, Tomas Doran wrote:

As suggested in the TODO list (and as I need the functionality
myself), I have implemented the current_query interface to
debug_query_string.


* docs need a bit more detail (they should emphasize that it is the


Detail added. I'm none too happy with the phrasing, anyone suggest  
better?



* use textin() to convert C-style strings to text, rather than
constructing a text datum by hand


Done.


* perhaps we can get away with marking current_query() stable?


Also done, note OID has changed as I was having conflicts (template1  
wouldn't build). Should I either pick something else unused which is  
lower (is there anything?), move current_query to the end of the file  
or just leave it be..



* AFAIK debug_query_string() still does the wrong thing when the user
submits multiple queries in a single protocol message (separated by
semi-colons). Not sure there's a way to fix that that is both easy and
efficient, though...


Should that be added to the TODO list?

Cheers
Tom



pgsql-current_query_2.patch
Description: Binary data

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [PATCHES] Implemented current_query

2007-05-09 Thread Alvaro Herrera
Tomas Doran wrote:
 
 On 7 May 2007, at 23:25, Neil Conway wrote:
 
 On Mon, 2007-07-05 at 19:48 +0100, Tomas Doran wrote:
 As suggested in the TODO list (and as I need the functionality
 myself), I have implemented the current_query interface to
 debug_query_string.

FWIW I think you should still provide dblink_current_query, even if it's
only a wrapper over current_query(), for backwards compatibility.

Also, typically we don't remove items from the TODO list.  We mark them
as done prepending them with a dash.  Patch authors are not expected
to do it either (though I don't see it be a problem if they did).


 Also done, note OID has changed as I was having conflicts (template1  
 wouldn't build). Should I either pick something else unused which is  
 lower (is there anything?), move current_query to the end of the file  
 or just leave it be..

Doesn't matter ... just make sure duplicate_oids doesn't report a
problem.  unused_oids is useful to find, err, unused OIDs.

 * AFAIK debug_query_string() still does the wrong thing when the user
 submits multiple queries in a single protocol message (separated by
 semi-colons). Not sure there's a way to fix that that is both easy and
 efficient, though...
 
 Should that be added to the TODO list?

Probably ...

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


[PATCHES] Implemented current_query

2007-05-07 Thread Tomas Doran
As suggested in the TODO list (and as I need the functionality  
myself), I have implemented the current_query interface to  
debug_query_string.


I'm not sure the best place to put this, suggestions welcome..

Please review the patch attached.

Cheers
Tom



pgsql-current_query.patch
Description: Binary data

---(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


Re: [PATCHES] Implemented current_query

2007-05-07 Thread Neil Conway
On Mon, 2007-07-05 at 19:48 +0100, Tomas Doran wrote:
 As suggested in the TODO list (and as I need the functionality  
 myself), I have implemented the current_query interface to  
 debug_query_string.

Comments:

* docs need a bit more detail (they should emphasize that it is the
current query string submitted by the client, as opposed to the
currently executing SPI command or the like). Also, the docs currently
claim current_query() returns name.

* use textin() to convert C-style strings to text, rather than
constructing a text datum by hand

* perhaps we can get away with marking current_query() stable?

* AFAIK debug_query_string() still does the wrong thing when the user
submits multiple queries in a single protocol message (separated by
semi-colons). Not sure there's a way to fix that that is both easy and
efficient, though...

-Neil



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq