Gregory Stark writes:
> There's an argument to be made that the code is easier to audit if you put the
> "%s" format string in explicitly too.
Yeah, the risk this is trying to guard against is variables containing
"%" unexpectedly. Even if that's not possible, it requires some work
to verify and
Peter Eisentraut writes:
> On Thursday 15 January 2009 02:08:42 Bruce Momjian wrote:
>> Added to TODO:
>> Have statement-level triggers fire for all tables in an
>> inheritance hierarchy
> I don't think that was really the conclusion from the thread.
> As far as I can interpret the opinions, sta
Andrew Chernow writes:
> Any objections adding the below to postgres.h?
> #define VARLEN(PTR) (VARSIZE(PTR) - VARHDRSZ)
For the most part, you should probably be using VARSIZE_ANY_EXHDR
anyplace that that might be a good idea.
regards, tom lane
--
Sent via pgsql-hackers
"Brendan Jurd" writes:
> Does this also explain the extra-weird output from HEAD, with the <=
> and = operators sorting earlier than the view, but the rest of the
> operators sorting after it?
No, that comes from the fact that we have dependencies on those two
operators (but not the whole opclass
Any objections adding the below to postgres.h?
#define VARLEN(PTR) (VARSIZE(PTR) - VARHDRSZ)
It adds a little more abstraction and cleans up userland code.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Peter Eisentraut writes:
> You apparently have your compiler configured with -Wformat-security. Our
> code
> doesn't do that. I think the cases the warning complains about are fine and
> the way the warning is designed is a bit bogus.
Hm, only a bit. You know, we've had precisely this bug
On Saturday 17 January 2009 11:44:07 Alan Li wrote:
> Attached are patches to fix the following compiler warnings that I see when
> using gcc 4.3.2.
>
> MASTER warning:
> tablecmds.c: In function 'DropErrorMsgWrongType':
> tablecmds.c:601: warning: format not a string literal and no format
> argume
On Thursday 15 January 2009 02:08:42 Bruce Momjian wrote:
> Added to TODO:
>
> Have statement-level triggers fire for all tables in an
> inheritance hierarchy
I don't think that was really the conclusion from the thread.
As far as I can interpret the opinions, statement level triggers
On Sun, Jan 18, 2009 at 5:56 AM, Tom Lane wrote:
> Interesting --- it works as expected in 8.2. The problem seems to have
> been created by the introduction of arrays over composites in 8.3.
Congratulations on identifying the source!
Does this also explain the extra-weird output from HEAD, with
Alvaro Herrera writes:
> Tom Lane wrote:
>> No, not really. AFAICS the reason for Alvaro not seeing it must be that
>> on his machine the new transaction happens to allocate its
>> TopTransactionContext control block right in the same place where the
>> old one was.
> But freed memory is clobber
Simon Riggs writes:
> Can we put a identifier into header of each control block, an ascending
> value that is unlikely duplicate between calls? That way we'd be able to
> tell immediately it wasn't the same block,
Same block than what? Unless you can somehow hide that ID number in
a MemoryContex
"Brendan Jurd" writes:
> On Fri, Jan 16, 2009 at 10:23 AM, Tom Lane wrote:
>> However --- it's also the case that
>> pg_dump should dump all operators *and* operator classes before it gets
>> to views. So either you were doing something funny with the dump/reload
>> or else there's a circular de
Tom Lane writes:
> Simon Riggs writes:
>> Can we add something to memory contexts to make this fail every time?
>
> No, not really. AFAICS the reason for Alvaro not seeing it must be that
> on his machine the new transaction happens to allocate its
> TopTransactionContext control block right in
Tom Lane wrote:
> Simon Riggs writes:
> > Can we add something to memory contexts to make this fail every time?
>
> No, not really. AFAICS the reason for Alvaro not seeing it must be that
> on his machine the new transaction happens to allocate its
> TopTransactionContext control block right in
On Sat, 2009-01-17 at 11:35 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > Can we add something to memory contexts to make this fail every time?
>
> No, not really. AFAICS the reason for Alvaro not seeing it must be that
> on his machine the new transaction happens to allocate its
> TopTransa
Simon Riggs writes:
> Can we add something to memory contexts to make this fail every time?
No, not really. AFAICS the reason for Alvaro not seeing it must be that
on his machine the new transaction happens to allocate its
TopTransactionContext control block right in the same place where the
old
On Fri, Jan 16, 2009 at 10:23 AM, Tom Lane wrote:
> However --- it's also the case that
> pg_dump should dump all operators *and* operator classes before it gets
> to views. So either you were doing something funny with the dump/reload
> or else there's a circular dependency in your DB that pg_du
"Brendan Jurd" writes:
> On Sun, Jan 18, 2009 at 2:52 AM, Tom Lane wrote:
>> Is there a hash opclass for the type? 8.4 can group types that have
>> hash but not btree opclasses, but prior versions insisted on btree.
> Well I sure didn't create one. I've only been attempting to create a
> btree
On Sun, Jan 18, 2009 at 2:52 AM, Tom Lane wrote:
> "Brendan Jurd" writes:
>> Update. Turns out that 8.4 DOES know how to execute the view. If you
>> try to group on a user-defined composite type, 8.4 just goes ahead and
>> groups it, rather than giving the old "could not identify an ordering
>>
"Brendan Jurd" writes:
> Update. Turns out that 8.4 DOES know how to execute the view. If you
> try to group on a user-defined composite type, 8.4 just goes ahead and
> groups it, rather than giving the old "could not identify an ordering
> operator" error.
Is there a hash opclass for the type?
On Sun, Jan 18, 2009 at 1:41 AM, Brendan Jurd wrote:
> ... but I'm confused as to why 8.4
> doesn't freak out when told to create a view it doesn't actually know
> how to execute. Have the rules for evaluating views changed?
>
Update. Turns out that 8.4 DOES know how to execute the view. If yo
On Fri, Jan 16, 2009 at 10:23 AM, Tom Lane wrote:
> Looking at it some more, I notice that the SortGroupClause dependencies
> are on the individual operators, which probably isn't good enough: the
> operator *classes* have to exist or the parser will complain when trying
> to make sense of the vie
Attached are patches to fix the following compiler warnings that I see when
using gcc 4.3.2.
MASTER warning:
tablecmds.c: In function 'DropErrorMsgWrongType':
tablecmds.c:601: warning: format not a string literal and no format
arguments
REL8_3_STABLE warnings:
utility.c: In function 'DropErrorMsg
On Fri, 2009-01-16 at 18:43 -0500, Tom Lane wrote:
> What is happening is that autovacuum_do_vac_analyze contains
>
> old_cxt = MemoryContextSwitchTo(AutovacMemCxt);
> ...
> vacuum(vacstmt, relids);
> ...
> MemoryContextSwitchTo(old_cxt);
>
> and at the t
24 matches
Mail list logo
