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
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
