"Steve Howe" <[EMAIL PROTECTED]> writes:
>> As long as there are at maximum 8 parameters allowed, this looks
>> practicable.
> There is no limit on the number of arguments.
You're both wrong: the limit is FUNC_MAX_ARGS, which hasn't been 8 in
quite some time. It's presently 16 by default, and c
Hello Haller!!!
> Your question about - pg_proc
> select t.typname from pg_type t , pg_proc p
> where p.proname = '' and p.proargtypes[0] = t.oid ;
> select t.typname from pg_type t , pg_proc p
> where p.proname = '' and p.proargtypes[1] = t.oid ;
> ...
> select t.typname from pg_type t , pg_proc
Hello Haller!!
>
> Your question about - pg_proc
> select t.typname from pg_type t , pg_proc p
> where p.proname = '' and p.proargtypes[0] = t.oid ;
> select t.typname from pg_type t , pg_proc p
> where p.proname = '' and p.proargtypes[1] = t.oid ;
> ...
> select t.typname from pg_type t , pg_pro
On Sat, 20 Oct 2001, Steve Howe wrote:
> Hello all!!
>
>
> I'm developer of a interface for PostgreSQL for the Borland Kylix
> and Delphi tools (http://www.vitavoom.com). I've run into the following
> problems with catalogs:
>
> - pg_group: the grolist field is an array. How can I
Hi Steve,
Your question about - pg_proc
select t.typname from pg_type t , pg_proc p
where p.proname = '' and p.proargtypes[0] = t.oid ;
select t.typname from pg_type t , pg_proc p
where p.proname = '' and p.proargtypes[1] = t.oid ;
...
select t.typname from pg_type t , pg_proc p
where p.pronam
"Steve Howe" <[EMAIL PROTECTED]> writes:
>> The group array is a hack but the pg_proc array would be hard to replace
>> becauseit acts as part of the unique key used for cache lookups.
> This design itself bothers me.
> We have no other option left ? Like arrays being referenced in relations ?
Steve Howe writes:
> > The group array is a hack but the pg_proc array would be hard to replace
> > becauseit acts as part of the unique key used for cache lookups.
> This design itself bothers me.
> We have no other option left ? Like arrays being referenced in relations ?
> That's far from per
Hi,
I think Bruce meant contrib/intarray which provides incredibly fast
indexed access to arrays of integers, which is your case.
We use it a lot, particularly in our full text search engine (OpenFTS).
regards,
Oleg
On Sat, 20 Oct 2001, Steve Howe wrote:
> > > I also qu
Hello Bruce!
> Yes, we inherited these arrays from Berkeley and haven't had any need to
> remove them. Are you trying to do things that the other interfaces like
> ODBC and JDBC don't handle?
About the groups: I just want to write a function that will return the users
names belonged by a given g
> > I also quote the PotgreSQL user manual
> >
(http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/arrays.html):
>
> In the contrib/ directory are procedures to search arrays for values.
> This may help.
Thanks for the tip, but in fact I've seen them (and they're listed on the
s
Yes, we inherited these arrays from Berkeley and haven't had any need to
remove them. Are you trying to do things that the other interfaces like
ODBC and JDBC don't handle?
The group array is a hack but the pg_proc array would be hard to replace
becauseit acts as part of the unique key used for
Hello all!!
I'm developer of a interface for PostgreSQL for the Borland Kylix
and Delphi tools (http://www.vitavoom.com). I've run into the following
problems with catalogs:
- pg_group: the grolist field is an array. How can I make a query
that tell me the usernames of a group ?
12 matches
Mail list logo
