From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jean-Denis Giguere <jdenisgiguere(at)fastmail(dot)fm>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: grant execute on many functions |
Date: | 2004-06-30 04:45:05 |
Message-ID: | 40E24551.3080606@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
Tom Lane wrote:
> Um. Sooner or later we ought to do something about the whole
> automatic-casting-to-and-from-text issue. Datatypes shouldn't have to
> supply both I/O procedures and text cast procedures.
I thought automatic (i.e. implicit) casting-to-and-from-text was a no-no
because it could cause strange and unintended conversion to take place,
no? I do believe that explict casting to text should be allowed -- the
result of any OUT function can be represented as text, can't it? A
C-language version of the following should do it:
create or replace function any2text(anyelement) returns text as '
begin
return $1;
end;
' language plpgsql;
And if we could cast text to cstring, it could be the input of any IN
function. Hmmm, I guess you can cast any literal to cstring though:
select int4in('1'::cstring);
int4in
--------
1
(1 row)
> Right, in the short term you can make it work inside a plpgsql function,
> since plpgsql is pretty darn lax about casting. But it'd be nice if it
> worked more generally.
>
So what would that look like, and still be "safe".
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-06-30 04:52:25 | Re: grant execute on many functions |
Previous Message | Tom Lane | 2004-06-30 04:38:01 | Re: grant execute on many functions |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-06-30 04:52:25 | Re: grant execute on many functions |
Previous Message | Tom Lane | 2004-06-30 04:38:01 | Re: grant execute on many functions |