| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
| Cc: | Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl>, "Postgres - Patches" <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: extend VacAttrStats to allow stavalues of different types |
| Date: | 2008-06-02 14:37:29 |
| Message-ID: | 18320.1212417449@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
"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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jan Urbański | 2008-06-02 15:58:48 | Re: extend VacAttrStats to allow stavalues of different types |
| Previous Message | Tom Lane | 2008-06-02 14:17:02 | Re: Feature: give pg_dump a WHERE clause expression |