Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers
Greg Smith g...@2ndquadrant.com writes: The last time I tried to do this a few years ago I failed miserably and never came back. I know way more about building software now though, and just got this to work for the first time. BTW, another thing that should be in the try-try-again category is seeing how close we could get to pgindent's results with GNU indent. It seems clear to me that a process based on GNU indent would be a lot easier for a lot of people. We tried that once before, and couldn't get close enough to want to consider switching, but maybe it just needs a more determined effort and/or more recent versions of GNU indent. (ISTR that we hit some things that seemed to be outright bugs in GNU indent, but this was quite a few years ago.) 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] Evaluation of secondary sort key.
On Mon, Apr 18, 2011 at 6:25 AM, Jesper Krogh jes...@krogh.cc wrote: Getting the value for the first sortkey and carrying on a closure for the rest would mostly (very often) be optimal ? Well that might depend. The input data to the function might be much larger than the output. Consider the, quite common, idiom of: order by case when (complex expresssion) 1 when (complex expression) 2 else 3 It would also enable a select that has to sortkeys to utilize an index that only contains the primary sortkey, which is a huge negative effect of what's being done today. This is a separate problem entirely. It would be nice to have a strategy for ordering that can take advantage of partially ordered results. It's not hard to see how to do the executor side -- it could keep a tuplesort for each group and truncate it when the group changes. As usual the hard part is having the planner figure out *when* to use it. We have a hard enough time calculating ndistinct for individual columns -- this would require having an idea of how many values are present for each major key column. -- 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] MMAP Buffers
On Sun, 17 Apr 2011 21:06:17 -0400, Robert Haas wrote: On Sun, Apr 17, 2011 at 5:32 PM, Radosław Smogura rsmog...@softperience.eu wrote: Each process has simple mirror of shared descriptors. I believe that modifications to buffer content may be only done when holding exclusive lock (with some simple exceptions) (+ MVCC), actually I saw only two things that can change already loaded data and cause damage, you have described (setting hint bits during scan, and vacuum - 1st may only cause, I think, that two processes will ask for same transaction statuses except vacuum, 2nd one is impossible as vacumm requires exclusive pin). When buffer tag is changed the version of buffer is bumped up, and checked against local version - this about reading buffer. Yes, an exclusive lock is required for substantive content changes. But if vacuum cleaning up the buffer is an issue for your patch, then it's probably also a problem if someone grabs an exclusive content lock and deletes the tuple (by setting XMAX) and some other backend later sees the old buffer contents after having in the meanwhile taken a new snapshot; or if likewise someone grabs an exclusive-lock, adds a tuple, and then your backend takes a new snapshot and then sees the old buffer contents. Basically, any time someone grabs an exclusive-lock and releases it, it's necessary for all observers to see the updated contents by the time the exclusive lock is released. In other cases after obtaining lock check is done if buffer has associated updatable buffer and if local mirror has it too, then swap should take place. I think this check would have to be done every time someone share-locks the buffer, which seems rather expensive. Logic about updatable buffers is similar to shared buffers, each updatable buffer has pin count, and updatable buffer can't be free if someone uses it, but in contrast to normal buffers, updatable buffers doesn't have any support for locking etc. Updatable buffers exists only on free list, or when associated with buffer. I don't see how you're going to get away with removing buffer locks. They exist for a reason, and adding mmap() to the mix is going to require MORE locking, not less. In future, I will change version to shared segment id, something like relation's oid + block, but ids will have continuous numbering 1,2,3..., so I will be able to bypass smgr/md during read, and tag version check - this looks like faster solution. I don't understand this part at all. To my previous post I want to clarify that updatable buffers are implemented in shared memory, so there is no way that process has own copy of data. Regards, Radek. -- 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] small bug in recoveryStopsHere()
On Fri, Apr 15, 2011 at 1:26 AM, Jaime Casanova ja...@2ndquadrant.com wrote: On Thu, Apr 14, 2011 at 1:30 PM, Robert Haas robertmh...@gmail.com wrote: I discovered while fooling around the other night that the named restore point patch introduced a small bug into recoveryStopsHere(): the test at the top of the function now lets through two resource-manager IDs rather than one, but the remainder of the function tests only the record_info flag and not the resource-manager-id. So the test for record_info == XLOG_XACT_COMMIT, for example, will also return true for an XLOG_CHECKPOINT_SHUTDOWN record, but the decoded commit time will be some random garbage rather than a commit time, because the format of the record is totally different. i guess, that's why i originally used a more complicated aproach (now i can breath again, i didn't fully reminded why i use that) ! couldStop = true; if (record-xl_rmid != RM_XACT_ID) ! couldStop = false; ! /* ! * Or when we found a named restore point ! */ record_info = record-xl_info ~XLR_INFO_MASK; + if ((record-xl_rmid == RM_XLOG_ID) (record_info == XLOG_RESTORE_POINT)) + couldStop = true; + + if (!couldStop) + return false; but i agree that your solution is more readible, i don't see any problems from here Thanks for the review; I've committed this. -- 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] Formatting Curmudgeons WAS: MMAP Buffers
On 04/18/2011 12:48 AM, Greg Smith wrote: Andrew Dunstan wrote: Now we could certainly make this quite a bit slicker. Apart from anything else, we should change the indent source code tarball so it unpacks into its own directory. Having it unpack into the current directory is ugly and unfriendly. And we should get rid of the make clean line in the install target of entab's makefile, which just seems totally ill-conceived. I think the script I submitted upthread has most of the additional slickness needed here. Looks like we both were working on documenting a reasonable way to do this at the same time the other day. The idea of any program here relying on being able to write to /usr/local/bin as your example did makes this harder for people to run; that's why I made everything in the build tree and just pushed the appropriate directories into the PATH. Since I see providing a script to automate this whole thing as the preferred way to make this easier, re-packaging the indent source tarball to extract to a directory doesn't seem worth the backwards compatibility trouble it will introduce. Improving the entab makefile I don't have an opinion on. Personally, I want pgindent installed in /usr/local/ or similar. That way I can have multiple trees and it will work in all of them without my having to build it for each. What I don't want is for the installed patched BSD indent to conflict with the system's indent, which is why I renamed it. If you still think that's a barrier to easy use, then I think we need a way to provide hooks in the makefiles for specifying the install location, so we can both be satisfied. Since there's no script I know of other than your prototype, I don't think repackaging is likely to break anything. That makes it worth doing *now* rather than later. But frankly, I'd rather do without an extra script if possible. It might also be worth setting it up so that instead of having to pass a path to a typedefs file on the command line, we default to a file sitting in, say, /usr/local/etc. Then you'd just be able to say pgindent my_file.c. OK, so I need to update my script to handle either indenting a single file, or doing all of them. Yes, very much. 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] WIP: Allow SQL-language functions to reference parameters by parameter name
On Thu, Apr 14, 2011 at 10:56 PM, Pavel Stehule pavel.steh...@gmail.com wrote: 2011/4/15 Jim Nasby j...@nasby.net: On Apr 14, 2011, at 4:20 PM, Kevin Grittner wrote: Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: So far the most promising proposal I've seen seems to be to let id mean the parameter called id only when it can't refer to anything in the query. Yeah, I've come round to that position too. I think allowing parameter names to be checked only after query names is probably the best answer. +1 That seems the most useful and least surprising approach to me. As part of this, can we also allow specifying an alias for the function name? That would make it far less onerous to disambiguate parameters. Unfortunately we obviously couldn't use AS as the keyword for this alias; maybe we could use ALIAS instead? IE: CREATE FUNCTION function_with_really_really_descriptive_name ( some_parameter int ) RETURNS int LANGUAGE SQL ALIAS fwrrdn AS $$ SELECT fwrrdn.some_parameter $$; -- I see this can be problem for other languages - mainly for PLpgSQL. There should be aliases supported too. And this small feature can be terible when somebody will try to port your code to other platforms. Personally I am thinking, so it isn't necessary -1 I don't much like Jim's syntax suggestion (the alias really ought to be declared within the function body, I think, not added to the CREATE FUNCTION statement) but I don't necessarily think it's a bad idea. What would be even better, in my view, is having a short alias that is defined by default, but all previous proposals in this vein have been shot down by Tom and Andrew. As a practical matter, though, I think what Jim is talking about speaks to a real need - people want to make SQL function names long and descriptive, but they do NOT want to spell out that long function name 16 times inside the function body. -- 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] switch UNLOGGED to LOGGED
I think I coded a very basic version of the UNLOGGED to LOGGED patch
(only wal_level=minimal case for the moment).
To remove the INIT fork, I changed somehow PendingRelDelete to have
a flag bool onlyInitFork so that the delete would remove only the INIT
fork at commit.
Everything works (note the quotes...) except in the case of not-clean
shutdown (-m immediate to pg_ctl stop). The reason is that the replay
code doesn't have any idea that it has to remove only the INIT fork: it will
remove ALL forks; so at the end of the redo procedure (at startup, after
a pg_ctl -m immediate stop) the table doesn't have any forks at all.
See xact_redo_commit:
/* Make sure files supposed to be dropped are dropped */
for (i = 0; i xlrec-nrels; i++)
{
[...]
for (fork = 0; fork = MAX_FORKNUM; fork++)
{
if (smgrexists(srel, fork))
{
XLogDropRelation(xlrec-xnodes[i], fork);
smgrdounlink(srel, fork, true);
}
}
smgrclose(srel);
}
[...]
Should I change xl_xact_commit in order to have, instead of:
/* Array of RelFileNode(s) to drop at commit */
RelFileNode xnodes[1]; /* VARIABLE LENGTH ARRAY */
an array of structures such as:
{
RelFileNode relfilenode;
bool onlyInitFork;
}
???
Otherwise I don't know how to tell the redo commit code to delete only
the INIT fork, instead of all the relation forks...
(maybe I'm doing all wrong: I'm open to any kind of suggestion here...)
Leonardo
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] JDBC connections to 9.1
I'm getting JDBC exceptions when I try to connect to 9.1 (master) with the postgresql-9.0-801.jdbc3.jar I don't have this issue with 9.0. There is nothing obvious at http://jdbc.postgresql.org or in the 9.1 alpha release notes that indicate a newer JDBC driver will be required. Have other people seen similar issues? If 9.1 does require a JDBC driver upgrade then it would be good if an updated driver was posted before we start encouraging people to test their applications with the beta. Caused by: org.postgresql.util.PSQLException: Protocol error. Session setup failed. at org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:496) at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:112) at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) at org.postgresql.jdbc2.AbstractJdbc2Connection.init(AbstractJdbc2Connection.java:125) at org.postgresql.jdbc3.AbstractJdbc3Connection.init(AbstractJdbc3Connection.java:30) at org.postgresql.jdbc3.Jdbc3Connection.init(Jdbc3Connection.java:24) at org.postgresql.Driver.makeConnection(Driver.java:393) at org.postgresql.Driver.connect(Driver.java:267) at java.sql.DriverManager.getConnection(DriverManager.java:620) at java.sql.DriverManager.getConnection(DriverManager.java:200) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:161) ... 14 more -- 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 connections to 9.1
Steve Singer ssin...@ca.afilias.info writes: I'm getting JDBC exceptions when I try to connect to 9.1 (master) with the postgresql-9.0-801.jdbc3.jar I don't have this issue with 9.0. Hmm, what shows up in the postmaster log? 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 connections to 9.1
--On 18. April 2011 09:44:38 -0400 Tom Lane t...@sss.pgh.pa.us wrote: I'm getting JDBC exceptions when I try to connect to 9.1 (master) with the postgresql-9.0-801.jdbc3.jar I don't have this issue with 9.0. Hmm, what shows up in the postmaster log? A quick check with an application here gives the following with JDBC loglevel=2 16:09:47.910 (1) PostgreSQL 9.1devel JDBC4 (build 900) 16:09:47.914 (1) Trying to establish a protocol version 3 connection to localhost:5438 16:09:47.930 (1) FE= StartupPacket(user=bernd, database=mailstore, client_encoding=UNICODE, DateStyle=ISO, extra_float_digits=2) 16:09:47.933 (1) =BE AuthenticationOk 16:09:47.942 (1) =BE ParameterStatus(application_name = ) 16:09:47.942 (1) =BE ParameterStatus(client_encoding = UTF8) org.postgresql.util.PSQLException: Protocol error. Session setup failed. at org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:498) at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:112) at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) at org.postgresql.jdbc2.AbstractJdbc2Connection.init(AbstractJdbc2Connection.java:125) at org.postgresql.jdbc3.AbstractJdbc3Connection.init(AbstractJdbc3Connection.java:30) at org.postgresql.jdbc3g.AbstractJdbc3gConnection.init(AbstractJdbc3gConnection.java:22) at org.postgresql.jdbc4.AbstractJdbc4Connection.init(AbstractJdbc4Connection.java:32) at org.postgresql.jdbc4.Jdbc4Connection.init(Jdbc4Connection.java:24) at org.postgresql.Driver.makeConnection(Driver.java:393) at org.postgresql.Driver.connect(Driver.java:267) at java.sql.DriverManager.getConnection(DriverManager.java:582) at java.sql.DriverManager.getConnection(DriverManager.java:154) at de.oopsware.mailstore.PGSQLMailstore.connect(Unknown Source) at de.oopsware.mailstore.PGSQLMailstore.connect(Unknown Source) at mailstore.main(Unknown Source) SQLException: SQLState(08P01) getConnection failed: org.postgresql.util.PSQLException: Protocol error. Session setup failed. org.postgresql.util.PSQLException: Protocol error. Session setup failed. Hmm, seems it stumbles while reading client_encoding -- 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] Typed table DDL loose ends
On Thu, Apr 14, 2011 at 9:38 PM, Noah Misch n...@leadboat.com wrote: On Thu, Apr 14, 2011 at 11:23:49AM -0700, Robert Haas wrote: On Thu, Apr 14, 2011 at 5:18 AM, Noah Misch n...@leadboat.com wrote: I guess my gut feeling is that it would make more sense to forbid it outright for 9.1, and we can look at relaxing that restriction later if we're so inclined. Much as with the problem Tom fixed in commit eb51af71f241e8cb199790dee9ad246bb36b3287, I'm concerned that there may be other cases that we're not thinking of right now, and while we could find them all and fix them, the amount of functionality gained is fairly marginal, and I don't really want to hold up the release while we bug-swat. Symmetry was the best cause I could find to continue allowing it, and your case in favor of reducing the bug surface is more compelling. ?Let's forbid it. OK. Care to propose a patch? Sure; attached. It requires that the type relation be RELKIND_COMPOSITE_TYPE. We hadn't explicitly discussed the use of foreign table, view, toast table, or sequence row types. The first two might have some value, someday; I'm sure nobody cares for the second two. It appears that this patch - which I've now committed - actually fixes two bugs. Without the patch, this leaves the tables out of step, because no relation lock is taken: S1: CREATE TYPE t AS (a int); S1: BEGIN; S1: CREATE TABLE t1 OF t; S2: ALTER TYPE t ADD ATTRIBUTE b int CASCADE; S1: COMMIT; I tweaked the comments accordingly, and also reverted your change to the error message, because I don't want to introduce new terminology here that we're not using anywhere else. I also thought about making this use parserOpenTable() rather than relation_open(), but it turns out that's not so easy, because the typed table name is getting shoved into a TypeName rather than a RangeVar. I don't think that's the choice I would have made but I'm not sure how excited it's worth getting about it. -- 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 connections to 9.1
On 11-04-18 09:44 AM, Tom Lane wrote: Steve Singerssin...@ca.afilias.info writes: I'm getting JDBC exceptions when I try to connect to 9.1 (master) with the postgresql-9.0-801.jdbc3.jar I don't have this issue with 9.0. Hmm, what shows up in the postmaster log? regards, tom lane LOG: unexpected EOF on client connection -- 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 connections to 9.1
On Mon, 2011-04-18 at 16:17 +0200, Bernd Helmle wrote: Hmm, seems it stumbles while reading client_encoding This is probably similar to what I had a couple weeks ago. With today's new minor releases, I get: $ psql psql: invalid connection option client_encoding (I was getting another message before) This is 9.1's psql connecting to 9.1's server. For some reason, psql uses 9.0 client libs, so if I export LD_LIBRARY_PATH, everything works: $ LD_LIBRARY_PATH=/usr/pgsql-9.1/lib psql ... Could it be the same thing? -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [HACKERS] JDBC connections to 9.1
--On 18. April 2011 16:17:57 +0200 Bernd Helmle maili...@oopsware.de wrote:
16:09:47.942 (1) =BE ParameterStatus(client_encoding = UTF8)
org.postgresql.util.PSQLException: Protocol error. Session setup failed.
at
org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFa
ctoryImpl.java:498)
ConnectionFactoryImpl.readStartupMessages() has this:
else if (name.equals(client_encoding))
{
if (!value.equals(UNICODE))
throw new PSQLException(GT.tr(Protocol error. Session
setup failed.), PSQLState.PROTOCOL_VIOLATION);
pgStream.setEncoding(Encoding.getDatabaseEncoding(UNICODE));
}
If i am reading it correct, it reads UTF8 from the backend, while expecting
UNICODE only. Not sure what change has caused this, though. If i extend the
check to include UTF8, everything seems to work.
--
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] Open issues for collations
Robert Haas robertmh...@gmail.com writes: [ assorted comments on original issues ] I believe that all the collation issues I complained about on 26 March are now resolved, except for the question of getting some more test cases, and the question of adding a cares-about-collation flag to pg_proc. I've added the latter to the TODO list since everybody agreed it was too late to consider it for 9.1. However, I've come across a new issue that maybe requires discussion: what collation should be associated with a multi-row VALUES in FROM? For instance, in SELECT ... FROM (VALUES (1, 'foo'), (2, 'bar' COLLATE C)) v(a,b), ... what collation should be imputed to references to v.b? The way the code currently works is that the first row of the VALUES list is inspected to determine what collation to report --- so in this example, you'd get default collation, ignoring the COLLATE clause in the second row. There are several problems with this: 1. I think it violates the SQL spec. SQL:2008 7.3 table value constructor says that the column types of a VALUES construct are resolved per the rules of section 9.3, and 9.3 is the one with the standard verbiage about resolving a common collation, so it's hard to see how use the first row and ignore the rest satisfies the spec. 2. It doesn't seem to satisfy the POLA --- in the above example, ignoring the explicit COLLATE clause is rather surprising. We could document that that's what it does, perhaps, but if you can attach COLLATE to any input of an operator or function and get the same results, it's hard to explain why the same isn't true of a VALUES column. Especially when VALUES resolves data types in a much more symmetrical fashion, eg this works: (VALUES (1, '1'), (2, '2'::real)) v(a,b) 3. It's not hard to imagine people thinking they can get row-by-row- varying collation behavior from something like SELECT ... FROM (VALUES (1, 'foo' COLLATE en_US), (2, 'bar' COLLATE C)) v(a,b), ... So not throwing an error, but rather silently doing something other than what this SQL seems to say, seems pretty unfriendly to me. The reason I'm expending so much verbiage on this is that fixing it seems to require an addition to struct RangeTblEntry, ie, a catversion bump and forced initdb, so that we can store a list of the resolved column collations for an RTE_VALUES RTE. I don't really think there's much choice though. Comments? 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] Typed table DDL loose ends
On Mon, Apr 18, 2011 at 10:20:21AM -0400, Robert Haas wrote: I tweaked the comments accordingly, and also reverted your change to the error message, because I don't want to introduce new terminology here that we're not using anywhere else. FWIW, the term stand-alone composite type appears twice in our documentation. I also thought about making this use parserOpenTable() rather than relation_open(), but it turns out that's not so easy, because the typed table name is getting shoved into a TypeName rather than a RangeVar. I don't think that's the choice I would have made but I'm not sure how excited it's worth getting about it. I hadn't thought about this angle. -- 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 connections to 9.1
Bernd Helmle maili...@oopsware.de writes: If i am reading it correct, it reads UTF8 from the backend, while expecting UNICODE only. Not sure what change has caused this, though. I am --- when I redid the GUC assign_hook logic a few weeks ago, I changed the client_encoding code so that it shows the normalized (official) name of the encoding, not whatever random string the client sent over. For instance, previous versions: regression=# set client_encoding = 'UnIcOdE'; SET regression=# show client_encoding ; client_encoding - UnIcOdE (1 row) versus HEAD: regression=# set client_encoding = 'UnIcOdE'; SET regression=# show client_encoding ; client_encoding - UTF8 (1 row) I wasn't aware that JDBC would fail on that. It's pretty annoying that it does, but maybe we should grin and bear it, ie revert the change to canonicalize the GUC's value? 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] Typed table DDL loose ends
On Mon, Apr 18, 2011 at 10:48 AM, Noah Misch n...@leadboat.com wrote: On Mon, Apr 18, 2011 at 10:20:21AM -0400, Robert Haas wrote: I tweaked the comments accordingly, and also reverted your change to the error message, because I don't want to introduce new terminology here that we're not using anywhere else. FWIW, the term stand-alone composite type appears twice in our documentation. Hmm, OK. Anyone else have an opinion on the relative merits of: ERROR: type stuff is not a composite type vs. ERROR: type stuff is not a stand-alone composite type The intent of adding stand-alone was, I believe, to clarify that it has to be a CREATE TYPE stuff AS ... type, not just a row type (that is, naturally, composite, in some less-pure sense). I'm not sure whether the extra word actually makes it more clear, though. Opinions? Suggestions? -- 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 connections to 9.1
On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: Bernd Helmle maili...@oopsware.de writes: If i am reading it correct, it reads UTF8 from the backend, while expecting UNICODE only. Not sure what change has caused this, though. I am --- when I redid the GUC assign_hook logic a few weeks ago, I changed the client_encoding code so that it shows the normalized (official) name of the encoding, not whatever random string the client sent over. For instance, previous versions: regression=# set client_encoding = 'UnIcOdE'; SET regression=# show client_encoding ; client_encoding - UnIcOdE (1 row) versus HEAD: regression=# set client_encoding = 'UnIcOdE'; SET regression=# show client_encoding ; client_encoding - UTF8 (1 row) I wasn't aware that JDBC would fail on that. It's pretty annoying that it does, but maybe we should grin and bear it, ie revert the change to canonicalize the GUC's value? Ouch. I hate to revert that, since it seems like a clear improvement. But I also hate to break JDBC. Ouch. -- 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: [JDBC] [HACKERS] JDBC connections to 9.1
On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: Bernd Helmle maili...@oopsware.de writes: If i am reading it correct, it reads UTF8 from the backend, while expecting UNICODE only. Not sure what change has caused this, though. I am --- when I redid the GUC assign_hook logic a few weeks ago, I changed the client_encoding code so that it shows the normalized (official) name of the encoding, not whatever random string the client sent over. For instance, previous versions: regression=# set client_encoding = 'UnIcOdE'; SET regression=# show client_encoding ; client_encoding - UnIcOdE (1 row) versus HEAD: regression=# set client_encoding = 'UnIcOdE'; SET regression=# show client_encoding ; client_encoding - UTF8 (1 row) I wasn't aware that JDBC would fail on that. It's pretty annoying that it does, but maybe we should grin and bear it, ie revert the change to canonicalize the GUC's value? regards, tom lane Older drivers will fail for sure. We can fix newer drivers, but if we leave it we will see a slew of bug reports. The reason the driver does this is to guarantee the client encoding is unicode. Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca -- 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 connections to 9.1
Tom Lane t...@sss.pgh.pa.us wrote: I changed the client_encoding code so that it shows the normalized (official) name of the encoding, not whatever random string the client sent over. For instance, previous versions: regression=# set client_encoding = 'UnIcOdE'; SET The whole area of character sets and encoding schemes is confusing enough without accepting a character set name as an encoding scheme specification. I'll bet that in five or ten years we'll be accepting more than one encoding scheme for the Unicode character set. I wasn't aware that JDBC would fail on that. It's pretty annoying that it does, but maybe we should grin and bear it, ie revert the change to canonicalize the GUC's value? Can we fix the JDBC driver rather than reverting this? Long run, I'd be in favor of just rejecting a character set name as a client encoding specification. I think inferring one is being generous. -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: [JDBC] [HACKERS] JDBC connections to 9.1
On 18/04/11 15:57, Tom Lane wrote: Bernd Helmlemaili...@oopsware.de writes: If i am reading it correct, it reads UTF8 from the backend, while expecting UNICODE only. Not sure what change has caused this, though. I am --- when I redid the GUC assign_hook logic a few weeks ago, I changed the client_encoding code so that it shows the normalized (official) name of the encoding, not whatever random string the client sent over. For instance, previous versions: regression=# set client_encoding = 'UnIcOdE'; SET regression=# show client_encoding ; client_encoding - UnIcOdE (1 row) versus HEAD: regression=# set client_encoding = 'UnIcOdE'; SET regression=# show client_encoding ; client_encoding - UTF8 (1 row) I wasn't aware that JDBC would fail on that. It's pretty annoying that it does, but maybe we should grin and bear it, ie revert the change to canonicalize the GUC's value? regards, tom lane Am I right in thinking that would be that change committed on the 7th (http://archives.postgresql.org/pgsql-committers/2011-04/msg00039.php) ? I've just run the JDBC test build on my machine and it fails dismally with this very message repeated over and over again. What concerns me most is that (assuming my dates are right) the JDBC driver has been broken for 11 days and no one noticed. This would lead me to believe that there is no JDBC build server. What would it take to set one up? If someone can point me to a test machine I'd happily assist in setting one up. As for the breakage itself I'm OK with a new driver version for a new database version and from my experience people expect that. I recall a number of people asking me if an 8.4 driver would be OK to use against 9 before the 9 version was stable. Regards, -- 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: [JDBC] [HACKERS] JDBC connections to 9.1
On Mon, Apr 18, 2011 at 11:14 AM, Mike Fowler m...@mlfowler.com wrote: On 18/04/11 15:57, Tom Lane wrote: Bernd Helmlemaili...@oopsware.de writes: If i am reading it correct, it reads UTF8 from the backend, while expecting UNICODE only. Not sure what change has caused this, though. I am --- when I redid the GUC assign_hook logic a few weeks ago, I changed the client_encoding code so that it shows the normalized (official) name of the encoding, not whatever random string the client sent over. For instance, previous versions: regression=# set client_encoding = 'UnIcOdE'; SET regression=# show client_encoding ; client_encoding - UnIcOdE (1 row) versus HEAD: regression=# set client_encoding = 'UnIcOdE'; SET regression=# show client_encoding ; client_encoding - UTF8 (1 row) I wasn't aware that JDBC would fail on that. It's pretty annoying that it does, but maybe we should grin and bear it, ie revert the change to canonicalize the GUC's value? regards, tom lane Am I right in thinking that would be that change committed on the 7th (http://archives.postgresql.org/pgsql-committers/2011-04/msg00039.php) ? I've just run the JDBC test build on my machine and it fails dismally with this very message repeated over and over again. What concerns me most is that (assuming my dates are right) the JDBC driver has been broken for 11 days and no one noticed. This would lead me to believe that there is no JDBC build server. What would it take to set one up? If someone can point me to a test machine I'd happily assist in setting one up. As for the breakage itself I'm OK with a new driver version for a new database version and from my experience people expect that. I recall a number of people asking me if an 8.4 driver would be OK to use against 9 before the 9 version was stable. Regards, One would need a machine which supports java 1.4, 1.5, and 1.6 since the driver builds all 3 versions. There's actually a 4th between 1.4 and 1.5 but I don't recall the specifics Dave -- Mike Fowler Registered Linux user: 379787 -- Sent via pgsql-jdbc mailing list (pgsql-j...@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-jdbc -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [JDBC] [HACKERS] JDBC connections to 9.1
Dave Cramer p...@fastcrypt.com writes: On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: I wasn't aware that JDBC would fail on that. It's pretty annoying that it does, but maybe we should grin and bear it, ie revert the change to canonicalize the GUC's value? Older drivers will fail for sure. We can fix newer drivers, but if we leave it we will see a slew of bug reports. Yeah. I'm thinking what we should do here is revert the change, with a note in the source about why, and also change the JDBC driver to send and expect UTF8 not UNICODE (which as Kevin says is more correct anyway). Then in a few releases' time we can un-revert the server change. 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: [JDBC] [HACKERS] JDBC connections to 9.1
Mike Fowler m...@mlfowler.com writes: On 18/04/11 15:57, Tom Lane wrote: I am --- when I redid the GUC assign_hook logic a few weeks ago, I changed the client_encoding code so that it shows the normalized (official) name of the encoding, not whatever random string the client sent over. For instance, previous versions: Am I right in thinking that would be that change committed on the 7th (http://archives.postgresql.org/pgsql-committers/2011-04/msg00039.php) ? Yes, that one. What concerns me most is that (assuming my dates are right) the JDBC driver has been broken for 11 days and no one noticed. This would lead me to believe that there is no JDBC build server. What would it take to set one up? +1 for doing something along that line. 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] Typed table DDL loose ends
Robert Haas robertmh...@gmail.com writes: On Mon, Apr 18, 2011 at 10:48 AM, Noah Misch n...@leadboat.com wrote: FWIW, the term stand-alone composite type appears twice in our documentation. Hmm, OK. Anyone else have an opinion on the relative merits of: ERROR: type stuff is not a composite type vs. ERROR: type stuff is not a stand-alone composite type The intent of adding stand-alone was, I believe, to clarify that it has to be a CREATE TYPE stuff AS ... type, not just a row type (that is, naturally, composite, in some less-pure sense). I'm not sure whether the extra word actually makes it more clear, though. In 99.9% of the code and docs, a table rowtype is a perfectly good composite type. I agree with Noah that just saying composite type is inadequate here; but I'm not sure that stand-alone is a helpful adjective either. What about inverting the message phrasing, ie ERROR: type stuff must not be a table's row type You might need some extra logic to keep on giving is not a composite type in cases where it's not composite at all. But this is enough of a departure from our usual behavior that I think the error message had better be pretty darn clear. 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] Typed table DDL loose ends
On Mon, Apr 18, 2011 at 11:33 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Mon, Apr 18, 2011 at 10:48 AM, Noah Misch n...@leadboat.com wrote: FWIW, the term stand-alone composite type appears twice in our documentation. Hmm, OK. Anyone else have an opinion on the relative merits of: ERROR: type stuff is not a composite type vs. ERROR: type stuff is not a stand-alone composite type The intent of adding stand-alone was, I believe, to clarify that it has to be a CREATE TYPE stuff AS ... type, not just a row type (that is, naturally, composite, in some less-pure sense). I'm not sure whether the extra word actually makes it more clear, though. In 99.9% of the code and docs, a table rowtype is a perfectly good composite type. I agree with Noah that just saying composite type is inadequate here; but I'm not sure that stand-alone is a helpful adjective either. What about inverting the message phrasing, ie ERROR: type stuff must not be a table's row type It also can't be a view's row type, a sequence's row type, a foreign table's row type... -- 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: [JDBC] [HACKERS] JDBC connections to 9.1
On Mon, Apr 18, 2011 at 11:24 AM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Cramer p...@fastcrypt.com writes: On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: I wasn't aware that JDBC would fail on that. It's pretty annoying that it does, but maybe we should grin and bear it, ie revert the change to canonicalize the GUC's value? Older drivers will fail for sure. We can fix newer drivers, but if we leave it we will see a slew of bug reports. Yeah. I'm thinking what we should do here is revert the change, with a note in the source about why, and also change the JDBC driver to send and expect UTF8 not UNICODE (which as Kevin says is more correct anyway). Then in a few releases' time we can un-revert the server change. Well initially my concern was that people would have a challenge in the case where they had to re-certify their application if we made this change, however I realize they will have to do this anyway since upgrading to 9.1 is what necessitates it. So I'm less concerned with bug reports since people can just upgrade both Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca -- 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] Typed table DDL loose ends
Robert Haas robertmh...@gmail.com writes: On Mon, Apr 18, 2011 at 11:33 AM, Tom Lane t...@sss.pgh.pa.us wrote: What about inverting the message phrasing, ie ERROR: type stuff must not be a table's row type It also can't be a view's row type, a sequence's row type, a foreign table's row type... Well, you could say relation's row type if you wanted to be formally correct, but I'm not convinced that's an improvement. 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] Typed table DDL loose ends
On Mon, Apr 18, 2011 at 11:46 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Mon, Apr 18, 2011 at 11:33 AM, Tom Lane t...@sss.pgh.pa.us wrote: What about inverting the message phrasing, ie ERROR: type stuff must not be a table's row type It also can't be a view's row type, a sequence's row type, a foreign table's row type... Well, you could say relation's row type if you wanted to be formally correct, but I'm not convinced that's an improvement. Me neither, especially since composite types are also relations, in our parlance. I'm not strongly attached to or repulsed by any particular option, so however we end up doing it is OK with me. -- 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: [JDBC] [HACKERS] JDBC connections to 9.1
Dave Cramer p...@fastcrypt.com writes: On Mon, Apr 18, 2011 at 11:24 AM, Tom Lane t...@sss.pgh.pa.us wrote: Yeah. I'm thinking what we should do here is revert the change, with a note in the source about why, and also change the JDBC driver to send and expect UTF8 not UNICODE (which as Kevin says is more correct anyway). Then in a few releases' time we can un-revert the server change. Well initially my concern was that people would have a challenge in the case where they had to re-certify their application if we made this change, however I realize they will have to do this anyway since upgrading to 9.1 is what necessitates it. I don't see any backwards compatibility risk, if that's what you mean. Every backend release since 7.3 has treated client_encoding 'UTF8' and 'UNICODE' the same, and earlier releases didn't accept either one. 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] switch UNLOGGED to LOGGED
Excerpts from Leonardo Francalanci's message of lun abr 18 09:36:13 -0300 2011: I think I coded a very basic version of the UNLOGGED to LOGGED patch (only wal_level=minimal case for the moment). To remove the INIT fork, I changed somehow PendingRelDelete to have a flag bool onlyInitFork so that the delete would remove only the INIT fork at commit. Everything works (note the quotes...) except in the case of not-clean shutdown (-m immediate to pg_ctl stop). The reason is that the replay code doesn't have any idea that it has to remove only the INIT fork: it will remove ALL forks; so at the end of the redo procedure (at startup, after a pg_ctl -m immediate stop) the table doesn't have any forks at all. Maybe you should change xl_act_commit to have a separate list of rels to drop the init fork for (instead of mixing those with the list of files to drop as a whole). -- Á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] WIP: Allow SQL-language functions to reference parameters by parameter name
Excerpts from Robert Haas's message of lun abr 18 09:33:06 -0300 2011: I don't much like Jim's syntax suggestion (the alias really ought to be declared within the function body, I think, not added to the CREATE FUNCTION statement) but I don't necessarily think it's a bad idea. What would be even better, in my view, is having a short alias that is defined by default, but all previous proposals in this vein have been shot down by Tom and Andrew. As a practical matter, though, I think what Jim is talking about speaks to a real need - people want to make SQL function names long and descriptive, but they do NOT want to spell out that long function name 16 times inside the function body. plpgsql has the #option thing in functions; why can't we have something similar in SQL functions? CREATE FUNCTION function_with_really_really_descriptive_name ( some_parameter int ) RETURNS int LANGUAGE SQL AS $$ #option function_alias fwrrdn SELECT fwrrdn.some_parameter $$; Not necessarily that exact syntax. -- Á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: [JDBC] [HACKERS] JDBC connections to 9.1
On 04/18/2011 11:25 AM, Tom Lane wrote: What concerns me most is that (assuming my dates are right) the JDBC driver has been broken for 11 days and no one noticed. This would lead me to believe that there is no JDBC build server. What would it take to set one up? +1 for doing something along that line. All you'd need to do is write a step for a buildfarm animal to fetch the JDBC driver and run some tests, and run it in a buildfarm client somewhere. The server code is quite agnostic about the steps that are reported on. IOW in addition to a running buildfarm member you need to write a small amount ( 100 lines, possibly much less) of perl code. 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] Evaluation of secondary sort key.
On 2011-04-18 11:00, Greg Stark wrote: On Mon, Apr 18, 2011 at 6:25 AM, Jesper Kroghjes...@krogh.cc wrote: Getting the value for the first sortkey and carrying on a closure for the rest would mostly (very often) be optimal ? Well that might depend. The input data to the function might be much larger than the output. Consider the, quite common, idiom of: order by case when (complex expresssion) 1 when (complex expression) 2 else 3 How come that expression be relevant? There is only one sortkey and no limit, so no matter what it should clearly get the full resultset in all cases. It would also enable a select that has to sortkeys to utilize an index that only contains the primary sortkey, which is a huge negative effect of what's being done today. This is a separate problem entirely. It would be nice to have a strategy for ordering that can take advantage of partially ordered results. It's not hard to see how to do the executor side -- it could keep a tuplesort for each group and truncate it when the group changes. As usual the hard part is having the planner figure out *when* to use it. We have a hard enough time calculating ndistinct for individual columns -- this would require having an idea of how many values are present for each major key column. Yes, as with all other cases it would be hard to get the optimum, but there is also cases where it is straightforward, say when the secondary sort column has an ndistinct of -1 (or similar close to). The current standard assumption is that 2 columns are unrelated, that would also work here. (As good as is does similar places in PG). Jesper -- Jesper -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [JDBC] [HACKERS] JDBC connections to 9.1
On 18/04/11 17:35, Andrew Dunstan wrote: On 04/18/2011 11:25 AM, Tom Lane wrote: What concerns me most is that (assuming my dates are right) the JDBC driver has been broken for 11 days and no one noticed. This would lead me to believe that there is no JDBC build server. What would it take to set one up? +1 for doing something along that line. All you'd need to do is write a step for a buildfarm animal to fetch the JDBC driver and run some tests, and run it in a buildfarm client somewhere. The server code is quite agnostic about the steps that are reported on. IOW in addition to a running buildfarm member you need to write a small amount ( 100 lines, possibly much less) of perl code. cheers andrew I've found the entry on the Developer Wiki (http://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto). What I'll do is set-up three farms on my machine - one for 1.4, one for 1.5 and one for 1.6. It's been a while since I've had an excuse to write some Perl! I can't guarantee when I'll have it done as I'm away for a little over a week from Wednesday and I'm not allowed internet access! Regards, -- 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] Formatting Curmudgeons WAS: MMAP Buffers
Excerpts from Tom Lane's message of lun abr 18 02:50:22 -0300 2011: Robert Haas robertmh...@gmail.com writes: ... Maybe someone out there is under the impression that I get high off of rejecting patches; but the statistics you cite from the CF app don't exactly support the contention that I'm going around looking for reasons to reject things, or if I am, I'm doing a pretty terrible job finding them. Hm ... there are people out there who think *I* get high off rejecting patches. I have a t-shirt to prove it. But I seem to be pretty ineffective at it too, judging from these numbers. Does this mean we need an auction to get Robert a nice $1000 t-shirt? -- Á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] Windows 64 bit warnings
Excerpts from Andrew Dunstan's message of sáb abr 16 21:46:44 -0300 2011: The other, slightly more serious case, is at src/test/regress/pg_regress.c:2280, which is this code: printf(_(running on port %d with pid %lu\n), port, (unsigned long) postmaster_pid); Here the postmaster_pid is in fact a HANDLE which is 8 bytes, and so it should probably be cast to an unsigned long long and rendered with the format %llu in Win64. Is this uint64 and UINT64_FORMAT? -- Á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] WIP: Allow SQL-language functions to reference parameters by parameter name
On Mon, Apr 18, 2011 at 11:33 AM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Robert Haas's message of lun abr 18 09:33:06 -0300 2011: I don't much like Jim's syntax suggestion (the alias really ought to be declared within the function body, I think, not added to the CREATE FUNCTION statement) but I don't necessarily think it's a bad idea. What would be even better, in my view, is having a short alias that is defined by default, but all previous proposals in this vein have been shot down by Tom and Andrew. As a practical matter, though, I think what Jim is talking about speaks to a real need - people want to make SQL function names long and descriptive, but they do NOT want to spell out that long function name 16 times inside the function body. plpgsql has the #option thing in functions; why can't we have something similar in SQL functions? CREATE FUNCTION function_with_really_really_descriptive_name ( some_parameter int ) RETURNS int LANGUAGE SQL AS $$ #option function_alias fwrrdn SELECT fwrrdn.some_parameter $$; Not necessarily that exact syntax. If we are rejecting $foo on grounds of deviating from sql standard, shouldn't this be rejected on the same grounds? There is no such syntax in sql/psm. merlin -- 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] Formatting Curmudgeons WAS: MMAP Buffers
Robert, Tom, Hm ... there are people out there who think *I* get high off rejecting patches. I have a t-shirt to prove it. But I seem to be pretty ineffective at it too, judging from these numbers. It's a question of how we reject patches, especially first-time patches. We can reject them in a way which makes the submitter more likely to fix them and/or work on something else, or we can reject them in a way which discourages people from submitting to PostgreSQL at all. For example, the emails to Radoslaw mentioned nothing about pg_ident, documented spacing requirements, accidental inclusion of files he didn't mean to touch, etc. Instead, a couple of people told him he should abandon his chosen development IDE in favor of emacs or vim. Radoslaw happens to be thick-skinned and persistent, but other first-time submitters would have given up at that point and run off to a more welcoming project. Mind, even better would be to get our so you're submitting a patch documentation and tools into shape; that way, all we need to do is send the first-time submitter a link. Will work on that between testing ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [JDBC] [HACKERS] JDBC connections to 9.1
On 18/04/11 17:12, Tom Lane wrote:
Dave Cramerp...@fastcrypt.com writes:
Well initially my concern was that people would have a challenge in
the case where they had to re-certify their application if we made
this change, however I realize they will have to do this anyway since
upgrading to 9.1 is what necessitates it.
I don't see any backwards compatibility risk, if that's what you mean.
Every backend release since 7.3 has treated client_encoding 'UTF8' and
'UNICODE' the same, and earlier releases didn't accept either one.
regards, tom lane
As there seems to be a consensus forming for fixing the JDBC driver,
I've taken the liberty do so at the risk of being shot down. The patch
is fairly straightforward, just changing UNICODE to UTF8 in a number of
files including the translation files. I've tested this against 9.1devel
(HEAD) and 8.4.7. For each database version I build and the tests
running JDKs 1.4.2_19, 1.5.0_22 and 1.6.0_2. All on 32-bit.
Regards,
--
Mike Fowler
Registered Linux user: 379787
Index: doc/pgjdbc.xml
===
RCS file: /cvsroot/jdbc/pgjdbc/doc/pgjdbc.xml,v
retrieving revision 1.40
diff -c -r1.40 pgjdbc.xml
*** doc/pgjdbc.xml 25 Dec 2010 07:07:44 - 1.40
--- doc/pgjdbc.xml 18 Apr 2011 16:32:49 -
***
*** 179,185
encoding and you will have problems the moment you store data in it that
does not fit in the seven bit acronymASCII/acronym character set.
If you do not know what your encoding will be or are otherwise unsure
! about what you will be storing the literalUNICODE/literal encoding
is a reasonable default to use.
/para
/sect1
--- 179,185
encoding and you will have problems the moment you store data in it that
does not fit in the seven bit acronymASCII/acronym character set.
If you do not know what your encoding will be or are otherwise unsure
! about what you will be storing the literalUTF8/literal encoding
is a reasonable default to use.
/para
/sect1
Index: org/postgresql/core/BaseConnection.java
===
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/core/BaseConnection.java,v
retrieving revision 1.23
diff -c -r1.23 BaseConnection.java
*** org/postgresql/core/BaseConnection.java 1 May 2010 14:40:51 - 1.23
--- org/postgresql/core/BaseConnection.java 18 Apr 2011 16:32:49 -
***
*** 96,102
/**
* Encode a string using the database's client_encoding
! * (usually UNICODE, but can vary on older server versions).
* This is used when constructing synthetic resultsets (for
* example, in metadata methods).
*
--- 96,102
/**
* Encode a string using the database's client_encoding
! * (usually UTF8, but can vary on older server versions).
* This is used when constructing synthetic resultsets (for
* example, in metadata methods).
*
Index: org/postgresql/core/v2/ConnectionFactoryImpl.java
===
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/core/v2/ConnectionFactoryImpl.java,v
retrieving revision 1.21
diff -c -r1.21 ConnectionFactoryImpl.java
*** org/postgresql/core/v2/ConnectionFactoryImpl.java 31 Mar 2011 03:06:38 - 1.21
--- org/postgresql/core/v2/ConnectionFactoryImpl.java 18 Apr 2011 16:32:49 -
***
*** 380,388
// 7.3 server that defaults to autocommit = off.
if (logger.logDebug())
! logger.debug(Switching to UNICODE client_encoding);
! String sql = begin; set autocommit = on; set client_encoding = 'UNICODE'; ;
if (dbVersion.compareTo(9.0) = 0) {
sql += SET extra_float_digits=3; ;
} else if (dbVersion.compareTo(7.4) = 0) {
--- 380,388
// 7.3 server that defaults to autocommit = off.
if (logger.logDebug())
! logger.debug(Switching to UTF8 client_encoding);
! String sql = begin; set autocommit = on; set client_encoding = 'UTF8'; ;
if (dbVersion.compareTo(9.0) = 0) {
sql += SET extra_float_digits=3; ;
} else if (dbVersion.compareTo(7.4) = 0) {
***
*** 391,397
sql += commit;
SetupQueryRunner.run(protoConnection, sql, false);
! protoConnection.setEncoding(Encoding.getDatabaseEncoding(UNICODE));
}
else
{
--- 391,397
sql += commit;
SetupQueryRunner.run(protoConnection, sql, false);
! protoConnection.setEncoding(Encoding.getDatabaseEncoding(UTF8));
}
else
{
Index: org/postgresql/core/v3/ConnectionFactoryImpl.java
Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers
On 4/18/11 10:57 AM, Robert Haas wrote: So first of all, no it's not fixable with sed. But secondly, writing *please* here seems to evince a level of frustration which is entirely out of proportion to the really rather mild comments which preceded it. What made you write it that way? I'll admit that the conversation I'd had at the Drizzle BOF the previous night strongly influenced me. to this continual commentary that we are not nice enough to people, especially newcomers. Well, OK, maybe we're not. But you know what? We're trying really hard, and getting accused of being nasty when we actually weren't is kind of a tough pill to swallow ... But in this case I think you were too quick off the trigger Well, my apologies to you. You are probably correct. In any case, I think the answer to this is constructive; better documentation and tools to let submitters get their code into good shape in the first place so that we don't have discussions about formatting. That way we waste *neither* the reviewers' nor the submitters' time. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.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] Formatting Curmudgeons WAS: MMAP Buffers
Does this mean we need an auction to get Robert a nice $1000 t-shirt? ... starting hunting through Robert's emails for a good quote ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.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] Typed table DDL loose ends
On Sat, 2011-04-09 at 21:57 -0400, Noah Misch wrote: * Table row types used in typed tables vs. ALTER TABLE This item was addressed, but the other ones were not, I think. * Inheriting from a typed table blocks further type DDL CREATE TYPE t AS (x int); CREATE TABLE parent OF t; CREATE TABLE child () INHERITS (parent); ALTER TYPE t ADD ATTRIBUTE y int CASCADE; -- ERROR: column must be added to child tables too We ought to just set INH_YES on the downstream command in ATTypedTableRecursion. If we get to that point, the user did choose ALTER TYPE CASCADE; it seems fair to assume he'd want inheritance recursion rather than a later error. Agreed. * Users can CREATE TABLE OF on a type they don't own This in turns blocks the owner's ability to alter the table/type. However, we already have this hazard with composite-type columns. A TODO to address this broadly seems in order, but it's not a 9.1 issue. I think we should change that to mirror the inheritance policy: you have to be the owner of the parent. Note that this is newly relevant in 9.1, because you couldn't change composite types before. * Can create a permanent table using a temp table row type CREATE TEMP TABLE tempt (); CREATE TABLE permt OF tempt; -- silently dropped on session exit Looks easy to fix, with no policy questions. This is now prohibited. -- 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] Open issues for collations
On Mon, 2011-04-18 at 10:41 -0400, Tom Lane wrote: However, I've come across a new issue that maybe requires discussion: what collation should be associated with a multi-row VALUES in FROM? For instance, in SELECT ... FROM (VALUES (1, 'foo'), (2, 'bar' COLLATE C)) v(a,b), ... what collation should be imputed to references to v.b? The way the code currently works is that the first row of the VALUES list is inspected to determine what collation to report Hmm, I do see this on my list of things to address, so yes, it should be fixed. I likely got stuck because it's pretty complicated. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ORDER BY 1 COLLATE
This came from a review by Noah Misch a great while ago: test= SELECT b FROM foo ORDER BY 1 COLLATE C; ERROR: 42804: collations are not supported by type integer According to SQL92, this should be supported. Do we want to bother? It doesn't look hard to fix, so it's really only a question of whether this would be useful, or its absence would be too confusing. -- 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] ORDER BY 1 COLLATE
Peter Eisentraut pete...@gmx.net writes: This came from a review by Noah Misch a great while ago: test= SELECT b FROM foo ORDER BY 1 COLLATE C; ERROR: 42804: collations are not supported by type integer According to SQL92, this should be supported. Do we want to bother? It doesn't look hard to fix, so it's really only a question of whether this would be useful, or its absence would be too confusing. The ORDER BY 1 business seems to me to be legacy anyway. I'm not inclined to put in even more hacks to make strange combinations work there --- I think we're likely to find ourselves painted into a corner someday as it is. 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] ORDER BY 1 COLLATE
On 04/18/2011 04:20 PM, Tom Lane wrote: Peter Eisentrautpete...@gmx.net writes: This came from a review by Noah Misch a great while ago: test= SELECT b FROM foo ORDER BY 1 COLLATE C; ERROR: 42804: collations are not supported by type integer According to SQL92, this should be supported. Do we want to bother? It doesn't look hard to fix, so it's really only a question of whether this would be useful, or its absence would be too confusing. The ORDER BY 1 business seems to me to be legacy anyway. I'm not inclined to put in even more hacks to make strange combinations work there --- I think we're likely to find ourselves painted into a corner someday as it is. It's likely to be used by SQL generators if nothing else, and I've been known to use it as a very convenient shorthand. It would seem to me like quite a strange inconsistency to allow order by n with some qualifiers but not others. 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] ORDER BY 1 COLLATE
-Original Message- From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- ow...@postgresql.org] On Behalf Of Andrew Dunstan Sent: Monday, April 18, 2011 1:43 PM To: Tom Lane Cc: Peter Eisentraut; pgsql-hackers Subject: Re: [HACKERS] ORDER BY 1 COLLATE On 04/18/2011 04:20 PM, Tom Lane wrote: Peter Eisentrautpete...@gmx.net writes: This came from a review by Noah Misch a great while ago: test= SELECT b FROM foo ORDER BY 1 COLLATE C; ERROR: 42804: collations are not supported by type integer According to SQL92, this should be supported. Do we want to bother? It doesn't look hard to fix, so it's really only a question of whether this would be useful, or its absence would be too confusing. The ORDER BY 1 business seems to me to be legacy anyway. I'm not inclined to put in even more hacks to make strange combinations work there --- I think we're likely to find ourselves painted into a corner someday as it is. It's likely to be used by SQL generators if nothing else, and I've been known to use it as a very convenient shorthand. It would seem to me like quite a strange inconsistency to allow order by n with some qualifiers but not others. I use order by result_set_column_number a lot, especially when result_set_column is a complicated expression. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pgbench \for or similar loop
Hi, Today (and previously) I wished that pgbench had a mechanism to help create simple random databases. For example, I could create a table tenk and fill it with random stuff like \setrandom foo 1 1 insert into foo values (:foo) Now I have to run this 1 times or something like that. But I don't want a transaction for each of those, so I had a desire for something like this: begin; \for iterator 1 1 \setrandom foo 1 :iterator insert into foo values (:foo); \end commit; Would something like this be acceptable? -- Álvaro Herrera alvhe...@alvh.no-ip.org -- 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] ORDER BY 1 COLLATE
Andrew Dunstan and...@dunslane.net wrote: It's likely to be used by SQL generators if nothing else, and I've been known to use it as a very convenient shorthand. It would seem to me like quite a strange inconsistency to allow order by n with some qualifiers but not others. That's pretty much how I feel. Like SELECT * or an INSERT without a target column list, I wouldn't want to see it used in production, but it saves time when hacking around in a development database or running ad hoc queries. If we didn't support it, the inconsistency would be odd, and we would need to document it as a deviation from the standard. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Still need mentor for advanced indexing project -- GSOC
Hackers, We're short one mentor for Google Summer of Code. There's one advanced indexing project we'd really really like to accept, but we cannot because we don't have a mentor who feels up to it. If you didn't previously volunteer to be a GSOC mentor, and might be able to help a student through working with custom data types, GiST/GIN etc., then please contact me off-list ASAP. We're almost at the deadline. Thanks! (I'm not being more specific about the project on purpose). -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.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] pgbench \for or similar loop
On Mon, Apr 18, 2011 at 4:02 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: Hi, Today (and previously) I wished that pgbench had a mechanism to help create simple random databases. For example, I could create a table tenk and fill it with random stuff like \setrandom foo 1 1 insert into foo values (:foo) Now I have to run this 1 times or something like that. But I don't want a transaction for each of those, so I had a desire for something like this: begin; \for iterator 1 1 \setrandom foo 1 :iterator insert into foo values (:foo); \end commit; Would something like this be acceptable? *) what does this do that isn't already possible with 'DO' (not being snarky, genuinely curious)? *) should psql get some of these features? simple logic and looping would be a nice addition? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] HTML tags :/
Folks, While readjusting pg_docbot's URLs for LEAST and GREATEST, I came across an infelicity. They'd been tagged as http://www.postgresql.org/docs/current/static/functions-conditional.html#AEN12680; and I re-tagged them as http://www.postgresql.org/docs/current/static/functions-conditional.html#AEN15582; I didn't see a more descriptive tag. Am I missing something important? 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] pgbench \for or similar loop
Excerpts from Merlin Moncure's message of lun abr 18 18:26:54 -0300 2011: On Mon, Apr 18, 2011 at 4:02 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: begin; \for iterator 1 1 \setrandom foo 1 :iterator insert into foo values (:foo); \end commit; Would something like this be acceptable? *) what does this do that isn't already possible with 'DO' (not being snarky, genuinely curious)? Uhm, not sure. I'm not really used to having DO available so I didn't think about it. I'll look at it a bit more. *) should psql get some of these features? simple logic and looping would be a nice addition? I dunno. They have been proposed and shot down in the past. Apparently people don't want psql to become too powerful. (But that would make psql turing complete! Soon you're going to want to have \while on it!). I think pgbench is supposed to be designed to handle data in bulk which is why I started using it for this in the first place. -- Á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] HTML tags :/
Excerpts from David Fetter's message of lun abr 18 18:34:11 -0300 2011: Folks, While readjusting pg_docbot's URLs for LEAST and GREATEST, I came across an infelicity. They'd been tagged as http://www.postgresql.org/docs/current/static/functions-conditional.html#AEN12680; and I re-tagged them as http://www.postgresql.org/docs/current/static/functions-conditional.html#AEN15582; I didn't see a more descriptive tag. Am I missing something important? The sect2 they are in would need an id attribute for there to be a stable #-style link. -- Á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] Evaluation of secondary sort key.
On Mon, Apr 18, 2011 at 5:38 PM, Jesper Krogh jes...@krogh.cc wrote: order by case when (complex expresssion) 1 when (complex expression) 2 else 3 How come that expression be relevant? There is only one sortkey and no limit, so no matter what it should clearly get the full resultset in all cases. Sure, imagine there are more order by clauses with this one as the last one. Yes, as with all other cases it would be hard to get the optimum, but there is also cases where it is straightforward, say when the secondary sort column has an ndistinct of -1 (or similar close to). The current standard assumption is that 2 columns are unrelated, that would also work here. (As good as is does similar places in PG). I'm not following what you mean with the secondary column having ndistinct of -1. Actually it seems to me a reasonable low-hanging fruit to reach for would be when the initial column has an ndistinct of -1 which is actually kind of common. A lot of SQL queries end up being written with GROUP BY primary_key, other_column, other_column, other_column just to get those other columns to be queryable. If we implemented the SQL standard dependent columns feature this would be unnecessary but we don't and even if we did people would still build schemas and queries that defeat the optimization. In these cases we probably do have ndistinct -1 for one of the columns and therefore that an index on that column alone would give us almost the right ordering and quite likely exactly the right ordering. If we buffered the outputs for any distinct value and output sorted them if there were multiple rows. It would probably somewhat worse if we guess wrong 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] Windows 64 bit warnings
Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Andrew Dunstan's message of sáb abr 16 21:46:44 -0300 2011: The other, slightly more serious case, is at src/test/regress/pg_regress.c:2280, which is this code: printf(_(running on port %d with pid %lu\n), port, (unsigned long) postmaster_pid); Here the postmaster_pid is in fact a HANDLE which is 8 bytes, and so it should probably be cast to an unsigned long long and rendered with the format %llu in Win64. Is this uint64 and UINT64_FORMAT? Considering that this is a purely informational printout, I don't see any reason to give a damn about the possibility of high-order bits in the HANDLE being dropped. And it's not an especially good idea to stick UINT64_FORMAT into a translatable string, because of the platform dependency that creates. I think all we need here is a way to shut up the overly-anal-retentive warning. I would have expected that explicit cast to be enough, actually, but apparently it's not. Ideas? 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] Formatting Curmudgeons WAS: MMAP Buffers
On 04/17/2011 11:07 PM, Tom Lane wrote: BTW, another thing that should be in the try-try-again category is seeing how close we could get to pgindent's results with GNU indent. It seems clear to me that a process based on GNU indent would be a lot easier for a lot of people. We tried that once before, and couldn't get close enough to want to consider switching, but maybe it just needs a more determined effort and/or more recent versions of GNU indent. (ISTR that we hit some things that seemed to be outright bugs in GNU indent, but this was quite a few years ago.) That seems like a definite win possibility there. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Developement Organizers of the PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579 -- 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] Evaluation of secondary sort key.
Greg Stark gsst...@mit.edu writes: A lot of SQL queries end up being written with GROUP BY primary_key, other_column, other_column, other_column just to get those other columns to be queryable. If we implemented the SQL standard dependent columns feature this would be unnecessary but we don't We do as of 9.1 ... 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] Formatting Curmudgeons WAS: MMAP Buffers
On Mon, Apr 18, 2011 at 12:52 PM, Joshua Berkus j...@agliodbs.com wrote: Robert, Tom, Hm ... there are people out there who think *I* get high off rejecting patches. I have a t-shirt to prove it. But I seem to be pretty ineffective at it too, judging from these numbers. It's a question of how we reject patches, especially first-time patches. We can reject them in a way which makes the submitter more likely to fix them and/or work on something else, or we can reject them in a way which discourages people from submitting to PostgreSQL at all. For example, the emails to Radoslaw mentioned nothing about pg_ident, documented spacing requirements, accidental inclusion of files he didn't mean to touch, etc. Instead, a couple of people told him he should abandon his chosen development IDE in favor of emacs or vim. Radoslaw happens to be thick-skinned and persistent, but other first-time submitters would have given up at that point and run off to a more welcoming project. Actually, the first reply was a very polite reply from Heikki pointing out the problem very gently and asking for a theory of operation. Radoslaw replied and said that he understood the formatting problem, but his editor was mangling it: Yes, but, hmm... in Netbeans I had really long gaps (probably 8 spaces, from tabs), so deeper ifs, comments at the and of variables, went of out my screen. I really wanted to not format this, but sometimes I needed. That prompted one - ONE! - person to reply and suggest that the use of another editor might work better. At which point, we got an apparently-exasperated note from you suggesting that a 10% performance improvement wasn't enough (which I disagree with) and that it was wrong for people to worry about whether they could read the patch well enough to understand it (which I also disagree with). Conceding that some of the following discussion may have gotten a little harsh (though frankly I think that was mostly directed at your remark, not the OP), what prompted that original note? Here it is: Guys, can we *please* focus on the patch for now, rather than the formatting, which is fixable with sed? So first of all, no it's not fixable with sed. But secondly, writing *please* here seems to evince a level of frustration which is entirely out of proportion to the really rather mild comments which preceded it. What made you write it that way? I think that the harshness of the reaction to your statement is a reflection of some underlying frustration on my part and perhaps also on the part of other reviewers - to this continual commentary that we are not nice enough to people, especially newcomers. Well, OK, maybe we're not. But you know what? We're trying really hard, and getting accused of being nasty when we actually weren't is kind of a tough pill to swallow. I would really like to see someone go back and look at every patch from a newcomer that's been submitted in the last year, and rate the reaction to that patch on an A-F scale. Then let's have a discussion about what percentage we did well on, and what percentage we did poorly on, and how we could have done better. When we actually start raking someone over the coals, I think it's great and a helpful service for you to jump in and say - hold on a minute, timeout. But in this case I think you were too quick off the trigger, and I don't think that acting as if it's unreasonable to want a patch that conforms to our submission guidelines is doing anyone any favors. -- 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] Evaluation of secondary sort key.
Excerpts from Greg Stark's message of lun abr 18 15:47:03 -0300 2011: A lot of SQL queries end up being written with GROUP BY primary_key, other_column, other_column, other_column just to get those other columns to be queryable. If we implemented the SQL standard dependent columns feature this would be unnecessary but we don't and even if we did people would still build schemas and queries that defeat the optimization. Actually we do have that in 9.1. It's a bit more restrictive than really required (there are some more cases we could handle), but AFAIR at least the primary key is handled now. -- Á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] Formatting Curmudgeons WAS: MMAP Buffers
On 04/18/2011 01:46 PM, Joshua D. Drake wrote: On 04/17/2011 11:07 PM, Tom Lane wrote: BTW, another thing that should be in the try-try-again category is seeing how close we could get to pgindent's results with GNU indent. It seems clear to me that a process based on GNU indent would be a lot easier for a lot of people. We tried that once before, and couldn't get close enough to want to consider switching, but maybe it just needs a more determined effort and/or more recent versions of GNU indent. (ISTR that we hit some things that seemed to be outright bugs in GNU indent, but this was quite a few years ago.) That seems like a definite win possibility there. If you're aware of any changes in GNU indent that would overcome the previous issues, then by all means spend the time on it. If not, it seems a bit like the definition of insanity (repeating an experiment with the expectation of a different result). 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] Formatting Curmudgeons WAS: MMAP Buffers
Excerpts from Andrew Dunstan's message of lun abr 18 19:20:30 -0300 2011: On 04/18/2011 01:46 PM, Joshua D. Drake wrote: On 04/17/2011 11:07 PM, Tom Lane wrote: BTW, another thing that should be in the try-try-again category is seeing how close we could get to pgindent's results with GNU indent. It seems clear to me that a process based on GNU indent would be a lot easier for a lot of people. We tried that once before, and couldn't get close enough to want to consider switching, but maybe it just needs a more determined effort and/or more recent versions of GNU indent. (ISTR that we hit some things that seemed to be outright bugs in GNU indent, but this was quite a few years ago.) That seems like a definite win possibility there. If you're aware of any changes in GNU indent that would overcome the previous issues, then by all means spend the time on it. If not, it seems a bit like the definition of insanity (repeating an experiment with the expectation of a different result). The source of GNU indent itself is 3x what it was when the experiment was last reported. (I checked this about a year ago with an eye on repeating the experiment but then I failed to actually do it.) It seems fair to say that, yes, it has changed a bit in the meantime. -- Á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] Formatting Curmudgeons WAS: MMAP Buffers
Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Andrew Dunstan's message of lun abr 18 19:20:30 -0300 2011: On 04/17/2011 11:07 PM, Tom Lane wrote: ... but maybe it just needs a more determined effort and/or more recent versions of GNU indent. If you're aware of any changes in GNU indent that would overcome the previous issues, then by all means spend the time on it. If not, it seems a bit like the definition of insanity (repeating an experiment with the expectation of a different result). The source of GNU indent itself is 3x what it was when the experiment was last reported. (I checked this about a year ago with an eye on repeating the experiment but then I failed to actually do it.) It seems fair to say that, yes, it has changed a bit in the meantime. Also, my recollection of the previous go-round is that we gave up rather quickly. Maybe by now there is somebody willing to put more than minimal effort into getting the options just so. 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] Typed table DDL loose ends
On Mon, Apr 18, 2011 at 10:44:53PM +0300, Peter Eisentraut wrote: On Sat, 2011-04-09 at 21:57 -0400, Noah Misch wrote: * Users can CREATE TABLE OF on a type they don't own This in turns blocks the owner's ability to alter the table/type. However, we already have this hazard with composite-type columns. A TODO to address this broadly seems in order, but it's not a 9.1 issue. I think we should change that to mirror the inheritance policy: you have to be the owner of the parent. Note that this is newly relevant in 9.1, because you couldn't change composite types before. Would we add that restriction to use of CREATE TABLE t (c comptype) as well, or just to CREATE TABLE t OF comptype? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE
On Fri, Apr 15, 2011 at 11:58:30AM -0400, Noah Misch wrote: When we're done with the relkind-restriction patch, I'll post a new version of this one. It will remove the circularity check and add a relkind check. Here it is. Changes from tt1v1-alter-of.patch to tt1v2-alter-of.patch: * Use transformOfType()'s relkind check in ATExecAddOf() * Remove circularity check * Open pg_inherits with AccessShareLock * Fix terminology in ATExecDropOf() comment * Rebase over pgindent changes Changes from tt2v1-binary-upgrade.patch to tt2v2-binary-upgrade.patch: * Rebase over dumpCompositeType() changes from commit acfa1f45 diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml index c194862..4e02438 100644 *** a/doc/src/sgml/ref/alter_table.sgml --- b/doc/src/sgml/ref/alter_table.sgml *** *** 63,68 ALTER TABLE replaceable class=PARAMETERname/replaceable --- 63,70 RESET ( replaceable class=PARAMETERstorage_parameter/replaceable [, ... ] ) INHERIT replaceable class=PARAMETERparent_table/replaceable NO INHERIT replaceable class=PARAMETERparent_table/replaceable + OF replaceable class=PARAMETERtype_name/replaceable + NOT OF OWNER TO replaceable class=PARAMETERnew_owner/replaceable SET TABLESPACE replaceable class=PARAMETERnew_tablespace/replaceable *** *** 491,496 ALTER TABLE replaceable class=PARAMETERname/replaceable --- 493,522 /varlistentry varlistentry + termliteralOF replaceable class=PARAMETERtype_name/replaceable/literal/term + listitem + para + This form links the table to a composite type as though commandCREATE + TABLE OF/ had formed it. The table's list of column names and types + must precisely match that of the composite type; the presence of + an literaloid/ system column is permitted to differ. The table must + not inherit from any other table. These restrictions ensure + that commandCREATE TABLE OF/ would permit an equivalent table + definition. + /para + /listitem +/varlistentry + +varlistentry + termliteralNOT OF/literal/term + listitem + para + This form dissociates a typed table from its type. + /para + /listitem +/varlistentry + +varlistentry termliteralOWNER/literal/term listitem para diff --git a/src/backend/commands/tablecindex 1f709a4..f0e6f24 100644 *** a/src/backend/commands/tablecmds.c --- b/src/backend/commands/tablecmds.c *** *** 81,86 --- 81,87 #include utils/snapmgr.h #include utils/syscache.h #include utils/tqual.h + #include utils/typcache.h /* *** *** 357,362 static void ATExecEnableDisableRule(Relation rel, char *rulename, --- 358,366 static void ATPrepAddInherit(Relation child_rel); static void ATExecAddInherit(Relation child_rel, RangeVar *parent, LOCKMODE lockmode); static void ATExecDropInherit(Relation rel, RangeVar *parent, LOCKMODE lockmode); + static void drop_parent_dependency(Oid relid, Oid refclassid, Oid refobjid); + static void ATExecAddOf(Relation rel, const TypeName *ofTypename, LOCKMODE lockmode); + static void ATExecDropOf(Relation rel, LOCKMODE lockmode); static void ATExecGenericOptions(Relation rel, List *options); static void copy_relation_data(SMgrRelation rel, SMgrRelation dst, *** *** 2684,2689 AlterTableGetLockLevel(List *cmds) --- 2688,2703 break; /* +* These subcommands affect implicit row type conversion. They +* have affects similar to CREATE/DROP CAST on queries. We +* don't provide for invalidating parse trees as a result of +* such changes. Do avoid concurrent pg_class updates, though. +*/ + case AT_AddOf: + case AT_DropOf: + cmd_lockmode = ShareUpdateExclusiveLock; + + /* * These subcommands affect general strategies for performance * and maintenance, though don't change the semantic results * from normal data reads and writes. Delaying an ALTER TABLE *** *** 2942,2954 ATPrepCmd(List **wqueue, Relation rel, AlterTableCmd *cmd, case AT_EnableAlwaysRule: case AT_EnableReplicaRule: case AT_DisableRule: - ATSimplePermissions(rel, ATT_TABLE); - /* These commands never recurse */ - /* No command-specific prep needed */ - pass = AT_PASS_MISC; - break; case AT_DropInherit:/* NO
Re: [JDBC] [HACKERS] JDBC connections to 9.1
On Mon, 18 Apr 2011, Mike Fowler wrote: On 18/04/11 17:12, Tom Lane wrote: Dave Cramerp...@fastcrypt.com writes: Well initially my concern was that people would have a challenge in the case where they had to re-certify their application if we made this change, however I realize they will have to do this anyway since upgrading to 9.1 is what necessitates it. I don't see any backwards compatibility risk, if that's what you mean. Every backend release since 7.3 has treated client_encoding 'UTF8' and 'UNICODE' the same, and earlier releases didn't accept either one. regards, tom lane As there seems to be a consensus forming for fixing the JDBC driver, I've taken the liberty do so at the risk of being shot down. The patch is fairly straightforward, just changing UNICODE to UTF8 in a number of files including the translation files. I've tested this against 9.1devel (HEAD) and 8.4.7. For each database version I build and the tests running JDKs 1.4.2_19, 1.5.0_22 and 1.6.0_2. All on 32-bit. Thanks, applied, mostly. It's great to have a patch for a problem before you even know it exists. I didn't modify the .po files. I doubt this will change the adjacent translation wording, but directly patching .po files is only something to do in more dire circumstances (like needing to make a backpatch to an old branch that won't get translators to look at it before the next release.) I also discarded your changes to AbstractJdbc3Statement. Those Unicode mentions are from the interface Javadoc, so I left them alone. Kris Jurka -- 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] Formatting Curmudgeons WAS: MMAP Buffers
On Mon, Apr 18, 2011 at 3:17 PM, Josh Berkus j...@agliodbs.com wrote: In any case, I think the answer to this is constructive; better documentation and tools to let submitters get their code into good shape in the first place so that we don't have discussions about formatting. That way we waste *neither* the reviewers' nor the submitters' time. Well, I'm all in favor of better documentation, but I think the biggest thing we need to do is get the word out: 1. We realize we have been too trigger-happy sometimes. 2. But we really want you to participate. 3. And we are trying very hard to do better. 4. And please tell us if we screw up, so we can keep working on it. -- 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] Formatting Curmudgeons WAS: MMAP Buffers
Robert, 1. We realize we have been too trigger-happy sometimes. 2. But we really want you to participate. 3. And we are trying very hard to do better. 4. And please tell us if we screw up, so we can keep working on it. I received a private offlist email from someone who didn't feel comfortable bringing up their issues with this list publicly. Let me quote from it, because I think it pins part of the issue: I believe this is due to the current postgresql commitfest process whereby there is no real way to present new ideas or technologies without coming to the table with a fully-baked plan and patch. This is obvious even in the name commitfest since the expectation is that every patch presented is considered ready-to-commit by the patch presenter. This makes a novice or experimental contribution less likely. You'll notice that this has been a complaint of veteran contributors as well; WIP patches either get no review, or get reviewed as if they were expected to be committable. The person who e-mailed me suggests some form of PostgreSQL Incubator as a solution. I'm not sure about that, but it does seem to me that we need somewhere or some way that people can submit patches, ideas, git forks, etc., for discussion without that discussion needing to immediately move to the cleanliness/maintainability/supportable status of the patch. I'm concerned though that if these WIP projects don't get to -hackers, then their creators won't get the feedback they really need. Thoughts? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.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] Formatting Curmudgeons WAS: MMAP Buffers
On 04/18/2011 06:38 PM, Robert Haas wrote: On Mon, Apr 18, 2011 at 3:17 PM, Josh Berkusj...@agliodbs.com wrote: In any case, I think the answer to this is constructive; better documentation and tools to let submitters get their code into good shape in the first place so that we don't have discussions about formatting. That way we waste *neither* the reviewers' nor the submitters' time. Well, I'm all in favor of better documentation, but I think the biggest thing we need to do is get the word out: 1. We realize we have been too trigger-happy sometimes. 2. But we really want you to participate. 3. And we are trying very hard to do better. 4. And please tell us if we screw up, so we can keep working on it. I think Robert has hit the nail on the head. As I mentioned at #PgWest, we are a 1000 person dysfunctional family. David Fetter reminded me gently (yes really) that as far as 1000 person families go, we're doing pretty good. We are one of the last true communities left. We need to find a way to let people know that we are only gruff, because of experience and that although we can be rough we welcome the participation and we try really hard. We are engineers (well, I'm not...) but most of us are. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Developement Organizers of the PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579 -- 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] Formatting Curmudgeons WAS: MMAP Buffers
On Mon, Apr 18, 2011 at 19:50, Josh Berkus j...@agliodbs.com wrote: You'll notice that this has been a complaint of veteran contributors as well; WIP patches either get no review, or get reviewed as if they were expected to be committable. I don't see this changing anytime in the future. We have a hard enough time getting finished patches reviewed. The person who e-mailed me suggests some form of PostgreSQL Incubator as a solution. I'm not sure about that, but it does seem to me that we need somewhere or some way that people can submit patches, ideas, git forks, etc., for discussion without that discussion needing to immediately move to the cleanliness/maintainability/supportable status of the patch. Reminds me a bit of what linux is doing with the staging tree. I don't see anyway for that to work with postgres (lower the bar for -contrib?). You can fork fairly easy with github nowdays. For example the replace GEQ with SA is on one of those git sites. Does that mean it gets any attention? *shrug* -- 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] Formatting Curmudgeons WAS: MMAP Buffers
On Mon, Apr 18, 2011 at 9:50 PM, Josh Berkus j...@agliodbs.com wrote: Robert, 1. We realize we have been too trigger-happy sometimes. 2. But we really want you to participate. 3. And we are trying very hard to do better. 4. And please tell us if we screw up, so we can keep working on it. I received a private offlist email from someone who didn't feel comfortable bringing up their issues with this list publicly. Let me quote from it, because I think it pins part of the issue: I believe this is due to the current postgresql commitfest process whereby there is no real way to present new ideas or technologies without coming to the table with a fully-baked plan and patch. This is obvious even in the name commitfest since the expectation is that every patch presented is considered ready-to-commit by the patch presenter. This makes a novice or experimental contribution less likely. You'll notice that this has been a complaint of veteran contributors as well; WIP patches either get no review, or get reviewed as if they were expected to be committable. The person who e-mailed me suggests some form of PostgreSQL Incubator as a solution. I'm not sure about that, but it does seem to me that we need somewhere or some way that people can submit patches, ideas, git forks, etc., for discussion without that discussion needing to immediately move to the cleanliness/maintainability/supportable status of the patch. I'm concerned though that if these WIP projects don't get to -hackers, then their creators won't get the feedback they really need. Thoughts? I think the quality of review that WIP patches get depends very much on how specific the submitter is about what they'd like to get out of the process. If you submit a patch and say I have this cool patch that allows FTL travel, but it's WIP, please review then you're basically asking some poor schmuck to reverse engineer what the patch is doing, and, when they find problems with it, guess which of those problems were things that you didn't think of and which were things that you knew about but haven't gotten around to fixing yet because you're still working on it. This is a pretty thankless task for the reviewer, and it's not surprising that it doesn't go well. However, if you say I have this cool patch that allows FTL travel. It current plays havoc with the transporter beams and the dilithium crystals tend to shatter if you exceed Warp 3, but I'd like to get a check as to whether the basic design is sound, and if anyone can see why the Heisenburg compensator is destabilizing, please let me know, your chances of getting some useful feedback are pretty good. Sometimes it even provokes a rather competitive spot-the-bug race... Also, I think the reason why we have a process called CommitFest and not a process called BrainstormingFest is because, when we didn't have a CommitFest process, patches fell on the floor. Since we've added that process, that problem has largely gone away. But it is generally not difficult to get a review of a big idea for which no code has been written yet - in fact it's often much faster and easier than getting a patch reviewed. It's true that there have been occasional times when people have gotten lightly toasted for bringing up big new ideas in the middle of a CF or beta period, but I think we've gotten less pedantic about that. Certainly, there are no shortage of ideas that have been proposed and commented on over the last few weeks, even as we have been working to get 9.1beta1 out the door. Code is not really getting reviewed right now, but ideas *are*. I'm not going to claim that this works perfectly: the way that ideas are presented and the relative level of interest and/or exhaustion of the people responding certainly play a role, but it is a pretty rare for an email to -hackers to get no answer at all. Maybe we need some formal process here just to make people more comfortable, but it's not necessary from a workflow perspective. Thinking back over the kinds of things that have lead to people getting jumped on, I think I can identify a pattern: people tend to get jumped on when they allege that our code sucks, or that they're smarter than we are. Whether or not they actually meant to imply those things turns out not to matter - it rubs people the wrong way, and everyone's a volunteer, so when you rub them the wrong way, they get annoyed. I make an effort, as I think most of us do, to be aware that just because someone makes an annoying remark doesn't necessarily mean that they are an annoying person; it just means they haven't quite figured it all out yet. But there are still people who get flamed that way far more than they probably deserve. That's an area we can improve, but in the meantime, approaching the topic with a bit of humility goes a long way. I can't remember the last time someone said I was thinking about working on ... and I thought I might approach it by ... Does this seem
Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers
On Mon, Apr 18, 2011 at 11:15 PM, Alex Hunsaker bada...@gmail.com wrote: On Mon, Apr 18, 2011 at 19:50, Josh Berkus j...@agliodbs.com wrote: You'll notice that this has been a complaint of veteran contributors as well; WIP patches either get no review, or get reviewed as if they were expected to be committable. I don't see this changing anytime in the future. We have a hard enough time getting finished patches reviewed. Sadly so. As much as I think we have gotten a LOT of useful milage out of the commitfest concept, it does, conceptually, have a strong bias (including in its very name) towards the assumption that changes are pretty much ready to commit. Two items still undergoing work (collations, sync rep) weren't at that level of readiness, needing some mere dusting off to make them ready. Rather, they needed substantial examination and modification before they'd be ready. And, while this has doubtless aroused some ire, it doesn't intrinsically make those items broken. The Apache guys may be onto something in having the incubator moniker, for things that aren't so ready we're calling them Commitable. There may be merit to separating out easy to commit and tougher to commit items, and having different kinds of pickiness for them, the former being good fodder for Easy CommitFest and the latter being PG Incubation. Though I'm not sure the latter makes it any easier to get tough features like synchronous replication into place. The person who e-mailed me suggests some form of PostgreSQL Incubator as a solution. I'm not sure about that, but it does seem to me that we need somewhere or some way that people can submit patches, ideas, git forks, etc., for discussion without that discussion needing to immediately move to the cleanliness/maintainability/supportable status of the patch. Reminds me a bit of what linux is doing with the staging tree. I don't see anyway for that to work with postgres (lower the bar for -contrib?). You can fork fairly easy with github nowdays. For example the replace GEQ with SA is on one of those git sites. Does that mean it gets any attention? *shrug* Well, the project hasn't been on Git for all that spectacularly long a time, so the comfort level with managing via forks maybe isn't quite there yet. Forking isn't as magically delicious as GitHub might make some imagine; it's fine and useful to have a bunch of forks, and eventually merge useful ones, when they are remaining pretty close together, and don't conflict. That's likely to work out happily for features that are essentially independent. If you and I are hacking on different contrib modules, that's pretty essentially independent. Unfortunately, deeper features are more likely to be more interdependent, and forks aren't so readily productive in that case. If we hack around with formatting, that would muck with *everything* else, as an even worse for instance. -- When confronted by a difficult problem, solve it by reducing it to the question, How would the Lone Ranger handle this? -- 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] Formatting Curmudgeons WAS: MMAP Buffers
On Mon, Apr 18, 2011 at 11:50 PM, Christopher Browne cbbro...@gmail.com wrote: Two items still undergoing work (collations, sync rep) weren't at that level of readiness, needing some mere dusting off to make them ready. Rather, they needed substantial examination and modification before they'd be ready. And, while this has doubtless aroused some ire, it doesn't intrinsically make those items broken. I don't think it really aroused that much ire. It's pretty clear that both of those patches cost us something on the schedule, and I would have preferred to see them committed sooner and with fewer bugs. But they are great features. Unfortunately, we have a tendency to leave things to the last minute, and that's something I think we could improve. We have gotten a bit better but there is clearly room for further improvement. With beta having gotten pushed out to the end of the month, there is a real chance that we are going to end up releasing in the fall again, and I would have much preferred July 1. But given how long CF4 lasted and how much surgery was required afterwards, it was an unfixable problem. It's not going to get any better unless we get more serious about getting these big features done early in the cycle, or postponing them to the next release if they aren't. Anyway, I'm drifting off topic: nothing against the patches, at least on my part, just want to make the schedule. -- 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: [JDBC] [HACKERS] JDBC connections to 9.1
Kris Jurka bo...@ejurka.com writes: On Mon, 18 Apr 2011, Mike Fowler wrote: As there seems to be a consensus forming for fixing the JDBC driver, I've taken the liberty do so at the risk of being shot down. The patch is fairly straightforward, just changing UNICODE to UTF8 in a number of files including the translation files. I've tested this against 9.1devel (HEAD) and 8.4.7. For each database version I build and the tests running JDKs 1.4.2_19, 1.5.0_22 and 1.6.0_2. All on 32-bit. Thanks, applied, mostly. It's great to have a patch for a problem before you even know it exists. For purposes of the notes in the server-side fix, could you state which JDBC driver versions these changes will first appear in? 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
