On Tue, Oct 13, 2009 at 10:25 PM, Tom Lane wrote:
> Dave Page writes:
>> On Tue, Oct 13, 2009 at 9:13 PM, Jaime Casanova
>> wrote:
>>> besides, as Robert mention, because of pooler connections using a GUC
>>> is more appropiate...
>
>> I'd like both options to be available to the programmer.
>
>
Tom Lane wrote:
> 2. I do not understand the stuff with propagating counts into the top
> instrumentation node. That seems like it's going to double-count those
> counts. In any case it is 100% inconsistent to propagate only buffer
> counts that way and not any other resource usage. I think y
In the hot standby patch, we have this comment in procarray.c:
> It is
> * important that the XLOG_XACT_ASSIGNMENT record contain *all* subxids
> * not just those so far unreported because the sole purpose is to ensure
> * we can remove the xids from KnownAssignedXids.
As the patch stands, t
On Wed, 2009-10-14 at 14:43 +0300, Heikki Linnakangas wrote:
> In the hot standby patch, we have this comment in procarray.c:
>
> > It is
> > * important that the XLOG_XACT_ASSIGNMENT record contain *all* subxids
> > * not just those so far unreported because the sole purpose is to ensure
> >
Itagaki Takahiro writes:
> Tom Lane wrote:
>> 2. I do not understand the stuff with propagating counts into the top
>> instrumentation node.
> It is required by contrib/pg_stat_statements. EXPLAIN wants per-node
> accumulation, but pg_stat_statements wants the total number.
Well, you need to fi
On Mon, Sep 28, 2009 at 7:37 PM, Tom Lane wrote:
>> IOW, having plaintext password in CREATE/ALTER time which can
>> then checked for weaknesses is better that MD5 password, which
>> actually does not increase security.
>
> This is not acceptable and will not happen. The case that ENCRYPTED
> pr
If someone wants to start working on the release notes for alpha 2, now
would be a good time.
In general, do we want the alpha 2 release notes as a separate section
above alpha 1, or merged with the alpha 1 notes thereby giving a
cumulative view of what happened since 8.4?
--
Sent via pgsql-hac
Dave Page writes:
> On Tue, Oct 13, 2009 at 10:25 PM, Tom Lane wrote:
>> We have several things already that can be fed either from an
>> environment variable or an option in the connection string.
>> Is there any compelling reason why those two mechanisms aren't
>> adequate for this?
> Err, yes
On Wed, Oct 14, 2009 at 3:42 PM, Tom Lane wrote:
> Dave Page writes:
>> On Tue, Oct 13, 2009 at 10:25 PM, Tom Lane wrote:
>>> We have several things already that can be fed either from an
>>> environment variable or an option in the connection string.
>>> Is there any compelling reason why those
On Tue, Oct 13, 2009 at 05:08:20PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> > The attached updated patch renames all user-visible uses of
> > "utf8" to "unicode". It also updates the documentation
> > regarding "locale" to "psql client character set encoding"
> > so the docs now match the c
Dave Page writes:
> I would suggest that in addition to the proposed plugin, we add an
> suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED
> PASSWORD to ensure that the password complexity can be checked when
> roles are created or modified.
That's going to stop us from being
Tom Lane wrote:
Dave Page writes:
I would suggest that in addition to the proposed plugin, we add an
suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED
PASSWORD to ensure that the password complexity can be checked when
roles are created or modified.
That's going
On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane wrote:
> Dave Page writes:
>> I would suggest that in addition to the proposed plugin, we add an
>> suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED
>> PASSWORD to ensure that the password complexity can be checked when
>> roles are c
Dave Page writes:
> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane wrote:
>> If you're really intent on making that happen, you can have your
>> password checker plugin reject crypted passwords; we don't need
>> such a questionable rule in core.
> Client software would need to have a standard way to
On 10/14/09, Dave Page wrote:
> On Mon, Sep 28, 2009 at 7:37 PM, Tom Lane wrote:
>
> >> IOW, having plaintext password in CREATE/ALTER time which can
> >> then checked for weaknesses is better that MD5 password, which
> >> actually does not increase security.
> >
> > This is not acceptable a
On Wed, Oct 14, 2009 at 4:30 PM, Tom Lane wrote:
> Dave Page writes:
>> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane wrote:
>>> If you're really intent on making that happen, you can have your
>>> password checker plugin reject crypted passwords; we don't need
>>> such a questionable rule in core.
On Wed, Oct 14, 2009 at 11:44 AM, Dave Page wrote:
> On Wed, Oct 14, 2009 at 4:30 PM, Tom Lane wrote:
>> Dave Page writes:
>>> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane wrote:
If you're really intent on making that happen, you can have your
password checker plugin reject crypted passw
KaiGai Kohei writes:
> Tom Lane wrote:
>> The most serious problem is that you ripped out myLargeObjectExists(),
>> apparently because you didn't understand what it's there for. The reason
>> it's there is to ensure that pg_dump runs don't fail. pg_dump is expected
>> to produce a consistent dum
Dave Page writes:
> You've twice asserted it's a reduction without providing any arguments
> to back that up.
You quoted two good arguments why it's insecure in your original
message, neither of which your proposed GUC does anything to protect
against; and you also admitted that there might be ot
On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane wrote:
> Dave Page writes:
>> You've twice asserted it's a reduction without providing any arguments
>> to back that up.
>
> You quoted two good arguments why it's insecure in your original
> message, neither of which your proposed GUC does anything to pr
On Wed, 2009-10-14 at 17:35 +0300, Peter Eisentraut wrote:
> In general, do we want the alpha 2 release notes as a separate section
> above alpha 1, or merged with the alpha 1 notes thereby giving a
> cumulative view of what happened since 8.4?
Cumulative makes sense to me. Even if people are tryi
Dave Page writes:
> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane wrote:
> I see one, and I proposed masking passwords in any relevant queries
> before they were written to the stats or logs to mitigate that.
Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to
throw a syntax error be
On Wed, Oct 14, 2009 at 5:25 PM, Tom Lane wrote:
> Dave Page writes:
>> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane wrote:
>> I see one, and I proposed masking passwords in any relevant queries
>> before they were written to the stats or logs to mitigate that.
>
> Let's see you do that (hint: "CRE
Hi,
the attached patch makes ECPG more robust
against applications that free() strings by storing
its own copy of the prepared statement name.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
On Oct 13, 2009, at 11:02 AM, Dave Page wrote:
A useful feature found in other DBMSs such as MS SQL Server that has
been requested on these lists a few times, is the ability for a client
application to report its name to the server.
I've been following this thread closely and haven't seen ment
On Wed, Oct 14, 2009 at 18:25, Tom Lane wrote:
> Dave Page writes:
>> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane wrote:
>> I see one, and I proposed masking passwords in any relevant queries
>> before they were written to the stats or logs to mitigate that.
>
> Let's see you do that (hint: "CREAT
On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge wrote:
> On Oct 13, 2009, at 11:02 AM, Dave Page wrote:
>
>> A useful feature found in other DBMSs such as MS SQL Server that has
>> been requested on these lists a few times, is the ability for a client
>> application to report its name to the server
On Wed, Oct 14, 2009 at 18:39, Dave Page wrote:
> On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge wrote:
>> On Oct 13, 2009, at 11:02 AM, Dave Page wrote:
>>
>>> A useful feature found in other DBMSs such as MS SQL Server that has
>>> been requested on these lists a few times, is the ability for a
Dave Page writes:
> On Wed, Oct 14, 2009 at 5:25 PM, Tom Lane wrote:
>> So you can use a plugin that does it that way, or if you want you
>> can use a plugin that throws error on a pre-md5'd password.
> My only concern with that idea is having some way for the client to
> know when to not hash t
Magnus Hagander writes:
> On Wed, Oct 14, 2009 at 18:25, Tom Lane wrote:
>> Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to
>> throw a syntax error before you realize there's anything there that
>> might need to be protected).
> I'm unsure if it's our responsibility to think
Dave Page writes:
> On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge wrote:
>> I've been following this thread closely and haven't seen mention of
>> including the setting as part of the process name, so a 'ps' (on Unix) would
>> display it. Thoughts?
> Isn't that cluttered enough already?
Given
nMagnus Hagander wrote:
> > Marko has pointed out repeatedly that a plugin can catch the worst
> > cases of insecure passwords even when given a pre-md5'd password.
> > So you can use a plugin that does it that way, or if you want you
> > can use a plugin that throws error on a pre-md5'd password.
On Wed, Oct 14, 2009 at 12:25 PM, Tom Lane wrote:
> Dave Page writes:
>> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane wrote:
>> I see one, and I proposed masking passwords in any relevant queries
>> before they were written to the stats or logs to mitigate that.
>
> Let's see you do that (hint: "CR
Peter Eisentraut writes:
> Btw., I might not get a chance to commit this within the next 48 hours.
> If someone else wants to, go ahead.
I will take it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On Oct 14, 2009, at 12:39 PM, Dave Page wrote:
Isn't that cluttered enough already?
I find the ps output uninformative. Having it display something that
gets generated from my application would start to make it useful.
Maybe what I really want is a totally different feature:
log_line_p
Robert Haas writes:
> On Wed, Oct 14, 2009 at 12:25 PM, Tom Lane wrote:
>> Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to
>> throw a syntax error before you realize there's anything there that
>> might need to be protected).
> It seems to me incredibly rare for anyone to iss
When I run ./configure, I get
(...warning..)
(If you are using the official distribution of PostgreSQL then you do
not need to worry about this because the Flex output is pre-generated.)
Well, I am am using the official distribution of PostreSQL and the
output is not pre-generated. Clearly this
Simon Riggs writes:
> When I run ./configure, I get
> (If you are using the official distribution of PostgreSQL then you do
> not need to worry about this because the Flex output is pre-generated.)
> Well, I am am using the official distribution of PostreSQL and the
> output is not pre-generated
Simon Riggs wrote:
>
> When I run ./configure, I get
>
> (...warning..)
> (If you are using the official distribution of PostgreSQL then you do
> not need to worry about this because the Flex output is pre-generated.)
>
> Well, I am am using the official distribution of PostreSQL and the
> outpu
On Wed, Oct 14, 2009 at 10:28 AM, Bruce Momjian wrote:
>
> I see three checks we are trying to do on passwords:
>
> 1) Password complexity enforcement/policies
> 2) Password history - you can't reuse a password
> 3) Account disable after X incorrect attempts
This whole discu
On Wed, Oct 14, 2009 at 7:42 PM, Greg Stark wrote:
> On Wed, Oct 14, 2009 at 10:28 AM, Bruce Momjian wrote:
>>
>> I see three checks we are trying to do on passwords:
>>
>> 1) Password complexity enforcement/policies
>> 2) Password history - you can't reuse a password
>> 3) A
On Wed, Oct 14, 2009 at 6:08 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Oct 14, 2009 at 18:25, Tom Lane wrote:
>>> Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to
>>> throw a syntax error before you realize there's anything there that
>>> might need to be protec
On Wed, Oct 14, 2009 at 1:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Oct 14, 2009 at 12:25 PM, Tom Lane wrote:
>>> Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to
>>> throw a syntax error before you realize there's anything there that
>>> might need to be protect
On 10/14/2009 12:25 PM, Tom Lane wrote:
Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to
throw a syntax error before you realize there's anything there that
might need to be protected).
And you ignored the question of insecure transmission pathways, anyway.
By the time the bac
Dave Page writes:
> On Wed, Oct 14, 2009 at 7:42 PM, Greg Stark wrote:
>> This whole discussion seems very strange to me. Surely any
>> organization with rules like this will want them to be system-wide and
>> will have already implemented them in their PAM and LDAP systems
>> (assuming their not
On Wed, Oct 14, 2009 at 9:00 PM, Tom Lane wrote:
> Okay, fine, so we're not looking for actual high-grade security,
> we're looking to tick off a checkbox in the minds of not terribly
> well-informed people. Then the plugin mechanism as currently proposed
> will do the job just fine. We do not n
I tried making a functional index based on an expression containing
the 2 argument regexp_matches() function. Is there a reason why this
function is not marked immutable instead of normal?
regards,
Rod Taylor
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Dave Page writes:
> I said up front this was a box-ticking exercise for these folks,
> however, rather than just tick the box and move on (meh - who cares if
> we can store 2009-02-31 - it stores all the valid dates which are the
> ones that matter :-p ) I prefer to discuss the issue and do the be
Dave Page wrote:
> I said up front this was a box-ticking exercise for these folks,
Can they check the box if the provided clients include password
strength checking? I'm just wondering if we're going at this the hard
way, if that really is the main goal.
>From the point of view of usefulne
Rod Taylor writes:
> I tried making a functional index based on an expression containing
> the 2 argument regexp_matches() function. Is there a reason why this
> function is not marked immutable instead of normal?
regex_flavor affects its result.
regards, tom lane
--
Se
On Wed, Oct 14, 2009 at 04:51:03PM -0400, Tom Lane wrote:
> Rod Taylor writes:
> > I tried making a functional index based on an expression
> > containing the 2 argument regexp_matches() function. Is there a
> > reason why this function is not marked immutable instead of
> > normal?
>
> regex_fla
David Fetter wrote:
On Wed, Oct 14, 2009 at 04:51:03PM -0400, Tom Lane wrote:
Rod Taylor writes:
I tried making a functional index based on an expression
containing the 2 argument regexp_matches() function. Is there a
reason why this function is not marked immutable instead of
normal
David Fetter wrote:
> On Wed, Oct 14, 2009 at 04:51:03PM -0400, Tom Lane wrote:
>> Rod Taylor writes:
>> > I tried making a functional index based on an expression
>> > containing the 2 argument regexp_matches() function. Is there a
>> > reason why this function is not marked immutable instead of
"Kevin Grittner" writes:
> And, perhaps slightly off topic: if the login password is sent over a
> non-encrypted stream, md5sum or not, can't someone use it to log in if
> they're generating their own stream to connect?
Not if they only capture a login exchange --- the password is doubly
encrypte
On Wed, 2009-10-14 at 15:06 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> >
> > When I run ./configure, I get
> >
> > (...warning..)
> > (If you are using the official distribution of PostgreSQL then you do
> > not need to worry about this because the Flex output is pre-generated.)
> >
> >
On 10/14/09 2:07 PM, David Fetter wrote:
> On Wed, Oct 14, 2009 at 04:51:03PM -0400, Tom Lane wrote:
>> Rod Taylor writes:
>>> I tried making a functional index based on an expression
>>> containing the 2 argument regexp_matches() function. Is there a
>>> reason why this function is not marked imm
On Wed, Oct 14, 2009 at 9:50 PM, Kevin Grittner
wrote:
> Dave Page wrote:
>
>> I said up front this was a box-ticking exercise for these folks,
>
> Can they check the box if the provided clients include password
> strength checking? I'm just wondering if we're going at this the hard
> way, if th
On Wed, Oct 14, 2009 at 05:14:31PM -0400, Andrew Dunstan wrote:
> David Fetter wrote:
>> On Wed, Oct 14, 2009 at 04:51:03PM -0400, Tom Lane wrote:
>>
>>> Rod Taylor writes:
>>>
I tried making a functional index based on an expression
containing the 2 argument regexp_matches() fun
On Sun, 2009-10-04 at 10:48 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > I understand the annoyance, but I think we do need to have an organized
> > way to do testing of non-ASCII data and in particular UTF8 data, because
> > there are an increasing number of special code paths for those.
Tom Lane wrote:
> "Kevin Grittner" writes:
>> if the login password is sent over a non-encrypted stream, md5sum
>> or not, can't someone use it to log in if they're generating their
>> own stream to connect?
> If they see the md5'd password in a CREATE USER command, then yeah
So anyone in a
Dave Page wrote:
> No. Any checks at the client are worthless, as they can be bypassed
> by 10 minutes worth of simple coding in any of a dozen or more
> languages.
Well, sure, but we're talking about a client going out of their way to
wrestle the point of the gun toward their own foot, aren't
> +1 It would seem to me to be more valuable to have the benefits of
> IMMUTABLE than preserve pre-7.4 compatibility forever.
Just create a shell function which calls it in a specific flavor, and
make that immutable.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner
wrote:
> Dave Page wrote:
>
>> No. Any checks at the client are worthless, as they can be bypassed
>> by 10 minutes worth of simple coding in any of a dozen or more
>> languages.
>
> Well, sure, but we're talking about a client going out of their w
Andrew Dunstan writes:
> David Fetter wrote:
>> Speaking of which, can we see about deprecating and removing this GUC?
>> I've yet to hear of anyone using a flavor other than the default.
> You have now. I have a client who sadly uses a non-default setting. And
> on 8.4, what is more.
How criti
Tom Lane wrote:
> "Kevin Grittner" writes:
> > And, perhaps slightly off topic: if the login password is sent over a
> > non-encrypted stream, md5sum or not, can't someone use it to log in if
> > they're generating their own stream to connect?
>
> Not if they only capture a login exchange --- the
On Wed, 2009-10-14 at 12:59 -0400, Tom Lane wrote:
> If psql or pgAdmin takes a password and
> then sends it in the clear without telling me, that's a breach of
> trust
> with potentially serious consequences. I might not trust the DBA, for
> example, or I might be less confident of the network in
Itagaki Takahiro writes:
> column-trigger_20091014.patch is a full patch to the HEAD.
Applied with assorted corrections, mostly cosmetic but not entirely.
One thing you really should have caught was updating
copyfuncs/equalfuncs for the parsenode field addition.
Next time, try grepping for every
On Wed, Oct 14, 2009 at 06:06:23PM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > David Fetter wrote:
> >> Speaking of which, can we see about deprecating and removing this GUC?
> >> I've yet to hear of anyone using a flavor other than the default.
>
> > You have now. I have a client who sad
On 10/14/2009 05:33 PM, Dave Page wrote:
On Wed, Oct 14, 2009 at 9:50 PM, Kevin Grittner
wrote:
Can they check the box if the provided clients include password
strength checking? I'm just wondering if we're going at this the hard
way, if that really is the main goal.
No. Any checks
Peter Eisentraut writes:
> Well, you would lose anyway if the DBA switches the pg_hba.conf setting
> from md5 to password without telling you.
True :-(. Anybody for a zero-knowledge protocol?
(Realistically, non-password-based auth methods are the only real
solution here, I fear. We should pro
On Wed, 2009-10-14 at 13:08 -0400, Tom Lane wrote:
> The reason to not want cleartext passwords in the logs is that the
> user doesn't trust the DBA.
I originally implemented the encrypt-on-the-client logic because the
previous way of using ALTER USER ... PASSWORD would promiscuously leave
the cle
On Wed, 2009-10-14 at 18:38 +0200, Magnus Hagander wrote:
> So throwing out a wild idea that's probably just wild enough to even
> consider, but one way to deal with the logging side of things would be
> to deprecate/remove ALTER USER/CREATE USER with password, and add a
> separate API call. With a
Bruce Momjian writes:
> Tom Lane wrote:
>> But the main point is to hide the cleartext password, in any case.
> What if we added a GUC that only allowed password changes via an SSL
> connection.
How's that help? The user has already exposed their new choice of
password to any hypothetical eaves
On 10/14/2009 06:02 PM, Dave Page wrote:
On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner
wrote:
Well, sure, but we're talking about a client going out of their way to
wrestle the point of the gun toward their own foot, aren't we? If
we're worried about the user compromising their own pas
On 10/14/2009 06:25 PM, Peter Eisentraut wrote:
On Wed, 2009-10-14 at 18:38 +0200, Magnus Hagander wrote:
So throwing out a wild idea that's probably just wild enough to even
consider, but one way to deal with the logging side of things would be
to deprecate/remove ALTER USER/CREATE USER wit
Peter Eisentraut writes:
> On Wed, 2009-10-14 at 15:06 -0300, Alvaro Herrera wrote:
>> I take it "official distribution" means "tarball" as different from a
>> copy obtained thru CVS.
> Maybe "If you are using an official release tarball of PostgreSQL", or
> "an official release source code archi
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > Well, you would lose anyway if the DBA switches the pg_hba.conf setting
> > from md5 to password without telling you.
>
> True :-(. Anybody for a zero-knowledge protocol?
>
> (Realistically, non-password-based auth methods ar
On Thu, 2009-10-15 at 00:26 +0300, Peter Eisentraut wrote:
> On Wed, 2009-10-14 at 15:06 -0300, Alvaro Herrera wrote:
> > Simon Riggs wrote:
> > >
> > > When I run ./configure, I get
> > >
> > > (...warning..)
> > > (If you are using the official distribution of PostgreSQL then you do
> > > not n
Martin Pihlak escribió:
> > By chance I noticed that the foreign_data regression test fails if run
> > in an installation where "bob" is a live user. It appears to be
> > assuming that half a dozen other fairly common names don't belong to
> > real users, either. Could we make this a little less
On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane wrote:
> KaiGai Kohei writes:
>> Tom Lane wrote:
>>> The most serious problem is that you ripped out myLargeObjectExists(),
>>> apparently because you didn't understand what it's there for. The reason
>>> it's there is to ensure that pg_dump runs don't
On Wed, Oct 14, 2009 at 9:56 AM, Tom Lane wrote:
> Itagaki Takahiro writes:
>> Tom Lane wrote:
>>> 2. I do not understand the stuff with propagating counts into the top
>>> instrumentation node.
>
>> It is required by contrib/pg_stat_statements. EXPLAIN wants per-node
>> accumulation, but pg_sta
On Sat, Oct 10, 2009 at 2:09 PM, Boszormenyi Zoltan wrote:
> Michael Meskes írta:
>> On Thu, Oct 08, 2009 at 01:15:58PM +0200, Boszormenyi Zoltan wrote:
>>
What's the point of that? It can't be applied without documentation,
and it just makes life more complicated to have two separate p
Tom Lane wrote:
> Applied with assorted corrections, mostly cosmetic but not entirely.
> One thing you really should have caught was updating
> copyfuncs/equalfuncs for the parsenode field addition.
> Next time, try grepping for every reference to a struct type you
> change ...
Thanks for the f
Tom Lane wrote:
>> The newer basis is same as other database objects, such as functions.
>> But why pg_dump performs correctly for these database objects?
>
> The reason pg_dump works reasonably well is that it takes locks on
> tables, and the other objects it dumps (such as functions) have
> indi
Robert Haas wrote:
> On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane wrote:
>> KaiGai Kohei writes:
>>> Tom Lane wrote:
The most serious problem is that you ripped out myLargeObjectExists(),
apparently because you didn't understand what it's there for. The reason
it's there is to ensur
2009/10/13 KaiGai Kohei :
> The attached patch is a revised one with the following updates:
Despite two fairly explicit requests, this patch (and, with the
exception of ECPG, only this patch) has not yet been reviewed by a
committer.
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00591.p
Robert Haas wrote:
> > Well, you need to find another way or risk getting the patch rejected
> > altogether. ?Those global variables are the weakest part of the whole
> > design, and I'm not going to commit a patch that destabilizes the entire
> > system for the sake of a debatable "requirement"
Robert Haas writes:
> Are any of the committers willing to take a look at this? Tom?
I do plan to look at it tomorrow.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas
wrote:
>> Do you
>> have any sense of how soon you'll feel confident to commit either
>> patch?
>
> I'm bad at estimating. Not this week for sure, and next week I'm
> traveling and won't be able to spend as much time on it as I am right
> now.
Robert Haas wrote:
> 2009/10/13 KaiGai Kohei :
>> The attached patch is a revised one with the following updates:
>
> Despite two fairly explicit requests, this patch (and, with the
> exception of ECPG, only this patch) has not yet been reviewed by a
> committer.
>
> http://archives.postgresql.or
2009/10/14 Itagaki Takahiro :
>
> Robert Haas wrote:
>
>> > Well, you need to find another way or risk getting the patch rejected
>> > altogether. ?Those global variables are the weakest part of the whole
>> > design, and I'm not going to commit a patch that destabilizes the entire
>> > system for
Robert Haas wrote:
> On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas
> wrote:
>>> Do you
>>> have any sense of how soon you'll feel confident to commit either
>>> patch?
>> I'm bad at estimating. Not this week for sure, and next week I'm
>> traveling and won't be able to spend as much time o
Robert Haas wrote:
> My (limited) experience is that it's usually better to get something
> incremental committed, even if it's not what you really want. You can
> always take another crack at the remaining issues later, but if the
> whole patch gets shot down then you are out of luck.
Yeah, t
On Wed, Oct 14, 2009 at 9:38 PM, Itagaki Takahiro
wrote:
>
> Robert Haas wrote:
>
>> My (limited) experience is that it's usually better to get something
>> incremental committed, even if it's not what you really want. You can
>> always take another crack at the remaining issues later, but if th
2009/10/14 KaiGai Kohei :
> Robert Haas wrote:
>> On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas
>> wrote:
Do you
have any sense of how soon you'll feel confident to commit either
patch?
>>> I'm bad at estimating. Not this week for sure, and next week I'm
>>> traveling and wo
2009/10/14 KaiGai Kohei :
> Robert Haas wrote:
>> On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane wrote:
>>> KaiGai Kohei writes:
Tom Lane wrote:
> The most serious problem is that you ripped out myLargeObjectExists(),
> apparently because you didn't understand what it's there for. The r
On Wed, Oct 14, 2009 at 9:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> Are any of the committers willing to take a look at this? Tom?
>
> I do plan to look at it tomorrow.
Oh, great. You've done an impressive job slogging through a bunch of
big, complex patches in the last week.
Thanks,
.
Tom Lane wrote:
Andrew Dunstan writes:
David Fetter wrote:
Speaking of which, can we see about deprecating and removing this GUC?
I've yet to hear of anyone using a flavor other than the default.
You have now. I have a client who sadly uses a non-default setting. And
on
Andrew Dunstan writes:
> They are probably quite open to changing it, but IIRC it is a setting
> imposed by OpenACS, which is what they are based on.
I seem to recall having asked this before ... but does OpenACS even
know what they're doing here? The difference between ERE mode and ARE
mode is
Robert Haas wrote:
> 2009/10/14 KaiGai Kohei :
>> Robert Haas wrote:
>>> On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane wrote:
KaiGai Kohei writes:
> Tom Lane wrote:
>> The most serious problem is that you ripped out myLargeObjectExists(),
>> apparently because you didn't understand
1 - 100 of 106 matches
Mail list logo
