On 9/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> It would break functions that actually want to use a caller-specified
> search path, and protect themselves by explicitly schema-qualifying
> every other reference than one to some caller-specified object. Which
> admittedly is notationally a pain
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Well, a SECURITY DEFINER function either sets its own search path, in which
> case a default search path would have no effect, or it doesn't set its own
> search path, in which case it's already broken (albeit in a different way).
> So setting a de
Am Dienstag, 11. September 2007 15:53 schrieb Tom Lane:
> Zdenek Kotala <[EMAIL PROTECTED]> writes:
> > I have a question about what does happen if search path is not defined
> > for SECURITY DEFINER function. My expectation is that SECURITY DEFINER
> > function should defined empty search patch in
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
I have a question about what does happen if search path is not defined
for SECURITY DEFINER function. My expectation is that SECURITY DEFINER
function should defined empty search patch in this case.
Your expectation is incorrect. We a
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I have a question about what does happen if search path is not defined
> for SECURITY DEFINER function. My expectation is that SECURITY DEFINER
> function should defined empty search patch in this case.
Your expectation is incorrect. We are not in the
Tom Lane wrote:
I thought about ways to include GUC settings directly into CREATE
FUNCTION, but it seemed pretty ugly and inconsistent with the
existing syntax. So I'm thinking of supporting only the above
syntaxes, meaning it'll take at least two commands to create a secure
SECURITY DEFINER f
On 9/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > On 9/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> Seems a little verbose, but maybe we could do "SET var FROM CURRENT"
> >> or "SET var FROM SESSION"?
>
> > I'd prefer FROM SESSION then. FROM CURRENT s
On Sat, 2007-09-01 at 13:55 -0400, Tom Lane wrote:
> You already have that issue with respect to the default public execute
> permissions on the function. The standard solution is to do it in a
> transaction block --- then no one can even see the function until you
> commit.
It might be a good id
On Sat, 2007-09-01 at 15:03 -0400, Tom Lane wrote:
> > ALTER FUNCTION func(args) SET var TO CURRENT;
>
> Hmmm ... that's certainly do-able, though I'm not sure how much it helps
> the use-case you suggest. The search path still has to be set at the
> top of the module script, no?
It gives some b
On Sun, 2007-09-02 at 12:11 -0400, Tom Lane wrote:
> I think we pretty clearly want to have it take the currently active
> setting, and I'd vote for FROM CURRENT as the best way of expressing
> that.
FROM CURRENT sounds good to me.
Another idea (just brainstorming): SET var AS CURRENT.
Regards,
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 9/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Seems a little verbose, but maybe we could do "SET var FROM CURRENT"
>> or "SET var FROM SESSION"?
> I'd prefer FROM SESSION then. FROM CURRENT seems unclear.
Actually, I think FROM SESSION is unclear,
On 9/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > On 9/1/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> One problem is that we'd have to make CURRENT a reserved word to make it
> >> work exactly like that. Can anyone think of a variant syntax that
> >> do
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 9/1/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> One problem is that we'd have to make CURRENT a reserved word to make it
>> work exactly like that. Can anyone think of a variant syntax that
>> doesn't need a new reserved word?
> SET var FROM CURRENT S
David Fetter <[EMAIL PROTECTED]> writes:
> On Sat, Sep 01, 2007 at 12:41:28PM -0400, Tom Lane wrote:
>> The most straightforward way to support this syntactically seems to
>> be to follow the per-user and per-database GUC setting features:
>>
>> ALTER FUNCTION func(args) SET var = value
> Would i
On Sat, Sep 01, 2007 at 12:41:28PM -0400, Tom Lane wrote:
> I believe we had consensus that 8.3 needs to include an easier way for a
> function to set a local value of search_path, as proposed here:
> http://archives.postgresql.org/pgsql-hackers/2007-03/msg01717.php
> I've been holding off actually
On 9/1/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > Can we also provide syntax which would be equivalent to setting "var"
> > for the function to be whatever the current value happens to be when the
> > ALTER FUNCTION is run? Possible syntax might be somethin
On Sat, Sep 01, 2007 at 03:03:14PM -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > Can we also provide syntax which would be equivalent to setting "var"
> > for the function to be whatever the current value happens to be when the
> > ALTER FUNCTION is run? Possible syntax might
On Sep 1, 2007, at 1:36 PM, Brendan Jurd wrote:
So if we integrated the GUC settings into CREATE FUNCTION, we'd end up
writing something like
CREATE FUNCTION foo(int) RETURNS int AS $$
...
$$
LANGUAGE plpgsql
STABLE
STRICT
SECURITY DEFINER
RESET search_path
SET regex_flavor = 'cinnamon';
On 9/1/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > Can we also provide syntax which would be equivalent to setting "var"
> > for the function to be whatever the current value happens to be when the
> > ALTER FUNCTION is run? Possible syntax might be somethin
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> This assumes that the search path at creation time has something to do
>> with the path you'd like to use at execution, which is unlikely to be
>> the case in existing pg_dump output, to name one example. I don't
Jeff Davis <[EMAIL PROTECTED]> writes:
> Can we also provide syntax which would be equivalent to setting "var"
> for the function to be whatever the current value happens to be when the
> ALTER FUNCTION is run? Possible syntax might be something like:
> ALTER FUNCTION func(args) SET var TO CURRENT
On Sat, 2007-09-01 at 12:41 -0400, Tom Lane wrote:
> A few days ago, Simon suggested that we should generalize this notion
> to allow per-function settings of any GUC variable:
> http://archives.postgresql.org/pgsql-hackers/2007-08/msg01155.php
> My reaction to that was more or less "D'oh, of cours
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I think security definer functions should automatically inherit their
>> search_path. The whole "secure by default" thing.
>
> This assumes that the search path at creation time has something to do
> with the pat
Gregory Stark <[EMAIL PROTECTED]> writes:
> I think security definer functions should automatically inherit their
> search_path. The whole "secure by default" thing.
This assumes that the search path at creation time has something to do
with the path you'd like to use at execution, which is unlike
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> CREATE FUNCTION foo(int) RETURNS int AS $$
> ...
> $$
> LANGUAGE plpgsql
> STABLE
> STRICT
> SECURITY DEFINER
> RESET search_path
> SET regex_flavor = 'cinnamon';
> That doesn't seem especially horrible. In what way do you feel it is
> inconsiste
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I thought about ways to include GUC settings directly into CREATE
> FUNCTION, but it seemed pretty ugly and inconsistent with the
> existing syntax. So I'm thinking of supporting only the above
> syntaxes, meaning it'll take at least two commands to create
On 9/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> I thought about ways to include GUC settings directly into CREATE
> FUNCTION, but it seemed pretty ugly and inconsistent with the
> existing syntax. So I'm thinking of supporting only the above
> syntaxes, meaning it'll take at least two commands to
27 matches
Mail list logo
