Tom Lane wrote:
Doug Quale <[EMAIL PROTECTED]> writes:
test=# select oid::regprocedure from pg_proc order by oid::regprocedure;
doesn't sort the way I would expect.
Nope, it'd just be ordering by the numeric OID. If you added a cast
procedure as we were just discussing, you could order by
oid::r
Tom Lane <[EMAIL PROTECTED]> writes:
> Doug Quale <[EMAIL PROTECTED]> writes:
> > test=# select oid::regprocedure from pg_proc order by oid::regprocedure;
>
> > doesn't sort the way I would expect.
>
> Nope, it'd just be ordering by the numeric OID. If you added a cast
> procedure as we were ju
Doug Quale <[EMAIL PROTECTED]> writes:
> test=# select oid::regprocedure from pg_proc order by oid::regprocedure;
> doesn't sort the way I would expect.
Nope, it'd just be ordering by the numeric OID. If you added a cast
procedure as we were just discussing, you could order by
oid::regprocedure:
Joe Conway <[EMAIL PROTECTED]> writes:
> That's even better -- I tried regproc, but forgot about
> regprocedure. I think the problem will be, though, that the output of
> the reg* datatypes is not castable to text, and therefore cannot be
> used to build a dynamic sql statement.
This must be why
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
select 'GRANT EXECUTE ON ' || 1142::regprocedure;
ERROR: array value must start with "{" or dimension information
BTW, it seems like there's something pretty broken here. How did
arrays get into it? A quick probe suggests that it is res
Joe Conway <[EMAIL PROTECTED]> writes:
> 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-
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
Joe Conway <[EMAIL PROTECTED]> writes:
>select 'GRANT EXECUTE ON ' || 1142::regprocedure;
>ERROR: array value must start with "{" or dimension information
BTW, it seems like there's something pretty broken here. How did
arrays get into it? A quick probe suggests that it is resolving
the
Joe Conway <[EMAIL PROTECTED]> writes:
> That's even better -- I tried regproc, but forgot about regprocedure. I
> think the problem will be, though, that the output of the reg* datatypes
> is not castable to text, and therefore cannot be used to build a dynamic
> sql statement.
Um. Sooner or
Tom Lane wrote:
Also, casting the function's OID to regprocedure may be useful.
Random example:
regression=# select 1142::regprocedure;
regprocedure
date_mii(date,integer)
(1 row)
That's even better -- I tried regproc, but forgot about regprocedure. I
think the prob
Joe Conway <[EMAIL PROTECTED]> writes:
> Jean-Denis Giguere wrote:
>> But, the problem is more complex for functions because you have to give
>> the arguments.
> Does this help?
> SELECT n.nspname || '.' || p.proname ||
> '(' || pg_catalog.oidvectortypes(p.proargtypes) || ')'
Also, cast
Jean-Denis Giguere wrote:
But, the problem is more complex for functions because you have to give
the arguments. You can find the list in the pg_proc table but they are
store in a array by oid. So you can resolve the type with the table
pg_type. After, you have to reproduce the correct syntax (w
Hi,
I have about 200 functions in a schema and I have to grant execute
privilege on all these functions to a group.
I have found on the web an interesting function for grant access on table.
http://www.lerctr.org/pgnotes/pgnotes.html
(http://www.lerctr.org/pgnotes/grant-all.html)
But, the prob
13 matches
Mail list logo
