Re: extend VacAttrStats to allow stavalues of different types

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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches