2010/7/14 Pavel Stehule :
> this patch is significantly reduced original patch. It doesn't propose
> a simple allocator - just eliminate a high memory usage for ispell
> dictionary.
I don't think introducing new methods is a good idea. If you want a
simple allocator, MemoryContextMethods layer see
On Jul 19, 2010, at 11:10 PM, Robert Haas wrote:
> On Tue, Jul 20, 2010 at 12:07 AM, Robert Haas wrote:
>> On Tue, Jul 20, 2010 at 12:02 AM, David Christensen
>> wrote:
I would propose to print instead:
You are connected to database "rhaas" via local socket as user "rhaas".
>>>
Robert Haas wrote:
On Tue, Jul 6, 2010 at 3:19 PM, Bruce Momjian wrote:
Log Message:
---
pgindent run for 9.0, second run
It appears that the git mirror has deduced the wrong
contents for this commit. Apparently as a result, when I build from
git master, the dblink regress
On Tue, Jul 20, 2010 at 12:07 AM, Robert Haas wrote:
> On Tue, Jul 20, 2010 at 12:02 AM, David Christensen
> wrote:
>>> I would propose to print instead:
>>>
>>> You are connected to database "rhaas" via local socket as user "rhaas".
>>
>>
>> One minor quibble here; you lose the ability to see w
On Tue, Jul 20, 2010 at 12:02 AM, David Christensen wrote:
>> I would propose to print instead:
>>
>> You are connected to database "rhaas" via local socket as user "rhaas".
>
>
> One minor quibble here; you lose the ability to see which pg instance you're
> running on if there are multiple ones
> I would propose to print instead:
>
> You are connected to database "rhaas" via local socket as user "rhaas".
One minor quibble here; you lose the ability to see which pg instance you're
running on if there are multiple ones running on different local sockets, so
maybe either the port or the
On Mon, Jul 19, 2010 at 11:41 PM, David Christensen wrote:
>> I took a look at this patch. One problem is that it doesn't handle
>> the case where there is no database connection (for example, shut down
>> the database with pg_ctl, then do select 1, then do \conninfo). I've
>> fixed that in the
On Wed, Jun 23, 2010 at 9:22 AM, Robert Haas wrote:
> On Wed, Jun 23, 2010 at 9:17 AM, gabrielle wrote:
>> On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas wrote:
>>> Well, that might be a good idea, too, but my expectation is that:
>>>
>>> psql -f one -f two -f three
>>>
>>> ought to behave in a ma
On Jul 19, 2010, at 10:34 PM, Robert Haas wrote:
> On Sun, Jul 18, 2010 at 2:00 PM, David Christensen wrote:
>> Updated the commitfest entry with the patch, updated the title to reflect
>> the actual name of the command, and marked as ready for committer.
>
> I took a look at this patch. One
On Sun, Jul 18, 2010 at 2:00 PM, David Christensen wrote:
> Updated the commitfest entry with the patch, updated the title to reflect the
> actual name of the command, and marked as ready for committer.
I took a look at this patch. One problem is that it doesn't handle
the case where there is n
On Tue, Jul 6, 2010 at 3:19 PM, Bruce Momjian wrote:
> Log Message:
> ---
> pgindent run for 9.0, second run
It appears that the git mirror has deduced the wrong
contents for this commit. Apparently as a result, when I build from
git master, the dblink regression tests fail.
Can someon
The attached patch is the revised one.
* It was rebased to the latest git HEAD.
* Prototype of ExecCheckRTEPerms() was changed; it become to return
a bool value to inform the caller its access control decision, and
its 'ereport_on_violation' argument has gone.
* ExecCheckRTPerms() calls aclche
On Mon, Jul 19, 2010 at 8:32 PM, Robert Haas wrote:
> On Mon, Jul 19, 2010 at 5:04 PM, Peter Eisentraut wrote:
>> On sön, 2010-07-18 at 09:42 -0700, David E. Wheeler wrote:
>>> On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
>>>
>>> > I think there are two ways we can do this, seeing that mo
On Sat, Jul 17, 2010 at 10:16 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On Sun, 2010-06-27 at 20:54 -0400, Robert Haas wrote:
>>> automatic_restart = true # reinitialize after backend crash?
>
>> "automatic_restart" makes me think "when does that happen?".
>
>> Can we call this "restart_a
On Mon, Jul 19, 2010 at 5:04 PM, Peter Eisentraut wrote:
> On sön, 2010-07-18 at 09:42 -0700, David E. Wheeler wrote:
>> On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
>>
>> > I think there are two ways we can do this, seeing that most appear to be
>> > in favor of doing it in the first plac
(2010/07/20 3:13), Robert Haas wrote:
> 2010/7/12 KaiGai Kohei:
>> (2010/07/10 5:53), Robert Haas wrote:
>>> 2010/6/14 KaiGai Kohei:
The attached patch tries to rework DML permission checks.
It was mainly checked at the ExecCheckRTEPerms(), but same logic was
implemented in COPY
2010/7/19 Tom Lane :
> I looked into the problem reported here:
> http://archives.postgresql.org/pgsql-bugs/2010-07/msg00119.php
>
> 1. Postpone coercion of the function inputs till after processing of
> the ORDER BY/DISTINCT decoration. This isn't too good because then
> we'll be using the "wrong
David Fetter wrote:
> Would something like this do? Thanks to Andrew Gierth for helping
> me figure out how to get this working :)
>
> CREATE OR REPLACE FUNCTION multi_result()
> RETURNS SETOF REFCURSOR
With appropriate tweaks to JDBC and the other drivers, this would
cover a lot of ground.
On sön, 2010-07-18 at 09:42 -0700, David E. Wheeler wrote:
> On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
>
> > I think there are two ways we can do this, seeing that most appear to be
> > in favor of doing it in the first place: Either we just flip the
> > default, make a note in the rel
I'd like to mark this as Ready for Committer :)
Review below.
Cheers,
David.
== Submission review ==
* Is the patch in context diff format?
Yes.
* Does it apply cleanly to the current CVS HEAD?
Yes, with a few offsets.
patch -p0 < ../reraise_issue_PG_v1.patch
patching file
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of s??b jul 17 21:21:52 -0400 2010:
> > Since we branched 9.1 before we released Postgres 9.0, I had to remove
> > the 9.0 TODO items before 9.0 was released, or people might have marked
> > items as "done" when they were done only in 9.
Excerpts from Bruce Momjian's message of sáb jul 17 21:21:52 -0400 2010:
> Since we branched 9.1 before we released Postgres 9.0, I had to remove
> the 9.0 TODO items before 9.0 was released, or people might have marked
> items as "done" when they were done only in 9.1.
Should we create a TodoDone
2010/7/12 KaiGai Kohei :
> (2010/07/10 5:53), Robert Haas wrote:
>> 2010/6/14 KaiGai Kohei:
>>> The attached patch tries to rework DML permission checks.
>>>
>>> It was mainly checked at the ExecCheckRTEPerms(), but same logic was
>>> implemented in COPY TO/FROM statement and RI_Initial_Check().
>>
On Mon, Jul 19, 2010 at 09:31:06AM -0500, Kevin Grittner wrote:
> >Stephen Frost wrote:
>
> > You think that the users of the libpq() interface (or even the
> > protocol itself) are going to handle getting \dt-type output back
> > somehow..?
>
> If you look back in the thread, you'll see that
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
David Fetter wrote:
>> No arguments there, but that's the nature of the beast. I don't
>> think it's as bad as is made out, however, as \d covers 99% of
>> everyday usage and certainly the "show tables" that started
>> this thread.
> It cove
On Mon, Jul 19, 2010 at 1:19 PM, Heikki Linnakangas
wrote:
> I guess what I'm saying is "write a patch, and I'll shoot it down when
> you're done" :-/. But hopefully the planner changes don't depend much on how
> we deduce which quals are leaky.
Oh, great... I love that.
/me rolls eyes
--
Rob
On Mon, 2010-07-19 at 10:23 -0700, David Fetter wrote:
> On Mon, Jul 19, 2010 at 02:12:19PM -, Greg Sabino Mullane wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: RIPEMD160
> >
> >
> > > 1. \d isn't exactly the most intuitive thing ever
> >
> > Seems fairly mnemomic to me (d=de
On Mon, Jul 19, 2010 at 02:12:19PM -, Greg Sabino Mullane wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> > 1. \d isn't exactly the most intuitive thing ever
>
> Seems fairly mnemomic to me (d=describe) and it packs a
> *lot* of information into a single letter (see
On 19/07/10 20:08, Robert Haas wrote:
2010/7/8 KaiGai Kohei:
(2010/07/08 22:08), Robert Haas wrote:
I think we pretty much have conceptual agreement on the shape of the
solution to this problem: when a view is created with CREATE SECURITY
VIEW, restrict functions and operators that might disclo
On 09/07/10 06:47, KaiGai Kohei wrote:
> When leaky and non-leaky functions are chained within a WHERE clause,
> it will be ordered by the cost of functions. So, we have possibility
> that leaky functions are executed earlier than non-leaky functions.
No, that needs to be forbidden as part of the
2010/7/8 KaiGai Kohei :
> (2010/07/08 22:08), Robert Haas wrote:
>> I think we pretty much have conceptual agreement on the shape of the
>> solution to this problem: when a view is created with CREATE SECURITY
>> VIEW, restrict functions and operators that might disclose tuple data
>> from being pu
On Mon, Jul 19, 2010 at 2:46 AM, Simon Riggs wrote:
> On Sun, 2010-07-18 at 22:47 -0400, Robert Haas wrote:
>> But it seems
>> that it's far from clear what to do about it, and it's not the job of
>> this patch to fix it anyway.
>
> Agreed.
>
>> Regarding the actual patch, it looks mostly good.
On Mon, Jul 19, 2010 at 10:25 AM, Greg Sabino Mullane wrote:
>> in the "alphabet soup" paragraph above. I don't think there's
>> anything WRONG with letting "\dFp" show text search dictionaries and
>> "\dfwS+" list system window functions with additional detail - but I'd
>> like an alternative th
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> I know, though, that the JDBC spec supports such things -- you can
> keep pulling ResultSet objects off the wire, each with its own
> distinct set of columns. (That is, each ResultSet has its own
> ResultSetMetaData which specifies how many c
>Stephen Frost wrote:
> You think that the users of the libpq() interface (or even the
> protocol itself) are going to handle getting \dt-type output back
> somehow..?
If you look back in the thread, you'll see that I admitted my
ignorance of whether this could be properly implemented in the b
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Kevin Grittner wrote:
> Any solution which only works within psql isn't a solution for a
> large part of the problem space people are trying to address. One
> important goal is that if someone spends a day to whip up a GUI
> query tool (as I d
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Robert Haas (robertmh...@gmail.com) wrote:
> I think "LIST COMMENTS ON SYSTEM AGGREGATES" would be an epic
> step forward in usability.
Perhaps. But it would behoove you to come up with a less er...
arcane example. I've been using Postgres a l
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> 1. \d isn't exactly the most intuitive thing ever
>
Seems fairly mnemomic to me (d=describe) and it packs a
*lot* of information into a single letter (see below).
Things that are done often should have short keystrokes,
and not require le
On tor, 2010-02-11 at 14:13 +0100, Bart Samwel wrote:
> I've been working on a patch to add hostname support to pg_hba.conf.
> It's not ready for public display yet, but I would just like to run a
> couple of issues / discussion points past everybody.
What's the status of this?
--
Sent via pgsq
39 matches
Mail list logo
