Josh Berkus writes:
> 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
> where
Kris Jurka 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
>> incl
On Mon, Apr 18, 2011 at 11:50 PM, Christopher Browne 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.
On Mon, Apr 18, 2011 at 11:15 PM, Alex Hunsaker wrote:
> On Mon, Apr 18, 2011 at 19:50, Josh Berkus 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
On Mon, Apr 18, 2011 at 9:50 PM, Josh Berkus 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 recei
On Mon, Apr 18, 2011 at 19:50, Josh Berkus 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 enoug
On 04/18/2011 06:38 PM, Robert Haas wrote:
On Mon, Apr 18, 2011 at 3:17 PM, Josh Berkus 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 form
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
comfor
On Mon, Apr 18, 2011 at 3:17 PM, Josh Berkus 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* th
On Mon, 18 Apr 2011, Mike Fowler wrote:
On 18/04/11 17:12, Tom Lane wrote:
Dave Cramer 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 anyw
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 tran
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
Alvaro Herrera 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 tha
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 res
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
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 featur
On Mon, Apr 18, 2011 at 12:52 PM, Joshua Berkus 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 re
Greg Stark 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
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 b
Alvaro Herrera 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_
On Mon, Apr 18, 2011 at 5:38 PM, Jesper Krogh 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.
S
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-ta
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
> wrote:
> > begin;
> > \for iterator 1 1
> > \setrandom foo 1 :iterator
> > insert into foo values (:foo);
> > \end
> > commit;
> >
> > Would something like this be
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.h
On Mon, Apr 18, 2011 at 4:02 PM, Alvaro Herrera 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 valu
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
Andrew Dunstan 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.
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.
> -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/20
On 04/18/2011 04:20 PM, Tom Lane wrote:
Peter Eisentraut 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
Peter Eisentraut 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 fi
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 o
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
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;
> CR
> 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
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
On 18/04/11 17:12, Tom Lane wrote:
Dave Cramer 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 necessitat
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 the
On Mon, Apr 18, 2011 at 11:33 AM, Alvaro Herrera
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
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 th
Excerpts from Tom Lane's message of lun abr 18 02:50:22 -0300 2011:
> Robert Haas 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
> > ar
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
On 2011-04-18 11:00, Greg Stark wrote:
On Mon, Apr 18, 2011 at 6:25 AM, Jesper Krogh 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 t
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 alo
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 b
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
Dave Cramer writes:
> On Mon, Apr 18, 2011 at 11:24 AM, Tom Lane 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
>> an
On Mon, Apr 18, 2011 at 11:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 18, 2011 at 11:33 AM, Tom Lane 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,
Robert Haas writes:
> On Mon, Apr 18, 2011 at 11:33 AM, Tom Lane 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 "rela
On Mon, Apr 18, 2011 at 11:24 AM, Tom Lane wrote:
> Dave Cramer writes:
>> On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane 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
On Mon, Apr 18, 2011 at 11:33 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 18, 2011 at 10:48 AM, Noah Misch 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
Robert Haas writes:
> On Mon, Apr 18, 2011 at 10:48 AM, Noah Misch 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 stu
Mike Fowler 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,
Dave Cramer writes:
> On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane 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
On Mon, Apr 18, 2011 at 11:14 AM, Mike Fowler wrote:
> On 18/04/11 15:57, Tom Lane wrote:
>>
>> Bernd Helmle 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 re
On 18/04/11 15:57, Tom Lane wrote:
Bernd Helmle 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 cod
Tom Lane 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
On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane wrote:
> Bernd Helmle 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 ch
On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane wrote:
> Bernd Helmle 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 ch
On Mon, Apr 18, 2011 at 10:48 AM, Noah Misch 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 e
Bernd Helmle 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 normalize
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
Robert Haas 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 latt
--On 18. April 2011 16:17:57 +0200 Bernd Helmle 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.ja
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 mes
On 11-04-18 09:44 AM, Tom Lane wrote:
Steve Singer 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: u
On Thu, Apr 14, 2011 at 9:38 PM, Noah Misch 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 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 th
--On 18. April 2011 09:44:38 -0400 Tom Lane 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 followin
Steve Singer 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
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 p
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
On Thu, Apr 14, 2011 at 10:56 PM, Pavel Stehule wrote:
> 2011/4/15 Jim Nasby :
>> On Apr 14, 2011, at 4:20 PM, Kevin Grittner wrote:
>>> Tom Lane wrote:
Robert Haas writes:
>>>
> So far the most promising proposal I've seen seems to be to let
> id mean the parameter called id only w
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 unfrie
On Fri, Apr 15, 2011 at 1:26 AM, Jaime Casanova wrote:
> On Thu, Apr 14, 2011 at 1:30 PM, Robert Haas 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
On Sun, 17 Apr 2011 21:06:17 -0400, Robert Haas wrote:
On Sun, Apr 17, 2011 at 5:32 PM, Radosław Smogura
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) (
On Mon, Apr 18, 2011 at 6:25 AM, Jesper Krogh 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,
76 matches
Mail list logo
