Re: extend VacAttrStats to allow stavalues of different types

Following the conclusion here:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00273.php
here's a patch that extends VacAttrStats to allow typanalyze functions
to store statistic values of different types than the underlying column.

The XXX comment can be taken into consideration or just dropped as
unimportant.

Cheers,
--
Jan Urbanski
GPG key ID: E583D7D2

ouden estin

Jan Urbański wrote:
> Following the conclusion here:
> http://archives.postgresql.org/pgsql-hackers/2008-05/msg00273.php
> here's a patch that extends VacAttrStats to allow typanalyze functions
> to store statistic values of different types than the underlying column.
>
> The XXX comment can be taken into consideration or just dropped as
> unimportant.

Doh, this time against HEAD, not my branch ...

--
Jan Urbanski
GPG key ID: E583D7D2

ouden estin

Jan Urbański wrote:
> Following the conclusion here:
> http://archives.postgresql.org/pgsql-hackers/2008-05/msg00273.php
> here's a patch that extends VacAttrStats to allow typanalyze functions
> to store statistic values of different types than the underlying column.

Looks good to me at first glance.

About this comment:

> + * XXX or maybe fall back on attrtype-> stuff when these are NULL? That way
> + * we won't break other people's custom typanalyze functions. Not sure if
> + * any exist, though.

I tried to google for a user defined data type with a custom typanalyze
function but didn't find anything, so I don't think it's an issue. It's
a bit nasty, though, because if one exists, it will compile and run just
fine, until you run ANALYZE. In general it's better to break an old API
obviously rather than silently, so that the old code doesn't even compile.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas wrote:
> I tried to google for a user defined data type with a custom typanalyze
> function but didn't find anything, so I don't think it's an issue. It's
> a bit nasty, though, because if one exists, it will compile and run just
> fine, until you run ANALYZE. In general it's better to break an old API
> obviously rather than silently, so that the old code doesn't even compile.

I can't think of a way to make the compilation fail if your old
typanalyze function fails to set the extra VacAttrStats fields. As I see
it, there are three options:
1. fall back on the old behaviour at the price of code uglification
2. put an Assert after the OidFunctionCall that calls a typanalyze
function if it exists, so people will get a nicer error message when
they test their code
3. put an ereport(ERROR, ...) after the OidFunctionCall, so people will
get a nicer error message if they don't use --enable-cassert and they'll
avoid segfaulting the backend on an ANALYZE call.

I think I like 2. best, but I just thought that you could check if the
custom typanalyze routine did set the fields right after it's been
called, and if it didn't then set them for it and thus get 1. in an
arguably clean way. Only that encourages sloppy programming (not setting
the fields and relying on someone to set them).

--
Jan Urbanski
GPG key ID: E583D7D2

ouden estin

"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> Jan Urbaski wrote:
>> + * XXX or maybe fall back on attrtype-> stuff when these are NULL? That way
>> + * we won't break other people's custom typanalyze functions. Not sure if
>> + * any exist, though.

> I tried to google for a user defined data type with a custom typanalyze
> function but didn't find anything, so I don't think it's an issue.

Oh, it absolutely is an issue. PostGIS has them, if no one else does.

I think the correct solution is to initialize the fields to match the
column type before calling the typanalyze function. Then you don't
break compatibility for existing typanalyze functions. It's also less
code, since the standard typanalyze functions can rely on those preset
values.

regards, tom lane

Tom Lane wrote:
> I think the correct solution is to initialize the fields to match the
> column type before calling the typanalyze function. Then you don't
> break compatibility for existing typanalyze functions. It's also less
> code, since the standard typanalyze functions can rely on those preset
> values.

Right. Updated patch attached.

--
Jan Urbanski
GPG key ID: E583D7D2

ouden estin

Jan Urbański wrote:
> Tom Lane wrote:
>> I think the correct solution is to initialize the fields to match the
>> column type before calling the typanalyze function. Then you don't
>> break compatibility for existing typanalyze functions. It's also less
>> code, since the standard typanalyze functions can rely on those preset
>> values.
>
> Right. Updated patch attached.

Thanks, committed.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com