> > Can we add a column to pg_conversion which represents the "growth
> > rate"? This would reduce the rate for most encodings much smaller than
> > 6.
> We need to do something, but the pg_conversion catalog seems a bad place
> to put the info --- don't we have places that need to be able to do
> conversion without catalog access?
Can you tell me where? I thought conversion functions are always
called by using OidFunctionCall5 thus we need to consult the
pg_conversion catalog beforehand anyway.
> Perhaps better would be to redefine the API for the conversion functions
> so that they palloc their own result space. Then each conversion
> function would have to know the maximum growth rate for its particular
> conversion. This change would also make it feasible for a conversion
> function to prescan the data and determine an exact output size, if that
> seemed worthwhile because the potential growth rate was too extreme.
SRA OSS, Inc. Japan
In response to
pgsql-hackers by date
|Next:||From: Stephen Frost||Date: 2007-05-29 02:55:33|
|Subject: Re: Fixing insecure security definer functions|
|Previous:||From: Tom Lane||Date: 2007-05-29 02:45:28|
|Subject: Re: Fixing insecure security definer functions |