Re: Extensions, this time with a patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Extensions, this time with a patch
Date
Msg-id 22006.1287757834@sss.pgh.pa.us
Whole thread Raw
In response to Re: Extensions, this time with a patch  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Extensions, this time with a patch
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Hang on.  Did I miss something?  Why doesn't the control file name equal
> the extension name?  I think the idea that you have to scan the whole
> share directory and parse all control files to find the one you need is
> a bit strange.

Yes.  It's horrid for performance, and it's worse for understandability,
and there's no obvious benefit to set against those.  Please let's make
the rule that the control file name equals the extension name.

>> It expects the file is in server encoding, but it is not always true
>> because we support multiple encodings in the same installation.
>> How about adding encoding parameter to the function?
>> => pg_execute_from_file( file, encoding )

> This seems sensible ... at least as sensible as it is to allow COPY to
> specify the encoding.

But then you have to figure out what encoding it is, and you have to
know that before you start reading the file.  I think a better idea
would be to do the same thing we did for text search config files:
mandate that these files have to be in utf8.

> I think it is OK to have the control files be pure ASCII (this doesn't
> mean they are in SQL_ASCII though).  The problems will start when we
> decide to allow translations for extension descriptions.  But we can
> leave that for another day.

Well, we can see the issue now, and anyway who's to say an extension
might not want to load up some non-ASCII data?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Extensions, this time with a patch
Next
From: Heikki Linnakangas
Date:
Subject: Re: Making OFF unreserved