"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I noticed an editing error in the patch I originally submitted; it
> defined the same debugging macro twice.
> I've attached a fresh copy of the patch against the current HEAD with
> the fix included.
Working through this patch now. I found one thing t
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
>> As discussed on -hackers, I've done some refactoring work on
>> backend/utils/adt/formatting.c, in an attempt to make the code a bit
>> more intelligible before improving handling of bogus formats.
Applied with minor revisions.
Added to Win32 TODO:
o Fix MSVC NLS support, like for to_char()
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00485.php
http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php
--
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> [ second version of quote_nullable patch ]
Applied with some revisions to sync it with CVS HEAD --- primarily,
since we now have a quote_literal(anyelement) function, it seemed
important to add a quote_nullable(anyelement) variant. I also
editorialized
Simon Riggs wrote:
> On Thu, 2008-01-31 at 11:20 -0300, Alvaro Herrera wrote:
> > > Tom Lane wrote:
> >
> > > > in fact, personally I'd like to make that case be a hard error,
> > > > rather than something people could override with -i.
> >
> > +1 to this idea. TODO for 8.4?
>
> -1 without some
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have developed the attached patch with improves wording for the
> pg_dump -i (ignore version) option.
I think this is going in exactly the wrong direction --- it makes
both the documentation and the warning message less scary not more
so.
Neil Conway <[EMAIL PROTECTED]> writes:
> Attached is a patch that allows an array of Datums + nulls to be
> inserted into a tuplestore without first creating a HeapTuple, per
> recent suggestion on -hackers. This avoids making an unnecessary copy.
> There isn't a really analogous optimization to b
I wrote:
One thing that I worried about for a little bit is that you can imagine
privilege-escalation scenarios.
> A conservative approach would be to report the query texts *only* in the
> server log and never to the client --- this would need a bit of klugery
> but seems doable.
Anybo
Tom Lane wrote:
> If we report the query texts only to the server log, we could remove all
> restrictions on which users' queries would be reported. That would
> clearly be helpful in some cases. On the other hand, it would clearly
> be less convenient to use than the existing approach that send
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think we should report to the client where it is not a security
> breach, and to the server log otherwise.
Well, the point of my original comment is that it's not always so
obvious what might be a security breach or not.
> I'm not sure about warts.
10 matches
Mail list logo
