Re: minimal update

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: minimal update
Дата
Msg-id EBBA1874-C593-4602-AB4E-6BE57C4B2E67@hagander.net
обсуждение исходный текст
Ответ на Re: minimal update  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: minimal update  (David Fetter <david@fetter.org>)
Re: minimal update  ("Merlin Moncure" <mmoncure@gmail.com>)
Re: minimal update  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers



On 20 okt 2008, at 16.51, Andrew Dunstan <andrew@dunslane.net> wrote:

>
>
> Magnus Hagander wrote:
>> Andrew Dunstan wrote:
>>
>>> Tom Lane wrote:
>>>
>>>> Andrew Dunstan <andrew@dunslane.net> writes:
>>>>
>>>>> OK. Where would be a good place to put the code? Maybe a new file
>>>>> src/backend/utils/adt/trigger_utils.c ?
>>>>>
>>>> I thought the plan was to make it a contrib module.
>>>>
>>>>
>>> Well, previous discussion did mention catalog entries, which would
>>> suggest otherwise, but I can do it as a contrib module if that's the
>>> consensus.
>>>
>>
>> What would be the actual reason to put it in contrib and not core?  
>> Are
>> there any "dangers" by having it there? Or is it "just a hack" and  
>> not a
>> "real solution"?
>>
>>
>>
>
> No, it's not just a hack. It's very close to what we'd probably do  
> if we built the facility right into the language, although it does  
> involve the overhead of calling the trigger. However, it performs  
> reasonably well - not surprising since the guts of it is just a  
> memcmp() call.
>
In that case, why not put the trigger in core so people can use it  
easily?

/magnus


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: automatic parser generation for ecpg
Следующее
От: Andrew Sullivan
Дата:
Сообщение: Re: SSL cleanups/hostname verification