Re: [HACKERS] What do you want me to do?
http://www.atlassian.com/software/jira/pricing.jsp I have no particular opinion on whether to use a free or non-free system to track bugs, but I'd like to recommend RT as being a very capable and useful program. It has been used to track Perl 5 and CPAN bugs for some time now, and it happens to be free (and it can use PostgreSQL :). http://www.bestpractical.com/rt/ -- ams ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Double linked list with one pointer
At 2003-12-07 18:19:26 +0100, [EMAIL PROTECTED] wrote: There is a new type in C99 for integer that can hold a pointer value. I think it's called intptr_t resp. uintptr_t, but I don't have the standard around. Yes, they're called intptr_t and uintptr_t (§7.18.1.4), but they're both optional types. I note in passing that the xor-trick is one of the pointer-hiding tricks that are the bane of garbage collectors for C (the other common example being writing a pointer to a file and reading it back). -- ams ---(end of broadcast)--- TIP 3: 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] specifying multiple result format codes with libpq
The documentation for PQexecPrepared says:
(There is not currently a provision to obtain different result
columns in different formats, although that is possible in the
underlying protocol.)
Would anyone be interested in a patch to allow this?
I could, for example, change PQsendQueryGuts to do something like:
static int PQsendQueryGuts( PGconn *conn,
const char *command,
const char *stmtName,
int nParams,
const Oid *paramTypes,
const char *const *paramValues,
const int *paramLengths,
const int *paramFormats,
int resultFormat,
... ) /* Add this last argument. */
{
...
if ( resultFormat == -1 ) { /* or == nParams, perhaps? */
va_list args;
const int *resultFormats;
va_start( args, resultFormat );
resultFormats = va_arg( args, const int * );
va_end( args );
if ( pqPutInt( nParams, 2, conn ) 0 )
goto sendFailed;
for ( i = 0; i nParams; i++ )
if ( pqPutInt( resultFormats[i], 2, conn ) 0 )
goto sendFailed;
}
/* This is what libpq does already. */
else if ( pqPutInt( 1, 2, conn ) 0 ||
pqPutInt( resultFormat, 2, conn ) )
goto sendFailed;
...
}
And then teach the other API functions (PQexecParams, PQsendQueryParams,
PQsendQueryPrepared) to accept and pass on the extra ... argument. That
wouldn't break existing code, and new users could set resultFormat to
invoke the new behaviour. It seems a bit ugly, but on the other hand,
it doesn't seem worthwhile to add a new interface for this behaviour.
Thoughts?
-- ams
---(end of broadcast)---
TIP 3: 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: [HACKERS] specifying multiple result format codes with libpq
At 2004-06-18 13:11:19 -0400, [EMAIL PROTECTED] wrote: Would anyone be interested in a patch to allow this? Yes, but not the way you suggest. The ... approach forces calling code to know *when it is written* how many result columns there will be, because you'd have to actually write that number of parameters in the call. I suspect I didn't explain my proposal sufficiently well. The signature of, say, PQexecParams does get ... added on to it, but new callers pass in only a count and an array, not one argument per expected result. That way, existing callers would continue to compile without any changes, and new code tells the function to look for the extra arguments by specifying a currently-invalid value for the resultFormat parameter. That said, however: No one's gotten around to thinking about a more general redesign of libpq's query API yet, but I'd rather see us do that than put more warts on the functions we have ... I am in complete agreement with that sentiment. -- ams ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] placeholder syntax
PostgreSQL currently uses $1/$2 for placeholders in prepared statements. I'm writing something that may potentially submit queries to both Oracle and Postgres, and it seems Oracle doesn't accept this syntax. Someone on IRC said I could use ? for both Oracle and Postgres. It isn't entirely clear to me if Oracle accepts it, but Postgres doesn't seem to. My copy of the SQL92 standard says: «In SQL-statements that are executed dynamically, the parameters are called dynamic parameters (dynamic parameter specifications) and are represented in SQL language by a question mark (?).» (There's also an embedded variable name production in the standard, which looks like the :foo syntax that Oracle also accepts, but I'm not sure it applies to placeholders. The standard is a bit hard to read.) Should Postgres accept ? as a placeholder? (If so, I'll dig around and try to figure out how to make it do so.) -- ams ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] compile errors in new PL/Pler
At 2004-07-02 08:55:56 -0400, [EMAIL PROTECTED] wrote: In the meantime, does this solve your problem?: #ifndef eval_pv #define eval_pv perl_eval_pv #endif The right way to do this is to #include ppport.h from Devel::PPPort. -- ams ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] PREPARE and transactions
At 2004-06-24 13:13:42 -0400, [EMAIL PROTECTED] wrote: This is why I proposed originally to keep the non-transactional behavior for Parse messages, but transactional for SQL PREPARE. The latter can be said to be inside the transaction and should behave like so. I think this lowers the surprise factor. It seems like we are closing in on an agreement that that is what should happen. As a client maintainer, I have no particular problem with the status quo (apparently like Greg and Cyril), but I can appreciate the point made in Jeroen's initial post in this thread, and I would not object to changing PREPARE to be transactional while leaving Parse messages alone. Nor do I have a problem with PREPARE OR REPLACE. But for what it's worth, I strongly dislike the later proposal of making prepared statements anonymous, and pattern matching the statement text, especially if they reintroduce the need to quote query parameters. Ugh. -- ams ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PREPARE and transactions
At 2004-07-03 08:20:17 +0530, [EMAIL PROTECTED] wrote: I would not object to changing PREPARE to be transactional while leaving Parse messages alone. That is to say, it wouldn't cause any problems for me. But since it does seem to be a nuisance for Oliver and Merlin (among others), I agree with Greg that I don't see much of a need to change anything. -- ams ---(end of broadcast)--- TIP 3: 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: [HACKERS] libpq and prepared statements progress for 8.0
At 2004-09-17 14:28:36 -0700, [EMAIL PROTECTED] wrote:
Assuming that anyone steps up and does the work, that is.
So...any volunteers?
OK, how about adding a PQprepare (PQcreatePrepared?) function like this?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
const char *query,
int nParams,
const Oid *paramTypes)
{
...
PQprepare would construct a Parse message to create a prepared statement
named stmtName from the given query, with nParams types pre-declared. It
could be called by DBD::Pg with nParams == 0 to let the server infer all
of the parameter types.
I suppose an asynchronous equivalent would also be needed.
(Yes, I'm volunteering to write both functions.)
-- ams
---(end of broadcast)---
TIP 3: 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: [HACKERS] libpq and prepared statements progress for 8.0
At 2004-09-20 01:25:56 -0400, [EMAIL PROTECTED] wrote: That means you also need to add a new Execute method that takes a portalName instead of a command. Yes, thanks. How about these functions, then? PGresult * PQprepare(PGconn *conn, const char *stmtName, const char *query, int nParams, const Oid *paramTypes); PGresult * PQbind(PGconn *conn, const char *stmtName, const char *portalName, int nParams, const char *const *paramValues, const int *paramLengths, int nFormats, const int *paramFormats, int nResults, const int *resultFormats); PGresult * PQexecute(PGconn *conn, const char *portalName, int nRows); -- ams ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] libpq and prepared statements progress for 8.0
(I apologise in advance if anyone receives multiple copies of this post. I posted from the wrong address earlier.) At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote: I assumed we would want a separate Bind and execute call. Do we? Yes, we do. (See below.) Personally I find it annoying that you can't call describe on a statement, only a portal, but that's the way it is now. No, it isn't. Describe accepts both prepared statement and portal names. In the former case, it returns ParameterDescription message as well as the RowDescriptions it returns for the latter. resultFormat is just a single integer in the protocol. You don't get to specify different formats for different columns. Yes, you do. Bind accepts 0 (use the default text format), 1 (use this format for all results), or as many result format specifiers as there are results. What's nRows? None of the existing PQexec* take an nRows parameter. Execute can be told to return no more than n rows of results. If there are more rows available, the server returns PortalSuspended and awaits another Execute message. The default of 0 imposes no limit. Because it's sometimes required to call Execute without Binding values again, libpq needs separate bind/execute functions to support this. Please read protocol-flow.html and protocol-message-formats.html. -- ams ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] libpq and prepared statements progress for 8.0
At 2004-09-20 10:20:03 -0400, [EMAIL PROTECTED] wrote: What you should be concerned with right now is providing an API for Parse + Describe Statement, to substitute for the existing approach of setting up statement objects via PQexec(PREPARE foo ...). Fair enough. That's why my original proposal was to add only a PQprepare function, which should be a patch small enough to write, test, and maybe apply before 8.0: PGresult * PQprepare(PGconn *conn, const char *stmtName, const char *query, int nParams, const Oid *paramTypes); Should I go ahead and do that? -- ams ---(end of broadcast)--- TIP 3: 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: [HACKERS] libpq and prepared statements progress for 8.0
At 2004-09-20 11:02:50 -0400, [EMAIL PROTECTED] wrote: (1) What about preparing an unnamed statement ... stmtName == will work. (2) What about discovering the actually resolved parameter types? I'm not sure what to do about that. I could extend PGresult to hold ParameterDescription information, then provide accessor functions à la PQnfields/PQfformat. But that would be a fairly intrusive change. And I shudder to even think about trying to reuse the existing PGresult fields/accessors to do the job. Do you have any suggestions? -- ams ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] libpq and prepared statements progress for 8.0
At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote: Personally I find it annoying that you can't call describe on a statement, only a portal, but that's the way it is now. No, it isn't. Describe accepts both prepared statement and portal names. In the former case, it returns ParameterDescription message as well as the RowDescriptions it returns for the latter. resultFormat is just a single integer in the protocol. You don't get to specify different formats for different columns. Yes, you do. Bind accepts 0 (use the default text format), 1 (use this format for all results), or as many result format specifiers as there are results. What's nRows? None of the existing PQexec* take an nRows parameter. Execute can be told to return no more than n rows of results. If there are more rows available, the server returns PortalSuspended and awaits another Execute message. The default of 0 imposes no limit. Please read protocol-flow.html and protocol-message-formats.html. -- ams ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] libpq and prepared statements progress for 8.0
(I apologise for the delayed response.) At 2004-10-07 01:23:56 -0400, [EMAIL PROTECTED] wrote: So why is this part of the patch ok? Isn't it going to make libpq get confused every time a PQExecPrepared sends a v3.0 prepare message? I thought about that for a while, but I couldn't find anything that is actually broken or confused by the patch. I could be missing something obvious, though, so I'd appreciate another set of eyes looking at it. Does anyone have any ideas? -- ams ---(end of broadcast)--- TIP 3: 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: [HACKERS] Nearing final release?
At 2004-10-16 18:41:05 -0400, [EMAIL PROTECTED] wrote:
I think the cleanest solution is probably to add a state flag indicating
whether ParseComplete should generate a PGresult or not.
Like the appended (incremental) patch?
(I didn't think this would work, because I thought libpq would allow you
to send multiple queries before trying to read results. But you said it
didn't support that, so...)
-- ams
--- libpq-int.h.1~ 2004-10-18 17:42:13.175759981 +0530
+++ libpq-int.h 2004-10-18 17:43:40.105986570 +0530
@@ -269,6 +269,8 @@
* nonblock sending
semantics */
boolext_query; /* was our last query sent with
extended
* query protocol? */
+ boolsent_prepare; /* was our last Parse message sent with
+* PQprepare? */
charcopy_is_binary; /* 1 = copy binary, 0 = copy text */
int copy_already_done; /* # bytes already
returned in
*
COPY OUT */
--- fe-exec.c.2~2004-10-18 17:47:55.540189274 +0530
+++ fe-exec.c 2004-10-18 17:48:30.119038902 +0530
@@ -686,6 +686,7 @@
goto sendFailed;
conn-ext_query = true;
+ conn-sent_prepare = true;
if (pqFlush(conn) 0)
goto sendFailed;
conn-asyncStatus = PGASYNC_BUSY;
--- fe-protocol3.c.2~ 2004-10-18 17:44:06.616198123 +0530
+++ fe-protocol3.c 2004-10-18 17:46:34.431656569 +0530
@@ -220,10 +220,13 @@
conn-asyncStatus = PGASYNC_READY;
break;
case '1': /* Parse Complete */
- if (conn-result == NULL)
- conn-result =
PQmakeEmptyPGresult(conn,
-
PGRES_COMMAND_OK);
- conn-asyncStatus = PGASYNC_READY;
+ if (conn-sent_prepare) {
+ if (!conn-result)
+ conn-result =
PQmakeEmptyPGresult(conn,
+
PGRES_COMMAND_OK);
+ conn-asyncStatus = PGASYNC_READY;
+ conn-sent_prepare = false;
+ }
break;
case '2': /* Bind Complete */
case '3': /* Close Complete */
--- libpq-fe.h.2~ 2004-10-18 17:55:40.632064120 +0530
+++ libpq-fe.h 2004-10-18 17:56:26.501634328 +0530
@@ -312,9 +312,9 @@
int resultFormat);
/* Interface for multiple-result or asynchronous queries */
-extern PGresult *PQsendPrepare(PGconn *conn, const char *stmtName,
- const char *query, int
nParams,
- const Oid *paramTypes);
+extern int PQsendPrepare(PGconn *conn, const char *stmtName,
+const char *query, int nParams,
+const Oid *paramTypes);
extern int PQsendQuery(PGconn *conn, const char *query);
extern int PQsendQueryParams(PGconn *conn,
const char *command,
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] libpq and prepared statements progress for 8.0
At 2004-10-05 17:48:27 -0400, [EMAIL PROTECTED] wrote: Searching for all references to one of the existing entry points such as PQexecPrepared will probably help you identify what you need to do. OK. I've attached two additional patches below. I don't really understand how the *.def files work, so I'm just guessing about what needs to be changed. Thanks to Josh Berkus and Kris Jurka for looking over the documentation patch, which just adds descriptions of the two new functions. I apologise in advance if I've missed anything. -- ams --- libpqdll.def.1~ 2004-10-06 03:34:38.727908153 +0530 +++ libpqdll.def2004-10-06 03:33:55.053473771 +0530 @@ -115,3 +115,5 @@ PQsendQueryPrepared @ 111 PQdsplen@ 112 PQserverVersion @ 113 +PQsendPrepare @ 114 +PQprepare @ 115 --- libpqddll.def.1~2004-10-06 03:34:58.573470328 +0530 +++ libpqddll.def 2004-10-06 03:35:12.184112562 +0530 @@ -115,3 +115,5 @@ PQsendQueryPrepared @ 111 PQdsplen@ 112 PQserverVersion @ 113 +PQsendPrepare @ 114 +PQprepare @ 115 --- blibpqdll.def.1~2004-10-06 03:31:57.372858897 +0530 +++ blibpqdll.def 2004-10-06 03:32:50.903586158 +0530 @@ -115,6 +115,8 @@ _PQsendQueryPrepared @ 111 _PQdsplen@ 112 _PQserverVersion @ 113 +_PQsendPrepare @ 114 +_PQprepare @ 115 ; Aliases for MS compatible names PQconnectdb = _PQconnectdb @@ -230,3 +232,5 @@ PQsendQueryPrepared = _PQsendQueryPrepared PQdsplen= _PQdsplen PQserverVersion = _PQserverVersion +PQsendPrepare = _PQsendPrepare +PQprepare = _PQprepare *** libpq.sgml.1~ 2004-10-06 03:30:42.803775731 +0530 --- libpq.sgml 2004-10-06 05:24:22.934466263 +0530 *** *** 1183,1194 /varlistentry /variablelist ! Presently, prepared statements for use with functionPQexecPrepared/ ! must be set up by executing an SQL commandPREPARE/ command, ! which is typically sent with functionPQexec/ (though any of ! applicationlibpq/'s query-submission functions may be used). ! A lower-level interface for preparing statements may be offered in a ! future release. /para para --- 1183,1238 /varlistentry /variablelist ! Prepared statements for use with functionPQexecPrepared/ can be ! created by executing an SQL commandPREPARE/ statement (which is ! sent with functionPQexec/, or one of the other query-submission ! functions), or with functionPQprepare/. The latter does not ! require parameter types to be pre-specified. ! /para ! ! para ! variablelist ! varlistentry ! termfunctionPQprepare/functionindextermprimaryPQprepare///term ! listitem ! para ! Submits a request to create a prepared statement with the ! given parameters, and waits for completion. ! synopsis ! PGresult *PQprepare(PGconn *conn, ! const char *stmtName, ! const char *query, ! int nParams, ! const Oid *paramTypes); ! /synopsis ! /para ! ! para ! functionPQprepare/ creates a prepared statement for execution with ! functionPQexecPrepared/. Unlike commandPREPARE/, it allows the ! client to prepare a statement without pre-specifying the types of each ! parameter. This function is supported only in protocol 3.0 and later ! connections; it will fail when using protocol 2.0. ! /para ! ! para ! The function creates a prepared statement named parameterstmtName/ ! (which may be literal/, to refer to the unnamed statement) from ! the parameterquery/. If any parameters are used, they are referred ! to in the query as literal$1/, literal$2/, etc. ! ! parameternParams/ is the number of parameters for which types are ! pre-specified in the array parameterparamTypes[]/. It may be zero, ! or up to the number of parameters used in the query. Each entry in the ! parameterparamTypes[]/ array should contain the OID of the type of ! the corresponding parameter. If parameternParams/ is 0, the server ! assigns a data type to each parameter, as it would for untyped literal ! strings. Likewise, if any element in the type array is zero, its type ! is inferred. ! /para ! /listitem ! /varlistentry ! /variablelist /para para *** *** 2353,2358 --- 2397,2423 /varlistentry varlistentry + termfunctionPQsendPrepare/indextermprimaryPQsendPrepare///term + listitem + para + Sends a request to create a prepared statement with the given + parameters, without waiting for completion. + synopsis + int PQsendPrepare(PGconn *conn, + const char *stmtName, + const char *query, + int nParams, + const Oid *paramTypes); + /synopsis + + This is an asynchronous version of
Re: [HACKERS] libpq and prepared statements progress for 8.0
;
case '1': /* Parse Complete */
+ if (conn-result == NULL)
+ conn-result =
PQmakeEmptyPGresult(conn,
+
PGRES_COMMAND_OK);
+ conn-asyncStatus = PGASYNC_READY;
+ break;
case '2': /* Bind Complete */
case '3': /* Close Complete */
/* Nothing to do for these message types */
/*
* Test program for PQprepare/PQdescribe.
* Abhijit Menon-Sen [EMAIL PROTECTED]
*
* create table pqtest (a int, b text, c text);
* insert into pqtest (a,b,c) values (1,'foo','bar');
* insert into pqtest (a,b,c) values (1,'foo','baz');
* insert into pqtest (a,b,c) values (2,'foo','barf');
*/
#include stdio.h
#include stdlib.h
#include string.h
#include libpq-fe.h
int main(int argc, char *argv[])
{
int i, a, b, c;
PGconn *conn;
PGresult *res;
char *query = select * from pqtest where a=$1 and b=$2;
const char *values[2];
conn = PQconnectdb();
if (PQstatus(conn) != CONNECTION_OK) {
fprintf(stderr, Couldn't connect to the database: %s,
PQerrorMessage(conn));
PQfinish(conn);
exit(-1);
}
res = PQprepare(conn, prep, query, 0, NULL);
if (PQresultStatus(res) != PGRES_COMMAND_OK) {
fprintf(stderr, PREPARE failed: %s, PQerrorMessage(conn));
PQclear(res);
PQfinish(conn);
exit(-1);
}
PQclear(res);
values[0] = 1;
values[1] = foo;
res = PQexecPrepared(conn, prep, 2, values, NULL, NULL, 0);
if (PQresultStatus(res) != PGRES_TUPLES_OK) {
fprintf(stderr, EXECUTE failed: %s, PQerrorMessage(conn));
PQclear(res);
PQfinish(conn);
exit(-1);
}
a = PQfnumber(res, a);
b = PQfnumber(res, b);
c = PQfnumber(res, c);
printf(Results:\n);
for(i = 0; i PQntuples(res); i++) {
char *av = PQgetvalue(res, i, a);
char *bv = PQgetvalue(res, i, b);
char *cv = PQgetvalue(res, i, c);
printf( (a=%s)(b=%s)(c=%s)\n, av, bv, cv);
}
printf(%d rows\n, i);
PQclear(res);
PQfinish(conn);
return 0;
}
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] #ifdef NOT_USED
(Sorry for the delayed response. I just got home from Germany after my visit to Linuxtag, and I'm catching up with my -hackers email now.) At 2005-06-25 09:30:17 -0400, pgman@candle.pha.pa.us wrote: Hi, i have found several #ifdef NOT_USED marked code... We keep such blocks of code around in case we might need to use it some day. I think that's a bad idea. Unused code should be removed with a suitable CVS checkin comment (and perhaps a comment where the code was), not left to clutter live code. That's what version control is for. -- ams ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Occupied port warning
At 2005-06-28 15:14:29 +0200, [EMAIL PROTECTED] wrote: I recall that it had something to do with IPv6, but I'm not sure. Under Linux, if you bind to AF_INET6/::0, a subsequent bind to AF_INET/0 will fail, but the IPv4 address is also bound by the first call, and the program will accept IPv4 connections anyway (BSD behaves differently). Maybe that had something to do with it? I remember I had to add code to my program to allow that second bind to fail without complaint, and now my code also exits only if it can't bind anything at all. (For what it's worth, I don't think this behaviour is such a big deal.) -- ams ---(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: [HACKERS] prepared queries in plperl
At 2005-07-15 17:17:01 +0200, [EMAIL PROTECTED] wrote: I needed prepared queries in plperl, but there's none, so I baked a patch that defines two extra perl functions, spi_prepare and spi_exec_prepared Oh. I've been working on the same functionality this week following a conversation with Nicolai Petri (Cc:ed). It's rather unfortunate that neither of us discussed our plans on the list beforehand. I would like to ask if someone could review it, so I could reshape it into something more appropriate for including into -devel. All right. I'll look over it soon. -- ams ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PostgreSQL overall design
At 2005-09-27 15:20:05 +0530, [EMAIL PROTECTED] wrote: Can anyone please tell/point me where I can get the postgresql system layout (I've an interest to contribute). http://www.postgresql.org/developer/coding And, in particular: http://www.postgresql.org/docs/faqs.FAQ_DEV.html -- ams ---(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] postgres protocol dissector plugin for ethereal
This weekend, I decided to teach Ethereal to decode the FE/BE protocol properly: until now, it could only extract likely-looking strings from the conversation, which I found woefully inadequate for debugging. I'm hoping the result will be useful to other people too: http://www.oryx.com/ams/packet-pgsql.c Copy it to epan/dissectors/ within an Ethereal source tree, and change the reference to packet-postgresql.c in Makefile.common to -pgsql.c, then configure and build. (Thanks to Kris Jurka for some testing. I've asked the Ethereal people if they want to distribute this with Ethereal.) Questions, comments, and suggestions are welcome. -- ams ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] postgres protocol dissector plugin for ethereal
At 2004-12-19 17:56:00 +0530, [EMAIL PROTECTED] wrote: I've asked the Ethereal people if they want to distribute this with Ethereal. It's in Ethereal CVS now. -- ams ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Copyright update
At 2004-12-31 23:49:35 -0500, pgman@candle.pha.pa.us wrote: With 8.0 coming out in 2005, I think I should update the copyrights on the files. I don't think it actually makes any difference. -- ams ---(end of broadcast)--- TIP 3: 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: [HACKERS] Allow GRANT/REVOKE permissions to be applied to all
At 2005-02-01 11:02:52 +0100, [EMAIL PROTECTED] wrote: We really should reimplement our query language in Scheme and implement SQL on top of that. It will make many things much easier. :-) Speaking of which, see http://schematics.sourceforge.net -- ams ---(end of broadcast)--- TIP 3: 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: [HACKERS] Allow GRANT/REVOKE permissions to be applied to all
At 2005-02-01 16:31:32 +0530, [EMAIL PROTECTED] wrote: Speaking of which, see http://schematics.sourceforge.net Actually, http://schematics.sourceforge.net/schemeql.html -- ams ---(end of broadcast)--- TIP 3: 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: [HACKERS] Patent issues and 8.1
At 2005-02-07 12:28:34 -0500, [EMAIL PROTECTED] wrote: There was some mention of an upgrade tool which would avoid the need for a dump/restore - did that idea die? No, but I don't see anyone volunteering to work on it now I like the idea of having a working pg_upgrade (independent of the ARC patent issue), so I don't mind working on it. I'll have a look at the code sometime this week. -- ams ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] UTF8 or Unicode
At 2005-02-14 21:14:54 -0500, pgman@candle.pha.pa.us wrote: Should our multi-byte encoding be referred to as UTF8 or Unicode? The *encoding* should certainly be referred to as UTF-8. Unicode is a character set, not an encoding; Unicode characters may be encoded with UTF-8, among other things. (One might think of a charset as being a set of integers representing characters, and an encoding as specifying how those integers may be converted to bytes.) I know UTF8 is a type of unicode but do we need to rename anything from Unicode to UTF8? I don't know. I'll go through the documentation to see if I can find anything that needs changing. -- ams ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] postgres crashing on a seemingly good query
Summary: I can crash 7.4-CVS and 8.0/HEAD by sending what appears to be
a valid query.
I'm trying to insert a unique entry into this table:
create table bodyparts (
id serial primary key,
bytes integer not null,
lines integer not null,
hashtext not null,
textbytea,
databytea
);
insert into bodyparts (bytes,lines,hash,text,data)
select $1,$2,$3,$4,$5 where not exists
(select id from bodyparts where hash=$3)
($1 = 58, $2 = 3, $3 = 3dd93158c8775c62e7a546ae1abad1da,
$4 = Appended is one html file and one French lesson.\r\n\r\nArnt\r\n,
$5 is NULL)
I issue a Parse (leaving all the placeholder types unspecified), Bind,
Describe, Execute, and Sync sequence, and the backend segfaults during
the Execute (some whitespace munged to make lines shorter):
Program received signal SIGSEGV, Segmentation fault.
0x08075071 in ComputeDataSize (tupleDesc=0x83ed778, values=0x83edab8,
nulls=0x83edae4 n~\177\177) at heaptuple.c:55
55 data_length = att_addlength(data_length, att[i]-attlen, values[i]);
(gdb) info local
data_length = 0
i = 0
numberOfAttributes = 5
att = (Form_pg_attribute *) 0x83ed7a4
(gdb) p att[i]
$7 = 0x83ed7d0
(gdb) p *$7
$8 = {attrelid = 0, attname = {data = ?column?, '\0' repeats 55 times,
alignmentDummy = 1819239231}, atttypid = 705, attstattarget = -1,
attlen = -1, attnum = 1, attndims = 0, attcacheoff = -1,
atttypmod = -1, attbyval = 0 '\0', attstorage = 112 'p',
attalign = 105 'i', attnotnull = 0 '\0', atthasdef = 0 '\0',
attisdropped = 0 '\0', attislocal = 1 '\001', attinhcount = 0}
(gdb) p values[i]
$9 = 58
Here's a backtrace:
(gdb) bt
#0 0x08075071 in ComputeDataSize (tupleDesc=0x83ed778, values=0x83edab8,
nulls=0x83edae4 n~\177\177) at heaptuple.c:55
#1 0x08076414 in heap_formtuple (tupleDescriptor=0x83ed778, values=0x83edab8,
nulls=0x83edae4 n~\177\177) at heaptuple.c:622
#2 0x0814e343 in ExecTargetList (targetlist=0x83ed594, targettype=0x83ed778,
econtext=0x83ed4cc, values=0x83edab8, nulls=0x83edae4 n~\177\177,
itemIsDone=0x83edaf8, isDone=0xbfffdad4) at execQual.c:3676
#3 0x0814e3a1 in ExecProject (projInfo=0x83eda8c, isDone=0xbfffdad4)
at execQual.c:3714
#4 0x0815900b in ExecResult (node=0x83ed440) at nodeResult.c:155
#5 0x08147b9c in ExecProcNode (node=0x83ed440) at execProcnode.c:292
#6 0x0815d659 in SubqueryNext (node=0x83eb878) at nodeSubqueryscan.c:77
#7 0x0814e4d6 in ExecScan (node=0x83eb878, accessMtd=0x815d610
SubqueryNext)
at execScan.c:98
#8 0x0815d691 in ExecSubqueryScan (node=0x83eb878) at nodeSubqueryscan.c:102
#9 0x08147c0a in ExecProcNode (node=0x83eb878) at execProcnode.c:315
#10 0x081460f5 in ExecutePlan (estate=0x83eb284, planstate=0x83eb878,
operation=CMD_INSERT, numberTuples=0, direction=ForwardScanDirection,
dest=0x8326568) at execMain.c:1060
#11 0x08145245 in ExecutorRun (queryDesc=0x83eac44,
direction=ForwardScanDirection, count=0) at execMain.c:226
#12 0x081e41ed in ProcessQuery (parsetree=0x83df51c, plan=0x83fc408,
params=0x83eaa74, dest=0x8326568, completionTag=0xbfffde70 )
at pquery.c:173
#13 0x081e5287 in PortalRunMulti (portal=0x83f2a7c, dest=0x8326568,
altdest=0x8326568, completionTag=0xbfffde70 ) at pquery.c:1016
#14 0x081e4adf in PortalRun (portal=0x83f2a7c, count=2147483647,
dest=0x83dad20, altdest=0x83dad20, completionTag=0xbfffde70 )
at pquery.c:617
#15 0x081e1b86 in exec_execute_message (portal_name=0x83dac14 ,
max_rows=2147483647) at postgres.c:1673
#16 0x081e374d in PostgresMain (argc=4, argv=0x836f7d4,
username=0x836f7a4 oryx) at postgres.c:3056
#17 0x081ad777 in BackendRun (port=0x837ef80) at postmaster.c:2816
#18 0x081acdc5 in BackendStartup (port=0x837ef80) at postmaster.c:2452
#19 0x081aaf9a in ServerLoop () at postmaster.c:1199
#20 0x081aa8b3 in PostmasterMain (argc=3, argv=0x836dd98) at postmaster.c:918
#21 0x0816b0e6 in main (argc=3, argv=0x836dd98) at main.c:268
I couldn't reproduce this with SQL PREPARE/EXECUTE statements in psql,
so I conjectured that it may have something to do with the parameter
types being unspecified. I added a statement-describe message between
the parse and the bind, however, and the server had correctly inferred
all of the types (23/23/25/17/17, i.e. INT4/INT4/TEXT/BYTEA/BYTEA).
I have a tcpdump capture of the transaction, which is available at
http://wiw.org/~ams/crash.tcpdump
The most convenient way to view that is to use Ethereal 0.10.9 or later,
since it includes the dissector that I wrote. Unfortunately, between the
time I contributed the code and the 0.10.9 release, someone introduced a
couple of bugs. In the presence of NULL parameter values, Ethereal may
wrongly report some Bind/Data-row messages as being malformed. :-(
You may
Re: [HACKERS] postgres crashing on a seemingly good query
At 2005-02-19 21:38:56 +0530, [EMAIL PROTECTED] wrote: Summary: I can crash 7.4-CVS and 8.0/HEAD by sending what appears to be a valid query. A couple of things I forgot to mention: 1. I turned the logging all the way up and I've uploaded the messages from the crashing backend to http://wiw.org/~ams/crash.log (Only the messages logged after it received the last query.) 2. It isn't obviously something my application is doing wrong, since the insert into ... select where not exists (...) style of query does work for me in other places (albeit simpler queries). Furthermore, if I change the query to a simple insert into bodyparts ..., it works fine, so it's not bogus parameter data or anything that's causing the problem. (Of course, the server probably shouldn't crash even if it were.) -- ams ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] postgres crashing on a seemingly good query
At 2005-02-19 21:38:56 +0530, [EMAIL PROTECTED] wrote: I couldn't reproduce this with SQL PREPARE/EXECUTE statements in psql, so I conjectured that it may have something to do with the parameter types being unspecified. I added a statement-describe message between the parse and the bind, however, and the server had correctly inferred all of the types (23/23/25/17/17, i.e. INT4/INT4/TEXT/BYTEA/BYTEA). Another data point: If I change my code (by means of an unspeakably vile hack, but never mind that) to specify each parameter types in the parse message, the server no longer crashes. Any ideas? -- ams ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] postgres crashing on a seemingly good query
At 2005-02-19 23:18:01 +0530, [EMAIL PROTECTED] wrote: If I change my code (by means of an unspeakably vile hack, but never mind that) to specify each parameter types in the parse message, the server no longer crashes. In fact, it works if I specify only the two integer types, and leave the three varlenas unspecified. -- ams ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] signed short fd
At 2005-03-14 16:25:22 -0500, [EMAIL PROTECTED] wrote: The file descriptor returned by open is the lowest numbered unused descriptor. [...] What is meant by unused? Perhaps you should actually look at the standard. The open( ) function shall return a file descriptor for the named file that is the lowest file descriptor not currently open for that process. The close( ) function shall deallocate the file descriptor indicated by fildes. To deallocate means to make the file descriptor available for return by subsequent calls to open( ) or other functions that allocate file descriptors. Is it read to mean that a higher number file is *never* returned if there is a lower number that has been used and is now available? Yes. -- ams ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] PHP stuff
[EMAIL PROTECTED] wrote: As the copyright owner, The PostgreSQL Global Development Group, has the right to license the documentation any way they see fit. The PGDG has never asked for copyright assignments from contributors (as I gather the PHP folks do), so the copyright to Postgres is collectively owned by everyone who has contributed to it, and not by the PGDG itself (as Peter said). Relicensing would require the consent of all copyright holders. At least in the USA, any entity that can be identified can own and control copyright. So this is a moot point. Then, what you are saying, is that anyone could come along and create a paper trail calling themselves The PostgreSQL Global Devlopment Group, and claim ownership. And that simply isn't possible. -- ams ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] prepared statements don't log arguments?
At 2005-04-07 12:14:19 +1000, [EMAIL PROTECTED] wrote: % tail /usr/local/pgsql/postmaster.log LOG: statement: prepare foo(int, int) as select $1 + $2; LOG: statement: execute foo(5, 10); LOG: statement: execute foo(15, 20); If you send a v3 protocol execute message instead of an SQL EXECUTE statement, the parameters don't get logged. -- ams ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] linuxtag 2005
Are any PostgreSQL hackers planning to be at Linuxtag in Karlsruhe? -- ams ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] creating WITH HOLD cursors using SPI
Hi. I've been working on making it possible for PL/Perl users to fetch large result sets one row at a time (the current spi_exec_query interface just returns a big hash). The idea is to have spi_query call SPI_prepare/SPI_open_cursor, and have an spi_fetchrow that calls SPI_cursor_fetch. It works well enough, but I don't know how to reproduce spi_exec_query's error handling (it runs the SPI_execute in a subtransaction). To do something similar, I would have to create a WITH HOLD cursor in my spi_query function. But SPI_cursor_open provides no way to do this, and it calls PortalStart before I can set CURSOR_OPT_HOLD myself. Suggestions? -- ams ---(end of broadcast)--- TIP 3: 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: [HACKERS] creating WITH HOLD cursors using SPI
At 2005-06-12 14:54:47 +0530, [EMAIL PROTECTED] wrote: The idea is to have spi_query call SPI_prepare/SPI_open_cursor, and have an spi_fetchrow that calls SPI_cursor_fetch. It works well enough, but I don't know how to reproduce spi_exec_query's error handling (it runs the SPI_execute in a subtransaction). One possibility would be to make plperl_call_handler create the internal subtransaction, so that all of the perl code runs inside it. But I'm not sure if that would actually work, especially if one of the SPI functions failed. But I can't think of what else to do, either. Thoughts? -- ams ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] passing constant parameters to functional indices
I'd like to add support for specifying constant parameters when creating a functional index, e.g. create index foo on bar (substr(baz, 1, 32)); Is this a good idea? If so, I'd like to ask for some suggestions before I proceed any further towards implementing it. The arguments to the index function are represented as T_Strings. I need to add some way to distinguish between field names and string constants. I could create A_Const nodes for numeric or string constants, and leave column names as T_Strings; alternatively, I could add a T_Name type and use it to store column names. Which is preferable? What's the best way to pass the parameters on to FormIndexDatum()? Any other suggestions will be appreciated, since this is my first foray into the PostgreSQL source (but it's been pleasant reading so far :). -- ams PS: Are mbox archives of the list available somewhere? I tried to look for related threads in the web archive, but I quickly tired of the Try to produce less restrictive search query. (sic) message. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Ding-dong, contrib is dead ...
At 2006-09-05 10:23:19 -0400, [EMAIL PROTECTED] wrote: Something like it ought to go into core, but personally I'd opt for taking the opportunity to redesign the API, which was a bit crufty to begin with. I'm happy to do the work right away (not that there's much) if someone suggests a better API. (I don't personally have a need for user-level locks, and if I did, I'd be happy with just user_lock/user_unlock. So if anyone has a more specific idea, I'm all ears.) That would eliminate all question of whether the clean room was clean enough. It was really, really clean! Honest! :-) -- ams ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Ding-dong, contrib is dead ...
At 2006-09-05 16:35:49 -0400, [EMAIL PROTECTED] wrote: The biggest part of the work needed is to write the documentation --- but we'd have to do that for Abhijit's patch too, since the userlocks docs presumably fall under GPL along with the code. I'll write the documentation, either for the code as it is, or for any replacement we decide to use. I didn't submit documentation (or a Makefile, uninstall_otherlock.sql, etc.) only because I didn't know if anything was going to be done with otherlock now. I just wanted to mention the existence of the code. So basically I don't see the point of investing effort in a bug-compatible version of userlocks, when we can have something cleaner and suitable for the long run with not very much more effort. Fine with me. Two questions: - Where would the code live, if it were in core? - Shall I hack up the API you suggested in your earlier message? -- ams ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Problems with extended-Query logging code
At 2006-09-06 18:01:38 -0400, [EMAIL PROTECTED] wrote: That is, we'd log a Parse or Bind operation if it individually exceeded the duration threshold, and not otherwise. Ok. If we've got support for logging the statement text and the parameter values at Execute time, isn't logging the preliminary steps just bloating the log? Agreed. Logging Parse/Bind only if they're particularly interesting sounds good to me. * I think that the best way to log bind-parameter values is to run the datatype output functions on the saved parameter values. This works whether they were sent in text or binary mode, and avoids any extra overhead at Bind time that might not be repaid. Great. (The logging of binary parameters is something I also... not exactly _need_, but would be happy about.) -- ams ---(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: [HACKERS] Ding-dong, contrib is dead ...
At 2006-09-07 00:16:38 -0400, [EMAIL PROTECTED] wrote: - Where would the code live, if it were in core? - Shall I hack up the API you suggested in your earlier message? are we still moving forward with this? I would love to see this go in for 8.2. I don't know about its going into 8.2 or not, but I'm writing the code, and I'll submit a patch tomorrow. -- ams ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Ding-dong, contrib is dead ...
At 2006-09-05 05:47:58 -, [EMAIL PROTECTED] wrote: that difficulty no longer exists now that Abhijit has posted his clean-room rewrite (look for otherlock in -patches). Perhaps he would be prepared to turn that into a patch against the core... Absolutely. Just tell me where it should live and I'll post a patch. -- ams ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] help wanted (fmgr.c)
At 2006-09-11 10:25:22 +0200, [EMAIL PROTECTED] wrote:
What are we testing to be NULL here?
Do we expect str to changed at line 1715
No. (Read the comment just above the function.)
The code is like this, starting from line 1703:
if (str == NULL flinfo-fn_strict)
return (Datum) 0;
That is, if the function is declared strict, and the argument (str) is
0, just return NULL straightaway. Then it sets up the fcinfo and calls
the function, and then:
...
/* Should get null result if and only if str is NULL */
if (str == NULL)
{
if (!fcinfo.isnull)
elog(ERROR, input function %u returned non-NULL,
fcinfo.flinfo-fn_oid);
}
else
{
if (fcinfo.isnull)
elog(ERROR, input function %u returned NULL,
fcinfo.flinfo-fn_oid);
}
This says: If the argument is NULL and the input function didn't return
a NULL, log an error; but if the argument is non-NULL and the function
returned NULL, log this other error. (Note that a function would set
fcinfo-isnull to indicate that it wants to return an SQL NULL, as
explained in $DOC/plhandler.html)
-- ams
---(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: [HACKERS] What is d2mdir?
At 2008-09-02 15:10:23 +0300, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] sgml]$ make man As Alvaro noted recently, you need to use make man D2MDIR=/some/path. -- ams -- 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] [PATCH] \ef function in psql
At 2008-09-06 14:58:25 -0400, [EMAIL PROTECTED] wrote: I wrote: ... define \ef with no argument as being the command that presents an empty CREATE FUNCTION command template to fill in. No complaints? I'll go make that happen. No complaints, it sounds fine to me. What about the general issue that neither \e nor \ef leave you with a presentation of what's in the query buffer? I don't know how that can be fixed; but I agree with Brendan that it's behaviour that people are used to, and that it can be left alone for now. -- ams -- 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] [PATCH] allow has_table_privilege(..., 'usage') on sequences
At 2008-09-06 19:59:55 -0400, [EMAIL PROTECTED] wrote: So I'm thinking it would be better to invent a has_sequence_privilege family of functions. Perhaps. I certainly wouldn't object to that approach. If there had been such a function, I would have used it; and, since has_table_privilege doesn't help me in any released version, I have nothing invested in that way of doing things. (I can't help but think that the USAGE privilege is a bit unfortunate. If granting SELECT rights allowed currval(), INSERT allowed nextval(), and UPDATE allowed nextval() and setval(), then has_table_privilege() would have been sufficient and there would be no need to invent a new set of functions just to check USAGE. At the moment, however, I have to grant UPDATE instead of USAGE, both for compatibility with 8.1, and because there is no easy way to check if USAGE has already been granted, even though I don't want to allow setval() at all. Pity.) -- ams PS. I'm sorry I haven't been able to review any patches this time. I meant to, but a sequence of unfortunate events conspired to keep me busy elsewhere. I look forward to participating again next time. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] postgres adoption in india suffers setback
Seen on a lamp standard in south Delhi: http://toroid.org/misc/ne.jpeg -- ams -- 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] [PATCH] allow has_table_privilege(..., 'usage') on sequences
At 2008-09-22 12:54:34 -0500, [EMAIL PROTECTED] wrote: can we tell there is consensus in create a new has_sequence_privilege()? Abhijit will you make it? if not i can make a try... Yes, I'll do it. -- ams -- 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] mailing list archiver chewing patches
(Many thanks to Dimitri for bringing this thread to my attention.) At 2010-01-11 10:46:10 +0100, mag...@hagander.net wrote: As for AOX, my understanding is that it is no longer maintained, so I'd be worried about choosing such a solution for a complex problem. I'll keep this short: Oryx, the company behind Archiveopteryx (aox), is no longer around, but the software is still maintained. The developers (myself included) are still interested in keeping it alive. It's been a while since the last release, but it'll be ready soon. If you're having any sort of problems with it, write to me, and I'll help you. (That said, we're not working on the web interface. It did work, in its limited fashion, but it's not feature complete; and I need to find some paying work, so it's not a priority. That, and some health problems, are also why I haven't been active on the pg lists for a while.) Feel free to write to me off-list for more. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] TODO/exotic features/sql*net
Regarding this item in the TODO: SQL*Net listener that makes PostgreSQL appear as an Oracle database to clients I recently had (an unrelated) reason to look into the SQL*Net protocol and discovered that no documentation for it is publicly available, and reverse-engineering it is (supposedly) a violation of the Oracle user agreement. People have wanted it for years, but Oracle (for whatever reason) thinks it's a secret worth guarding closely. I've discussed this item with various people, so I thought I'd mention this for the sake of the archives. (IMO, the TODO item should be dropped.) -- ams, who is eternally grateful for protocol.html ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Logging configuration changes [REVIEW]
(This is my review of the small patch Peter posted on 2009-08-29. See
http://archives.postgresql.org/message-id/1251495487.18151.12.ca...@vanquo.pezone.net
for the original message.)
At 2009-08-29 00:38:07 +0300, pete...@gmx.net wrote:
Found an easy solution; see attached patch.
Neat. The patch (a) applies to HEAD and builds correctly, (b) does what
it's supposed to, i.e. report parameters whose value has been changed or
reset to the default, and (c) seems sensible.
I can't help but think that it would be nice to report the default value
of a parameter that is reset (i.e. parameter $x reset to default value
$y). The first attached patch does this by calling GetConfigOption()
after the value has been reset by set_config_option(). It also skips
the report if the earlier value was the same as the default.
On a related note, I suggest reverting or revising this logging change:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=293c816e4aad8e760bcb4eaba0aa16da0ccd2d04
FWIW, I agree about this too.
I would suggest changing the errmsg to just Parameter \%s\ cannot be
changed without restarting the server. I have attached a second patch
to do this.
LOG: received SIGHUP, reloading configuration files
LOG: parameter log_connections reset to default value off
LOG: parameter log_disconnections reset to default value off
LOG: Parameter max_connections cannot be changed without restarting the
server
LOG: parameter log_checkpoints changed to on
-- ams
diff --git a/src/backend/utils/misc/guc-file.l b/src/backend/utils/misc/guc-file.l
index 9e9c3f7..3bda73b 100644
--- a/src/backend/utils/misc/guc-file.l
+++ b/src/backend/utils/misc/guc-file.l
@@ -252,6 +252,8 @@ ProcessConfigFile(GucContext context)
{
struct config_generic *gconf = guc_variables[i];
GucStack *stack;
+ const char *pre_value;
+ const char *post_value;
if (gconf-reset_source != PGC_S_FILE ||
(gconf-status GUC_IS_IN_FILE))
@@ -280,9 +282,18 @@ ProcessConfigFile(GucContext context)
stack-source = PGC_S_DEFAULT;
}
+ if (context == PGC_SIGHUP)
+ pre_value = pstrdup(GetConfigOption(gconf-name));
+
/* Now we can re-apply the wired-in default */
set_config_option(gconf-name, NULL, context, PGC_S_DEFAULT,
GUC_ACTION_SET, true);
+
+ post_value = pstrdup(GetConfigOption(gconf-name));
+ if (context == PGC_SIGHUP strcmp(pre_value, post_value) != 0)
+ ereport(elevel,
+ (errmsg(parameter \%s\ reset to default value \%s\,
+ gconf-name, post_value)));
}
/*
@@ -309,9 +320,18 @@ ProcessConfigFile(GucContext context)
/* If we got here all the options checked out okay, so apply them. */
for (item = head; item; item = item-next)
{
+ const char *pre_value;
+
+ if (context == PGC_SIGHUP)
+ pre_value = pstrdup(GetConfigOption(item-name));
+
if (set_config_option(item-name, item-value, context,
PGC_S_FILE, GUC_ACTION_SET, true))
{
+ if (context == PGC_SIGHUP strcmp(pre_value, GetConfigOption(item-name)) != 0)
+ereport(elevel,
+ (errmsg(parameter \%s\ changed to \%s\,
+item-name, item-value)));
set_config_sourcefile(item-name, item-filename,
item-sourceline);
}
diff --git a/src/backend/utils/misc/guc-file.l b/src/backend/utils/misc/guc-file.l
index 9e9c3f7..a290601 100644
--- a/src/backend/utils/misc/guc-file.l
+++ b/src/backend/utils/misc/guc-file.l
@@ -260,9 +260,8 @@ ProcessConfigFile(GucContext context)
{
ereport(elevel,
(errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
- errmsg(attempted change of parameter \%s\ ignored,
- gconf-name),
- errdetail(This parameter cannot be changed after server start.)));
+ errmsg(Parameter \%s\ cannot be changed without restarting the server,
+ gconf-name)));
continue;
}
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 2224d56..8fa9599 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -4599,18 +4599,16 @@ set_config_option(const char *name, const char *value,
if (changeVal !is_newvalue_equal(record, value))
ereport(elevel,
(errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
- errmsg(attempted change of parameter \%s\ ignored,
- name),
- errdetail(This parameter cannot be changed after server start.)));
+ errmsg(Parameter \%s\ cannot be changed without restarting the server,
+ name)));
return true;
}
if (context != PGC_POSTMASTER)
{
ereport(elevel,
(errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
- errmsg(attempted change of parameter \%s\ ignored,
- name),
- errdetail(This parameter cannot be changed after server start.)));
+ errmsg(Parameter \%s\ cannot be changed without restarting the server,
+ name)));
return false;
}
break;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Re: [HACKERS] Logging configuration changes [REVIEW]
At 2009-09-16 01:18:10 -0500, jcasa...@systemguards.com.ec wrote:
ok, maybe this is not the most brilliant observation but someone has
to say it... keep the same case in the word parameter ;)
Oops, thanks. Re²vised patch attached.
-- ams
diff --git a/src/backend/utils/misc/guc-file.l b/src/backend/utils/misc/guc-file.l
index 9e9c3f7..a290601 100644
--- a/src/backend/utils/misc/guc-file.l
+++ b/src/backend/utils/misc/guc-file.l
@@ -260,9 +260,8 @@ ProcessConfigFile(GucContext context)
{
ereport(elevel,
(errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
- errmsg(attempted change of parameter \%s\ ignored,
- gconf-name),
- errdetail(This parameter cannot be changed after server start.)));
+ errmsg(parameter \%s\ cannot be changed without restarting the server,
+ gconf-name)));
continue;
}
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 2224d56..8fa9599 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -4599,18 +4599,16 @@ set_config_option(const char *name, const char *value,
if (changeVal !is_newvalue_equal(record, value))
ereport(elevel,
(errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
- errmsg(attempted change of parameter \%s\ ignored,
- name),
- errdetail(This parameter cannot be changed after server start.)));
+ errmsg(parameter \%s\ cannot be changed without restarting the server,
+ name)));
return true;
}
if (context != PGC_POSTMASTER)
{
ereport(elevel,
(errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
- errmsg(attempted change of parameter \%s\ ignored,
- name),
- errdetail(This parameter cannot be changed after server start.)));
+ errmsg(parameter \%s\ cannot be changed without restarting the server,
+ name)));
return false;
}
break;
--
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] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote: This patch changes plpgsql IN parameters so they are mutable. Makes sense, applies fine, works fine. -- ams -- 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] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
At 2009-09-16 08:37:40 -0400, and...@dunslane.net wrote: How does this compare with PLSQL? I don't remember anything of PL/SQL myself, but Pavel Stehule had this to say in response to the original post: This behave is in conflict with PL/SQL, what should do some problems. I thing, so I understand well, why this behave is in PL/SQL. It hasn't sense in plpgsql, because OUT and INOUT params has little bit different syntax (calling) and nobody will do similar bugs (perhaps). What is interesting - this behave is in conformity with SQL/PSM, where parameters are mutable too. I am for it. PL/pgSQL doesn't promise compatibility with PL/SQL and this change should to help some beginners (and this limit is artificial and unnecessary). Given the existing OUT/INOUT syntax difference as noted, I don't think the patch represents a significant problem. -- ams -- 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] pg_hba.conf: samehost and samenet [REVIEW]
(This is my review of the latest version of Stef Walter's samehost/net
patch, posted on 2009-09-17. See
http://archives.postgresql.org/message-id/4ab28043.3050...@memberwebs.com
for the original message.)
The patch applies and builds cleanly, and the samehost/samenet keywords
in pg_hba.conf work as advertised. I have no particular opinion on the
desirability of the feature, but I can see it would be useful in some
circumstances, as Stef described.
I think the patch is more or less ready, but I have a few minor
comments:
First, it needs to be reformatted to not use a space before the opening
parentheses in (some) function calls and definitions.
*** a/doc/src/sgml/client-auth.sgml
--- b/doc/src/sgml/client-auth.sgml
[...]
+ paraInstead of an replaceableCIDR-address/replaceable, you can
specify
+the values literalsamehost/literal or
literalsamenet/literal. To
+match any address on the subnets connected to the local machine,
specify
+literalsamenet/literal. By specifying
literalsamehost/literal, any
+addresses present on the network interfaces of local machine will
match.
+ /para
+
I'd suggest something like the following instead:
paraInstead of a replaceableCIDR-address/replaceable, you can
specify literalsamehost/literal to match any of the server's own
IP addresses, or literalsamenet/literal to match any address in
a subnet that the server belongs to.
*** a/src/backend/libpq/hba.c
--- b/src/backend/libpq/hba.c
[...]
+ else if (addr-sa_family == AF_INET
+ raddr-addr.ss_family == AF_INET6)
+ {
+ /*
+ * Wrong address family. We allow only one case: if the file
+ * has IPv4 and the port is IPv6, promote the file address to
+ * IPv6 and try to match that way.
+ */
How about this instead:
If we're listening on IPv6 but the file specifies an IPv4 address to
match against, we promote the latter also to an IPv6 address before
trying to match the client's address.
(The comment is repeated elsewhere.)
+ int
+ pg_foreach_ifaddr(PgIfAddrCallback callback, void * cb_data)
+ {
+ #ifdef WIN32
+ return foreach_ifaddr_win32(callback, cb_data);
+ #else /* !WIN32 */
+ #ifdef HAVE_GETIFADDRS
+ return foreach_ifaddr_getifaddrs(callback, cb_data);
+ #else /* !HAVE_GETIFADDRS */
+ return foreach_ifaddr_ifconf(callback, cb_data);
+ #endif
+ #endif /* !WIN32 */
+ }
First, writing it this way is less noisy:
#ifdef WIN32
return foreach_ifaddr_win32(callback, cb_data);
#elif defined(HAVE_GETIFADDRS)
return foreach_ifaddr_getifaddrs(callback, cb_data);
#else
return foreach_ifaddr_ifconf(callback, cb_data);
#endif
Second, I can't see that it makes very much difference, but why do it
this way at all? You could just have each of the three #ifdef blocks
define a function named pg_foreach_ifaddr() and be done with it. No
need for a fourth function.
*** a/src/backend/libpq/pg_hba.conf.sample
--- b/src/backend/libpq/pg_hba.conf.sample
[...]
+ # You can also specify samehost to limit connections to those from
addresses
+ # of the local machine. Or you can specify samenet to limit connections
+ # to addresses on the subnets of the local network.
This should be reworded to match the documentation change suggested
above.
-- ams
--
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] GRANT ON ALL IN schema
(This is a partial review of the grantonall-20090810v2.diff patch posted
by Petr Jelinek on 2009-08-10 (hi PJMODOS!). See
http://archives.postgresql.org/message-id/4a7f5853.5010...@pjmodos.net
for the original message.)
I have not yet been able to do a complete review of this patch, but I am
posting this because I'll be travelling for a week starting tomorrow. My
comments are based mostly on reading the patch, and not on any intensive
testing of the feature. I have left the patch status unchanged at needs
review, although I think it's close to ready for committer.
I really like this patch. It's easy to understand and written in a very
straightforward way, and addresses a real need that comes up time and
again on various support fora. I have only a couple of minor comments.
1. The patch did apply to HEAD and build cleanly, but there are now a
couple of minor (documentation) conflicts. (Sorry, I would have fixed
them and reposted a patch, but I'm running out of time right now.)
*** a/doc/src/sgml/ref/grant.sgml
--- b/doc/src/sgml/ref/grant.sgml
[...]
para
+There is also the possibility of granting permissions to all objects of
+given type inside one or multiple schemas. This functionality is
supported
+for tables, views, sequences and functions and can done by using
+ALL {TABLES|SEQUENCES|FUNCTIONS} IN SCHEMA schemaname syntax in place
+of object name.
+ /para
+
+ para
2. Here I suggest the following wording:
para
You can also grant permissions on all tables, sequences, or
functions that currently exist within a given schema by specifying
ALL {TABLES|SEQUENCES|FUNCTIONS} IN SCHEMA schemaname in place of
an object name.
/para
3. I believe MySQL's grant all privileges on foo.* to someone grants
privileges on all existing objects in foo _but also_ on any objects
that may be created later. This patch only gives you a way to grant
privileges only on the objects currently within a schema. I strongly
prefer this behaviour myself, but I do think the documentation needs
a brief mention of this fact, to avoid surprising people. That's why
I added that currently exist to (2), above. Maybe another sentence
that specifically says that objects created later are unaffected is
in order. I'm not sure.
-- ams
--
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] GRANT ON ALL IN schema
At 2009-09-20 20:20:11 +0530, a...@toroid.org wrote: 1. The patch did apply to HEAD and build cleanly, but there are now a couple of minor (documentation) conflicts. To be more clear, what I meant is that it did apply and build cleanly when it was posted, but things have drifted enough now that applying it causes conflicts in some sgml files. -- ams -- 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] GRANT ON ALL IN schema
At 2009-09-27 12:54:48 -0400, robertmh...@gmail.com wrote: If this patch looks good now, can you mark it Ready for Committer in the CommitFest app? Done. -- ams -- 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] plperl returning setof foo[]
At 2009-09-12 13:17:50 -0400, and...@dunslane.net wrote:
I have just noticed, somewhat to my chagrin, that while in a plperl
function that returns an array type you can return a perl arrayref,
like this:
return [qw(a b c)];
if the function returns a setof an array type you cannot do this:
return_next [qw(a b c)];
Right. This was an unintentional omission on my part.
The fix is fairly small (see attached) although I need to check with
some perlguts guru to see if I need to decrement a refcounter here or
there.
Slightly simpler patch attached (and tested).
-- ams
*** a/src/pl/plperl/plperl.c
--- b/src/pl/plperl/plperl.c
***
*** 2021,2027 plperl_return_next(SV *sv)
if (SvOK(sv))
{
! char *val = SvPV(sv, PL_na);
ret = InputFunctionCall(prodesc-result_in_func, val,
prodesc-result_typioparam, -1);
--- 2021,2035
if (SvOK(sv))
{
! char *val;
!
! if (prodesc-fn_retisarray SvROK(sv)
! SvTYPE(SvRV(sv)) == SVt_PVAV)
! {
! sv = plperl_convert_to_pg_array(sv);
! }
!
! val = SvPV(sv, PL_na);
ret = InputFunctionCall(prodesc-result_in_func, val,
prodesc-result_typioparam, -1);
--
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] pg_hba.conf: samehost and samenet [REVIEW]
At 2009-09-30 11:16:57 -0500, stef-l...@memberwebs.com wrote: I've now added tests for sys/ioctl.h and net/if.h even though these headers seemed to be common to all the unixes investigated. Thanks. I've marked this ready for committer now. FWIW, there are checks for various bad netmasks. I incorporated these techniques after seeing them in the corresponding postfix code. [...] BTW, there's also fallback code. If none of the methods work on a given OS, then the ifaddrs code just lists 127.0.0.1/8 and ::1/128. Both of these look good. + /* + * Wrong address family. We allow only one case: if the file + * has IPv4 and the port is IPv6, promote the file address to + * IPv6 and try to match that way. + */ I still think this comment should be fixed in _both_ places it now occurs, but oh well. (Note: I have not tested under Windows, and I've not tested test_ifaddrs.c. Also, there are a few lines which introduce trailing whitespace.) -- ams -- 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] Use samehost by default in pg_hba.conf?
At 2009-09-30 22:08:12 -0400, t...@sss.pgh.pa.us wrote: # local connections via TCP/IP: hostall all samehost @authmethod@ I think that's an excellent idea. On the other hand, I tend to be slightly against the idea of changing the default listen_addresses from localhost to '*', for a combination of the reasons mentioned by others; but I don't have strong feelings about it. -- ams -- 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] Wire protocol docs
At 2009-10-13 17:25:15 +0100, dp...@pgadmin.org wrote: I cannot find anything that is obviously 'elsewhere' in the docs - does that need fixing, or do my searching skills need improving? I don't know, but… *starts reading source code* :-) Look at what fe-protocol3.c:build_startup_packet() does with its options argument (and see fe-connect.c:EnvironmentOptions to see what is passed to it). Basically, libpq sets some connection parameters to values taken from the environment (e.g. client_encoding from PGCLIENTENCODING). What the documentation you quoted is saying is that the wire protocol doesn't know or care where the values came from. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] psql: \edit-function function-name
Hi.
I'm working on a patch where if you say \ef foo in psql, it'll start
$EDITOR with a CREATE OR REPLACE FUNCTION statement to recreate the
function. So you edit and save and quit, and if you made any changes,
psql will execute the statement.
The psql(/command.c) parts of this are quite simple. I've attached a
patch to demonstrate the idea.
The problem is, of course, generating the CREATE OR REPLACE statement.
There is some code to do this in pg_dump.c:dumpFunc(), but it's strongly
tied to pg_dump (global variables, output to Archive *, dependencies on
other functions, etc.).
I could either try to duplicate this code (and there's a lot of it), or
rip dumpFunc() and its dependencies out of pg_dump into dumpfunc.c and
make it callable both by pg_dump and psql. I've done some work towards
the latter, so I know it's possible, but it's a lot of work, which I
don't want to do if it won't be accepted anyway.
I would appreciate some advice on how to proceed.
-- ams
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index f66fd7e..3724533 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -35,6 +35,7 @@
#include libpq-fe.h
#include pqexpbuffer.h
#include dumputils.h
+#include dumpfunc.h
#include common.h
#include copy.h
@@ -53,7 +54,7 @@
static backslashResult exec_command(const char *cmd,
PsqlScanState scan_state,
PQExpBuffer query_buf);
-static bool do_edit(const char *filename_arg, PQExpBuffer query_buf);
+static bool do_edit(const char *, PQExpBuffer, bool *);
static bool do_connect(char *dbname, char *user, char *host, char *port);
static bool do_shell(const char *command);
@@ -432,11 +433,71 @@ exec_command(const char *cmd,
expand_tilde(fname);
if (fname)
canonicalize_path(fname);
- status = do_edit(fname, query_buf) ? PSQL_CMD_NEWEDIT : PSQL_CMD_ERROR;
+ if (do_edit(fname, query_buf, 0))
+status = PSQL_CMD_NEWEDIT;
+ else
+status = PSQL_CMD_ERROR;
free(fname);
}
}
+ /*
+ * \ef -- edit the named function in $EDITOR.
+ */
+
+ else if (strcmp(cmd, ef) == 0)
+ {
+ Oid foid;
+ char *func;
+
+ func = psql_scan_slash_option(scan_state, OT_WHOLE_LINE, NULL, true);
+ if (!func)
+ {
+ psql_error(no function name specified\n);
+ status = PSQL_CMD_ERROR;
+ }
+
+ if (!lookup_function_oid(pset.db, func, foid))
+ {
+ psql_error(PQerrorMessage(pset.db));
+ status = PSQL_CMD_ERROR;
+ }
+ else
+ {
+ bool edited = false;
+
+ termPQExpBuffer(query_buf);
+ if (foid)
+ {
+char *s = create_or_replace_function_text(foid);
+appendPQExpBufferStr(query_buf, s);
+free(s);
+ }
+ else
+ {
+printfPQExpBuffer(query_buf,
+ CREATE FUNCTION %s%s RETURNS ... AS $$\n
+ ...\n
+ $$ LANGUAGE '...'\n,
+ func, strchr(func,'(') ? : (...) );
+ }
+
+ if (!do_edit(0, query_buf, edited))
+ {
+status = PSQL_CMD_ERROR;
+ }
+ else if (!edited)
+ {
+printf(No changes\n);
+ }
+ else
+ {
+status = PSQL_CMD_SEND;
+ }
+ free(func);
+ }
+ }
+
/* \echo and \qecho */
else if (strcmp(cmd, echo) == 0 || strcmp(cmd, qecho) == 0)
{
@@ -1298,7 +1359,7 @@ editFile(const char *fname)
/* call this one */
static bool
-do_edit(const char *filename_arg, PQExpBuffer query_buf)
+do_edit(const char *filename_arg, PQExpBuffer query_buf, bool *edited)
{
char fnametmp[MAXPGPATH];
FILE *stream = NULL;
@@ -1420,6 +1481,10 @@ do_edit(const char *filename_arg, PQExpBuffer query_buf)
psql_error(%s: %s\n, fname, strerror(errno));
error = true;
}
+ else if (edited)
+ {
+*edited = true;
+ }
fclose(stream);
}
--
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] psql: \edit-function function-name
At 2008-06-15 23:35:34 -0400, [EMAIL PROTECTED] wrote: There's been a lot of talk (but no action) about refactoring pg_dump into a library plus wrapper. Yes. After having tried to do what would have amounted to just a small part of that work, I can see why nobody has done it yet. I'd much rather see that tackled in a holistic fashion. I'd much rather see someone *else* tackle it in a holistic fashion ;), but since I don't like the other alternatives (pg_dump --function and pg_get_functiondef), I suppose I'd better get to work. PS: two trivial stylistic gripes: Thanks, noted. -- ams -- 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] Removal of the patches email list
At 2008-06-26 18:51:46 -0400, [EMAIL PROTECTED] wrote: I propose we close the patches list and tell everyone to start using only the hackers list. That's an excellent idea. -- ams -- 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] Processing database query-results piecemeal
At 2008-06-30 13:17:42 +0200, [EMAIL PROTECTED] wrote:
It seems that the most efficient way to communicate with the
DB would be through PQexecParams(), which avoids the whole
bytea-encoding issues.
Yes.
Does it become $10 or ${10} or $(10) or is it simply not possible
te reference more than nine parameters this way?
$10 etc.
- Say that the SELECT returns 1000 rows of 100MB each, is there a way
to avoid PQexecParams() from wanting to allocate 1000*100MB = 100GB
Use a cursor and keep executing FETCH.
-- ams
--
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] Limits of backwards compatibility for psql's \d commands
At 2008-07-02 09:16:30 +0200, [EMAIL PROTECTED] wrote: I don't think we should add support for pre-7.4 releases. I agree. It's not worth the effort. -- ams -- 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] Git Repository for WITH RECURSIVE and others
At 2008-07-03 11:16:49 +0900, [EMAIL PROTECTED] wrote: # WITH RECURSIVE repository % git-clone git://git.postgresql.org/git/~davidfetter/postgresql/.git Initialized empty Git repository in /home/y-asaba/x/postgresql/.git/ fatal: The remote end hung up unexpectedly Run git-clone http://git.postgresql.org/git/~davidfetter/postgresql/.git instead. git://... apparently doesn't work on that repository (I don't know why not). -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] SSL configure patch: review
These are my review comments on Mark Woodward's SSL configure patch:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
(The patch is whitespace-damaged and the one fe-secure.c hunk doesn't
apply cleanly to the latest source, but I'm ignoring both problems for
the moment.)
1. To begin with, the patch should document the new connection options.
In fe-connect.c:
@@ -181,6 +181,19 @@
{sslmode, PGSSLMODE, DefaultSSLMode, NULL,
SSL-Mode, , 8}, /* sizeof(disable) == 8 */
+ {sslcert, PGSSLCERT, NULL, NULL,
+ SSL-Client-Cert, , 64},
+
+ {sslkey, PGSSLKEY, NULL, NULL,
+ SSL-Client-Key, , 64},
+
+ {ssltrustcrt, PGSSLKEY, NULL, NULL,
+ SSL-Trusted-Keys, , 64},
+
+ {sslcrl, PGSSLKEY, NULL, NULL,
+ SSL-Revocation-List, , 64},
2. You have PGSSLKEY for ssltrustcrt and sslcrl. Cut and paste
error?
3. I'd suggest using the names PGROOTCERT and sslrootcert instead of
ssltrustcrt, to better match the ROOT_CERT_FILE value you're trying
to configure.
In libpq-int.h:
@@ -293,6 +293,11 @@
char *pgpass;
boolpgpass_from_client; /* did password come from
connect args? */
char *sslmode;/* SSL mode
(require,prefer,allow,disable) */
+char *sslkey; /* ssl key file filename for call back */
+char *sslcert;/* ssl certificate filename for call back */
+char *ssltrustcrt; /* Trusted certificuits */
+char *sslcrl; /* certificates revoked by certificate
authorities */
+
4. I'd say SSL client key filename, SSL client certificate filename,
SSL root certificate filename, and SSL certificate revocation list
filename in the comments. (It's not clear what the call back is in
this context; nor does it need to be.)
(I like certificuits. It makes me think of cookies. :-)
In fe-secure.c:
@@ -939,8 +950,13 @@
if ((cvstore = SSL_CTX_get_cert_store(SSL_context)) !=
NULL)
{
+if(conn-sslcrl)
+strncpy(fnbuf, conn-sslcrl,
sizeof(fnbuf));
+else
+snprintf(fnbuf, sizeof(fnbuf),
%s/%s, homedir, ROOT_CRL_FILE);
+
/* setting the flags to check against the
complete CRL chain */
- if (X509_STORE_load_locations(cvstore,
ROOT_CRL_FILE, NULL) != 0)
+ if (X509_STORE_load_locations(cvstore, fnbuf,
NULL) != 0)
5. I notice you're adding homedir/ to the ROOT_CRL_FILE. This looks
sensible, but I wanted to make sure it was intentional. Is this what
you (i.e. Mark) meant in another message when you said:
BTW: the revocation list probably never worked in the client.
Finally, I don't know enough (i.e. anything) about Windows to evaluate
the changes to libpq.rc, but the file that should be patched is really
libpq.rc.in.
-- ams
--
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] SSL configure patch: review
At 2008-07-08 08:27:29 +0530, [EMAIL PROTECTED] wrote:
(The patch is whitespace-damaged and the one fe-secure.c hunk doesn't
apply cleanly to the latest source, but I'm ignoring both problems for
the moment.)
It wasn't hard to fix those, so I've attached an updated patch here.
Finally, I don't know enough (i.e. anything) about Windows to evaluate
the changes to libpq.rc, but the file that should be patched is really
libpq.rc.in.
(But I didn't touch libpq.rc.in. I'm not sure if it even needs to be
changed any more.)
-- ams
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index 307b805..6b53e37 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -181,6 +181,19 @@ static const PQconninfoOption PQconninfoOptions[] = {
{sslmode, PGSSLMODE, DefaultSSLMode, NULL,
SSL-Mode, , 8}, /* sizeof(disable) == 8 */
+ {sslcert, PGSSLCERT, NULL, NULL,
+ SSL-Client-Cert, , 64},
+
+ {sslkey, PGSSLKEY, NULL, NULL,
+ SSL-Client-Key, , 64},
+
+ {sslrootcert, PGROOTCERT, NULL, NULL,
+ SSL-Root-Certificate, , 64},
+
+ {sslcrl, PGSSLCRL, NULL, NULL,
+ SSL-Revocation-List, , 64},
+
+
#if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
/* Kerberos and GSSAPI authentication support specifying the service name */
{krbsrvname, PGKRBSRVNAME, PG_KRB_SRVNAM, NULL,
@@ -413,6 +426,14 @@ connectOptions1(PGconn *conn, const char *conninfo)
conn-connect_timeout = tmp ? strdup(tmp) : NULL;
tmp = conninfo_getval(connOptions, sslmode);
conn-sslmode = tmp ? strdup(tmp) : NULL;
+ tmp = conninfo_getval(connOptions, sslkey);
+ conn-sslkey = tmp ? strdup(tmp) : NULL;
+ tmp = conninfo_getval(connOptions, sslcert);
+ conn-sslcert = tmp ? strdup(tmp) : NULL;
+ tmp = conninfo_getval(connOptions, sslrootcert);
+ conn-sslrootcert = tmp ? strdup(tmp) : NULL;
+ tmp = conninfo_getval(connOptions, sslcrl);
+ conn-sslcrl = tmp ? strdup(tmp) : NULL;
#ifdef USE_SSL
tmp = conninfo_getval(connOptions, requiressl);
if (tmp tmp[0] == '1')
diff --git a/src/interfaces/libpq/fe-secure.c b/src/interfaces/libpq/fe-secure.c
index a61dbfb..a4fdba1 100644
--- a/src/interfaces/libpq/fe-secure.c
+++ b/src/interfaces/libpq/fe-secure.c
@@ -599,7 +599,11 @@ client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
}
/* read the user certificate */
- snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, USER_CERT_FILE);
+
+ if (conn-sslcert)
+ strncpy(fnbuf, conn-sslcert, sizeof(fnbuf));
+ else
+ snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, USER_CERT_FILE);
/*
* OpenSSL = 0.9.8 lacks error stack handling, which means it's likely to
@@ -650,7 +654,7 @@ client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
BIO_free(bio);
#if (SSLEAY_VERSION_NUMBER = 0x00907000L) !defined(OPENSSL_NO_ENGINE)
- if (getenv(PGSSLKEY))
+ if (getenv(PGSSLKEY) !conn-sslkey)
{
/* read the user key from engine */
char *engine_env = getenv(PGSSLKEY);
@@ -702,7 +706,11 @@ client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
#endif /* use PGSSLKEY */
{
/* read the user key from file */
- snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, USER_KEY_FILE);
+ if (conn-sslkey)
+ strncpy(fnbuf, conn-sslkey, sizeof(fnbuf));
+ else
+ snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, USER_KEY_FILE);
+
if (stat(fnbuf, buf) != 0)
{
printfPQExpBuffer(conn-errorMessage,
@@ -904,7 +912,11 @@ initialize_SSL(PGconn *conn)
/* Set up to verify server cert, if root.crt is present */
if (pqGetHomeDirectory(homedir, sizeof(homedir)))
{
- snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, ROOT_CERT_FILE);
+ if (conn-ssltrustcrt)
+ strncpy(fnbuf, conn-ssltrustcrt, sizeof(fnbuf));
+ else
+ snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, ROOT_CERT_FILE);
+
if (stat(fnbuf, buf) == 0)
{
X509_STORE *cvstore;
@@ -922,8 +934,13 @@ initialize_SSL(PGconn *conn)
if ((cvstore = SSL_CTX_get_cert_store(SSL_context)) != NULL)
{
+if (conn-sslcrl)
+ strncpy(fnbuf, conn-sslcrl, sizeof(fnbuf));
+else
+ snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, ROOT_CRL_FILE);
+
/* setting the flags to check against the complete CRL chain */
-if (X509_STORE_load_locations(cvstore, ROOT_CRL_FILE, NULL) != 0)
+if (X509_STORE_load_locations(cvstore, fnbuf, NULL) != 0)
/* OpenSSL 0.96 does not support X509_V_FLAG_CRL_CHECK */
#ifdef X509_V_FLAG_CRL_CHECK
X509_STORE_set_flags(cvstore,
diff --git a/src/interfaces/libpq/libpq-int.h b/src/interfaces/libpq/libpq-int.h
index 4af1388..f47e50e 100644
--- a/src/interfaces/libpq/libpq-int.h
+++ b/src/interfaces/libpq/libpq-int.h
@@ -293,6 +293,11 @@ struct pg_conn
char *pgpass;
bool pgpass_from_client; /* did password come from connect args? */
char *sslmode; /* SSL mode (require,prefer,allow,disable) */
+ char *sslkey; /* client key filename */
+ char *sslcert; /* client certificate filename */
+ char *sslrootcert; /* root certificate filename */
+ char *sslcrl;
Re: [HACKERS] Adding variables for segment_size, wal_segment_size and block sizes
At 2008-07-03 16:36:02 +0200, [EMAIL PROTECTED] wrote: Here's a patch for this. I reviewed the patch, it basically looks fine. A few quibbles with the provided documentation: + Reports the number of pages which can be stored within a file segment. + The total physical size of a segment file in bytes can be determined by multiplying + the varnameblock_size/varname parameter with varnamesegment_size/varname. I would say: Reports the number of blocks/pages which can be stored within a file segment. The total size of a segment file in bytes is equal to the varnamesegment_size/ multiplied by the varnameblock_size/. + Reports the size of a write ahead log disk block. It is determined by the value + of literalXLOG_BLCKSZ/ when building the server. The default + value is 8192 bytes. varnamewal_block_size/varname influences the total physical + size of a write ahead log segment. See xref + linkend=guc-wal-segment-size for more information. +/para I'd change write ahead log disk block to WAL disk block. How about this: Reports the size of a WAL disk block, as determined by the value of literalXLOG_BLCKSZ/ when compiling the server. The default is 8192 bytes. varnamewal_block_size/ influences the total size of a WAL segment file. See xref linkend=guc-wal-segment-size for more information. + Reports the number of pages within a write ahead log segment file. varnamewal_segment_size/varname multiplied with varnamewal_block_size/varname gives the total physical size of a write ahead + log segment file in bytes. Again, I'd say WAL here instead of write ahead log, because the full form is clumsy in context. How about this: Reports the number of pages in a WAL segment file. The total size of a WAL segment file in bytes is equal to varnamewal_segment_size/ multiplied by varnamewal_block_size/. What do you think? -- ams -- 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] Extending grant insert on tables to sequences
At 2008-07-08 09:32:44 -0400, [EMAIL PROTECTED] wrote: The idea of this patch is to avoid the need to make explicit grants on sequences owned by tables. [...] I had a look at this patch and it looks good. The only thing that's not clear to me is whether we have agreed we want this to be the default behavior? For what it's worth, I quite like the idea. (I looked at the patch, and it looks good to me too.) Wouldn't it be clearer to build a list with all the sequences owned by the tables in istmt.objects, and then call ExecGrantStmt_oids() a single time with the big list? i.e., to hoist most of the istmt_seq initialisation out of the loop, right? Yes, that makes sense. -- ams -- 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] Extending grant insert on tables to sequences
At 2008-07-09 15:11:25 -0400, [EMAIL PROTECTED] wrote:
No, actually I meant having a lone list = lappend(list, newseq); in
the loop, so that ExecGrantStmt_oids is called only once.
Yes, I understand what you meant. I just phrased my agreement poorly.
Here's a more precise phrasing. ;-)
(I agree with Robert Treat that there seems to be no point granting
SELECT on the sequence. I don't *particularly* care about it, but I
tend towards wanting to drop that bit. This patch reflects that.)
Jaime: please feel free to use or ignore this, as you wish.
-- ams
diff --git a/src/backend/catalog/aclchk.c b/src/backend/catalog/aclchk.c
index 15f5af0..8664203 100644
--- a/src/backend/catalog/aclchk.c
+++ b/src/backend/catalog/aclchk.c
@@ -361,6 +361,41 @@ ExecuteGrantStmt(GrantStmt *stmt)
}
ExecGrantStmt_oids(istmt);
+
+ /* If INSERT or UPDATE privileges are being granted or revoked on a
+* relation, this extends the operation to include any sequences
+* owned by the relation.
+*/
+
+ if (istmt.objtype == ACL_OBJECT_RELATION
+ (istmt.privileges (ACL_INSERT | ACL_UPDATE)))
+ {
+ InternalGrant istmt_seq;
+
+ istmt_seq.is_grant = istmt.is_grant;
+ istmt_seq.objtype = ACL_OBJECT_SEQUENCE;
+ istmt_seq.grantees = istmt.grantees;
+ istmt_seq.grant_option = istmt.grant_option;
+ istmt_seq.behavior = istmt.behavior;
+ istmt_seq.all_privs = false;
+
+ istmt_seq.privileges = ACL_NO_RIGHTS;
+ if (istmt.privileges ACL_INSERT)
+ istmt_seq.privileges |= ACL_USAGE;
+ if (istmt.privileges ACL_UPDATE)
+ istmt_seq.privileges |= ACL_UPDATE;
+
+ istmt_seq.objects = NIL;
+ foreach (cell, istmt.objects)
+ {
+ istmt_seq.objects =
+ list_concat(istmt_seq.objects,
+
getOwnedSequences(lfirst_oid(cell)));
+ }
+
+ if (istmt_seq.objects != NIL)
+ ExecGrantStmt_oids(istmt_seq);
+ }
}
/*
--
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] WITH RECURSIVE updated to CVS TIP
At 2008-07-09 17:06:19 -0700, [EMAIL PROTECTED] wrote: I'm really new to this git thing, but I now have access to create git-shell accounts, etc. on git.postgresql.org. Any ideas you can offer on how better to handle this would really help me. :) The question is: what is your objective in providing this repository? I've only just cloned your repository, so I can only guess at how it is managed, but you seem to be rebasing your changes on top of the current Postgres source and responding to upstream changes by throwing away the old patches and applying the new ones. (By the way, your origin/master appears to be lagging the current HEAD by 71 commits, i.e. a month.) That has several problems: - There is no indication of how the WITH RECURSIVE patches have changed over time or in response to feedback. For example, the bugs recently fixed are indistinguishable from earlier changes. This would be very valuable information to have during review (and that's really what I was expecting when I cloned). - One has to clone a 250MB repository (over HTTP, with almost no progress indication) to see what is essentially exactly the same as the posted patch. - Rebasing isn't appropriate for a public branch, since you're rewriting history that people have pulled already. If your objective is only to make an up-to-date patch always available, then it is unnecessary to publicise your repository. You could just use git-rebase to stay abreast of significant changes in origin/master and run git-format-patch to generate a patch... but then you still end up with essentially the same thing that Tatsuo Ishii posted to the list the other day anyway. I agree with Alvaro. If the developers aren't committing to this repository that the patches are generated from, there's really no point to using the repository for review. It's very much simpler to just read the patch as posted to the list. The only real benefit to review that I can imagine would be if full change history were available, which it could do if a) changes were committed separately with proper comments and b) if the branch were *NOT* rebased, but instead periodically merged with origin/master. That way I could pull from the repository and run e.g. git-log --stat origin/master..with-recursive or similar. Hope this helps. -- ams -- 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] Protocol 3, Execute, maxrows to return, impact?
(I don't really have much to add to the discussion here; I'm just posting for the record on the question of client behaviour, since I also wrote and maintain a client library in C++.) At 2008-07-10 18:40:03 +0200, [EMAIL PROTECTED] wrote: I start returning rows as they arrive, and pause reading from the network when the application wants to pause. My library also starts returning rows as they arrive, and in fact my application makes heavy use of that feature. The data rows are read from a non-blocking socket and the caller either does something for each one, or waits until they've all arrived before proceeding. Interleaved retrieval using multiple portals is not what most libraries support, I'd guess. My code did support that mode of operation in theory, but in practice in the few situations where I have needed to use something like it, I found it more convenient to open explicit cursors and FETCH from them (but I usually needed this inside a transaction, and so did not open multiple connections). Thus my code always sets maxrows to 0 at the moment, and so... The only thing I could imagine is that *if* at the server end, the notifications that arrive during the retrieval of one long running Execute, are queued *after* all the data, instead of inserted into the datastream, then it might be worth doing it differently. ...I can't comment on this interesting observation. i.e. in one row I can have both text and binary columns, without the application needing to specify which is which. Yes, that's nice. My first attempt to define an API for bind variables set the data format to text by default and allowed it to be overriden, but that was much too troublesome. Now the code decides by itself what format is best to use for a given query. (Again, though my library certainly supports mixing text and binary format columns, my application has not needed to use this feature.) -- ams -- 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] WITH RECURSIVE updated to CVS TIP
At 2008-07-10 07:18:28 -0700, [EMAIL PROTECTED] wrote: Here are my objectives: 1. Make a repository that keeps up with CVS HEAD. 2. Allow people who are not currently committers on CVS HEAD to make needed changes. OK. Then, to begin with, I think it is very important to make the repository available via the git protocol. HTTP just won't cut it. It would be even nicer if we can put together a standard procedure for new patches. Would you be willing to write it up? The standard procedure for new patches would be the standard procedure for *any* patches when you use git. You have a branch that tracks the upstream (by which I mean the Postgres source) and a branch where you work (apply individual changes), and you merge with the origin every now and then (either in your working branch or in another branch). And once you've published a branch, you try never to rebase it. The apply individual changes part could be done by hand (git-apply, git-commit), or by accepting individual patches via email (git-am) or pulling from a remote repository, or by having others push into your repository. It doesn't matter. Again, git.postgresql.org is good for this and other places are not for reasons I've mentioned before. I haven't seen your reasons, but frankly, I would be suspicious of them even if git.postgresql.org filled me with confidence, which it doesn't. It seems to lag some way behind CVS and, as Alvaro pointed out earlier, may be missing some patches. (I realise those might have been teething troubles, and it may even be fixed now, but I just use the mirror on repo.or.cz instead.) -- ams -- 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] posix advises ...
Hi Zoltán.
I was reading through your posix_fadvise patch, and I wanted to ask
about this change in particular:
--- a/src/backend/executor/nodeIndexscan.c
+++ b/src/backend/executor/nodeIndexscan.c
@@ -290,7 +290,7 @@ ExecIndexEvalArrayKeys(ExprContext *econtext,
/* We want to keep the arrays in per-tuple memory */
oldContext = MemoryContextSwitchTo(econtext-ecxt_per_tuple_memory);
- for (j = 0; j numArrayKeys; j++)
+ for (j = numArrayKeys-1; j = 0; j--)
{
ScanKey scan_key = arrayKeys[j].scan_key;
ExprState *array_expr = arrayKeys[j].array_expr;
Why is this loop reversed? (I could have missed some discussion about
this, I just wanted to make sure it was intentional.)
I can confirm that the patch applies to HEAD, that the configure test
correctly #defines USE_POSIX_FADVISE, that it compiles cleanly, and it
looks basically sensible to me. The nodeBitmapHeapscan.c and iterator
changes need a second look by someone who understands the code better
than I do.
The documentation patch could use a little tweaking:
+productnamePostgreSQL/productname can give hints to POSIX
compatible
+operating systems using posix_fadvise(2) to pre-read pages that will
+be needed in the near future. Reading the pages into the OS kernel's
+disk buffer will be done asynchronically while
productnamePostgreSQL/productname
+works on pages which are already in memory. This may speed up bitmap
scans
+considerably. This setting only applies to bitmap scans.
+Hinting for sequential scans is also used but no GUC is needed in
this case.
I would suggest something like this instead:
productnamePostgreSQL/productname can use posix_fadvise(2) to
tell the operating system about pages that it knows will be needed
in the near future. The performance of bitmap scans is considerably
improved when the kernel pre-reads such pages into its disk buffers.
This variable controls how many pages are marked for pre-reading at
a time during a bitmap scan.
But I'm not convinced that this GUC is well-advised; at least, it needs
some advice about how to determine a sensible size for the parameter
(and maybe a better name). But is it really necessary at all?
Thanks.
-- ams
--
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] Proposal of SE-PostgreSQL patches [try#2]
At 2008-07-11 19:10:16 +0900, [EMAIL PROTECTED] wrote: And I have a question. Is it legal to use a pointer value as a condition, like `while (!pointer) ...' ? Yes, it's fine. -- ams -- 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] CommitFest rules
At 2008-07-08 13:50:24 +0100, [EMAIL PROTECTED] wrote: I can tell you from the perspective of CF coordinator, it's a PITA. I felt so too at first, but I'm comfortable with it now. Then I'm in awe of your wiki-editing skills. After keeping at it for a few days, I've given up trying to do anything to the Commitfest page, because even adding a comment or changing the status of something is too painful for me. Given the number of entries that haven't been updated, I'm guessing that I'm not the only one having trouble. -- ams -- 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] Extending grant insert on tables to sequences
At 2008-07-11 11:57:37 -0500, [EMAIL PROTECTED] wrote:
attached is a new version of the patch, it implements Alvaro's
suggestion and fix a bug i found (it wasn't managing GRANT ALL) :(
Looks good to me.
About the SELECT issue, AFAIU Robert doesn't complaint he just asked
what is the use case... if people think it should be removed ok, but
OTOH: why? i don't think that affects anything...
As I said, I don't feel too strongly about it.
para
! Granting permission on a table automatically extend
! permissions to any sequences owned by the table, including
! sequences tied to typeSERIAL/ columns.
/para
Should be Granting permissions on a table automatically extends those
permissions to
+ if ((istmt.objtype == ACL_OBJECT_RELATION) (istmt.all_privs ||
+ (istmt.privileges (ACL_INSERT | ACL_UPDATE | ACL_SELECT
+ {
The parentheses around the first comparison can go away, and also the
ones around the ACL_* here:
+ if (istmt.privileges (ACL_INSERT))
+ istmt_seq.privileges |= ACL_USAGE;
+ if (istmt.privileges (ACL_UPDATE))
+ istmt_seq.privileges |= ACL_UPDATE;
+ if (istmt.privileges (ACL_SELECT))
+ istmt_seq.privileges |= ACL_SELECT;
-- ams
--
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] posix advises ...
At 2008-07-12 00:52:42 +0100, [EMAIL PROTECTED] wrote: There was some discussion about this change and in fact if you look at CVS HEAD you'll find it already applied. Not as far as I can see. Incrementing the most significant index keys would maximize the distance we're jumpin around in the index tree. I see. Thanks. The later versions of mine had a GUC named effective_spindle_count which I think is nicely abstracted away from the implementation details. Yes, that does sound much better. (The patch I read had a preread_pages_bitmapscan variable instead.) -- ams -- 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] Extending grant insert on tables to sequences
At 2008-07-12 14:32:03 -0500, [EMAIL PROTECTED] wrote: Should be Granting permissions on a table automatically extends those permissions to what about extends them to... Yes, sounds fine, thanks. But I notice that nobody else has commented on whether they want this feature or not. Does anyone particularly dislike the idea? -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH] \ef function in psql
Refactoring pg_dump was more work than I had time to do right now, and I
wanted \ef to work, so I hacked up the attached (by copying dumpFunc and
its dependencies to src/bin/psql/dumpfunc.[ch]).
-- ams
*** a/src/bin/psql/Makefile
--- b/src/bin/psql/Makefile
***
*** 21,27 override CPPFLAGS := -I$(srcdir) -I$(libpq_srcdir) -I$(top_srcdir)/src/bin/pg_du
OBJS= command.o common.o help.o input.o stringutils.o mainloop.o copy.o \
startup.o prompt.o variables.o large_obj.o print.o describe.o \
! psqlscan.o tab-complete.o mbprint.o dumputils.o $(WIN32RES)
EXTRA_OBJS = $(top_builddir)/src/backend/parser/keywords.o
--- 21,27
OBJS= command.o common.o help.o input.o stringutils.o mainloop.o copy.o \
startup.o prompt.o variables.o large_obj.o print.o describe.o \
! psqlscan.o tab-complete.o mbprint.o dumputils.o dumpfunc.o $(WIN32RES)
EXTRA_OBJS = $(top_builddir)/src/backend/parser/keywords.o
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
***
*** 38,43
--- 38,44
#include libpq-fe.h
#include pqexpbuffer.h
#include dumputils.h
+ #include dumpfunc.h
#include common.h
#include copy.h
***
*** 56,62
static backslashResult exec_command(const char *cmd,
PsqlScanState scan_state,
PQExpBuffer query_buf);
! static bool do_edit(const char *filename_arg, PQExpBuffer query_buf);
static bool do_connect(char *dbname, char *user, char *host, char *port);
static bool do_shell(const char *command);
--- 57,64
static backslashResult exec_command(const char *cmd,
PsqlScanState scan_state,
PQExpBuffer query_buf);
! static bool do_edit(const char *filename_arg, PQExpBuffer query_buf,
! bool *edited);
static bool do_connect(char *dbname, char *user, char *host, char *port);
static bool do_shell(const char *command);
***
*** 444,454 exec_command(const char *cmd,
expand_tilde(fname);
if (fname)
canonicalize_path(fname);
! status = do_edit(fname, query_buf) ? PSQL_CMD_NEWEDIT : PSQL_CMD_ERROR;
free(fname);
}
}
/* \echo and \qecho */
else if (strcmp(cmd, echo) == 0 || strcmp(cmd, qecho) == 0)
{
--- 446,521
expand_tilde(fname);
if (fname)
canonicalize_path(fname);
! if (do_edit(fname, query_buf, NULL))
! status = PSQL_CMD_NEWEDIT;
! else
! status = PSQL_CMD_ERROR;
free(fname);
}
}
+ /*
+ * \ef -- edit the named function in $EDITOR.
+ */
+
+ else if (strcmp(cmd, ef) == 0)
+ {
+ Oid foid;
+ char *func;
+
+ func = psql_scan_slash_option(scan_state, OT_WHOLE_LINE, NULL, true);
+ if (!func)
+ {
+ psql_error(no function name specified\n);
+ status = PSQL_CMD_ERROR;
+ }
+ else if (!lookup_function_oid(pset.db, func, foid))
+ {
+ psql_error(PQerrorMessage(pset.db));
+ status = PSQL_CMD_ERROR;
+ }
+ else {
+ termPQExpBuffer(query_buf);
+ if (foid)
+ {
+ char *s = create_or_replace_function_text(pset.db, foid);
+ if (s)
+ {
+ appendPQExpBufferStr(query_buf, s);
+ free(s);
+ }
+ else
+ status = PSQL_CMD_ERROR;
+ }
+ else
+ {
+ printfPQExpBuffer(query_buf,
+ CREATE FUNCTION %s%s RETURNS ... AS $$\n
+ ...\n
+ $$ LANGUAGE '...'\n,
+ func, strchr(func,'(') ? : (...) );
+ }
+ }
+
+ if (status != PSQL_CMD_ERROR)
+ {
+ bool edited = false;
+ if (!do_edit(0, query_buf, edited))
+ {
+ status = PSQL_CMD_ERROR;
+ }
+ else if (!edited)
+ {
+ printf(No changes\n);
+ }
+ else
+ {
+ status = PSQL_CMD_SEND;
+ }
+ free(func);
+ }
+ }
+
/* \echo and \qecho */
else if (strcmp(cmd, echo) == 0 || strcmp(cmd, qecho) == 0)
{
***
*** 1410,1416 editFile(const char *fname)
/* call this one */
static bool
! do_edit(const char *filename_arg, PQExpBuffer query_buf)
{
char fnametmp[MAXPGPATH];
FILE *stream = NULL;
--- 1477,1483
/* call this one */
static bool
! do_edit(const char *filename_arg, PQExpBuffer query_buf, bool *edited)
{
char fnametmp[MAXPGPATH];
FILE *stream = NULL;
***
*** 1532,1537 do_edit(const char *filename_arg, PQExpBuffer query_buf)
--- 1599,1608
psql_error(%s: %s\n, fname, strerror(errno));
error = true;
}
+ else if (edited)
+ {
+ *edited = true;
+ }
fclose(stream);
}
*** /dev/null
--- b/src/bin/psql/dumpfunc.c
***
*** 0
--- 1,496
+ #include dumpfunc.h
+
+ #include libpq-fe.h
+ #include pqexpbuffer.h
+ #include dumputils.h
+ #include common.h
+ #include catalog/pg_proc.h
+
+ #define atooid(x) ((Oid) strtoul((x), NULL, 10))
+
+ /*
+ * This function takes a function description, e.g. x or x(int), and
+ * issues a query on the given connection to retrieve the function's oid
+ * using a cast to regproc or regprocedure (as appropriate). The
Re: [HACKERS] [PATCH] \ef function in psql
At 2008-07-15 10:33:02 -0400, [EMAIL PROTECTED] wrote: I doubt we'd consider accepting a patch done this way. Yes, it's much too ugly to live. I was posting it only for the record, I should have made that clear. -- ams -- 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] Fwd: Proposal - UUID data type
At 2008-07-15 08:34:01 -0700, [EMAIL PROTECTED] wrote: An answer of Jerry Stuckle: Please stop cross-posting messages from this list to whatever MySQL list you're on. It's a boring, pointless waste of time at best, and at worst will get you written off as a troll in both places pretty soon. -- ams -- 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] [PATCH] \ef function in psql
At 2008-07-15 20:28:39 +0530, [EMAIL PROTECTED] wrote: I doubt we'd consider accepting a patch done this way. Yes, it's much too ugly to live. Though I must say it would have been even MORE horrible to copy all this code into the backend to make pg_get_functiondef(), notwithstanding the extra utility of a generally-callable function. But what I'm wondering, since Gavin said he once had a working version of this patch (i.e. \ef) which he somehow lost, is how he approached the problem at the time. Gavin? Do you remember? Was it horrible? -- ams -- 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] [PATCH] \ef function in psql
At 2008-07-17 18:28:19 -0400, [EMAIL PROTECTED] wrote: It wouldn't take a whole lot to convince me that a pg_get_functiondef would be useful, although I don't foresee either of those applications wanting to use it because of their backward-compatibility constraints. If the code lives in psql (as with my patch), then it has some chance of working with older servers, but if you're happy with pg_get_functiondef, then I'm happy enough to use it to get \ef working. I agree that pg_dump wouldn't want to use it, of course, but I guess it doesn't matter very much if \ef doesn't work on older servers. What would the function return? CREATE OR REPLACE FUNCTION ...? Would that be good enough for everyone who might want to call it? (BTW, psql from 8.3 is already somewhat broken with 8.1: archiveopteryx= \d access_keys ERROR: column i.indisvalid does not exist And 8.2 as well: archiveopteryx= \d access_keys ERROR: column t.tgconstraint does not exist LINE 3: WHERE t.tgrelid = '16847' AND t.tgconstraint = 0 ^ Oh, I see they've both been fixed in CVS. Sorry for the noise.) -- ams -- 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] [PATCH] \ef function in psql
At 2008-07-23 10:50:03 -0400, [EMAIL PROTECTED] wrote: What would the function return? CREATE OR REPLACE FUNCTION ...? I think I'd go with CREATE FUNCTION for simplicity. OK, I have a mostly working pg_get_functiondef now, and some questions about the remaining pieces: 1. Why is prorows a float4? Should I print it that way, i.e. %f? 2. Can I print the contents of proconfig as just SET %s? It seems to work for the variables I've tried (e.g. DateStyle=iso), but I wonder if they'll always be quoted correctly (i.e., if the split on '=' thing pg_dump does is necessary for an 8.4 function). 3. Is there a function I can use from ruleutils.c to do dollar quoting of prosrc/probin? If not, and I have to write one, where should it live? 4. What exactly is probin? Do I need to worry about it at all? Thanks. -- ams -- 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] [PATCH] \ef function in psql
At 2008-07-29 15:42:27 +0530, [EMAIL PROTECTED] wrote:
OK, I have a mostly working pg_get_functiondef now, and some
questions about the remaining pieces:
While I look for answers to those questions, here's the patch as it
stands now, in case anyone feels like reading through it.
-- ams
diff --git a/src/include/utils/builtins.h b/src/include/utils/builtins.h
index 1ba20b0..ccf0d68 100644
--- a/src/include/utils/builtins.h
+++ b/src/include/utils/builtins.h
@@ -551,6 +551,7 @@ extern Datum pg_get_expr(PG_FUNCTION_ARGS);
extern Datum pg_get_expr_ext(PG_FUNCTION_ARGS);
extern Datum pg_get_userbyid(PG_FUNCTION_ARGS);
extern Datum pg_get_serial_sequence(PG_FUNCTION_ARGS);
+extern Datum pg_get_functiondef(PG_FUNCTION_ARGS);
extern Datum pg_get_function_arguments(PG_FUNCTION_ARGS);
extern Datum pg_get_function_result(PG_FUNCTION_ARGS);
extern char *deparse_expression(Node *expr, List *dpcontext,
diff --git a/src/backend/utils/adt/ruleutils.c b/src/backend/utils/adt/ruleutils.c
index 0d28310..dbfeff5 100644
--- a/src/backend/utils/adt/ruleutils.c
+++ b/src/backend/utils/adt/ruleutils.c
@@ -137,6 +137,7 @@ static char *pg_get_expr_worker(text *expr, Oid relid, char *relname,
int prettyFlags);
static int print_function_arguments(StringInfo buf, HeapTuple proctup,
bool print_table_args);
+static void print_function_rettype(StringInfo buf, HeapTuple proctup);
static void make_ruledef(StringInfo buf, HeapTuple ruletup, TupleDesc rulettc,
int prettyFlags);
static void make_viewdef(StringInfo buf, HeapTuple ruletup, TupleDesc rulettc,
@@ -1398,6 +1399,129 @@ pg_get_serial_sequence(PG_FUNCTION_ARGS)
/*
+ * pg_get_functiondef
+ * Returns the CREATE FUNCTION ... statement for a function.
+ */
+Datum
+pg_get_functiondef(PG_FUNCTION_ARGS)
+{
+ Oid funcid = PG_GETARG_OID(0);
+ StringInfoData buf;
+ HeapTuple proctup;
+ HeapTuple langtup;
+ Form_pg_proc proc;
+ Form_pg_language lang;
+ bool isnull;
+ Datum tmp;
+ const char *prosrc;
+ const char *name;
+ const char *nsp;
+ float4 cost;
+ int n;
+
+ initStringInfo(buf);
+
+ proctup = SearchSysCache(PROCOID, ObjectIdGetDatum(funcid), 0, 0, 0);
+ if (!HeapTupleIsValid(proctup))
+ elog(ERROR, cache lookup failed for function %u, funcid);
+ proc = (Form_pg_proc) GETSTRUCT(proctup);
+
+ langtup = SearchSysCache(LANGOID, ObjectIdGetDatum(proc-prolang), 0, 0, 0);
+ if (!HeapTupleIsValid(langtup))
+ elog(ERROR, cache lookup failed for language %u, proc-prolang);
+ lang = (Form_pg_language) GETSTRUCT(langtup);
+
+ name = NameStr(proc-proname);
+ nsp = get_namespace_name(proc-pronamespace);
+ appendStringInfo(buf, CREATE FUNCTION %s(,
+ quote_qualified_identifier(nsp, name));
+ (void) print_function_arguments(buf, proctup, false);
+ appendStringInfoString(buf, )\n RETURNS );
+ print_function_rettype(buf, proctup);
+ appendStringInfo(buf, \n LANGUAGE '%s'\n, NameStr(lang-lanname));
+
+ n = 1;
+
+ switch (proc-provolatile) {
+ case PROVOLATILE_IMMUTABLE:
+ appendStringInfoString(buf, IMMUTABLE);
+ break;
+ case PROVOLATILE_STABLE:
+ appendStringInfoString(buf, STABLE);
+ break;
+ case PROVOLATILE_VOLATILE:
+ default:
+ n--;
+ break;
+ }
+
+ if (proc-proisstrict)
+ {
+ n++;
+ appendStringInfoString(buf, STRICT);
+ }
+
+ if (proc-prosecdef)
+ {
+ n++;
+ appendStringInfoString(buf, SECURITY DEFINER);
+ }
+
+ cost = 100;
+ if (proc-prolang == INTERNALlanguageId ||
+ proc-prolang == ClanguageId)
+ cost = 1;
+
+ if (proc-procost != cost)
+ {
+ n++;
+ appendStringInfo(buf, COST %f, proc-procost);
+ }
+
+ if (proc-prorows != 0 proc-prorows != 1000)
+ {
+ n++;
+ appendStringInfo(buf, ROWS %f, proc-prorows);
+ }
+
+ if (n != 0)
+ appendStringInfoString(buf, \n);
+
+ tmp = SysCacheGetAttr(PROCOID, proctup, Anum_pg_proc_proconfig, isnull);
+ if (!isnull)
+ {
+ int i;
+ ArrayType *a = DatumGetArrayTypeP(tmp);
+
+ for (i = 1; i = ARR_DIMS(a)[0]; i++)
+ {
+ Datum d;
+ bool isnull;
+
+ d = array_ref(a, 1, i, -1, -1, false, 'i', isnull);
+ if (!isnull)
+ {
+const char *s = TextDatumGetCString(d);
+appendStringInfo(buf, SET %s\n, s);
+ }
+ }
+ }
+
+ tmp = SysCacheGetAttr(PROCOID, proctup, Anum_pg_proc_prosrc, isnull);
+ if (isnull)
+ elog(ERROR, null prosrc);
+ prosrc = TextDatumGetCString(tmp);
+
+ appendStringInfo(buf, AS $$\n%s\n$$;, prosrc);
+
+ ReleaseSysCache(langtup);
+ ReleaseSysCache(proctup);
+
+ PG_RETURN_TEXT_P(string_to_text(buf.data));
+}
+
+
+/*
* pg_get_function_arguments
* Get a nicely-formatted list of arguments for a function.
* This is everything that would go between the parentheses in
@@ -1436,8 +1560,6 @@ pg_get_function_result(PG_FUNCTION_ARGS)
Oid funcid = PG_GETARG_OID(0);
StringInfoData buf;
HeapTuple proctup;
- Form_pg_proc procform;
- int ntabargs = 0;
initStringInfo(buf);
@@ -1446,32 +1568,46 @@ pg_get_function_result(PG_FUNCTION_ARGS)
0, 0, 0);
if (!HeapTupleIsValid(proctup))
elog(ERROR, cache lookup failed for function %u, funcid);
Re: [HACKERS] [PATCH] \ef function in psql
I have attached two patches:
- funcdef.diff implements pg_get_functiondef()
- edit.diff implements \ef function in psql based on (1).
Comments appreciated.
-- ams
diff --git a/src/include/utils/builtins.h b/src/include/utils/builtins.h
index 1ba20b0..ccf0d68 100644
--- a/src/include/utils/builtins.h
+++ b/src/include/utils/builtins.h
@@ -551,6 +551,7 @@ extern Datum pg_get_expr(PG_FUNCTION_ARGS);
extern Datum pg_get_expr_ext(PG_FUNCTION_ARGS);
extern Datum pg_get_userbyid(PG_FUNCTION_ARGS);
extern Datum pg_get_serial_sequence(PG_FUNCTION_ARGS);
+extern Datum pg_get_functiondef(PG_FUNCTION_ARGS);
extern Datum pg_get_function_arguments(PG_FUNCTION_ARGS);
extern Datum pg_get_function_result(PG_FUNCTION_ARGS);
extern char *deparse_expression(Node *expr, List *dpcontext,
diff --git a/src/backend/utils/adt/ruleutils.c b/src/backend/utils/adt/ruleutils.c
index 0d28310..71e601a 100644
--- a/src/backend/utils/adt/ruleutils.c
+++ b/src/backend/utils/adt/ruleutils.c
@@ -137,6 +137,7 @@ static char *pg_get_expr_worker(text *expr, Oid relid, char *relname,
int prettyFlags);
static int print_function_arguments(StringInfo buf, HeapTuple proctup,
bool print_table_args);
+static void print_function_rettype(StringInfo buf, HeapTuple proctup);
static void make_ruledef(StringInfo buf, HeapTuple ruletup, TupleDesc rulettc,
int prettyFlags);
static void make_viewdef(StringInfo buf, HeapTuple ruletup, TupleDesc rulettc,
@@ -1398,6 +1399,137 @@ pg_get_serial_sequence(PG_FUNCTION_ARGS)
/*
+ * pg_get_functiondef
+ * Returns the CREATE OR REPLACE FUNCTION ... statement for the
+ * specified function.
+ */
+Datum
+pg_get_functiondef(PG_FUNCTION_ARGS)
+{
+ Oid funcid = PG_GETARG_OID(0);
+ StringInfoData buf;
+ StringInfoData dq;
+ HeapTuple proctup;
+ HeapTuple langtup;
+ Form_pg_proc proc;
+ Form_pg_language lang;
+ bool isnull;
+ Datum tmp;
+ const char *prosrc;
+ const char *name;
+ const char *nsp;
+ float4 cost;
+ int n;
+
+ initStringInfo(buf);
+
+ proctup = SearchSysCache(PROCOID, ObjectIdGetDatum(funcid), 0, 0, 0);
+ if (!HeapTupleIsValid(proctup))
+ elog(ERROR, cache lookup failed for function %u, funcid);
+ proc = (Form_pg_proc) GETSTRUCT(proctup);
+
+ langtup = SearchSysCache(LANGOID, ObjectIdGetDatum(proc-prolang), 0, 0, 0);
+ if (!HeapTupleIsValid(langtup))
+ elog(ERROR, cache lookup failed for language %u, proc-prolang);
+ lang = (Form_pg_language) GETSTRUCT(langtup);
+
+ name = NameStr(proc-proname);
+ nsp = get_namespace_name(proc-pronamespace);
+ appendStringInfo(buf, CREATE OR REPLACE FUNCTION %s(,
+ quote_qualified_identifier(nsp, name));
+ (void) print_function_arguments(buf, proctup, false);
+ appendStringInfoString(buf, )\n RETURNS );
+ print_function_rettype(buf, proctup);
+ appendStringInfo(buf, \n LANGUAGE '%s'\n, NameStr(lang-lanname));
+
+ n = 1;
+
+ switch (proc-provolatile) {
+ case PROVOLATILE_IMMUTABLE:
+ appendStringInfoString(buf, IMMUTABLE);
+ break;
+ case PROVOLATILE_STABLE:
+ appendStringInfoString(buf, STABLE);
+ break;
+ case PROVOLATILE_VOLATILE:
+ default:
+ n--;
+ break;
+ }
+
+ if (proc-proisstrict)
+ {
+ n++;
+ appendStringInfoString(buf, STRICT);
+ }
+
+ if (proc-prosecdef)
+ {
+ n++;
+ appendStringInfoString(buf, SECURITY DEFINER);
+ }
+
+ cost = 100;
+ if (proc-prolang == INTERNALlanguageId ||
+ proc-prolang == ClanguageId)
+ cost = 1;
+
+ if (proc-procost != cost)
+ {
+ n++;
+ appendStringInfo(buf, COST %.0f, proc-procost);
+ }
+
+ if (proc-prorows != 0 proc-prorows != 1000)
+ {
+ n++;
+ appendStringInfo(buf, ROWS %.0f, proc-prorows);
+ }
+
+ if (n != 0)
+ appendStringInfoString(buf, \n);
+
+ tmp = SysCacheGetAttr(PROCOID, proctup, Anum_pg_proc_proconfig, isnull);
+ if (!isnull)
+ {
+ int i;
+ ArrayType *a = DatumGetArrayTypeP(tmp);
+
+ for (i = 1; i = ARR_DIMS(a)[0]; i++)
+ {
+ Datum d;
+ bool isnull;
+
+ d = array_ref(a, 1, i, -1, -1, false, 'i', isnull);
+ if (!isnull)
+ {
+const char *s = TextDatumGetCString(d);
+appendStringInfo(buf, SET %s\n, s);
+ }
+ }
+ }
+
+ tmp = SysCacheGetAttr(PROCOID, proctup, Anum_pg_proc_prosrc, isnull);
+ if (isnull)
+ elog(ERROR, null prosrc);
+ prosrc = TextDatumGetCString(tmp);
+
+ initStringInfo(dq);
+ appendStringInfoString(dq, $);
+ while (strstr(prosrc, dq.data) != NULL)
+ appendStringInfoString(dq, x);
+ appendStringInfoString(dq, $);
+
+ appendStringInfo(buf, AS %s\n%s\n%s;, dq.data, prosrc, dq.data);
+
+ ReleaseSysCache(langtup);
+ ReleaseSysCache(proctup);
+
+ PG_RETURN_TEXT_P(string_to_text(buf.data));
+}
+
+
+/*
* pg_get_function_arguments
* Get a nicely-formatted list of arguments for a function.
* This is everything that would go between the parentheses in
@@ -1436,8 +1568,6 @@ pg_get_function_result(PG_FUNCTION_ARGS)
Oid funcid = PG_GETARG_OID(0);
StringInfoData buf;
HeapTuple proctup;
- Form_pg_proc procform;
- int ntabargs = 0;
initStringInfo(buf);
@@ -1446,32 +1576,46 @@
[HACKERS] [PATCH] allow has_table_privilege(..., 'usage') on sequences
I just noticed, to my dismay, that has_table_privilege() does not allow me to check for usage privileges on sequences. I suspect this may have been an oversight. If so, the attached patch fixes it for me. -- ams *** a/src/backend/utils/adt/acl.c --- b/src/backend/utils/adt/acl.c *** *** 1558,1563 convert_table_priv_string(text *priv_type_text) --- 1558,1568 if (pg_strcasecmp(priv_type, TRIGGER WITH GRANT OPTION) == 0) return ACL_GRANT_OPTION_FOR(ACL_TRIGGER); + if (pg_strcasecmp(priv_type, USAGE) == 0) + return ACL_USAGE; + if (pg_strcasecmp(priv_type, USAGE WITH GRANT OPTION) == 0) + return ACL_GRANT_OPTION_FOR(ACL_USAGE); + if (pg_strcasecmp(priv_type, RULE) == 0) return 0;/* ignore old RULE privileges */ if (pg_strcasecmp(priv_type, RULE WITH GRANT OPTION) == 0) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] which statements need bind/describe messages?
My client library sends Parse/Bind/Describe/Execute/Sync for each query, unless it's using a previously-prepared statement, in which case it can omit the Parse message. For which statements can I also avoid sending Bind and Describe? As far as I can tell, I can just send Parse/Execute/Sync for any utility statements (i.e. those that are handled by ProcessUtility()) that do not UtilityReturnsTuples(). Furthermore, I can omit Describe for ordinary (i.e. without returning) INSERT and DELETE and UPDATE. Right? I could also omit Bind for any queries that do not have bind parameters, except that I always want binary-format results; so I suppose I always have to send Bind for non-utility statements. Comments appreciated. -- ams -- 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] which statements need bind/describe messages?
At 2008-08-09 15:57:42 +0530, [EMAIL PROTECTED] wrote: For which statements can I also avoid sending Bind and Describe? I can't avoid sending Bind because Execute needs a portal and Bind is what creates one. Let's pretend I didn't mention Bind at all. Sorry. -- ams -- 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] September Commit Fest coming soon!
At 2008-08-28 20:09:21 +0900, [EMAIL PROTECTED] wrote: For the git hosted projects, should we send in the latest patch file to this list? Yes, please do that. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] sqlstate 22P06 is a warning in an error's clothing
The server logs WARNING: nonstandard use of \\ in a string literal at character 44, but the message comes with sqlstate code 22P06, which is in an error class (Data exception). So my application thinks it's an error, and is unhappy. Since the sqlstate code is the only useful machine-readable field in the error message, it is rather unfortunate for it to not reflect the actual failure status. Of course, I can special-case code 22P06 in my code and treat it as a warning (which is what I'll have to do anyway, for 8.2 compatibility), but I think: - the warning should be assigned a different code in the 01 class. - The 22P06 code should be retired, i.e. not reassigned to a real error in future (because then any bug workaround similar to mine would break). Thoughts? -- ams ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] libpq, PQexecPrepared, data size sent to FE vs. FETCH_COUNT
At 2010-05-25 07:35:34 -0400, alex-goncha...@comcast.net wrote: | Where does the result set (GBs of data) reside after I call | PQexecPrepared? On BE, I hope? Unless you explicitly declare and fetch from an SQL-level cursor, your many GBs of data are going to be transmitted to libpq, which will eat lots of memory. (The wire protocol does have something like cursors, but libpq does not use them, it retrieves the entire result set.) -- ams -- 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] functional call named notation clashes with SQL feature
At 2010-05-27 08:50:18 +0200, pavel.steh...@gmail.com wrote: I don't see any advantage of FOR. We can change ir to support new standard or don't change it. Adopting FOR would mean we don't use AS in a way that conflicts with the standard. That's its only advantage. But I agree with you, I don't think it's worth inventing a new non-standard wart for this case. I don't really like the idea of getting rid of = as an operator either; I'm torn between staying true to the standard and politely looking the other way as Tom suggested we might end up doing. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
