Questions about parsing boolean and casting to anyelement
| От | ITAGAKI Takahiro |
|---|---|
| Тема | Questions about parsing boolean and casting to anyelement |
| Дата | |
| Msg-id | 20090216121254.F19D.52131E4D@oss.ntt.co.jp обсуждение исходный текст |
| Ответы |
Re: Questions about parsing boolean and casting to anyelement
Allow on/off as input texts for boolean. |
| Список | pgsql-hackers |
The pg_autovacuum system catalog will be deprecated in 8.4,
but my customers use them to control autovacuum to emulate
maintenance window. So, I'm trying to re-implement the catalog
using a VIEW and RULEs in 8.4.
The attached is a WIP script, but I have some questions around it:
(XXX: I don't mean to propose the script in the core.)
- Postgres interprets 'on' as true and 'off' as false in configuration
parameters, but they are not accepted in sql-boolean.
Is it a design? or should we add a parser for 'on' and 'off' ?
I'd like to allow 'on' and 'off' in sql-boolean, too.
- The input strings are stored as-is in pg_class.reloptions.
So, mixed values could be shown in reloptions. For example
autovacuum_enabled=0/1/on/off/true/false .
Should we canonicalize them? However, I think the current behavior
is not so bad because it can preserve user inputs.
- Are there any limitations in casting to anyelement?
I got an error when I define the 3rd argument of array_find()
as anyelement:
ERROR: UNION types text and integer cannot be matched
Even if I use casts, it seems to be ignored.
CREATE FUNCTION array_find(text[], text, anyelement)
RETURNS anyelement AS
$$
SELECT substring(i from E'\\W*=(.*)')::anyelement
FROM unnest($1) AS t(i) WHERE i LIKE $2 || '=%'
UNION ALL SELECT $3 LIMIT 1
$$
LANGUAGE sql IMMUTABLE STRICT;
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
Вложения
В списке pgsql-hackers по дате отправления: