Attached is a patch that removes the use of the flat auth file during
client authentication, instead using regular access to the pg_auth
catalogs. As previously discussed, this implies pushing the
authentication work down to InitPostgres. I didn't yet do anything
about the idea of falling back to
On Fri, Aug 28, 2009 at 04:37:41PM -0700, David E. Wheeler wrote:
> On Aug 28, 2009, at 3:45 PM, Stephen Frost wrote:
>
> >+1 from me. I've read the other comments and just plain don't agree
> >with them. It's a small patch, adds a useful format for EXPLAIN, and
> >would be used.
> >
> >One of t
Kevin Grittner wrote:
>
> The first test seems unnecessary if you have the second.
> x >= 0, so x can't be zero unless y is, too.
> Returning x on y == 0.0 will return 0.0 whenever x == 0.0.
>
> -Kevin
>
Wish granted. :-)
--
--
Fools ignore complexity. Pragmatists suffer it.
Some can avoi
Peter Eisentraut wrote:
> On fre, 2009-08-28 at 20:13 +, Greg Sabino Mullane wrote:
>> Readability and easy editing. All the power of JSON without the
>> annoying quotes, braces, and brackets.
>
> But these are supposed to be machine-readable formats. So readability
> and editability are not
The question is still valid, though it's better put in your words - do
we want to refactor the existing compiler or write a separate one ?
So, for now I went with the path of custom compiler and current executor.
I attached current version of the patch. I don't expect this to get
committed or a
David Fetter wrote:
On Fri, Aug 28, 2009 at 11:57:07PM +0100, Greg Stark wrote:
On Fri, Aug 28, 2009 at 10:57 PM, Kevin
Grittner wrote:
David Fetter wrote:
cvs diff if you're on CVS. If you're using git, commit to your
local repository and git-diff.
I tried that.
On Aug 28, 2009, at 3:45 PM, Stephen Frost wrote:
+1 from me. I've read the other comments and just plain don't agree
with them. It's a small patch, adds a useful format for EXPLAIN, and
would be used.
One of the best things about PG is the flexibility and usability.
I agree, I tend to pref
On Fri, Aug 28, 2009 at 11:59 PM, David Fetter wrote:
>> You have to "cvs add" the file
>
> That only works if you have write permissions to the central repo. I
> don't.
True. The only workable way to use cvs that i found was to rsync the
repository and then check out from that. If you cvs add th
On fre, 2009-08-28 at 16:57 -0500, Kevin Grittner wrote:
> David Fetter wrote:
>
> > cvs diff if you're on CVS. If you're using git, commit to your
> > local repository and git-diff.
>
> I tried that. When I just did it at the top level, it ignored the new
> file. When I specified the file
Petr,
> But if I understood Tom's suggestions correctly then his approach does
> not solve this at all since every one of those users with CREATE TABLE
> privileges would have to also set same DEFAULT PRIVILEGES and the dba
> would have no say in the matter.
This latter approach benefits nobody.
On Fri, Aug 28, 2009 at 11:57:07PM +0100, Greg Stark wrote:
> On Fri, Aug 28, 2009 at 10:57 PM, Kevin
> Grittner wrote:
> > David Fetter wrote:
> >
> >> cvs diff if you're on CVS. If you're using git, commit to your
> >> local repository and git-diff.
> >
> > I tried that. When I just did it at
I had some time to work on this patch, and I implemented the ALTER
DEFAULT PRIVILEGES syntax as proposed by Tom and adjusted some other
stuff, but before I can submit the new patch for commitfest there is
still this fundamental issue about how it should behave.
The situation is as following. J
On Fri, Aug 28, 2009 at 10:57 PM, Kevin
Grittner wrote:
> David Fetter wrote:
>
>> cvs diff if you're on CVS. If you're using git, commit to your
>> local repository and git-diff.
>
> I tried that. When I just did it at the top level, it ignored the new
> file. When I specified the file:
You h
* Greg Sabino Mullane (g...@turnstep.com) wrote:
> Attached patch adds YAML output option to explain:
>
> explain (format YAML) select * from information_schema.columns;
+1 from me. I've read the other comments and just plain don't agree
with them. It's a small patch, adds a useful format for E
On Fri, Aug 28, 2009 at 04:57:24PM -0500, Kevin Grittner wrote:
> David Fetter wrote:
>
> > cvs diff if you're on CVS. If you're using git, commit to your
> > local repository and git-diff.
>
> I tried that. When I just did it at the top level, it ignored the
> new file. When I specified t
David Fetter wrote:
> cvs diff if you're on CVS. If you're using git, commit to your
> local repository and git-diff.
I tried that. When I just did it at the top level, it ignored the new
file. When I specified the file:
kgri...@kgrittn-desktop:~/pg/pgsql$ cvs diff -c -N
contrib/start-sc
On Fri, Aug 28, 2009 at 04:41:47PM -0500, Kevin Grittner wrote:
> I wrote:
>
> > But before I spend a lot of time fine-tuning it, I wanted to post
> > this as a proof-of-concept draft and see if people think it's on
> > the right track.
>
> I chose to take the lack of response as an indication
>
> -- Forwarded message --
> From: Simon Riggs
> To: pgsql-hackers
> Date: Fri, 28 Aug 2009 20:07:32 +0100
> Subject: LWLock Queue Jumping
>
> WALInsertLock is heavily contended and likely always will be even if we
> apply some of the planned fixes.
>
> Some callers of WALInsertL
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> How many lines of code does YAML support add to the codebase?
About 80.
> While I personally like YAML, it's not like it has broad industry
> support. And people wouldn't interface with the XML or JSON directly;
> they'd use a library for t
I wrote:
> But before I spend a lot of time fine-tuning it, I wanted to post
> this as a proof-of-concept draft and see if people think it's on the
> right track.
I chose to take the lack of response as an indication that nobody who
cares about this thought there was anything seriously wrong w
On ons, 2009-08-26 at 22:13 -0400, Tom Lane wrote:
> Seems to me it would be too chatty to be useful, at least for people who
> set more than one or two things in postgresql.conf. Would it be that
> hard to track which values actually changed? Without having looked at
> the code, I'm thinking tha
On fre, 2009-08-28 at 20:13 +, Greg Sabino Mullane wrote:
> Readability and easy editing. All the power of JSON without the
> annoying quotes, braces, and brackets.
But these are supposed to be machine-readable formats. So readability
and editability are not high priority criteria.
--
Sent
On Fri, 2009-08-28 at 14:23 -0700, Josh Berkus wrote:
> On 8/28/09 1:13 PM, Greg Sabino Mullane wrote:
> >
> >> I thought the consensus was that we didn't want to get into supporting
> >> more formats. What does YAML provide that JSON does not?
> >
> > Readability and easy editing. All the power
On 8/28/09 1:13 PM, Greg Sabino Mullane wrote:
>
>> I thought the consensus was that we didn't want to get into supporting
>> more formats. What does YAML provide that JSON does not?
>
> Readability and easy editing. All the power of JSON without the
> annoying quotes, braces, and brackets.
How
* Greg Sabino Mullane:
>> I thought the consensus was that we didn't want to get into supporting
>> more formats. What does YAML provide that JSON does not?
>
> Readability and easy editing. All the power of JSON without the
> annoying quotes, braces, and brackets.
But YAML is much more difficult
On tis, 2009-08-11 at 12:42 +0300, Peter Eisentraut wrote:
> I've been thinking that we could actually get rid of that build-in-srcdir
> behavior, which also occasionally puzzles vpath users with respect to gram.c
> and so on. The new behavior would be to build targets in the local
> directory.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I thought the consensus was that we didn't want to get into supporting
> more formats. What does YAML provide that JSON does not?
Readability and easy editing. All the power of JSON without the
annoying quotes, braces, and brackets.
By the w
On Fri, 2009-08-28 at 10:55 -0700, Josh Berkus wrote:
> Here is my proposal for CFs for this year:
>
> We do four CFs, July 15, September 15, November 15, and January 15.
>
> However, we rigidly apply the 30-day deadline for the January 15 CF.
> That is, anything which is not completely ready f
Hello Tom,
Tom Lane wrote:
> Don't call them BUFFER_FOO --- that term already has a pretty specific
> meaning in most of the backend. STRINGINFO_FOO is a bit long but
> seems to fit the best with the existing naming in stringinfo.h.
Understood and agreed. Note however, that lots of places, espec
Greg Sabino Mullane wrote:
Attached patch adds YAML output option to explain:
I thought the consensus was that we didn't want to get into supporting
more formats. What does YAML provide that JSON does not?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
Attached patch adds YAML output option to explain:
explain (format YAML) select * from information_schema.columns;
--
Greg Sabino Mullane g...@turnstep.com
PGP Key: 0x14964AC8 200908281414
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
Index: contrib/auto_explain/auto_expl
WALInsertLock is heavily contended and likely always will be even if we
apply some of the planned fixes.
Some callers of WALInsertLock are more important than others
* Writing new Clog or Multixact pages (serialized by ClogControlLock)
* For Hot Standby, writing SnapshotData (serialized by ProcA
On Fri, Aug 28, 2009 at 06:12:30PM +0300, Marko Tiikkaja wrote:
> Hi everyone,
>
> Today I needed a feature like $subject. The use case was: UPDATE
> foo SET bar = bar + 1 WHERE id=$1, but I wanted to only do it when
> bar was 0. In order to give the user an informative error message,
> I also ne
Folks,
Here is my proposal for CFs for this year:
We do four CFs, July 15, September 15, November 15, and January 15.
However, we rigidly apply the 30-day deadline for the January 15 CF.
That is, anything which is not completely ready for commit on February
14 gets punted to the next version. N
All,
>>> There's some very good reasons for the health of the project to have
>>> specific release dates and stick to them.
>> Help me understand why?
We've cited this before, but here's the definitive paper on the subject:
http://www.cyrius.com/publications/michlmayr-phd.pdf
summary here:
http:
On Fri, Aug 28, 2009 at 12:12 PM, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> On Fri, 2009-08-28 at 11:52 -0400, Tom Lane wrote:
>>> I've thought of an easier way to handle this: if the given database name
>>> is invalid, connect to database "postgres" instead, and perform
>>> authentication us
"Joshua D. Drake" writes:
> On Fri, 2009-08-28 at 11:52 -0400, Tom Lane wrote:
>> I've thought of an easier way to handle this: if the given database name
>> is invalid, connect to database "postgres" instead, and perform
>> authentication using normal access to the pg_auth catalogs. If
>> authen
On Fri, 2009-08-28 at 11:52 -0400, Tom Lane wrote:
> I've thought of an easier way to handle this: if the given database name
> is invalid, connect to database "postgres" instead, and perform
> authentication using normal access to the pg_auth catalogs. If
> authentication succeeds, *then* throw
KaiGai Kohei wrote:
> BTW, currently, the default ACL of largeobject allows anything for owner
> and nothing for world. Do you have any comment for the default behavior?
Backwards compatibility would say that the world should be able to at
least read the object.
--
Alvaro Herrera
KaiGai Kohei writes:
> BTW, currently, the default ACL of largeobject allows anything for owner
> and nothing for world. Do you have any comment for the default behavior?
Mph. I think the backlash will be too great. You have to leave the
default behavior the same as it is now, ie, world access.
I'm back on the warpath about $SUBJECT. (Aside from any other reason to
do it, it occurs to me that we really need to get rid of the flat files
for Hot Standby. Otherwise we'd need some way to keep them up to date
during WAL replay.) I wrote earlier:
> The easy way to do it would be to postpone
The CREATE USER/ROLE statement got a new option: LARGEOBJECT/NOLARGEOBJECT.
It enables to controls whether the user can create a largeobject, or not.
>>> I don't think this is necessary or appropriate.
>
>> What should control privilege to create a new largeobject?
>> Or, it implicitly a
Ron Mayer wrote:
> Josh Berkus wrote:
>> There's some very good reasons for the health of the project to
>> have specific release dates and stick to them.
>
> Help me understand why?
I don't know how many places are like this, but to get any significant
staff or hardware resources officially
KaiGai Kohei writes:
> Tom Lane wrote:
>> What about DELETE permissions? Should we track that separately from
>> UPDATE?
> PostgreSQL checks ownership of the database object when user tries to
> drop it. This patch also add pg_largeobject_ownercheck() on lo_unlink().
Oh, okay, that will do fine
Tom Lane wrote:
> KaiGai Kohei writes:
>> The attached patch provides access control features on largeobject.
>> This patch adds the ownership and two permissions (SELECT and UPDATE) on
>> largeobjects. The two permissions controls reader and writer accesses to
>> the largeobejcts.
>
> What about
Hi everyone,
Today I needed a feature like $subject. The use case was: UPDATE foo SET
bar = bar + 1 WHERE id=$1, but I wanted to only do it when bar was 0. In
order to give the user an informative error message, I also needed to
distinguish the two cases: a row with id = $1 doesn't exist, and bar
Paul Matthews wrote:
> Feedback appreciated.
+ /* As x is the larger value, this must be the correct answer.
Also
+ * avoids division by zero. */
+ if( x == 0.0 )
+ return 0.0;
+
+ /* Trivial case. */
+ if( y == 0.0 )
+ return x;
The first test seems unne
KaiGai Kohei writes:
> The attached patch provides access control features on largeobject.
> This patch adds the ownership and two permissions (SELECT and UPDATE) on
> largeobjects. The two permissions controls reader and writer accesses to
> the largeobejcts.
What about DELETE permissions? Shou
2009/8/28 Andrew Dunstan :
> You function doesn't look too immutable. Is it really?
Hi, I fixed that, but the server continues to crash, where can I see a
full example of something using the SRF functions to parse a query?
All examples I see set the columns, but I parse a query that I don't
have a
"Markus Wanner" writes:
> trying to clean up the Postgres-R code further, I would like to make
> use of StringInfo and accompanying functions in libpq/pqformat.c
> instead of some home-brown duplicate of it. However, I'm missing
> helper macros like these (mainly for readability of the code)
Pavel Stehule wrote:
> this small patch complete MOVE support in plpgsql and equalize
plpgsql
> syntax with sql syntax.
Quick correction on the doc changes:
s/similar as for/similar to/
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
Hi,
trying to clean up the Postgres-R code further, I would like to make
use of StringInfo and accompanying functions in libpq/pqformat.c
instead of some home-brown duplicate of it. However, I'm missing
helper macros like these (mainly for readability of the code):
#define BUFFER_START_PT
Adriano Lange writes:
> I need to control the size of a memory context on the fly and take
> some actions when
> the used memory exceeds a defined size.
The existing places that do that sort of thing do their own counting
of how much they've allocated.
regards, tom lane
Greg Stark wrote:
> They basically don't do any integration testing and leave that up to
> the distributions now. Instead they have an "rc" release *every week*
> like clockwork and every 2-3 months the last one becomes a new version
> regardless of whether there's any notable new feature.
They h
On Fri, Aug 28, 2009 at 5:18 AM, Greg Smith wrote:
> On Fri, 28 Aug 2009, Tom Lane wrote:
>
>> MemoryContextStats() might help. It just dumps the info to stderr
>> though.
>
> Which means it ends up in the database log files in the common configuration
> where where the database's stderr is redire
On Fri, Aug 28, 2009 at 7:35 AM, Greg Smith wrote:
> It's really amazing that a useful result ever comes out of this model at
> all, and I know I'm not alone that I presume all Linux kernel releases are
> too full of bugs to be useful until I've proven otherwise with my own QA.
>
> If the core Post
On Thu, Aug 27, 2009 at 08:02:03PM -0700, Ron Mayer wrote:
> Andrew Dunstan wrote:
> > I don't know of anyone who is likely to want to try out alphas in their
> > normal development environments. The client I approached was
> > specifically prepared to test beta releases that way.
>
> Perhaps end-
Greg Smith wrote:
The Linux kernel developers are very clear that they don't care one
bit about testing for stability or lack of data loss in any
system-oriented way. That's somebody else's job now, typically the
Linux distributor who decides which of the kernels floating around are
the m
On Thu, Aug 27, 2009 at 09:38:15PM +0200, Dimitri Fontaine wrote:
> Exactly, and I think that what we're missing here is a simple tool for
> our users to check a new PostgreSQL release against their existing
> application.
>
> We already know how to either log all queries and analyze the log files
Another attempt at replacing the current HYPOT macro with a much better
behaved function. I've added comments addressing those sections of code
that tripped people up before. As well as explaining some of the design
decisions. Feedback appreciated.
Index: src/backend/utils/adt/geo_ops.c
===
On Fri, 28 Aug 2009, Tom Lane wrote:
MemoryContextStats() might help. It just dumps the info to stderr
though.
Which means it ends up in the database log files in the common
configuration where where the database's stderr is redirected to there.
I even script running this regularly against
61 matches
Mail list logo
