On 10/17/2010 05:30 AM, Dean Rasheed wrote:
On 16 October 2010 18:25, Dean Rasheed<dean.a.rash...@gmail.com> wrote:
Are there corner cases the author has failed to consider?
None that I could find.
Are there any assertion failures or crashes?
I just thought of another corner case, which can lead to a crash. The
comparison code assumes that the number of elements in the enumeration
is constant during a query, but that's not necessarily the case. For
example the following will crash it:
CREATE TYPE test_enum AS ENUM('Elem 1');
CREATE OR REPLACE FUNCTION test_fn(a int) RETURNS test_enum AS
$$
DECLARE
new_label text;
BEGIN
new_label := 'Elem '||a;
EXECUTE 'ALTER TYPE test_enum ADD '''||new_label||''' BEFORE ''Elem 1''';
RETURN new_label::test_enum;
END;
$$
LANGUAGE plpgsql;
WITH t(a) AS (SELECT test_fn(i) FROM generate_series(2, 10) g(i))
SELECT MAX(a) from t;
Of course that's a pathalogical example, but we should protect against
it, preferrably without compromising performance in more normal cases.
Yeah, good point. But how do we manage that? Looking up the number of
elements on each function call will cause a performance degradation, I
suspect. I'll think about it, but if you have any ideas please speak up.
I'm fairly sure we should also recheck the cached sorted property for
the same reason, incidentally.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
