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
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:
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
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 this
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 default
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 in
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 seems 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
doesn't need a new
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, as it opens the
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,
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 better
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 idea
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 implementing that because adding a column
to pg_proc would
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
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 a
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
inconsistent with
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 unlikely to
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 path you'd like to
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 course!
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;
Hmmm
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
really
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 something like:
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 =
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 be
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 something like:
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
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 it be hard
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 SESSION
Seems
28 matches
Mail list logo
