On Fri, Aug 27, 2010 at 09:35:55PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Didn't we inject some smarts so that the compiler would notice that
> > elog(ERROR) doesn't return?
>
> No. If you know a portable (as in "works on every compiler") way
> to do that, we could talk. If only so
On Fri, Aug 27, 2010 at 9:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> What's a bit odd about this is that I do get warnings for this kind of
>> thing in general, which get turned into errors since I compile with
>> -Werror; and in fact the version of the patch that I committed has no
>> fewer
Robert Haas writes:
> What's a bit odd about this is that I do get warnings for this kind of
> thing in general, which get turned into errors since I compile with
> -Werror; and in fact the version of the patch that I committed has no
> fewer than four places where there is a comment that says "pl
On Fri, Aug 27, 2010 at 9:35 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Didn't we inject some smarts so that the compiler would notice that
>> elog(ERROR) doesn't return?
>
> No. If you know a portable (as in "works on every compiler") way
> to do that, we could talk. If only some compiler
Alvaro Herrera writes:
> Didn't we inject some smarts so that the compiler would notice that
> elog(ERROR) doesn't return?
No. If you know a portable (as in "works on every compiler") way
to do that, we could talk. If only some compilers understand it,
we'll probably end up worse off --- the on
Excerpts from Robert Haas's message of vie ago 27 18:07:55 -0400 2010:
> On Fri, Aug 27, 2010 at 5:57 PM, Kevin Grittner
> wrote:
> > Robert Haas wrote:
> >> I suppose this is unhappy because it things elog(ERROR) might
> >> return?
> >
> > If I set these fields right in front of the elog(ERROR)
Robert Haas wrote:
> I set them right after the ERROR so that those statements needn't
> actually be executed.
Good thinking.
I checked and that also eliminates the warnings for me. (No
surprise there, of course.)
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On Fri, Aug 27, 2010 at 5:57 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> I suppose this is unhappy because it things elog(ERROR) might
>> return?
>
> If I set these fields right in front of the elog(ERROR) the warnings
> go away for me. (Hopefully this observation will make up, to some
> e
Robert Haas wrote:
> I suppose this is unhappy because it things elog(ERROR) might
> return?
If I set these fields right in front of the elog(ERROR) the warnings
go away for me. (Hopefully this observation will make up, to some
extent, for my earlier brain fart.)
-Kevin
--
Sent via pgsql-
Robert Haas wrote:
> OK, I must be missing something. Go through that a little slower?
No, my mistake. Please ignore.
I am getting the same warnings, but I think your take on the cause
must be right.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Fri, Aug 27, 2010 at 5:35 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> I suppose this is unhappy because it things elog(ERROR) might
>> return?
>
> It looks more like this code uses it without initialization:
>
> case OBJECT_INDEX:
> case OBJECT_SEQUENCE:
> case OBJEC
Robert Haas wrote:
> I suppose this is unhappy because it things elog(ERROR) might
> return?
It looks more like this code uses it without initialization:
case OBJECT_INDEX:
case OBJECT_SEQUENCE:
case OBJECT_TABLE:
case OBJECT_VIEW:
relation =
On Fri, Aug 27, 2010 at 4:16 PM, Peter Eisentraut wrote:
> On fre, 2010-08-27 at 07:49 -0400, Robert Haas wrote:
>> Anyway, committed.
>
> I suppose this is responsible for this:
>
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-alias
On fre, 2010-08-27 at 07:49 -0400, Robert Haas wrote:
> Anyway, committed.
I suppose this is responsible for this:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
-fwrapv -g -Werror -Wno-inline -I../../../src/include -D_GNU_SOUR
On Fri, Aug 27, 2010 at 12:52 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Aug 19, 2010 at 3:34 PM, Tom Lane wrote:
>>> Robert Haas writes:
Any other kibitzing before I commit this?
>>>
>>> Sure ...
>>>
>>> [kibitzing]
>
>> v4.
>
> For my money, you could just have said "Applied wi
Robert Haas writes:
> On Thu, Aug 19, 2010 at 3:34 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Any other kibitzing before I commit this?
>>
>> Sure ...
>>
>> [kibitzing]
> v4.
For my money, you could just have said "Applied with suggested changes".
They were pretty darn trivial.
Robert Haas writes:
> Any other kibitzing before I commit this?
Sure ...
+ * If the object is a relation or a child object of a relation (e.g. an
+ * attribute or contraint, *relp will set to point to that relation). This
Parenthesis in the wrong place here, grammar and spelling not much bet
On Thu, Aug 19, 2010 at 11:57 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Robert Haas's message of mié ago 18 21:32:48 -0400 2010:
>>> Here's v3.
>
>> The header comment in objectaddress.c contains a funny mistake: it says
>> it works with ObjectAddresses. However, ObjectAddres
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mié ago 18 21:32:48 -0400 2010:
>> Here's v3.
> The header comment in objectaddress.c contains a funny mistake: it says
> it works with ObjectAddresses. However, ObjectAddresses is a different
> type altogether, so I recommend not
Excerpts from Robert Haas's message of mié ago 18 21:32:48 -0400 2010:
> Here's v3.
The header comment in objectaddress.c contains a funny mistake: it says
it works with ObjectAddresses. However, ObjectAddresses is a different
type altogether, so I recommend not using that as plural for
ObjectAd
Robert Haas writes:
> On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane wrote:
>> I don't insist that the separation has to be crisp. I'm merely saying
>> that putting a large chunk of useful-only-at-execution-time code into
>> backend/parser is the Wrong Thing.
> OK, but there should be a reason for t
On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane wrote:
>>> Rereading this, I see I didn't make my point very clearly. The reason
>>> this code doesn't belong in parser/ is that there's no prospect the
>>> parser itself would e
Robert Haas writes:
> On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane wrote:
>> Rereading this, I see I didn't make my point very clearly. The reason
>> this code doesn't belong in parser/ is that there's no prospect the
>> parser itself would ever use it. ObjectAddress is an execution-time
>> creat
On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane wrote:
> I wrote:
>> Maybe so, but the parser is expected to put out a representation that
>> will still be valid when the command is executed some time later.
>
> Rereading this, I see I didn't make my point very clearly. The reason
> this code doesn't
I wrote:
> Maybe so, but the parser is expected to put out a representation that
> will still be valid when the command is executed some time later.
Rereading this, I see I didn't make my point very clearly. The reason
this code doesn't belong in parser/ is that there's no prospect the
parser its
Robert Haas writes:
> On Mon, Aug 16, 2010 at 3:48 PM, Tom Lane wrote:
>> I think the problem is you're trying to put this into backend/parser
>> which is not really the right place for it.
> If this isn't parse analysis, then you and I have very different ideas
> of what parse analysis is.
May
On Mon, Aug 16, 2010 at 3:48 PM, Tom Lane wrote:
>> 2. I haven't done anything about moving the definition of
>> ObjectAddress elsewhere, as Alvaro suggested, because I'm not sure
>> quite where it ought to go. I still think it's a good idea, though
>> I'm not dead set on it, either. Suggestions
Robert Haas writes:
> 5. Since I'm hoping Tom will read this, I ran it through filterdiff. :-)
OK, I looked ;-). It mostly looks good, but of course I've got some
opinions...
> 2. I haven't done anything about moving the definition of
> ObjectAddress elsewhere, as Alvaro suggested, because I'm
Excerpts from KaiGai Kohei's message of lun ago 16 00:19:54 -0400 2010:
> (2010/08/16 11:50), Robert Haas wrote:
> When we were developing largeobject access controls, Tom Lane commented
> as follows:
>
> * Re: [HACKERS] [PATCH] Largeobject access controls
> http://marc.info/?l=pgsql-hackers&m=
(2010/08/16 11:50), Robert Haas wrote:
> On Fri, Aug 6, 2010 at 11:15 PM, KaiGai Kohei wrote:
>> [brief review]
>
> OK, here's an updated patch:
>
> 1. I fixed the typo Alvaro spotted.
>
> 2. I haven't done anything about moving the definition of
> ObjectAddress elsewhere, as Alvaro suggested,
(2010/08/07 0:02), Robert Haas wrote:
At PGCon, we discussed the possibility that a minimal SE-PostgreSQL
implementation would need little more than a hook in
ExecCheckRTPerms() [which we've since added] and a security label
facility [for which KaiGai has submitted a patch]. I actually sat
down
On Fri, Aug 6, 2010 at 12:26 PM, Simon Riggs wrote:
> I understand the concept and it seems like it might work. Not too keen
> on pretending a noun is a verb. That leads to erroring.
>
> SECURITY LABEL? verb = CREATE, ADD, ...
>
> Can't objects have more than one label?
>
> How will you set defau
On Fri, 2010-08-06 at 11:02 -0400, Robert Haas wrote:
> At PGCon, we discussed the possibility that a minimal SE-PostgreSQL
> implementation would need little more than a hook in
> ExecCheckRTPerms() [which we've since added] and a security label
> facility [for which KaiGai has submitted a patch].
On Fri, Aug 6, 2010 at 11:36 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of vie ago 06 11:02:58 -0400 2010:
>
>> Any comments? (ha ha ha...)
>
> Interesting idea. The patch looks fine on a quick once-over.
Thanks for taking a look.
> Two small
> things: this comment
>
> +
Excerpts from Robert Haas's message of vie ago 06 11:02:58 -0400 2010:
> Any comments? (ha ha ha...)
Interesting idea. The patch looks fine on a quick once-over. Two small
things: this comment
+/*
+ * Databases, tablespaces, and roles are cluster-wide objects, so any
+ * comments
35 matches
Mail list logo
