Re: [HACKERS] [GENERAL] pg_filedump binary for CentOS
On Thu, Oct 14, 2010 at 05:53:30PM -0400, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Should we consider moving pg_filedump into our /contrib? Can't: it's GPL. Depends on whether we can get it relicensed. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] [JDBC] Support for JDBC setQueryTimeout, et al.
On Tue, 12 Oct 2010 20:03:29 +0200, Magnus Hagander mag...@hagander.net wrote: On Tue, Oct 12, 2010 at 17:55, David Fetter da...@fetter.org wrote: On Tue, Oct 12, 2010 at 10:37:00AM -0500, Kevin Grittner wrote: David Fetter da...@fetter.org wrote: Is there something incomplete about the ones I sent, and if so, what? Well, I'm still curious why it was necessary to modify the server side to implement an interface feature for which everything needed seems to be present on the client side. Not everything is. Let's imagine you have a connection pooler with two clients, A and B. A calls setQueryTimeout, then starts a query, which terminates in time, but dies before handling it. B connects to the pool, gets A's connection, and finds a statement_timeout that's not the default, even though only A's single query was supposed to have that statement_timeout. This is not a situation that can be resolved without being able to set a timer *on the server side*. Sure it can. The connection pooler just needs to issue a RESET ALL statement when it hands over a connection from one client to another. Isn't that what for example pgbouncer does - at least when configured per instructions? Also, doesn't this affect *all* settings, not just timeout, if it doesn't? Imagine client A executing a SET datestyle for example. AFAICS, any connection pooler that *doesn't* issue a reset between handing this around is broken, isn't it? If I'm right you would like to say, that when taking connection from pool REST ALL should be invoked. But... connection pooler will not send RESET ALL in some situations, because JDBC driver can have no notify about switching client. In EE platforms (e. g. Glassfish), server sometimes creates it's own pool and in certain configuration, when you close Connection, server will never pass close to PooledConection, nor physical connection. This due to fact, that GF and others adds functionality for statements pooling (if server will call close on pooled conn, then reusing cached statement will cause error - in fact this problem occurs with Hibernate, C3po, XA, and GFv3). To summarize, you should never believe that RESET ALL will be called, nor any other behavior when switching clients. Am I right? -- Radosław Smogura http://www.softperience.eu -- 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] knngist plans
Recently I worked a lot with gist and read about knngist. I have spotted weaknesses in docs. So I would be happy to help if you tell me how. On Fri, Oct 15, 2010 at 5:57 AM, Robert Haas robertmh...@gmail.com wrote: On Wed, Oct 13, 2010 at 7:07 PM, Marios Vodas mvo...@gmail.com wrote: I would like to ask in which future version of postgresql knngist is planned to be included. Is there any possibility to be included in 9.1? There's a possibility, but I think the patch still needs some more work. One thing that would help is if someone felt motivated to write some documentation. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch
--On 14. Oktober 2010 20:47:27 +0100 Dean Rasheed dean.a.rash...@gmail.com wrote: OK, here it is. I've not cured this compiler warning (in fact I'm not sure what it's complaining about, because the variable *is* used): tablecmds.c: In function 'ATExecSetNotNull': tablecmds.c:4747: warning: unused variable 'is_new_constraint' Just a left over from earlier coding, i have removed this in my patch version. I have adapted your fixes and would like to propose that we are proceeding with my version, if that's okay for you? -- Thanks Bernd -- 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] Re: starting to review the Extend NOT NULL representation to pg_constraint patch
On 15 October 2010 08:32, Bernd Helmle maili...@oopsware.de wrote: --On 14. Oktober 2010 20:47:27 +0100 Dean Rasheed dean.a.rash...@gmail.com wrote: OK, here it is. I've not cured this compiler warning (in fact I'm not sure what it's complaining about, because the variable *is* used): tablecmds.c: In function 'ATExecSetNotNull': tablecmds.c:4747: warning: unused variable 'is_new_constraint' Just a left over from earlier coding, i have removed this in my patch version. I have adapted your fixes and would like to propose that we are proceeding with my version, if that's okay for you? Ah, I see it (I was looking at the wrong copy of that variable). Yes, let's proceed with your version. If these were the only problems with this patch, given that they required only trivial changes to initialise variables to NIL/false, perhaps it was premature to mark it as returned with feedback. Thoughts? Regards, Dean -- 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] [GENERAL] pg_filedump binary for CentOS
On Thu, Oct 14, 2010 at 2:53 PM, Tom Lane t...@sss.pgh.pa.us wrote: Bruce Momjian br...@momjian.us writes: Should we consider moving pg_filedump into our /contrib? Can't: it's GPL. I don't particularly see a problem with having GPL'd contrib modules. It would mean any users hoping to redistribute the package couldn't include those modules except under the GPL. But most repackagers don't include the contrib modules anyways. Even ones that do and want to include those modules would only have to include the source to that module. I can see not wanting to let that camel's nose in for fear of having packagers always be uncertain about the status of each contrib module though. -- greg -- 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] [JDBC] Support for JDBC setQueryTimeout, et al.
On Fri, Oct 15, 2010 at 08:56, Radosław Smogura rsmog...@softperience.eu wrote: On Tue, 12 Oct 2010 20:03:29 +0200, Magnus Hagander mag...@hagander.net wrote: On Tue, Oct 12, 2010 at 17:55, David Fetter da...@fetter.org wrote: On Tue, Oct 12, 2010 at 10:37:00AM -0500, Kevin Grittner wrote: David Fetter da...@fetter.org wrote: Is there something incomplete about the ones I sent, and if so, what? Well, I'm still curious why it was necessary to modify the server side to implement an interface feature for which everything needed seems to be present on the client side. Not everything is. Let's imagine you have a connection pooler with two clients, A and B. A calls setQueryTimeout, then starts a query, which terminates in time, but dies before handling it. B connects to the pool, gets A's connection, and finds a statement_timeout that's not the default, even though only A's single query was supposed to have that statement_timeout. This is not a situation that can be resolved without being able to set a timer *on the server side*. Sure it can. The connection pooler just needs to issue a RESET ALL statement when it hands over a connection from one client to another. Isn't that what for example pgbouncer does - at least when configured per instructions? Also, doesn't this affect *all* settings, not just timeout, if it doesn't? Imagine client A executing a SET datestyle for example. AFAICS, any connection pooler that *doesn't* issue a reset between handing this around is broken, isn't it? If I'm right you would like to say, that when taking connection from pool REST ALL should be invoked. Yes. Unless the client app (or pooler) *knows* that nothing that executes modifies any settings or session state. But... connection pooler will not send RESET ALL in some situations, because JDBC driver can have no notify about switching client. In EE platforms (e. g. Glassfish), server sometimes creates it's own pool and in certain configuration, when you close Connection, server will never pass close to PooledConection, nor physical connection. This due to fact, that GF and others adds functionality for statements pooling (if server will call close on pooled conn, then reusing cached statement will cause error - in fact this problem occurs with Hibernate, C3po, XA, and GFv3). To me, that sounds like a bug in the connection pooler. It is only safe under quite limited circumstances. To summarize, you should never believe that RESET ALL will be called, nor any other behavior when switching clients. In that cas, you ct your client from calling any SET commands etc, and it should be documented as a major limitation of the connection pooling software. I don't see any other way to make it safe - others may have one of course :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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] Extensions, this time with a patch
Alvaro Herrera alvhe...@commandprompt.com writes:
Maybe it would be worthwhile to split the parts that parse a file and
execute from a file, and submit separately. It is obviously
self-contained and serves a useful purpose on its own. It also forces
you to think harder about renaming the parse function :-)
So, you will find two new branches for those purposes at the repository,
named cfparser and pg_execute_from_file:
http://git.postgresql.org/gitweb?p=postgresql-extension.git;a=summary
Please find attached the patches extracted from those branches. Note
that currently, the main extension branch still contains the
modifications, I intend to merge/rebase that against the master after
the commits.
I've also merged the master repository into my feature branch, and git
just did it all by itself. I like it when the tools are helping! :)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
*** a/src/backend/access/transam/xlog.c
--- b/src/backend/access/transam/xlog.c
***
*** 55,60
--- 55,61
#include utils/guc.h
#include utils/ps_status.h
#include utils/relmapper.h
+ #include utils/cfparser.h
#include pg_trace.h
***
*** 5018,5117 str_time(pg_time_t tnow)
}
/*
- * Parse one line from recovery.conf. 'cmdline' is the raw line from the
- * file. If the line is parsed successfully, returns true, false indicates
- * syntax error. On success, *key_p and *value_p are set to the parameter
- * name and value on the line, respectively. If the line is an empty line,
- * consisting entirely of whitespace and comments, function returns true
- * and *keyp_p and *value_p are set to NULL.
- *
- * The pointers returned in *key_p and *value_p point to an internal buffer
- * that is valid only until the next call of parseRecoveryCommandFile().
- */
- static bool
- parseRecoveryCommandFileLine(char *cmdline, char **key_p, char **value_p)
- {
- char *ptr;
- char *bufp;
- char *key;
- char *value;
- static char *buf = NULL;
-
- *key_p = *value_p = NULL;
-
- /*
- * Allocate the buffer on first use. It's used to hold both the parameter
- * name and value.
- */
- if (buf == NULL)
- buf = malloc(MAXPGPATH + 1);
- bufp = buf;
-
- /* Skip any whitespace at the beginning of line */
- for (ptr = cmdline; *ptr; ptr++)
- {
- if (!isspace((unsigned char) *ptr))
- break;
- }
- /* Ignore empty lines */
- if (*ptr == '\0' || *ptr == '#')
- return true;
-
- /* Read the parameter name */
- key = bufp;
- while (*ptr !isspace((unsigned char) *ptr)
- *ptr != '=' *ptr != '\'')
- *(bufp++) = *(ptr++);
- *(bufp++) = '\0';
-
- /* Skip to the beginning quote of the parameter value */
- ptr = strchr(ptr, '\'');
- if (!ptr)
- return false;
- ptr++;
-
- /* Read the parameter value to *bufp. Collapse any '' escapes as we go. */
- value = bufp;
- for (;;)
- {
- if (*ptr == '\'')
- {
- ptr++;
- if (*ptr == '\'')
- *(bufp++) = '\'';
- else
- {
- /* end of parameter */
- *bufp = '\0';
- break;
- }
- }
- else if (*ptr == '\0')
- return false; /* unterminated quoted string */
- else
- *(bufp++) = *ptr;
-
- ptr++;
- }
- *(bufp++) = '\0';
-
- /* Check that there's no garbage after the value */
- while (*ptr)
- {
- if (*ptr == '#')
- break;
- if (!isspace((unsigned char) *ptr))
- return false;
- ptr++;
- }
-
- /* Success! */
- *key_p = key;
- *value_p = value;
- return true;
- }
-
- /*
* See if there is a recovery command file (recovery.conf), and if so
* read in parameters for archive recovery and XLOG streaming.
*
--- 5019,5024
***
*** 5147,5153 readRecoveryCommandFile(void)
char *tok1;
char *tok2;
! if (!parseRecoveryCommandFileLine(cmdline, tok1, tok2))
{
syntaxError = true;
break;
--- 5054,5060
char *tok1;
char *tok2;
! if (!cfParseOneLine(cmdline, tok1, tok2))
{
syntaxError = true;
break;
*** a/src/backend/utils/misc/Makefile
--- b/src/backend/utils/misc/Makefile
***
*** 15,21 include $(top_builddir)/src/Makefile.global
override CPPFLAGS := -I. -I$(srcdir) $(CPPFLAGS)
OBJS = guc.o help_config.o pg_rusage.o ps_status.o superuser.o tzparser.o \
!rbtree.o
# This location might depend on the installation directories. Therefore
# we can't subsitute it into pg_config.h.
--- 15,21
override CPPFLAGS := -I. -I$(srcdir) $(CPPFLAGS)
OBJS = guc.o help_config.o pg_rusage.o ps_status.o superuser.o tzparser.o \
!rbtree.o cfparser.o
# This location might depend on the installation directories. Therefore
# we can't subsitute it into pg_config.h.
*** /dev/null
--- b/src/backend/utils/misc/cfparser.c
***
*** 0
--- 1,112
+ /*-
+ *
+ * cfparser.c
+ *
Re: [HACKERS] [JDBC] Support for JDBC setQueryTimeout, et al.
On Fri, 15 Oct 2010 10:37:05 +0200, Magnus Hagander mag...@hagander.net wrote: But... connection pooler will not send RESET ALL in some situations, because JDBC driver can have no notify about switching client. In EE platforms (e. g. Glassfish), server sometimes creates it's own pool and in certain configuration, when you close Connection, server will never pass close to PooledConection, nor physical connection. This due to fact, that GF and others adds functionality for statements pooling (if server will call close on pooled conn, then reusing cached statement will cause error - in fact this problem occurs with Hibernate, C3po, XA, and GFv3). To me, that sounds like a bug in the connection pooler. It is only safe under quite limited circumstances. It's hard to say this is bug. The GF connection pooler is general pooler for all drivers, so it can't know anything about reseting, and if I have right JDBC4 doesn't support such notifications. It can't close logical connections, as if would close, cached statements will be invalideted too. But benefits of pooling statements are much more greater then RESET ALL, because you can take advance of precompiling prepared statements, increasing performance; it is comparable to using connection pool instead of starting physical connections. In ~2008, Sun published result of (spectest?) Glassfih v2 and PostgreSQL with special patches allowing statement caching (on JDBC driver side) - it was the fastest combination, biting all professional and highly paid software. Probably same wrapping can do JBoss, WAS, and others. in fact this problem occurs with Hibernate, C3po, XA, and GFv3). Hibernate, with C3P0 hacks and uses some private code, unwraps objects, etc... :(, so when private implementation changes we have BUM. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- -- Radosław Smogura http://www.softperience.eu -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [DOCS] [HACKERS] Docs for archive_cleanup_command are poor
On Thu, 2010-10-14 at 18:05 -0400, Tom Lane wrote: Brendan Jurd dire...@gmail.com writes: Agreed that there are no doc bugs. The reason I suggested a backpatch is that I'm concerned that a lot of people are going to be approaching the whole Standby topic for the first time with 9.0, so it would be nice to give those folks an accessible account of how archive_cleanup_command is meant to be used. Yeah, if this is a material improvement in the usefulness of the HS docs, I think including it into 9.0.x isn't a bad idea. Done. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- 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] string function - format function proposal
2010/10/15 Itagaki Takahiro itagaki.takah...@gmail.com: On Fri, Oct 15, 2010 at 12:59 PM, Pavel Stehule pavel.steh...@gmail.com wrote: then maybe %ls or %is - like literal string or ident string. Yeah, good idea! I don't think so merging sprintf and format can be good. Sprintf is too complex - so long years users don't know specification well and creating some like sprintf function can be messy for users. I like to see accurate sprintf function in contrib - and some else in core. I agree that full-spec sprintf is too complex, but precision and zero-full for numeric types are commonly used. I think someone will ask us Why don't have numeric formats though we have %s?. And the reply is - we have function to_char. I don't see any reason why we have to have two independent formatting systems. Pavel -- Itagaki Takahiro -- 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] string function - format function proposal
On Fri, Oct 15, 2010 at 8:20 PM, Pavel Stehule pavel.steh...@gmail.com wrote: And the reply is - we have function to_char. I don't see any reason why we have to have two independent formatting systems. The formats for literal and identifier can be replaced to quote_nullable() and quote_ident(), too. Features to write simple queries are constantly in demand. -- Itagaki Takahiro -- 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] knngist plans
On Fri, 15 Oct 2010, Marios Vodas wrote: Recently I worked a lot with gist and read about knngist. I have spotted weaknesses in docs. So I would be happy to help if you tell me how. We have some documentation already, Teodor will post soon. Marios, I'd happy to help in writing docs. Do you have some plans ? On Fri, Oct 15, 2010 at 5:57 AM, Robert Haas robertmh...@gmail.com wrote: On Wed, Oct 13, 2010 at 7:07 PM, Marios Vodas mvo...@gmail.com wrote: I would like to ask in which future version of postgresql knngist is planned to be included. Is there any possibility to be included in 9.1? There's a possibility, but I think the patch still needs some more work. One thing that would help is if someone felt motivated to write some documentation. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company Regards, Oleg _ Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru), Sternberg Astronomical Institute, Moscow University, Russia Internet: o...@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(495)939-16-83, +007(495)939-23-83 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Timeout and wait-forever in sync rep
Hi, As the result of the discussion, I think that we need the following two parameters for the case where the standby goes down. * replication_timeout This is the maximum time to wait for the ACK from the standby. If this timeout expires, the master closes the replication connection and disconnects the standby. This parameter is just used for the master to detect the standby crash or the network outage. We already have keepalive parameters for that purpose. But they cannot detect the disconnection in some cases. So replication_timeout needs to be introduced for sync rep. * allow_standalone_master This specifies whether we allow the master to process transactions alone when there is no connected and sync'd standby. If this is false, all the transactions on the master are blocked until sync'd standby has appeared. Of course, this happen not only when replication_timeout expires but also when we start the master alone at the initial setup, when the master detects the disconnection by using keepalive parameters, and when the standby is shut down normally. People who want 'wait-forever' will disable this parameter to reduce the risk of data loss. OTOH, if this is true, the absence of sync'd standby doesn't prevent the master from processing transactions alone. People who want high availability even though the risk of data loss increases will enable this parameter. The timeout doesn't oppose to 'wait-forever'. Even if you choose 'wait -forever' (i.e., you set allow_standalone_master to false), the master should detect the standby crash as soon as possible by using the timeout. For example, imagine that max_wal_senders is set to one and the master cannot detect the standby crash because of absence of the timeout. In this case, even if you start new standby, it will not be able to connect to the master since there is no free walsender slot. As the result, the master actually waits forever. Thought? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] security hook on table creation
KaiGai, * KaiGai Kohei (kai...@kaigai.gr.jp) wrote: However, it requires the plugin modules need to know everything; such as what is visible/invisible. It seems to me too closely- coupled interface. I agree with Robert on this one. We're not trying to design a wholly independent security module system for any project to pick up and use here. We're discussing hooks to go into PostgreSQL to support a PostgreSQL security module. In other words, I don't think we need to worry over if the PG-SELinux security module could be re-used for another project or is too PG specific. If it's *not* very PG specific then something is wrong. The issues we're talking about with regard to MVCC, visibility, etc, would all be applicable to any serious database anyway. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch
On Fri, Oct 15, 2010 at 4:06 AM, Dean Rasheed dean.a.rash...@gmail.com wrote: If these were the only problems with this patch, given that they required only trivial changes to initialise variables to NIL/false, perhaps it was premature to mark it as returned with feedback. Sure. Is someone available to do a detailed code review? Alvaro, were you planning to pick this one up? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Re: starting to review the Extend NOT NULL representation to pg_constraint patch
The new patch applies cleanly to head, there are no compile errors and all the make check tests pass (linux). Thanks Andrew On Thu, Oct 14, 2010 at 4:35 PM, Bernd Helmle maili...@oopsware.de wrote: --On 14. Oktober 2010 16:28:51 -0300 Alvaro Herrera alvhe...@commandprompt.com wrote: Looking in that function, there is a similar found variable that isn't being initialised (which my compiler didn't warn about). Initialising that to false, sems to fix the problem and all the regression tests then pass. Excellent. Please send an updated patch. Here is an updated version of the patch. It fixes the following issues Andrew discovered during his review cycle: * Fix compiler warnings and crash due to uninitialized variables (pretty much the fix Dean proposed) * Remove accidentally added pg_latch.c in my own git repos. I will do further cycles over Andrew's review report. -- Thanks Bernd -- 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] [GENERAL] pg_filedump binary for CentOS
On Fri, Oct 15, 2010 at 2:36 AM, Greg Stark gsst...@mit.edu wrote: On Thu, Oct 14, 2010 at 2:53 PM, Tom Lane t...@sss.pgh.pa.us wrote: Bruce Momjian br...@momjian.us writes: Should we consider moving pg_filedump into our /contrib? Can't: it's GPL. I don't particularly see a problem with having GPL'd contrib modules. It would mean any users hoping to redistribute the package couldn't include those modules except under the GPL. But most repackagers don't include the contrib modules anyways. Even ones that do and want to include those modules would only have to include the source to that module. I can see not wanting to let that camel's nose in for fear of having packagers always be uncertain about the status of each contrib module though. I think that's a bad idea for all kinds of reasons. For one thing, it seems that someone could easily end up copying some of that code into some other place. It would be *nice* to have this available as part of our regular distribution but I don't want to take any risk of GPL contamination. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] string function - format function proposal
On Fri, Oct 15, 2010 at 12:55 AM, Itagaki Takahiro itagaki.takah...@gmail.com wrote: On Fri, Oct 15, 2010 at 12:59 PM, Pavel Stehule pavel.steh...@gmail.com wrote: then maybe %ls or %is - like literal string or ident string. Yeah, good idea! -1 from me. What does this do except make it more long-winded? I don't think so merging sprintf and format can be good. Sprintf is too complex - so long years users don't know specification well and creating some like sprintf function can be messy for users. I like to see accurate sprintf function in contrib - and some else in core. I agree that full-spec sprintf is too complex, but precision and zero-full for numeric types are commonly used. I think someone will ask us Why don't have numeric formats though we have %s?. I think someone might also ask - why are you bothering to create this at all? The amount of work that has been put into this is, IMHO, far out of proportion to the value of the feature. As Pavel points out, we already have perfectly good mechanisms for converting our various data types to text. We do not need to invent new ones. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] [GENERAL] pg_filedump binary for CentOS
On 10/15/2010 7:24 AM, Robert Haas wrote: I think that's a bad idea for all kinds of reasons. For one thing, it seems that someone could easily end up copying some of that code into some other place. It would be *nice* to have this available as part of our regular distribution but I don't want to take any risk of GPL contamination. I think there's a tendency to assume that one license rules them all within a single package, tarball etc. Just wondering what was the motivation to GPL this code ? I mean, if I were to write a utility that was only useful for project X, I'd want to license my code with the same (or a compatible) license as X. I'd need a really good reason to use a different license. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] docs on contrib modules that can't pg_upgrade?
Howdy folks, Was wondering if there are any docs on which contrib modules don't work with pg_upgrade? I seem to remember discussion on this during the 9.0 cycle, but couldn't find it in the mail archive, and don't see anything in the wiki. What brings this up is I'm currently working on an 8.3 upgrade and it has pg_freespacemap which breaks things; I think easy enough to work-around in this case, but I am sure for other contribs, or for folks with a lot of machinery built on top of a contrib, that won't always be the case. If something like this doesn't exist, I'll start a wiki page on it, but thought I'd ask first. -- Robert Treat Play: http://www.xzilla.net Work: http://omniti.com/is/hiring -- 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] [GENERAL] pg_filedump binary for CentOS
On 10/15/2010 02:36 AM, Greg Stark wrote: On Thu, Oct 14, 2010 at 2:53 PM, Tom Lanet...@sss.pgh.pa.us wrote: Bruce Momjianbr...@momjian.us writes: Should we consider moving pg_filedump into our /contrib? Can't: it's GPL. I don't particularly see a problem with having GPL'd contrib modules. It would mean any users hoping to redistribute the package couldn't include those modules except under the GPL. But most repackagers don't include the contrib modules anyways. Even ones that do and want to include those modules would only have to include the source to that module. I can see not wanting to let that camel's nose in for fear of having packagers always be uncertain about the status of each contrib module though. Didn't we go through the exercise of removing modules that were GPLed a few years ago? Having a plethora of different licenses covering code in our repository seems like a recipe for major confusion, and I think is to be avoided. cheers andrew -- 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] [GENERAL] pg_filedump binary for CentOS
Robert Haas robertmh...@gmail.com writes: On Fri, Oct 15, 2010 at 2:36 AM, Greg Stark gsst...@mit.edu wrote: I don't particularly see a problem with having GPL'd contrib modules. I think that's a bad idea for all kinds of reasons. Yeah. From my viewpoint as a downstream packager, it creates a mess. We've spent a great amount of effort and cajolery over the years to make sure that the Postgres sources, including contrib, are uniformly licensed. We're not going to abandon that policy. I have no idea whether Red Hat could be persuaded to relicense pg_filedump. It might be worth asking though. regards, tom lane -- 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] WIP: extensible enums
On 10/15/2010 04:33 AM, Dean Rasheed wrote: I started looking at this last night, but ran out of time. I'll continue this evening / over the weekend. Here are my comments so far: Patch applies cleanly to current git master with no offsets. Compiles cleanly with no warnings. Regression tests pass. The regression tests look reasonable, but I'd like to see a test of \dT+. Also it could be made to exercise the comparison function more if the test query did an ORDER BY CAST(enumlabel as planets). The docs for ALTER TYPE have been updated. I found a few minor typos, and also a couple of other sections of the manual that needed updating. Attached is an updated version with these changes. Andrew, let me know if you're happy with these tweaks and I'll continue reviewing over the weekend. Thanks for the review. This looks good. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [HACKERS] XML schema validation
Hi Robert, I would like to contribute for community. Under licence used by PostgreSQL. So is (or was) there anybody with the same interest as me? Původní zpráva Od: Robert Haas robertmh...@gmail.com Předmět: Re: [HACKERS] XML schema validation Datum: 15.10.2010 05:02:56 On Thu, Oct 14, 2010 at 4:26 PM, Tomáš Pospíšil killt...@seznam.cz wrote: Hi hackers, I choose (for my master's thesis) support PostgresSQL XML schema validation. Is anybody there with suggestions? I had a look at current state and noted that there is commented out code for DTD. My plan is to use libxml2, that have in the last version better support for DTD, XSD and Relax NG (must be checked) and use as much as possible of SQL:2008. Is this something you're looking to have committed, or just a private project? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] [JDBC] Support for JDBC setQueryTimeout, et al.
* Radosław Smogura (rsmog...@softperience.eu) wrote: To me, that sounds like a bug in the connection pooler. It is only safe under quite limited circumstances. It's hard to say this is bug. The GF connection pooler is general pooler for all drivers, so it can't know anything about reseting, and if I have right JDBC4 doesn't support such notifications. It can't close logical connections, as if would close, cached statements will be invalideted too. If it can't figure out a way to issue a command in between handing around a connection to different clients then, yeah, I'd call it a bug that needs to be fixed. Maybe other systems don't need it, and it can be a no-op there, but the capability certainly needs to be there. But benefits of pooling statements are much more greater then RESET ALL, because you can take advance of precompiling prepared statements, increasing performance; it is comparable to using connection pool instead of starting physical connections. errr, I don't believe RESET ALL touches cache'd plans and whatnot (which is actually a problem I've run into in the past, because changing the search_path also doesn't invalidate plans, and neither does set role, so you end up with cache'd plans that try to hit things you don't have permissions to any more :( ). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [JDBC] Support for JDBC setQueryTimeout, et al.
=?UTF-8?Q?Rados=C5=82aw_Smogura?= rsmog...@softperience.eu writes: On Fri, 15 Oct 2010 10:37:05 +0200, Magnus Hagander mag...@hagander.net wrote: But... connection pooler will not send RESET ALL in some situations, To me, that sounds like a bug in the connection pooler. It is only safe under quite limited circumstances. It's hard to say this is bug. No it isn't. What you've described is a broken, unsafe, insecure pooler that could not under any circumstances be recommended for general purpose use. It might be okay if you trust all the clients to cooperate completely, and to not have any bugs that might cause them to release a connection while it's in a non-default state. regards, tom lane -- 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] Re: starting to review the Extend NOT NULL representation to pg_constraint patch
Robert Haas robertmh...@gmail.com writes: On Fri, Oct 15, 2010 at 4:06 AM, Dean Rasheed dean.a.rash...@gmail.com wrote: If these were the only problems with this patch, given that they required only trivial changes to initialise variables to NIL/false, perhaps it was premature to mark it as returned with feedback. Sure. Is someone available to do a detailed code review? Alvaro, were you planning to pick this one up? I had been planning to take this one once it got past initial review, since it was mostly my wish to start with. regards, tom lane -- 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] [GENERAL] pg_filedump binary for CentOS
David Boreham david_l...@boreham.org writes: Just wondering what was the motivation to GPL this code ? It was written at Red Hat and they have (or at least had at the time) a company policy of using GPL for any code written in-house. regards, tom lane -- 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] [JDBC] Support for JDBC setQueryTimeout, et al.
Stephen Frost sfr...@snowman.net writes: * RadosÅaw Smogura (rsmog...@softperience.eu) wrote: But benefits of pooling statements are much more greater then RESET ALL, because you can take advance of precompiling prepared statements, increasing performance; it is comparable to using connection pool instead of starting physical connections. errr, I don't believe RESET ALL touches cache'd plans and whatnot (which is actually a problem I've run into in the past, because changing the search_path also doesn't invalidate plans, and neither does set role, so you end up with cache'd plans that try to hit things you don't have permissions to any more :( ). Yeah, actually what you need is DISCARD ALL when reassigning a connection to another client. Anything less than that assumes the clients are cooperating closely, ie they *want* the same prepared statements etc. But even if you make that assumption, a pooler that isn't even capable of sending an ABORT between clients doesn't seem usable to me. For example, if a client loses its network connection mid-transaction, that failure will cascade to other clients if you don't have any ability to reset the database session before handing it to another client. regards, tom lane -- 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] Re: [HACKERS] XML schema validation
On 15/10/10 15:08, Tomáš Pospíšil wrote: Hi Robert, I would like to contribute for community. Under licence used by PostgreSQL. So is (or was) there anybody with the same interest as me? Yes, I've been looking at improving the XML support overall, or at least working to finish the implementation of the SQL 2008 XML specification. Currently I've been looking at implementing XQuery, however I have recently started to come to the conclusion that Schema validation should be implemented first as there is some overlap of functionality. What have you looked at? Do you have an outline design you could share on how you would go about adding schema validation? Regrads, -- Mike Fowler Registered Linux user: 379787 -- 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] First patch proposal
On 14/10/10 15:53, Alastair Turner wrote: It isn't a TODO item, or related to any previous thread I could find. It's certainly something I can see a use for. When I'm having a bad typing day I get annoyed that I find I've made a mistake after I've typed the password. To me this is a feature that will just make life a little more pleasant for command line junkies like me. Regards, -- Mike Fowler Registered Linux user: 379787 NB: Post attmpt two, yesterday's was never delievered to hackers so apologies if Alastair and Hitoshi have seen this message once already. -- 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] [JDBC] Support for JDBC setQueryTimeout, et al.
* Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost sfr...@snowman.net writes: errr, I don't believe RESET ALL touches cache'd plans and whatnot (which is actually a problem I've run into in the past, because changing the search_path also doesn't invalidate plans, and neither does set role, so you end up with cache'd plans that try to hit things you don't have permissions to any more :( ). Yeah, actually what you need is DISCARD ALL when reassigning a connection to another client. Anything less than that assumes the clients are cooperating closely, ie they *want* the same prepared statements etc. That assumption is certainly something I feel we should consider a valid and important use-case. I'd think a lot of the time your typical website is going to be using a dedicated pooler for connections and a dedicated database where having those queries cache'd would be good. I recall seeing a module that even set things up so you feed it all the queries that you're going to run and it plans them all out for you when you start up the pooler. Been meaning to look into it more, but.. The whole problem with search_path and role is very frustrating. We've taken to just hacking things to be dynamic SQL whenever it's role-specific, but that's a really poor solution. I wonder if it would be possible to have the function and prepare'd plan caches be key'd off of the search_path and role too..? So if you change one of those you end up having to re-plan it, but then that's also cached, etc.. But even if you make that assumption, a pooler that isn't even capable of sending an ABORT between clients doesn't seem usable to me. For example, if a client loses its network connection mid-transaction, that failure will cascade to other clients if you don't have any ability to reset the database session before handing it to another client. I agree, the pooler definitely needs to be able to handle those situations or you'll be running into some serious problems down the road. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] string function - format function proposal
Robert Haas robertmh...@gmail.com writes: On Fri, Oct 15, 2010 at 12:55 AM, Itagaki Takahiro itagaki.takah...@gmail.com wrote: I agree that full-spec sprintf is too complex, but precision and zero-full for numeric types are commonly used. I think someone will ask us Why don't have numeric formats though we have %s?. I think someone might also ask - why are you bothering to create this at all? The amount of work that has been put into this is, IMHO, far out of proportion to the value of the feature. As Pavel points out, we already have perfectly good mechanisms for converting our various data types to text. We do not need to invent new ones. I beg to differ. IMO to_char is a lot closer to the sucks big-time end of the spectrum than the perfectly good end of the spectrum: it's a bad implementation of a crummy design. I think a lot of people would like to have something closer to sprintf-style formatting. I think we should go into this with the idea that it might only do 10% of what sprintf can do initially, but there will be pressure to cover a lot of the other 90% eventually. So it would be a good idea to ensure that we don't make any choices that are gratuitously incompatible with standard sprintf format codes. In particular, I agree with the idea of using %I not %i for identifiers --- in fact I'd go so far as to suggest that all specifiers we invent, rather than borrowing from sprintf, be upper-case. regards, tom lane -- 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] Foreign Visual Studio builds
On Thu, Oct 14, 2010 at 19:37, Greg Smith g...@2ndquadrant.com wrote: We got an interesting documentation document left by Christian Freund recently, in regards to http://www.postgresql.org/docs/9.0/interactive/install-windows-full.html ; it says: Regarding 16.1.3 - perl mkvcbuild.pl In case you use a German version of VC change line 69 in Solution.pm to: if ($line !~ /^Microsoft\s*\(R\) Visual C\+\+-Projekt-Generator - \D+(\d+)\.00\.\d+/) I'm going to approve the doc comment so that it might help someone else that runs into this in the short-term, but I thought it was was worth sharing as something that might be improved in the build code instead. That regex seems a bit too specific. yeah. I wonder if we can't just get away with: if ($line !~ /^Microsoft\s*\(R\) Visual C\+\+ [^-]+ - \D+(\d+)\.00\.\d+/) That's still quite specific, but should work as long as they don't localize the product name itself. I doubt they do that even in Japanese/Chinese - Hiroshi (or someone else with a Japanese install), can you confirm what the output from vcbuild /? is on a Japanese machine? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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] Timeout and wait-forever in sync rep
On Fri, 2010-10-15 at 21:41 +0900, Fujii Masao wrote: As the result of the discussion, I think that we need the following two parameters for the case where the standby goes down. * replication_timeout This is the maximum time to wait for the ACK from the standby. If this timeout expires, the master closes the replication connection and disconnects the standby. This parameter is just used for the master to detect the standby crash or the network outage. We already have keepalive parameters for that purpose. Yes, I had thought we would just use the keepalives... But they cannot detect the disconnection in some cases. So replication_timeout needs to be introduced for sync rep. When exactly don't the keepalives work? * allow_standalone_master This specifies whether we allow the master to process transactions alone when there is no connected and sync'd standby. If this is false, all the transactions on the master are blocked until sync'd standby has appeared. Of course, this happen not only when replication_timeout expires but also when we start the master alone at the initial setup, when the master detects the disconnection by using keepalive parameters, and when the standby is shut down normally. People who want 'wait-forever' will disable this parameter to reduce the risk of data loss. OTOH, if this is true, the absence of sync'd standby doesn't prevent the master from processing transactions alone. People who want high availability even though the risk of data loss increases will enable this parameter. OK -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- 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] knngist - 0.8
forward. Tom and I laid out a technical design back in January and I still think it's a good one, even though I know you think it's silly. We may just have to agree to disagree on this point. As I remember, there were several suggested designs: 1) 5-th boolean column (amopfamily, amoplefttype, amoprighttype, amopstrategy, amoporder) to point kind of operator (search or order) + saves one record for operator in pg_amop - operator could not be used in both roles - increase number of arguments for syscache machinery 2) 5-th combined column, which contains some kind of flag for each role + saves one record for operator in pg_amop + operator could be used in both roles - strategy number for operator is the same for both roles, it's unacceptable because GiST's consistentFn will not have information about role. GiST itself could distinguish them by invented SK_ORDER flag. So, this requires to introduce one more argument for consistentFn, while it already has 5 arguments. - increase number of arguments for syscache machinery 3) 3-rd boolean column (amopopr, amopfamily, amoporder) - could be two records per operator + operator could be used in both roles + strategy number could be different for different roles All three options require to add flag of role op_in_opfamily/get_op_opfamily_strategy/get_op_opfamily_properties to check applicability of operation in current code path. First two options could do not change of interface of op_in_opfamily/get_op_opfamily_strategy but it will be needed to check actual role of operator later. Basing on this comparison, I think, that 2) is worse and 3) is better. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- 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] knngist - 0.8
Teodor Sigaev teo...@sigaev.ru writes: As I remember, there were several suggested designs: 1) 5-th boolean column (amopfamily, amoplefttype, amoprighttype, amopstrategy, amoporder) to point kind of operator (search or order) + saves one record for operator in pg_amop - operator could not be used in both roles - increase number of arguments for syscache machinery 2) 5-th combined column, which contains some kind of flag for each role + saves one record for operator in pg_amop + operator could be used in both roles - strategy number for operator is the same for both roles, it's unacceptable because GiST's consistentFn will not have information about role. GiST itself could distinguish them by invented SK_ORDER flag. So, this requires to introduce one more argument for consistentFn, while it already has 5 arguments. - increase number of arguments for syscache machinery 3) 3-rd boolean column (amopopr, amopfamily, amoporder) - could be two records per operator + operator could be used in both roles + strategy number could be different for different roles How can #3 work at all? It's ignoring a couple of critical index columns. In particular, I believe the sticking point here is this unique index: pg_amop_fam_strat_index UNIQUE, btree (amopfamily, amoplefttype, amoprighttype, amopstrategy) #3 doesn't explain what to do about this index. If we extend it to five columns, as we'd logically have to do to preserve uniqueness, then the associated syscache has to have five key columns as well, and now we're at solution #1. I'm not terribly thrilled with using a boolean here in any case. Now that we have two roles an operator might play in an opclass, who's to say there might not be more roles someday? We should use a column type that will support more than two roles without basic rejiggering. BTW, have we discussed the idea of embedding the role in the strategy number? For example, require regular operators to have strategy numbers 1-, while ordering operators have numbers 1-1, leaving room for a couple more roles before we have to rethink the assignment or widen amopstrategy to an int. That's a bit ugly but might be better than adding a separate role column. regards, tom lane -- 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] [JDBC] Support for JDBC setQueryTimeout, et al.
Tom Lane wrote: I'm all for doing this client-side. Well, that makes a big difference. Unless someone can make a convincing argument for why we should modify the server side to support this, I think we should just focus on this one client-side patch. I'd be happy to give it a closer look, but I may not be able to do so for a few weeks, and won't complain if someone beats me to it. -Kevin -- 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] Foreign Visual Studio builds
Hi. Ahh, as for Japanese, it becomes the same. C:\MinGW\home\HIROSHIvcbuild /? Microsoft(R) Visual C++ Project Builder - コマンド ライン バージョン 9.00.21022 Copyright (C) Microsoft Corporation. All rights reserved. http://winpg.jp/~saito/pg_work/VisualStudio/vcbuild_help_SJIS.txt Regards, Hiroshi Saito - Original Message - From: Magnus Hagander mag...@hagander.net On Thu, Oct 14, 2010 at 19:37, Greg Smith g...@2ndquadrant.com wrote: We got an interesting documentation document left by Christian Freund recently, in regards to http://www.postgresql.org/docs/9.0/interactive/install-windows-full.html ; it says: Regarding 16.1.3 - perl mkvcbuild.pl In case you use a German version of VC change line 69 in Solution.pm to: if ($line !~ /^Microsoft\s*\(R\) Visual C\+\+-Projekt-Generator - \D+(\d+)\.00\.\d+/) I'm going to approve the doc comment so that it might help someone else that runs into this in the short-term, but I thought it was was worth sharing as something that might be improved in the build code instead. That regex seems a bit too specific. yeah. I wonder if we can't just get away with: if ($line !~ /^Microsoft\s*\(R\) Visual C\+\+ [^-]+ - \D+(\d+)\.00\.\d+/) That's still quite specific, but should work as long as they don't localize the product name itself. I doubt they do that even in Japanese/Chinese - Hiroshi (or someone else with a Japanese install), can you confirm what the output from vcbuild /? is on a Japanese machine? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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] First patch proposal
On Wed, 2010-10-13 at 22:29 +0200, Alastair Turner wrote: I am proposing altering psql to raise certain errors and exit before prompting for a password. These errors would have to be on items which didn't leak any information, my current list is: - Does the input file (-f) exist and is it readable - Do paths to the output files ( -o and -l) exist and are they writable - Is the host/socket listening (-h) I think these are pretty good. The last one might not be as easy as you think. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- 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] Timeout and wait-forever in sync rep
On 10/15/2010 05:43 PM, Simon Riggs wrote: On Fri, 2010-10-15 at 21:41 +0900, Fujii Masao wrote: As the result of the discussion, I think that we need the following two parameters for the case where the standby goes down. * replication_timeout This is the maximum time to wait for the ACK from the standby. If this timeout expires, the master closes the replication connection and disconnects the standby. This parameter is just used for the master to detect the standby crash or the network outage. We already have keepalive parameters for that purpose. Yes, I had thought we would just use the keepalives... But they cannot detect the disconnection in some cases. So replication_timeout needs to be introduced for sync rep. When exactly don't the keepalives work? well tcp level keepalives are not terribly portable(or can only be partially controlledd from the app) and on some platforms have lower limits that are in the minutes which is too long for a lot of usecases. The keepalive usage we have in 9.0 is mostly for removing an annoyance on some major platforms but depending on them for a major feature like timeouts in sync rep is probably not a good idea. Stefan -- 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] Re: starting to review the Extend NOT NULL representation to pg_constraint patch
Bernd Helmle maili...@oopsware.de writes: Here is an updated version of the patch. It fixes the following issues Andrew discovered during his review cycle: I looked through this a bit. It's not ready to commit unfortunately. The main gripe I've got is that you've paid very little attention to updating comments that your code changes invalidate. That's not even a little bit acceptable: people will still have to read this code later. Two examples are that struct CookedConstraint is now used for notnull constraints in addition to its other duties, but you didn't adjust the comments in its declaration; and that you made transformColumnDefinition put NOTNULL constraints into the ckconstraints list, ignoring the fact that both its name and the comments say that that's only CHECK constraints. In the latter case it'd probably be a better idea to add a separate nnconstraints list to CreateStmtContext. Some other random points: * The ALTER TABLE changes seem to be inserting a whole lot of CommandCounterIncrement calls in places where there were none before. Do we really need those? Usually the theory is that one at the end of an operation is sufficient. * All those bits with deconstruct_array could usefully be folded into a subroutine, along the lines of bool constraint_is_for_single_column(HeapTuple constraintTup, int attno) * As best I can tell from looking, the patch *always* generates a name for NOT NULL constraints. It should honor the user's name for the constraint if one is given, ie create table foo (f1 int constraint nn1 not null); Historically we've had to drop such names on the floor, but that should stop. * pg_dump almost certainly needs some updates. I imagine the behavior we'll want from it is to print NOT NULL only when the column's notnull constraint shows that it's locally defined. If it gets printed for columns that only have an inherited NOT NULL, then dump and reload will change the not-null inheritance state. This may be a bit tricky since pg_dump also has to still work against older servers, but with any luck you can steal its logic for inherited check constraints. We probably want it to start preserving the names of notnull constraints, too. * In general you should probably search for all places that reference pg_constraint.contype, as a means of spotting any other code that needs to be updated for this. * Lots of bogus trailing whitespace. git diff --check can help you with that. Also, please try to avoid unnecessary changes of whitespace on lines the patch isn't otherwise changing. That makes it harder for reviewers to see what the patch *is* changing, and it's a useless activity anyway because the next run of pg_indent will undo such changes. * No documentation updates. At the very least, catalogs.sgml has to be updated: both the pg_attribute and pg_constraint pages probably have to have something to say about this. * No regression test updates. There ought to be a few test cases that demonstrate the new behavior. regards, tom lane -- 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] Timeout and wait-forever in sync rep
On Fri, 2010-10-15 at 18:51 +0200, Stefan Kaltenbrunner wrote: When exactly don't the keepalives work? well tcp level keepalives are not terribly portable(or can only be partially controlledd from the app) and on some platforms have lower limits that are in the minutes which is too long for a lot of usecases. The keepalive usage we have in 9.0 is mostly for removing an annoyance on some major platforms but depending on them for a major feature like timeouts in sync rep is probably not a good idea. If we need it, then I'm glad. It's easy to understand and easy to program too. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- 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] Extensions, this time with a patch
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
So, you will find two new branches for those purposes at the repository,
named cfparser and pg_execute_from_file:
http://git.postgresql.org/gitweb?p=postgresql-extension.git;a=summary
I updated the pg_execute_from_file branch with documentation for the
function, and added documentation (catalog, functions, custom classes)
to the main feature branch too.
The cfparser patch didn't change, the current version is still v1.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
extension.v2.patch.gz
Description: extension, v2, more docs
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
***
*** 13895,13900 postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
--- 13895,13907
entrytyperecord/type/entry
entryReturn information about a file/entry
/row
+ row
+entry
+ literalfunctionpg_execute_from_file(parameterfilename/ typetext/)/function/literal
+/entry
+entrytypevoid/type/entry
+entryExecutes the acronymSQL/ commands contained in a file/entry
+ /row
/tbody
/tgroup
/table
***
*** 13933,13938 SELECT (pg_stat_file('filename')).modification;
--- 13940,13954
/programlisting
/para
+indexterm
+ primarypg_execute_from_file/primary
+/indexterm
+para
+ functionpg_execute_from_file/ makes the server
+ execute acronymSQL/ commands to be found in a file. This function is
+ reserved to superusers.
+/para
+
para
The functions shown in xref linkend=functions-advisory-locks manage
advisory locks. For details about proper use of these functions, see
***
*** 13955,13960 SELECT (pg_stat_file('filename')).modification;
--- 13971,13977
entrytypevoid/type/entry
entryObtain exclusive advisory lock/entry
/row
+
row
entry
literalfunctionpg_advisory_lock(parameterkey1/ typeint/, parameterkey2/ typeint/)/function/literal
*** a/src/backend/utils/adt/genfile.c
--- b/src/backend/utils/adt/genfile.c
***
*** 7,12
--- 7,13
* Copyright (c) 2004-2010, PostgreSQL Global Development Group
*
* Author: Andreas Pflug pgad...@pse-consulting.de
+ * Dimitri Fontaine dimi...@2ndquadrant.fr
*
* IDENTIFICATION
* src/backend/utils/adt/genfile.c
***
*** 30,35
--- 31,46
#include utils/memutils.h
#include utils/timestamp.h
+ #include tcop/pquery.h
+ #include tcop/tcopprot.h
+ #include tcop/utility.h
+ #include access/transam.h
+ #include access/xact.h
+ #include utils/resowner.h
+ #include utils/snapmgr.h
+ #include parser/analyze.h
+ #include access/printtup.h
+
typedef struct
{
char *location;
***
*** 264,266 pg_ls_dir(PG_FUNCTION_ARGS)
--- 275,459
SRF_RETURN_DONE(funcctx);
}
+
+ /*
+ * Read a file then execute the SQL commands it contains.
+ */
+ Datum
+ pg_execute_from_file(PG_FUNCTION_ARGS)
+ {
+ text *filename_t = PG_GETARG_TEXT_P(0);
+ char *filename;
+ FILE *file;
+ int64 fsize = -1, nbytes;
+ struct stat fst;
+ char *query_string = NULL;
+
+ CommandDest dest = DestNone;
+ MemoryContext oldcontext;
+ List *parsetree_list;
+ ListCell *parsetree_item;
+ bool save_log_statement_stats = log_statement_stats;
+ bool was_logged = false;
+ bool isTopLevel;
+ char msec_str[32];
+
+ if (!superuser())
+ ereport(ERROR,
+ (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
+ (errmsg(must be superuser to get file information;
+
+ /*
+ * Only superuser can call pg_execute_from_file, and CREATE EXTENSION
+ * uses that too. Don't double check the PATH. Also note that
+ * extension's install files are not in $PGDATA but `pg_config
+ * --sharedir`.
+ */
+ filename = text_to_cstring(filename_t);
+
+ if (stat(filename, fst) 0)
+ ereport(ERROR,
+ (errcode_for_file_access(),
+ errmsg(could not stat file \%s\: %m, filename)));
+
+ fsize = Int64GetDatum((int64) fst.st_size);
+
+ if ((file = AllocateFile(filename, PG_BINARY_R)) == NULL)
+ ereport(ERROR,
+ (errcode_for_file_access(),
+ errmsg(could not open file \%s\ for reading: %m,
+ filename)));
+
+ if (ferror(file))
+ ereport(ERROR,
+ (errcode_for_file_access(),
+ errmsg(could not read file \%s\: %m, filename)));
+
+ query_string = (char *)palloc((fsize+1)*sizeof(char));
+ memset(query_string, 0, fsize+1);
+ nbytes = fread(query_string, 1, (size_t) fsize, file);
+ pg_verifymbstr(query_string, nbytes, false);
+ FreeFile(file);
+
+ /*
+ elog(NOTICE, pg_execute_from_file('%s') read %d/%d bytes:, filename, nbytes, fsize);
+ elog(NOTICE, %s, query_string);
+ */
+
+ /*
+ * Code pasted from postgres.c:exec_simple_query, main differences are:
+ * - don't override unnamed portal, name
Re: [HACKERS] How to reliably detect if it's a promoting standby
On Thu, Oct 14, 2010 at 7:35 PM, Tatsuo Ishii is...@postgresql.org wrote: What new public interfaces do you think are needed for 9.1 in this regard? At this point I'm thinking of modifying existing pg_is_in_recovery(), thus 0 new public interface. pg_is_in_recovery() returns a bool, are you proposing to change that? -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- 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] [GENERAL] column-level update privs + lock table
[Moving to -hackers] On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs si...@2ndquadrant.com wrote: On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote: On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt schmi...@gmail.com wrote: I noticed that granting a user column-level update privileges doesn't allow that user to issue LOCK TABLE with any mode other than Access Share. Anyone think this could be added as a TODO? Seems so to me, but you raise on Hackers. Thanks, Simon. Attached is a simple patch to let column-level UPDATE privileges allow a user to LOCK TABLE in a mode higher than Access Share. Small doc. update and regression test update are included as well. Feedback is welcome. Thanks Josh column_level_lock.patch Description: Binary data -- 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] UNION DISTINCT in doc
Hitoshi Harada umi.tan...@gmail.com writes: 2010/10/15 Tom Lane t...@sss.pgh.pa.us: I think it'd be hard to describe without confusing people, because while DISTINCT is a noise word there, it's definitely not a noise word after SELECT. I thought adding DISTINCT next to ALL is enough like select_statement UNION [ ALL | DISTINCT ] select_statement and say UNION DISTINCT is identical to UNION only or something. That sounds not so confusing with DISTINCT clause description. I looked at this more closely and decided that we could probably avoid confusion if the description of the DISTINCT clause was careful to say SELECT DISTINCT and SELECT ALL, rather than just DISTINCT/ALL. Committed that way. regards, tom lane -- 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] host name support in pg_hba.conf
I have addressed these issues in my final patch. One other change I did was change the host name comparison to case insensitive (Apache and TCP Wrappers do the same). I'm planning to work on a wildcard mechanism soon. After that the issue of which way the host resolution should work will have an additional argument, so I'm not going to address that any further right now. On tis, 2010-10-12 at 16:33 -0400, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: Hopefully final patch, which addresses the above issues, adds some documentation enhancements, and the possibility to quote host names (in case someone wants to have a host named samehost). A few minor gripes: + If a host name is specified (anything that is not an IP address + or a special key word is processed as a potential host name), + that name is compared with the result of a reverse name + resolution of the client's IP address (e.g., reverse DNS + lookup, if DNS is used). If there is a match, then a forward + name resolution (e.g., forward DNS lookup) is performed on the + host name to check if it resolves to an IP address that is + equal to the client's IP address. If both directions match, + then the entry is considered to match. I think the reason you're getting repeated questions about why the reverse DNS lookup is needed is that the documentation fails to explain that. It'd be helpful if this part of the docs pointed out why the apparently-extra lookup is necessary. If I understand correctly, the point is that we do the reverse lookup only once per connection (when first finding a name-based pg_hba.conf entry) and that saves us having to do forward lookup on all the name-based entries that don't match. Which means BTW that the technique loses if the first name-based entry matches the connection, and only wins when the match comes at the third or later name-based entry. Are we really sure this is a good tradeoff? Are we sure there shouldn't be a way to turn it off? I'm a bit concerned about the fact that the argument seems to be better performance versus makes it completely useless for some use cases, as here: http://archives.postgresql.org/pgsql-hackers/2010-08/msg00726.php Another smaller point is that it might be helpful if the wording didn't make it sound like we expect the forward DNS lookup to produce just one IP address. Perhaps If there is a match, then a forward name resolution (e.g., forward DNS lookup) is performed on the host name to check if any of the addresses it resolves to are equal to the client's IP address. In check_hostname(): + port-remote_hostname = strdup(remote_hostname); Seems like this had better be pstrdup(), or at least have an error check. Dumping core at the next line is not a real acceptable substitute for an out of memory error. + /* Lookup IP from host name and check against original IP */ + ret = getaddrinfo(port-remote_hostname, NULL, NULL, gai_result); + if (ret != 0) + ereport(ERROR, + (errcode(ERRCODE_CONFIG_FILE_ERROR), +errmsg(getaddrinfo failed on \%s\: %s, + port-remote_hostname, gai_strerror(ret; Is ERRCODE_CONFIG_FILE_ERROR really the most appropriate code here? regards, tom lane -- 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] [JDBC] Support for JDBC setQueryTimeout, et al.
Stephen Frost sfr...@snowman.net writes: That assumption is certainly something I feel we should consider a valid and important use-case. I'd think a lot of the time your typical website is going to be using a dedicated pooler for connections and a dedicated database where having those queries cache'd would be good. Using pgbouncer without setting server_reset_query is possible and allow to reuser prepared queries. I abuse the feature in some environment where prepare takes ~42ms and execute 5ms, as all the data is in RAM. I recall seeing a module that even set things up so you feed it all the queries that you're going to run and it plans them all out for you when you start up the pooler. Been meaning to look into it more, but.. Yeah, for this same project I wanted the application code to stop having to check whether the session given already has the queries prepared. As pgbouncer will take new connections here and there (which is a good idea), you have to check for that. Enters preprepare: http://preprepare.projects.postgresql.org/README.html http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/preprepare/preprepare/ http://packages.debian.org/sid/postgresql-8.4-preprepare There's no release yet and the code is still under CVS, but I could see about moving it to github some day. Well, maybe I also should implement support for 9.0. The whole problem with search_path and role is very frustrating. We've taken to just hacking things to be dynamic SQL whenever it's role-specific, but that's a really poor solution. I wonder if it would be possible to have the function and prepare'd plan caches be key'd off of the search_path and role too..? So if you change one of those you end up having to re-plan it, but then that's also cached, etc.. By default pgbouncer maintains a different pool per database and role, so you should be partly covered here. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- 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] [JDBC] Support for JDBC setQueryTimeout, et al.
Dimitri, * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: [... much useful info ...] Thanks for all of that, I certainly appreciate it. By default pgbouncer maintains a different pool per database and role, so you should be partly covered here. No, not really.. We have a single unprivileged account which is used for login and then that account can 'set role' to other roles (of course, we set it up so the login role *has* to set role to another user to be able to do anything). I doubt pgbouncer is going to switch pooler connections on seeing a set role and I'm not really sure it'd make sense for it to anyway. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [JDBC] Support for JDBC setQueryTimeout, et al.
Stephen Frost sfr...@snowman.net writes: The whole problem with search_path and role is very frustrating. We've taken to just hacking things to be dynamic SQL whenever it's role-specific, but that's a really poor solution. I wonder if it would be possible to have the function and prepare'd plan caches be key'd off of the search_path and role too..? So if you change one of those you end up having to re-plan it, but then that's also cached, etc.. FWIW, I can see the point of making cached plan lookup be search-path-specific. But why does the active role need to factor into it? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Trailing Whitespace Tips (was: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch)
Tom Lane t...@sss.pgh.pa.us writes: * Lots of bogus trailing whitespace. git diff --check can help you with that. This is a repetitive common remark that I think sharing tips to avoid that problem is a good idea. Here's an emacs setup to have trailing whitespace hurt the eyes, and more-than-80 columns lines too. This one is more controversial as we find lots of long lines in the PostgreSQL sources. Still: ;; display only tails of lines longer than 80 columns, and ;; trailing whitespaces (require 'whitespace) (setq whitespace-line-column 80 whitespace-style '(face trailing lines-tail empty)) ;; face for tabs long lines' tails (set-face-attribute 'whitespace-tab nil :background red1 :foreground yellow :weight 'bold) (set-face-attribute 'whitespace-line nil :background red1 :foreground yellow :weight 'bold) ;; activate minor whitespace mode when in some coding modes (add-hook 'emacs-lisp-mode-hook 'whitespace-mode) (add-hook 'python-mode-hook 'whitespace-mode) (add-hook 'c-mode-hook 'whitespace-mode) Now, it's easy to find some more about it, including images of how it looks. You can't miss trailing whitespace any more : http://ruslanspivak.com/2010/09/27/keep-track-of-whitespaces-and-column-80-overflow/ http://panela.blog-city.com/python_and_emacs_4_whitespace_tabs_tabwidth_visualizi.htm http://www.emacswiki.org/emacs/WhiteSpace I suppose people using other editors or tools will come up with other tricks and tips. Maybe it should go in src/tools/editors/emacs.samples, too? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- 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] [JDBC] Support for JDBC setQueryTimeout, et al.
* Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost sfr...@snowman.net writes: The whole problem with search_path and role is very frustrating. We've taken to just hacking things to be dynamic SQL whenever it's role-specific, but that's a really poor solution. I wonder if it would be possible to have the function and prepare'd plan caches be key'd off of the search_path and role too..? So if you change one of those you end up having to re-plan it, but then that's also cached, etc.. FWIW, I can see the point of making cached plan lookup be search-path-specific. But why does the active role need to factor into it? Because of $user being used in the search_path. Thinking about it, I'm sure we'd handle the look-up at query time and would resolve the $user in the search_path to an actual schema first, so the cache doesn't need to be keyed off role itself. IOW, yeah, you're right, the role doesn't really matter. One thing that occurs to me when I last ran into a problem with this- it was painful to debug because the permission denied error didn't indicate which schema the table it was trying to access was in. I wonder if we could fix that. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Git migration deadline for Buildfarm
On 09/27/2010 08:13 AM, Andrew Dunstan wrote: In about a week I propose to have the buildfarm server start to reject results based on snapshots where the newest file is older than the time of the git migration a week ago. That means buildfarm owners need to upgrade to using git. Many have already: see http://www.pgbuildfarm.org/cgi-bin/show_status.pl [snip] If you think you deserve a dispensation, please ask me, but I really don't want the buildfarm server polluted with new builds of frozen code. That doesn't help anyone - it's just useless noise. I have now implemented a policy of refusing results from snapshots older than 10 days. It's not quite what I said above, but I think it's sound policy. Also, I think we've waited long enough, and a few owners aren't responding to multiple prods. cheers andrew
Re: [HACKERS] string function - format function proposal
On Fri, Oct 15, 2010 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Oct 15, 2010 at 12:55 AM, Itagaki Takahiro itagaki.takah...@gmail.com wrote: I agree that full-spec sprintf is too complex, but precision and zero-full for numeric types are commonly used. I think someone will ask us Why don't have numeric formats though we have %s?. I think someone might also ask - why are you bothering to create this at all? The amount of work that has been put into this is, IMHO, far out of proportion to the value of the feature. As Pavel points out, we already have perfectly good mechanisms for converting our various data types to text. We do not need to invent new ones. I beg to differ. IMO to_char is a lot closer to the sucks big-time end of the spectrum than the perfectly good end of the spectrum: it's a bad implementation of a crummy design. I think a lot of people would like to have something closer to sprintf-style formatting. I think we should go into this with the idea that it might only do 10% of what sprintf can do initially, but there will be pressure to cover a lot of the other 90% eventually. So it would be a good idea to ensure that we don't make any choices that are gratuitously incompatible with standard sprintf format codes. In particular, I agree with the idea of using %I not %i for identifiers --- in fact I'd go so far as to suggest that all specifiers we invent, rather than borrowing from sprintf, be upper-case. Hmm. I have a feeling that's going to be a rathole. Among other problems, what about types other than strings and numbers? The thing I most often need to format is a date, and the second most common one is timestamp with time zone. The specification for sprintf is ridiculously complicated with just the things C has as built-in types, never mind SQL. Then again, if I'm not the one who has to spend time in the rathole... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] [JDBC] Support for JDBC setQueryTimeout, et al.
Stephen Frost sfr...@snowman.net writes:
IOW, yeah, you're right, the role doesn't really matter. One thing that
occurs to me when I last ran into a problem with this- it was painful to
debug because the permission denied error didn't indicate which schema
the table it was trying to access was in. I wonder if we could fix
that.
Hm, are you sure you actually got a permission denied error? Because
AFAICS such a message would name the schema:
regression= select * from s1.t1;
ERROR: permission denied for schema s1
The part that is a bit nasty is if you try to put a schema in your
search_path that you don't have permissions for. My recollection is
that we just silently drop it out of the effective search path, so:
regression= set search_path = s1, public;
SET
regression= select current_schemas(false);
current_schemas
-
{public}
(1 row)
regression= select * from t1;
ERROR: relation t1 does not exist
This isn't terribly user-friendly, but I'm not sure how to do better.
We can't really throw an error at the point of setting the search
path, because there are too many scenarios where a default search
path is effectively set up for you, and it might or might not list
some unsearchable (or even nonexistent) schemas.
regards, tom lane
--
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 migration deadline for Buildfarm
Andrew Dunstan and...@dunslane.net writes: I have now implemented a policy of refusing results from snapshots older than 10 days. It's not quite what I said above, but I think it's sound policy. +1. Might be time to advise buildfarm owners to shut down the 7.4 and 8.0 branches, and remind them to start up 9.0 if they haven't already. regards, tom lane -- 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] knngist - 0.8
On Fri, Oct 15, 2010 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote: BTW, have we discussed the idea of embedding the role in the strategy number? For example, require regular operators to have strategy numbers 1-, while ordering operators have numbers 1-1, leaving room for a couple more roles before we have to rethink the assignment or widen amopstrategy to an int. That's a bit ugly but might be better than adding a separate role column. Yeah, we talked about it. http://archives.postgresql.org/pgsql-hackers/2010-02/msg01075.php http://archives.postgresql.org/pgsql-hackers/2010-02/msg01079.php -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] string function - format function proposal
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 15, 2010 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we should go into this with the idea that it might only do 10%
of what sprintf can do initially, but there will be pressure to cover a
lot of the other 90% eventually.
Hmm. I have a feeling that's going to be a rathole. Among other
problems, what about types other than strings and numbers?
I think the general solution is to split those off as subproblems.
If you've got a type that has special formatting requirements,
you can do
sprintf('foo is %s', format_my_type(value, other-arguments))
where format_my_type returns text. (So, in particular, you could use
to_char for this if it solved the particular need.)
Having said that, it might make sense to provide special case handling
of dates and timestamps, since that's definitely the most common case
where you might not be satisfied with the default conversion to text.
The specification for sprintf is
ridiculously complicated with just the things C has as built-in types,
never mind SQL.
Sure, but an awful lot of those bells and whistles turn out to be handy.
Personally I think the field width control options are the main thing
that sprintf has got over to_char, so I think we're going to want those
sooner rather than later.
Then again, if I'm not the one who has to spend time in the rathole...
Yeah, I'm not in a hurry to spend time on it either. I just foresee
that somebody will want to, and so I don't want a dead-end definition.
regards, tom lane
--
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] knngist - 0.8
On Fri, Oct 15, 2010 at 5:35 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, Oct 15, 2010 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote: BTW, have we discussed the idea of embedding the role in the strategy number? For example, require regular operators to have strategy numbers 1-, while ordering operators have numbers 1-1, leaving room for a couple more roles before we have to rethink the assignment or widen amopstrategy to an int. That's a bit ugly but might be better than adding a separate role column. Yeah, we talked about it. http://archives.postgresql.org/pgsql-hackers/2010-02/msg01075.php http://archives.postgresql.org/pgsql-hackers/2010-02/msg01079.php Having said that, I'm not wild on having 5-key syscaches, even though the patch is ready to go (modulo whatever rebasing is needed, which probably isn't much). So if you can figure out a way to avoid it, let's do that. I still feel vaguely uneasy about the fact that the proposed patch can't handle ASC/DESC or NULLS FIRST/LAST, and that unease grew a bit more last night when I read Peter's patch to add collation support. We could possibly cram ASC/DESC and NULLS FIRST/LAST in by defining four new categories of operator strategies rather than one, but there's no way that's going to work for collations. Is there some other way to approach this problem? Can we leave pg_amop as it is, and pass the context (sort vs. qual, ASC/DESC, NULLS FIRST/LAST, collation, whatever...) to the index via some sort of side channel? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] string function - format function proposal
On Fri, Oct 15, 2010 at 5:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 15, 2010 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we should go into this with the idea that it might only do 10%
of what sprintf can do initially, but there will be pressure to cover a
lot of the other 90% eventually.
Hmm. I have a feeling that's going to be a rathole. Among other
problems, what about types other than strings and numbers?
I think the general solution is to split those off as subproblems.
If you've got a type that has special formatting requirements,
you can do
sprintf('foo is %s', format_my_type(value, other-arguments))
where format_my_type returns text. (So, in particular, you could use
to_char for this if it solved the particular need.)
Having said that, it might make sense to provide special case handling
of dates and timestamps, since that's definitely the most common case
where you might not be satisfied with the default conversion to text.
The specification for sprintf is
ridiculously complicated with just the things C has as built-in types,
never mind SQL.
Sure, but an awful lot of those bells and whistles turn out to be handy.
No doubt. The problem is that we're going to end up with those bells
and whistles in two places: in to_char or other type-specific
formatting functions, and again in format.
Personally I think the field width control options are the main thing
that sprintf has got over to_char, so I think we're going to want those
sooner rather than later.
Then again, if I'm not the one who has to spend time in the rathole...
Yeah, I'm not in a hurry to spend time on it either. I just foresee
that somebody will want to, and so I don't want a dead-end definition.
Perhaps we could design a family of (heh, heh, undocumented) functions
called _format_helper(type, text), or something like that. format()
would call the format helper for the appropriate type with the datum
to be formatted and the sprintf-like format string as arguments. Or
maybe that isn't feasible, I'm just brainstorming.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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] knngist - 0.8
Robert Haas robertmh...@gmail.com writes: I still feel vaguely uneasy about the fact that the proposed patch can't handle ASC/DESC or NULLS FIRST/LAST, and that unease grew a bit more last night when I read Peter's patch to add collation support. Good point. We could possibly cram ASC/DESC and NULLS FIRST/LAST in by defining four new categories of operator strategies rather than one, but there's no way that's going to work for collations. Is there some other way to approach this problem? Can we leave pg_amop as it is, and pass the context (sort vs. qual, ASC/DESC, NULLS FIRST/LAST, collation, whatever...) to the index via some sort of side channel? Well, we cannot avoid changing pg_amop, or at least changing its interpretation, because the current scheme simply can't represent indexable operators that are used for anything except simple boolean WHERE tests. I agree though that we do *not* want pg_amop involved in the details of exactly what sort ordering is referenced by a sortable operator. Somehow that needs to be passed in a side channel. Maybe we should think in terms of a side channel for Peter's patch as well. I share your feeling that trying to propagate collation the same way we now propagate typmod is a recipe for serious pain. regards, tom lane -- 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] knngist - 0.8
On Fri, Oct 15, 2010 at 7:10 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: I still feel vaguely uneasy about the fact that the proposed patch can't handle ASC/DESC or NULLS FIRST/LAST, and that unease grew a bit more last night when I read Peter's patch to add collation support. Good point. We could possibly cram ASC/DESC and NULLS FIRST/LAST in by defining four new categories of operator strategies rather than one, but there's no way that's going to work for collations. Is there some other way to approach this problem? Can we leave pg_amop as it is, and pass the context (sort vs. qual, ASC/DESC, NULLS FIRST/LAST, collation, whatever...) to the index via some sort of side channel? Well, we cannot avoid changing pg_amop, or at least changing its interpretation, because the current scheme simply can't represent indexable operators that are used for anything except simple boolean WHERE tests. What exactly do you mean by that? It has always seemed to me that the operator class mechanism is a complicated abstraction mechanism that actually adds only a very small amount of abstraction. Instead of referring to operators by name or OID we refer to them by a number that maps onto a name or OID. That allows the user to change the name or OID without breaking anything, but that's about it. Perhaps we should think of pg_amop not so much as a way to tell the AM what to do, but just a way to tell it what operator is logically involved without relying on the name or OID. I agree though that we do *not* want pg_amop involved in the details of exactly what sort ordering is referenced by a sortable operator. Somehow that needs to be passed in a side channel. Yeah. Maybe we should think in terms of a side channel for Peter's patch as well. I share your feeling that trying to propagate collation the same way we now propagate typmod is a recipe for serious pain. I'm not sure what you're thinking of here. I think we can have the idea of a FullySpecifiedType = typid, typmod, collationoid, but that's not so much a side channel as an abstraction layer. It absolutely won't work to stuff the collations in a global variable or something like that, if that's what you're imagining. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] top-level DML under CTEs
Hitoshi Harada umi.tan...@gmail.com writes: 2010/10/5 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi: This patch conflicted with Tom's WITH .. INSERT change. I tweaked the patch just a bit and it now passes all regression tests so I can review it. New version attached for documentation purposes. Thank you, I didn't notice that commit. In your last patch, the snippet to add errhint() and ref/insert sgml is unnecessary since it was for INSERT ... VALUES fix. Committed with minor fixes (mostly documentation improvements). regards, tom lane -- 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] knngist - 0.8
Robert Haas robertmh...@gmail.com writes: On Fri, Oct 15, 2010 at 7:10 PM, Tom Lane t...@sss.pgh.pa.us wrote: Well, we cannot avoid changing pg_amop, or at least changing its interpretation, because the current scheme simply can't represent indexable operators that are used for anything except simple boolean WHERE tests. What exactly do you mean by that? It has always seemed to me that the operator class mechanism is a complicated abstraction mechanism that actually adds only a very small amount of abstraction. Instead of referring to operators by name or OID we refer to them by a number that maps onto a name or OID. Well, the amount of abstraction might be minimal, but the point is to be able to understand which operators are related to an index and exactly what the relationship is. There might be a better way to represent this operator acts as = for btree int4 indexes than this operator has strategy number 2 for btree int4 indexes, but it doesn't seem to me that there's a lot of win available there. C code certainly finds it more convenient to work with numbers than names, so I'm not excited about replacing the strategy numbers with strategy names, if that's what you're thinking. Perhaps we should think of pg_amop not so much as a way to tell the AM what to do, but just a way to tell it what operator is logically involved without relying on the name or OID. I already think of it that way ... Maybe we should think in terms of a side channel for Peter's patch as well. I share your feeling that trying to propagate collation the same way we now propagate typmod is a recipe for serious pain. I'm not sure what you're thinking of here. I'm not either. I'm dissatisfied with the direction he's heading because of the amount of code it's going to break, but I don't have a better idea. It may well be impossible to have this feature without breaking everything in sight. (And, if we are going to break everything in sight, now would be a good time to think about changing typmod to something more flexible than one int32.) regards, tom lane -- 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] knngist - 0.8
On Fri, Oct 15, 2010 at 8:10 PM, Tom Lane t...@sss.pgh.pa.us wrote: Perhaps we should think of pg_amop not so much as a way to tell the AM what to do, but just a way to tell it what operator is logically involved without relying on the name or OID. I already think of it that way ... OK. Maybe we should think in terms of a side channel for Peter's patch as well. I share your feeling that trying to propagate collation the same way we now propagate typmod is a recipe for serious pain. I'm not sure what you're thinking of here. I'm not either. I'm dissatisfied with the direction he's heading because of the amount of code it's going to break, but I don't have a better idea. It may well be impossible to have this feature without breaking everything in sight. (And, if we are going to break everything in sight, now would be a good time to think about changing typmod to something more flexible than one int32.) I assume I don't need to tell you my vote on that. But I'm also not sure how far this gets us with KNNGIST, where the issue is not the typmods but the auxilliary information about the context of the sort and/or whether this is a sort or qual. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Re: starting to review the Extend NOT NULL representation to pg_constraint patch
--On 15. Oktober 2010 13:36:38 -0400 Tom Lane t...@sss.pgh.pa.us wrote: Bernd Helmle maili...@oopsware.de writes: Here is an updated version of the patch. It fixes the following issues Andrew discovered during his review cycle: I looked through this a bit. It's not ready to commit unfortunately. Thanks for looking at this. I didn't reckon that i really got everything done (admitted, docs and regression tests were liberally left out), and given your comments your review is invaluable at this point. The main gripe I've got is that you've paid very little attention to updating comments that your code changes invalidate. That's not even a little bit acceptable: people will still have to read this code later. Two examples are that struct CookedConstraint is now used for notnull constraints in addition to its other duties, but you didn't adjust the comments in its declaration; and that you made transformColumnDefinition put NOTNULL constraints into the ckconstraints list, ignoring the fact that both its name and the comments say that that's only CHECK constraints. In the latter case it'd probably be a better idea to add a separate nnconstraints list to CreateStmtContext. Agreed, there's much more cleanup needed. Some other random points: * The ALTER TABLE changes seem to be inserting a whole lot of CommandCounterIncrement calls in places where there were none before. Do we really need those? Usually the theory is that one at the end of an operation is sufficient. Hmm i seem to remember that i had some problems during coding and some testing, where changes were unvisible during recursionI will go through them again. * All those bits with deconstruct_array could usefully be folded into a subroutine, along the lines of bool constraint_is_for_single_column(HeapTuple constraintTup, int attno) Ok * As best I can tell from looking, the patch *always* generates a name for NOT NULL constraints. It should honor the user's name for the constraint if one is given, ie create table foo (f1 int constraint nn1 not null); Historically we've had to drop such names on the floor, but that should stop. Oh, i really missed that. * pg_dump almost certainly needs some updates. I imagine the behavior we'll want from it is to print NOT NULL only when the column's notnull constraint shows that it's locally defined. If it gets printed for columns that only have an inherited NOT NULL, then dump and reload will change the not-null inheritance state. This may be a bit tricky since pg_dump also has to still work against older servers, but with any luck you can steal its logic for inherited check constraints. We probably want it to start preserving the names of notnull constraints, too. I will look at it. * In general you should probably search for all places that reference pg_constraint.contype, as a means of spotting any other code that needs to be updated for this. Ok * Lots of bogus trailing whitespace. git diff --check can help you with that. Also, please try to avoid unnecessary changes of whitespace on lines the patch isn't otherwise changing. That makes it harder for reviewers to see what the patch *is* changing, and it's a useless activity anyway because the next run of pg_indent will undo such changes. whoops...i've set (setq-default show-trailing-whitespace t) in my .emacs, so i don't miss it again. * No documentation updates. At the very least, catalogs.sgml has to be updated: both the pg_attribute and pg_constraint pages probably have to have something to say about this. * No regression test updates. There ought to be a few test cases that demonstrate the new behavior. I'll include them. It was important for me to get a feeling about wether the direction in refactoring/extending this code is the correct one or needs more thinking. So, thanks again for reviewing. -- Thanks Bernd -- 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] knngist - 0.8
On Fri, Oct 15, 2010 at 8:45 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, Oct 15, 2010 at 8:10 PM, Tom Lane t...@sss.pgh.pa.us wrote: Perhaps we should think of pg_amop not so much as a way to tell the AM what to do, but just a way to tell it what operator is logically involved without relying on the name or OID. I already think of it that way ... OK. Thinking about it that way, perhaps we could add an integer column amop_whats_it_good_for that gets used as a bit field. That wouldn't require changing the index structure, although it might break some other things. The core KNNGIST patch is actually quite small, actually. Excluding a lot of not-very-interesting changes to pg_amop.h, it's just over 300 lines of new code, about half of which is in indxpath.c. If we could get this issue of how to structure the catalogs resolved, it seems to me that we might be able to see our way to committing that part of this work fairly quickly. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] [JDBC] Support for JDBC setQueryTimeout, et al.
On 15/10/2010 10:38 PM, Tom Lane wrote: Yeah, actually what you need is DISCARD ALL when reassigning a connection to another client. Anything less than that assumes the clients are cooperating closely, ie they *want* the same prepared statements etc. For what it's worth, this is quite common in the world of web apps. Java EE application servers, in particular, tend to offer per-application connection pools that can significantly benefit from this sort of thing. I don't know how much that sort of co-operating group of apps is likely to use external pooling via PgPool and friends, though. Most such apps have an *internal* connection pool, whether managed by an appserver, web server, or by the app code its self. The JDBC driver's org.postgresql.ds.PGPoolingDataSource is rather unclear about how it behaves in terms of resetting GUCs, resetting roles, clearing prepared statements etc between connection uses, so it's not clear what category it falls into. The docs suggest it's a bit of a toy implementation that's not intended for real-world production use, though. OTOH, it's not clear how connection pools like DBCP should know how or when to do this when returning a PostgreSQL connection to the pool, so it may well be an issue for serious non-Pg-specific pools too. The JDBC spec doesn't seem to offer a generic reset this connection to defaults method for use when pooling a connection. But even if you make that assumption, a pooler that isn't even capable of sending an ABORT between clients doesn't seem usable to me. For example, if a client loses its network connection mid-transaction, that failure will cascade to other clients if you don't have any ability to reset the database session before handing it to another client. You can never really assume that the connection you get from a pool (or have directly made) is working and usable, though. You always have to be prepared to handle failures because someone trips over an Ethernet cable, etc, so you can get a fresh connection and re-issue your transaction. Nonetheless, I tend to agree that pools should make some effort to handle failures in one connection that indicate likely failure in all other connections, re-testing all the connections before handing them out to clients. -- Craig Ringer Tech-related writing at http://soapyfrogs.blogspot.com/ -- 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] Extensions, this time with a patch
Excerpts from Dimitri Fontaine's message of vie oct 15 16:15:23 -0300 2010: Dimitri Fontaine dimi...@2ndquadrant.fr writes: So, you will find two new branches for those purposes at the repository, named cfparser and pg_execute_from_file: http://git.postgresql.org/gitweb?p=postgresql-extension.git;a=summary I updated the pg_execute_from_file branch with documentation for the function, and added documentation (catalog, functions, custom classes) to the main feature branch too. The cfparser patch didn't change, the current version is still v1. Hmm, did you try make install in contrib? It fails for me in intagg: make[1]: Entering directory `/home/alvherre/Code/CVS/pgsql/build/HEAD/contrib/intagg' /bin/mkdir -p '/pgsql/install/HEAD/share/contrib' touch .control test ! -f .control echo name = '' \nversion = '9.1' .control make[1]: *** [.control] Error 1 make[1]: *** Deleting file `.control' make[1]: Leaving directory `/home/alvherre/Code/CVS/pgsql/build/HEAD/contrib/intagg' make: *** [install] Error 2 I also note that the .control file generation is not working as intended for me -- the \n ends up verbatim in the generated files, not as a newline. It's probably easier to call echo two times. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Extensions, this time with a patch
Excerpts from Alvaro Herrera's message of sáb oct 16 00:30:41 -0300 2010: Hmm, did you try make install in contrib? It fails for me in intagg: make[1]: Entering directory `/home/alvherre/Code/CVS/pgsql/build/HEAD/contrib/intagg' /bin/mkdir -p '/pgsql/install/HEAD/share/contrib' touch .control test ! -f .control echo name = '' \nversion = '9.1' .control make[1]: *** [.control] Error 1 make[1]: *** Deleting file `.control' make[1]: Leaving directory `/home/alvherre/Code/CVS/pgsql/build/HEAD/contrib/intagg' make: *** [install] Error 2 Oh, I see what's going on here ... you have this bit in pgxs.mk: # create extension support ifndef CONTROL ifdef MODULE_big CONTROL = $(MODULE_big).control EXTENSION = $(MODULE_big) else CONTROL = $(MODULES).control EXTENSION = $(MODULES) endif endif The reason it fails for intagg is that it doesn't define MODULE_big, so it takes the other path. But since MODULES is not defined either, this ends up defining CONTROL as .control; and then test returns a failure because a file with the same name has been created in the previous line. I don't think the MODULES bit works either; see the spi contrib for an example. What it ends up doing is probably not what you want. Maybe what you should be doing here is that modules should provide another definition, say EXTENSION, and they have to explicitely define it in their Makefile (maybe require EXTENSION_VERSION too or something like that). I think the idea that modules should continue to work as extensions without any modification is doomed. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Extensions, this time with a patch
Excerpts from Dimitri Fontaine's message of vie oct 15 16:15:23 -0300 2010: I updated the pg_execute_from_file branch with documentation for the function, and added documentation (catalog, functions, custom classes) to the main feature branch too. Hmm. To be honest I don't like the direction that pg_execute_from_file has taken. (Now that I look, it's been like this since inception). I have two problems with it: one is that it is #including half the world into genfile.c. This already smells trouble in itself. I got worried when I saw the CommandDest declaration. Really, I think having the guts of postgres.c into that file is not a good idea from a modularisation point of view. The other problem is that it's slurping the whole file and executing it as a single query. This is really two problems: one is that you shouldn't be trusting that the file is going to be small enough to be read that way. The other one is that I don't think it's a good idea to execute it in a fell swoop; seems to be it would be better to split it into queries, and rewrite/parse/plan/execute them one by one. I think a better way to go about this is to have another entry point in postgres.c that executes a query the way you want; and somehow read the file in small chunks, find where each query ends, and execute them one by one. (To be honest, I have no idea how to find out where each query ends. psql knows how to do it, but I'm not sure how trustworthy it is.) As far as #include lines go, please keep them in alphabetical order. As a matter of style we always have postgres.h alone, then a blank line, then system includes, another blank, then the rest of the includes. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
