On mån, 2010-01-25 at 20:26 -0500, Tom Lane wrote: > Simon Riggs <si...@2ndquadrant.com> writes: > > On Mon, 2010-01-25 at 09:30 -0500, Robert Haas wrote: > >> +1 for removing default_do_language, too. > > > +1 for removing default_do_language OR adding default_language. > > > I prefer a hard-wired default of PLpgSQL, so a missing language > > statement on a DO block is always interpreted the same. > > So it seems everyone is okay with the latter? (Remove > default_do_language in place of a hard-wired default of "plpgsql", > don't change CREATE FUNCTION's behavior.)
Another option, which would avoid the hardcoding, would be to add a column to pg_language to indicate which is the default language. That would be kind of like the way the default operator classes are handled: There are valid reasons to change them on occasion, but you should really know what you are doing. Maybe that's not something we have to implement right now, but perhaps let's keep it in mind. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
