Re: [HACKERS] Re: [SQL] plpgsql error

Поиск
Список
Период
Сортировка
От jwieck@debis.com (Jan Wieck)
Тема Re: [HACKERS] Re: [SQL] plpgsql error
Дата
Msg-id m10hWOD-000EBaC@orion.SAPserv.Hamburg.dsh.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: [SQL] plpgsql error  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Re: [SQL] plpgsql error  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] Re: [SQL] plpgsql error  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
>
> Brook Milligan <brook@trillium.NMSU.Edu> writes:
> > Isn't the correct solution to have the Makefile contain a rule that
> > creates the file from a template (e.g., with sed -e
> > 's/@xxx@/${xxx}/g')?  That way make resolves the variable references
> > and you needn't worry about it.
>
> (after further thought...)  Oh, right, I see what you're saying: don't
> generate mklang.sql in configure at all, but let pl/plpgsql/src/Makefile
> be responsible for it.  Yeah, that'd be a cleaner solution.  However,
> what I just committed works ;-).  If you feel like improving it, be
> my guest; I have other items on the to-do list...

    I've  just  committed  a  little  change  to  initdb and it's
    Makefile. The initdb Makefile now expands  __DLSUFFIX__  into
    it  and  initdb uses $PGLIB/plpgsql__DLSUFFIX__ to test if it
    is there  and  then  runs  the  appropriate  queries  against
    template1. Same for PL/Tcl.

    If  anyone  agrees we can get rid of these mklang.sql scripts
    totally.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #

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

Предыдущее
От: jwieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] 6.5 TODO list
Следующее
От: Mirko Kaffka
Дата:
Сообщение: backend dies suddenly after a lot of error messages