On 26/12/10 21:17, Tom Lane wrote:
> Jan Urbański <wulczer@wulczer.org> writes:
>> Makes sense. Wait, no, errcodes.sgml includes the entries for success
>> and warnings, but the plpgsql conditions list does not. So we need a
>> separate column to differentiate.
>
> OK. But not 0/1 please. Maybe 'E', 'W', or 'S' ? And again, fixed
> width columns first, so something like
>
> sqlstate E/W/S errcode_macro_name plpgsql_condition_name
>
> where I guess we could still make the plpgsql condition name optional.
All right, E/W/S sounds good. I'm actually faulty of a misnomer by
calling the field plpgsql_condition_name. It's more like spec_name, and
it will be used to generate plpgsql condition names for E entries and
rows in errcodes.sgml for all entries.
Remember that there will also be Section: lines there, because
errcodes.sgml needs to know where particular the error classes start and
end.
So:
sqlstate E/W/S errcode_macro_name spec_name
where spec_name is lowercase and underscore-separated.
errcodes.h would be generated by splitting sqlstate into letters and
emitting `#define errcode_macro_name MAKE_SQLSTATE('x','x','x','x','x')'
plerrcodes.h would be generated by emitting `{ "spec_name",
errcode_macro_name },' for each E line
errcodes.sgml would be generated by emitting a <row/> element with
sqlstate, spec_name in uppercase and with underscores stripped and just
spec_name. The Section: lines would generate table headers.
... and spiexceptions.h in plpython would be "spec_name" with
underscores converted to camel case and errcode_macro_name
How does that sound?
Jan