Re: Statistics Import and Export
От | Corey Huinker |
---|---|
Тема | Re: Statistics Import and Export |
Дата | |
Msg-id | CADkLM=dbta2JCE4Uab8K8g-GdpdJKOJ_YYnmMiiCFVksTFdHAA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Statistics Import and Export (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
That's not what I suggested at all. The function parameters would
be declared anyarray, but the values passed to them would be coerced
to the correct concrete array types. So as far as the coercion rules
are concerned this'd be equivalent to the variadic-any approach.
+1
> That's pretty persuasive. It also means that we need to trap for error in
> the array_in() calls, as that function does not yet have a _safe() mode.
Well, the approach I'm advocating for would have the array input and
coercion done by the calling query before control ever reaches
pg_set_attribute_stats, so that any incorrect-for-the-data-type values
would result in hard errors. I think that's okay for the same reason
you probably figured you didn't have to trap array_in: it's the fault
of the originating pg_dump if it offers a value that doesn't coerce to
the datatype it claims the value is of.
+1
В списке pgsql-hackers по дате отправления: