Thread: 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 3fo
----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; /*
OIDof 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; /*
numberof
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>:
> "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
>
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 */ -- 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 ... > I though it, but I believed so there is some smart mechanism :) thank you Pavel > regards, tom lane >