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

Reply via email to