Re: BUG #6212: PREPARE(pseudotype) should be blocked off

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Caleb(dot)Welton(at)emc(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6212: PREPARE(pseudotype) should be blocked off
Date: 2011-09-16 20:48:20
Message-ID: 10987.1316206100@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

<Caleb(dot)Welton(at)emc(dot)com> writes:
> On Sep 16, 2011, at 11:11 AM, Tom Lane wrote:
>> Hmm. It would require an extra catalog lookup per parameter to enforce
>> that. Not sure that it's worth it just to prevent "peculiar" errors.
>> Can you point to any worse consequences?

> I haven't found any more severe issues and I'll agree its not a high priority item. But the fix is simple enough that I don't see a reason to ignore it either.

> The easiest fix would be, as you say, adding one extra syscache lookup:

If it were just PREPARE I'd have done it without quibbling; that isn't
something I regard as a critical performance path. But if we're trying
to lock this out then we logically have to enforce the same restriction
in exec_parse_message, and that *is* a performance-critical path. Plus
it has no existing catalog lookup that might be kluged to pass back the
extra information.

Maybe we should do it anyway, but I'd really like to see a more
significant reason.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Carlo Curatolo 2011-09-16 21:10:12 Re: BUG #5800: "corrupted" error messages (encoding problem ?)
Previous Message Caleb.Welton 2011-09-16 19:35:05 Re: BUG #6212: PREPARE(pseudotype) should be blocked off