On Mon, Dec 28, 2009 at 3:22 AM, Robert Haas wrote:
> I have scrutinized the latest version of this patch and I feel that it
> is a modest improvement on the status quo and that there is really no
> downside. Absent strong objections, I will commit it later this week.
Committed.
...Robert
--
On Wed, Dec 2, 2009 at 2:59 PM, Caleb Welton wrote:
> New patch attached:
>
> 1. Does not add a new error message (though the pg_atoi's error message is a
> little goofy looking).
> 2. Handles int2 overflow cases.
> 3. oidvectorin does NOT suffer from the same problems as int2vectorin,
> someone a
New patch attached:
1. Does not add a new error message (though the pg_atoi's error message is a
little goofy looking).
2. Handles int2 overflow cases.
3. oidvectorin does NOT suffer from the same problems as int2vectorin, someone
already fixed it.
As for the use-case I'm not completely sure...
Caleb Welton writes:
> On 12/1/09 7:38 PM, "Tom Lane" wrote:
>> Under what circumstances would users (or anyone at all) be putting data into
>> an int2vector?
> What exactly is your objection to having the int2arrayin parser handle its
> input conversion reasonably?
I'm trying to gauge what t
On Tue, Dec 1, 2009 at 10:38 PM, Tom Lane wrote:
> Caleb Welton writes:
>> I believe the int2vectorin function should handle invalid input more cleanly.
>
> Why bother? Under what circumstances would users (or anyone at all)
> be putting data into an int2vector? It's an internal type and is
> c
Tom,
Thanks for the comments.
Caleb Welton writes:
> I believe the int2vectorin function should handle invalid input more cleanly.
On 12/1/09 7:38 PM, "Tom Lane" wrote:
>> Why bother?
Because correctness is good. Results that produce unexpected results from
incorrect input formatting lead
Caleb Welton writes:
> I believe the int2vectorin function should handle invalid input more cleanly.
Why bother? Under what circumstances would users (or anyone at all)
be putting data into an int2vector? It's an internal type and is
certainly not meant for use in user tables.
