2012/3/9 Robert Haas <robertmh...@gmail.com>: > On Fri, Mar 9, 2012 at 5:09 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: >>> Well, that just means that it'd be a good idea for that function to be >>> supplied by the same shared library that supplies the plpgsql execution >>> functions. There wouldn't need to be any connection that the core >>> system particularly understands. So, like Peter, I'm not quite sure >>> what distinction is meant to be drawn by "internal" vs "external". >> >> internal - implement in core, external - implement in extension. > [...] >> I cannot to move plpgsql checker to extension, because there is >> dependency on plpgsql lib, and this is problem. If I can do it, then I >> did it > > I don't object to having this feature live in src/pl/plpgsql, and I > don't think Tom's objecting to that either. I just don't think it > needs any particular support in src/backend. > >> I don't see a reason why we need a multiple checkers - checkers are >> parametrised, so there are no real reason, But what statement will be >> maintain this catalog - CREATE CHECK ? You need DROP, ALTER, .. it is >> lot code too. > > If the checkers are written by different people and shipped > separately, then a parameter interface does not make anything better.
ok - it has sense, but it has sense only with some "smart" statements (like CHECK). Without these statements I have to directly call checker function and then concept of generalised checkers has not sense. Pavel > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
