what is necessary for filling SysCache?
Hello
I added two new columns to pg_proc. I have a problem because access
via SearchSysCache doesn't work
/* Search syscache by name only */
catlist = SearchSysCacheList(PROCNAMEARGSNSP, 1,
CStringGetDatum(funcname),
0, 0, 0);
for (i = 0; i < catlist->n_members; i++)
{
HeapTuple proctup = &catlist->members[i]->tuple;
Form_pg_proc procform = (Form_pg_proc) GETSTRUCT(proctup);
...
elog(NOTICE, "%d", SysCacheGetAttr(PROCOID, proctup,
Anum_pg_proc_prondefargs, &isnull));
elog(NOTICE, "%d %d", procform->prondefargs, procform->pronargs);
result:
postgres=# select fo(10,20);
NOTICE: 1
NOTICE: 0 1
NOTICE: 2
NOTICE: 0 2
NOTICE: 2
NOTICE: 0 3
fo
----
10
(1 row)
what is mechanism, that select between directly accessed fields and
fields that are accessed via SysCacheGetAttr?
Thank you
Pavel Stehule
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
I added two new columns to pg_proc. I have a problem because access
via SearchSysCache doesn't work
Well, you blew the catalog modifications somewhere, but since you
haven't shown us what you did it's hard to guess where.
You might want to pull the diffs for some past pg_proc addition from
CVS and go over the changes. This one is a good minimal example:
http://archives.postgresql.org/pgsql-committers/2005-03/msg00433.php
Also, not sure if this is relevant, but all the fixed-width columns
have to come first. Anything that's past a var-width column has to
be fetched via SysCacheGetAttr --- you can't fetch it as a struct
member.
regards, tom lane
some more info:
CATALOG(pg_proc,1255) BKI_BOOTSTRAP
{
NameData proname; /* procedure name */
Oid pronamespace; /* OID of namespace
containing this proc */
Oid proowner; /* procedure owner */
Oid prolang; /* OID of
pg_language entry */
float4 procost; /* estimated execution cost */
float4 prorows; /* estimated # of rows
out (if proretset) */
Oid provariadic; /* element type of
variadic array, or 0 */
bool proisagg; /* is it an aggregate? */
bool prosecdef; /* security definer */
bool proisstrict; /* strict with respect to NULLs? */
bool proretset; /* returns a set? */
char provolatile; /* see PROVOLATILE_ categories below */
int2 pronargs; /* number of arguments */
Oid prorettype; /* OID of result type */
/* VARIABLE LENGTH FIELDS: */
oidvector proargtypes; /* parameter types (excludes
OUT params) */
Oid proallargtypes[1]; /* all
param types (NULL if IN o
char proargmodes[1]; /* parameter modes (NULL if IN only) */
text proargnames[1]; /* parameter names (NULL if no names) */
int2 prondefargs; /* number of
default arguments */ -- new
text prodefargs; /* default
arguments */ -- new
text prosrc; /* procedure source text */
bytea probin; /* secondary procedure
info (can be NULL) */
text proconfig[1]; /* procedure-local GUC settings */
aclitem proacl[1]; /* access permissions */
} FormData_pg_proc;
#define Schema_pg_proc \
{ 1255, {"proname"}, 19, -1, NAMEDATALEN, 1, 0,
-1, -1, false, 'p', 'c', true, false, false, true, 0 }, \
{ 1255, {"pronamespace"}, 26, -1, 4, 2, 0, -1, -1,
true, 'p', 'i', true, false, false, true, 0 }, \
{ 1255, {"proowner"}, 26, -1, 4, 3, 0, -1, -1,
true, 'p', 'i', true, false, false, true, 0 }, \
{ 1255, {"prolang"}, 26, -1, 4, 4, 0, -1, -1,
true, 'p', 'i', true, false, false, true, 0 }, \
{ 1255, {"procost"}, 700, -1, 4, 5, 0, -1, -1,
FLOAT4PASSBYVAL, 'p', 'i', true, false, false, true, 0 }, \
{ 1255, {"prorows"}, 700, -1, 4, 6, 0, -1, -1,
FLOAT4PASSBYVAL, 'p', 'i', true, false, false, true, 0 }, \
{ 1255, {"provariadic"}, 26, -1, 4, 7, 0, -1, -1,
true, 'p', 'i', true, false, false, true, 0 }, \
{ 1255, {"proisagg"}, 16, -1, 1, 8, 0, -1, -1,
true, 'p', 'c', true, false, false, true, 0 }, \
{ 1255, {"prosecdef"}, 16, -1, 1, 9, 0, -1, -1,
true, 'p', 'c', true, false, false, true, 0 }, \
{ 1255, {"proisstrict"}, 16, -1, 1, 10, 0, -1, -1,
true, 'p', 'c', true, false, false, true, 0 }, \
{ 1255, {"proretset"}, 16, -1, 1, 11, 0, -1, -1,
true, 'p', 'c', true, false, false, true, 0 }, \
{ 1255, {"provolatile"}, 18, -1, 1, 12, 0, -1, -1,
true, 'p', 'c', true, false, false, true, 0 }, \
{ 1255, {"pronargs"}, 21, -1, 2, 13, 0, -1, -1,
true, 'p', 's', true, false, false, true, 0 }, \
{ 1255, {"prorettype"}, 26, -1, 4, 14, 0, -1, -1,
true, 'p', 'i', true, false, false, true, 0 }, \
{ 1255, {"proargtypes"}, 30, -1, -1, 15, 1, -1, -1,
false, 'p', 'i', true, false, false, true, 0 }, \
{ 1255, {"proallargtypes"}, 1028, -1, -1, 16, 1, -1, -1, false, 'x',
'i', false, false, false, true, 0 }, \
{ 1255, {"proargmodes"}, 1002, -1, -1, 17, 1, -1, -1, false,
'x', 'i', false, false, false, true, 0 }, \
{ 1255, {"proargnames"}, 1009, -1, -1, 18, 1, -1, -1, false,
'x', 'i', false, false, false, true, 0 }, \
{ 1255, {"prondefargs"}, 21, -1, 2, 19, 0, -1,
-1, true, 'p', 's', true, false, false, true, 0 }, \
{ 1255, {"prodefargs"}, 25, -1, -1, 20, 0, -1,
-1, false, 'x', 'i', false, false, false, true, 0 }, \
{ 1255, {"prosrc"}, 25, -1, -1, 21, 0, -1,
-1, false, 'x', 'i', false, false, false, true, 0 }, \
{ 1255, {"probin"}, 17, -1, -1, 22, 0, -1,
-1, false, 'x', 'i', false, false, false, true, 0 }, \
{ 1255, {"proconfig"}, 1009, -1, -1, 23, 1, -1, -1, false,
'x', 'i', false, false, false, true, 0 }, \
{ 1255, {"proacl"}, 1034, -1, -1, 24, 1, -1, -1,
false, 'x', 'i', false, false, false, true, 0 }
This is only one problem - after my changes regression test are passed
Pavel
2008/11/26 Tom Lane <tgl@sss.pgh.pa.us>:
Show quoted text
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
I added two new columns to pg_proc. I have a problem because access
via SearchSysCache doesn't workWell, you blew the catalog modifications somewhere, but since you
haven't shown us what you did it's hard to guess where.You might want to pull the diffs for some past pg_proc addition from
CVS and go over the changes. This one is a good minimal example:
http://archives.postgresql.org/pgsql-committers/2005-03/msg00433.phpAlso, not sure if this is relevant, but all the fixed-width columns
have to come first. Anything that's past a var-width column has to
be fetched via SysCacheGetAttr --- you can't fetch it as a struct
member.regards, tom lane
Hi,
Le mercredi 26 novembre 2008, Tom Lane a écrit :
You might want to pull the diffs for some past pg_proc addition from
CVS and go over the changes. This one is a good minimal example:
http://archives.postgresql.org/pgsql-committers/2005-03/msg00433.php
The following link should help the lazy clic & browse amongst us:
http://git.postgresql.org/?p=postgresql.git;a=commitdiff;h=578ce39692571e39fd0edddd677c079b05fad52d
Hope this helps ;)
--
dim
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
some more info:
/* VARIABLE LENGTH FIELDS: */
oidvector proargtypes; /* parameter types (excludes
OUT params) */
Oid proallargtypes[1]; /* all
param types (NULL if IN o
char proargmodes[1]; /* parameter modes (NULL if IN only) */
text proargnames[1]; /* parameter names (NULL if no names) */
int2 prondefargs; /* number of
default arguments */ -- new
Well, you ignored the rule about fixed-width before variable-width
columns. That's why there's a big VARIABLE LENGTH FIELDS marker
comment there ...
regards, tom lane
2008/11/26 Tom Lane <tgl@sss.pgh.pa.us>:
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
some more info:
/* VARIABLE LENGTH FIELDS: */
oidvector proargtypes; /* parameter types (excludes
OUT params) */
Oid proallargtypes[1]; /* all
param types (NULL if IN o
char proargmodes[1]; /* parameter modes (NULL if IN only) */
text proargnames[1]; /* parameter names (NULL if no names) */
int2 prondefargs; /* number of
default arguments */ -- newWell, you ignored the rule about fixed-width before variable-width
columns. That's why there's a big VARIABLE LENGTH FIELDS marker
comment there ...
I though it, but I believed so there is some smart mechanism :)
thank you
Pavel
Show quoted text
regards, tom lane