| From: | Florian Pflug <fgp(at)phlo(dot)org> | 
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> | 
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kris Jurka <books(at)ejurka(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Rushabh Lathia <rushabh(dot)lathia(at)enterprisedb(dot)com> | 
| Subject: | Re: [BUGS] Server crash while trying to read expression using pg_get_expr() | 
| Date: | 2010-06-15 12:19:19 | 
| Message-ID: | 0DA83484-7662-4146-9AB3-5571E6732E07@phlo.org | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers | 
On Jun 15, 2010, at 9:31 , Heikki Linnakangas wrote:
> You could avoid changing the meaning of fn_expr by putting the check in the parse analysis phase, into transformFuncCall(). That would feel safer at least for back-branches.
For 9.0, wouldn't a cleaner way to accomplish this be a seperate type for expressions, say pg_expr, instead of storing them as text? With an input function that unconditionally raises and error and no cast to pg_expr, creating new instances of that type would be impossible for normal users. The output function and casts to text would call pg_get_expr() with zero as the second argument.
The internal representation wouldn't change, it's just the type's OID in the catalog that'd be different.
best regards,
Florian Pflug
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2010-06-15 14:07:41 | Re: BUG #5507: missing chunk number 0 for toast value XXXXX in pg_toast_XXXXX | 
| Previous Message | Maxim Boguk | 2010-06-15 10:53:18 | Re: BUG #5503: error in trigger function with dropped columns | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2010-06-15 12:37:50 | Re: [v9.1] Add security hook on initialization of instance | 
| Previous Message | Florian Pflug | 2010-06-15 12:05:11 | Re: Proposal for 9.1: WAL streaming from WAL buffers |