On Jul 23, 2009, at 9:09 AM, Andrew Dunstan wrote:
Please particularly see this sentence: "But unless someone wants to
tackle that I think we should leave schema management entirely
alone, and leave it up to the extension author / DBA between them."
I think we are in some danger of massivel
Dimitri Fontaine wrote:
Richard Huxton writes:
INSTALL chinese_calendar;
IMPORT FROM chinese_calendar SECTION (default) INTO SCHEMA pg_extension;
IMPORT FROM chinese_calendar SECTION (year_names) INTO SCHEMA lookups;
Please see Andrew Dunstan mail about using some notion of ALIAS (i
Richard Huxton writes:
> INSTALL chinese_calendar;
> IMPORT FROM chinese_calendar SECTION (default) INTO SCHEMA pg_extension;
> IMPORT FROM chinese_calendar SECTION (year_names) INTO SCHEMA lookups;
Please see Andrew Dunstan mail about using some notion of ALIAS (is that
a standard compliant SYNO
Peter Eisentraut writes:
> On Tuesday 23 June 2009 20:44:39 Dimitri Fontaine wrote:
> Instead of installing an "extension", that is, say, a collection of types and
> functions provided by a third-party source, I would like to have a mechanism
> to deploy my own actual database application code.
Peter Eisentraut wrote:
> Instead of installing an "extension", that is, say, a collection
> of types and functions provided by a third-party source, I would
> like to have a mechanism to deploy my own actual database
> application code.
On the matter of schemas, I suggest that we consider two i
On Tuesday 23 June 2009 20:44:39 Dimitri Fontaine wrote:
> === installing and removing an extension
>
> begin;
> install extension foo with search_path = foo;
> commit;
>
> Extensions authors are asked not to bother about search_path in their sql
> scripts so that it's easy for DBAs to decide
Tom Lane writes:
> I have zero interest in trying to support either. I doubt it's even
> possible --- the backend code has no way to inform the dynamic loader
> how to resolve cross-library references. So if the DL doesn't already
> understand the dependency it's never going to work.
Ok, that m
Dimitri Fontaine writes:
> Tom Lane writes:
>> You should be able to configure the dynamic loader to do that, although
>> in the case of uuid I strongly doubt it's worth the trouble.
> In the context of the extensions facility, will we be able to do this
> configuration automatically from the ba
Tom Lane writes:
> You should be able to configure the dynamic loader to do that, although
> in the case of uuid I strongly doubt it's worth the trouble.
In the context of the extensions facility, will we be able to do this
configuration automatically from the backend, or to "manually" load any
d
Dimitri Fontaine writes:
> Any advice or missing knowledge about loading modules which depends on
> code from another module not already loaded in the backend is welcome :)
You should be able to configure the dynamic loader to do that, although
in the case of uuid I strongly doubt it's worth the
Hi,
While backporting UUID stuff to 8.2 where I'll need it (I wish I could
have more impact on PostgreSQL upgrade schedules... who doesn't), I
faced a problem I didn't foresee, and that we maybe should think about.
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/backports/
The idea in this backpo
Peter Eisentraut wrote:
Another thing we might want to consider once we have a robust extension
mechanism is to move some things out of the backend into extensions.
Candidates could be uuid, legacy geometry types, inet/cidr, for example.
These extensions would still be available and probabl
On Thursday 25 June 2009 01:09:17 Andrew Dunstan wrote:
> Well, I think in our case that would be going too far. I think there is
> a very good case for keeping a few key extensions in core both as
> exemplars and to make it easy to validate the extension mechanism
> itself. There have been suggest
On Jun 25, 2009, at 10:10 AM, Tom Lane wrote:
Is there no platform-independent build system we could take advantage
of?
There's been some talk of using cmake, but the conversion effort would
be massive, and I'm not sure the benefits would warrant it.
Might it be worthwhile just for the exten
"David E. Wheeler" writes:
> Is there no platform-independent build system we could take advantage
> of?
There's been some talk of using cmake, but the conversion effort would
be massive, and I'm not sure the benefits would warrant it.
regards, tom lane
--
Sent via pg
On 6/25/09, David E. Wheeler wrote:
> On Jun 25, 2009, at 2:21 AM, Dave Page wrote:
>
>>> Is it possible to design this part of the extension system with only
>>> PGXS in mind and later adapt the windows toolsuite?
>>
>> Anything is possible :-). Better to ask someone with more perl
>> expertise t
On Jun 25, 2009, at 7:16 AM, Tom Lane wrote:
The problem is, I think, that the Makefile format is way too
flexible.
I think the contrib makefiles are considered to be our standard test
suite for PGXS. If a 3rd-party makefile is doing anything not
represented in contrib, it's not guaranteed t
On Jun 25, 2009, at 2:21 AM, Dave Page wrote:
Is it possible to design this part of the extension system with only
PGXS in mind and later adapt the windows toolsuite?
Anything is possible :-). Better to ask someone with more perl
expertise than me how much effort it might take to have the VC++
Magnus Hagander writes:
>> On Thu, Jun 25, 2009 at 9:58 AM, Dimitri Fontaine
>> wrote:
>>> Is it possible to design this part of the extension system with only
>>> PGXS in mind and later adapt the windows toolsuite?
> We do it for Makefiles in contrib, so in theory it should be doable.
> The pr
Magnus Hagander writes:
> We do it for Makefiles in contrib, so in theory it should be doable.
Excellent!
> The problem is, I think, that the Makefile format is way too flexible.
> You can write anything as shell commands in there, and there is no way
> we can ever parse that and make it work in
Dave Page wrote:
> On Thu, Jun 25, 2009 at 9:58 AM, Dimitri Fontaine
> wrote:
>> Dave Page writes:
>>> PGXS is essentially useless on Windows unless you're compiling your
>>> own code using Mingw/msys, which will be a miniscule percentage of
>>> users. Our installers for 8.3 and above are all bui
On Thu, Jun 25, 2009 at 9:58 AM, Dimitri Fontaine wrote:
> Dave Page writes:
>> PGXS is essentially useless on Windows unless you're compiling your
>> own code using Mingw/msys, which will be a miniscule percentage of
>> users. Our installers for 8.3 and above are all built using VC++.
>
> I guess
Dave Page writes:
> On Wed, Jun 24, 2009 at 9:43 PM, Josh Berkus wrote:
>> Also, this means that we'll want to make sure that PGXS is included in all
>> existing packages of PostgresQL. Is it?
>
> Apologies if I missed further discussion on this - I'm somewhat
> distracted with release preparati
On Wed, Jun 24, 2009 at 9:43 PM, Josh Berkus wrote:
>> == OS Filesystem Interaction
>>
>> PostgreSQL already provides standard paths where to install extensions by
>> means of PGXS, and distribution packagers have been able to adapt those.
>> We
>> should just stick with this, meaning the problem
Re-reading in the morning rather that late at night...
Josh Berkus writes:
>> === installing and removing an extension
>>
>>begin;
>>install extension foo with search_path = foo;
>
> Needs install file location:
>
> INSTALL EXTENSION foo FROM '~/downloads/foo' WITH search_path = 'foo';
On Jun 24, 2009, at 3:41 PM, Andrew Dunstan wrote:
We have been conservative about this in the past and there is no
reason to expect we will not be in the future. If anything, we are
likely to become more so.
Good, perfect.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hacke
David E. Wheeler wrote:
On Jun 24, 2009, at 3:09 PM, Andrew Dunstan wrote:
Well, I think in our case that would be going too far. I think there
is a very good case for keeping a few key extensions in core both as
exemplars and to make it easy to validate the extension mechanism
itself. Ther
On Jun 24, 2009, at 3:09 PM, Andrew Dunstan wrote:
Well, I think in our case that would be going too far. I think there
is a very good case for keeping a few key extensions in core both as
exemplars and to make it easy to validate the extension mechanism
itself. There have been suggestions
On Wed, Jun 24, 2009 at 4:07 PM, Andrew Dunstan wrote:
>
> Beyond standard extensions, I'm not sure we need a committee to "approve"
> extensions. Does Perl have such an animal? I'm fairly wary of creating new
> decision-making bureaucracies.
>
not "approve", just mark it as something like: "teste
David E. Wheeler wrote:
On Jun 24, 2009, at 2:41 PM, Andrew Dunstan wrote:
I agree they have too many. I think moving to none would be a
mistake, though. Would they even drop things like Dynaloader or
ExtUtils::MakeMaker? That would be crazy, IMNSHO. I think there's a
sweet spot here and we
On Jun 24, 2009, at 2:41 PM, Andrew Dunstan wrote:
I agree they have too many. I think moving to none would be a
mistake, though. Would they even drop things like Dynaloader or
ExtUtils::MakeMaker? That would be crazy, IMNSHO. I think there's a
sweet spot here and we are not very far away f
Josh Berkus wrote:
Andrew,
Actually, I think we should be like Perl here. There is a list of
standard modules that comes with the base Perl distro, and then there
are addons, such as you find on CPAN. File::Find is an example of a
standard module, DBD::Pg is an example of an addon.
Actually
On Jun 24, 2009, at 2:12 PM, Dimitri Fontaine wrote:
The core team isn't appropriate for this. We'd start a new
committee/list somewhere instead, and it would be part of the same
effort which produces a "recommended" list of extensions and
drivers for packagers.
It'd still deprecate cont
On Jun 24, 2009, at 2:07 PM, Andrew Dunstan wrote:
Actually, I think we should be like Perl here. There is a list of
standard modules that comes with the base Perl distro, and then
there are addons, such as you find on CPAN.
Actually, the lesson slowly emerging in the Perl community is that
Andrew,
Actually, I think we should be like Perl here. There is a list of
standard modules that comes with the base Perl distro, and then there
are addons, such as you find on CPAN. File::Find is an example of a
standard module, DBD::Pg is an example of an addon.
Actually, chromatic, Allison,
Le 24 juin 09 à 23:07, Andrew Dunstan a écrit :
Actually, I think we should be like Perl here. There is a list of
standard modules that comes with the base Perl distro, and then
there are addons, such as you find on CPAN. File::Find is an example
of a standard module, DBD::Pg is an example o
Le 24 juin 09 à 22:43, Josh Berkus a écrit :
... most of. Some of the things in contrib are largely examples or
hacker tools; if we don't cover those it's OK.
Good to know.
We need versioning support right now, separate from any UIP support.
Otherwise the dump/reload won't work.
You want
Josh Berkus wrote:
- a core team approved list of extensions (replacing contribs,
maybe adding
to it), where approved means code has been reviewed and the only
reason
why it's not in the core itself is that core team feels that it's
not
part of a RDBMS per-se, or feel like the
Dim,
The contenders are extension, module, bundle and package. My vote is
extension.
+1 on "extension".
We're not trying to be feature complete on first round.
* must have
- support for all what you find in contrib/ for 8.4 (covered already?)
... most of. Some of the things in contrib
On Jun 24, 2009, at 12:59 AM, Dimitri Fontaine wrote:
are you aware of the enormous job that will imply for core team?
I'm not saying I want core to take care of all pgfoundry projects that
will make them available as extensions, but to have contrib/ made
extensions and have core if possible c
Jaime Casanova writes:
> On Tue, Jun 23, 2009 at 12:44 PM, Dimitri
> Fontaine wrote:
>>
>> - a core team approved list of extensions (replacing contribs,
>
> are you aware of the enormous job that will imply for core team?
I'm not saying I want core to take care of all pgfoundry projects that
w
On Tue, Jun 23, 2009 at 12:44 PM, Dimitri
Fontaine wrote:
>
> - a core team approved list of extensions (replacing contribs,
are you aware of the enormous job that will imply for core team?
maybe a community approved list of extensions or maybe we can have
some kind of jury (just like patch revie
David E. Wheeler wrote:
On Jun 23, 2009, at 3:02 PM, Dimitri Fontaine wrote:
It's "just" PostgreSQL reading an SQL file (foo.install.sql) and
parsing each statement etc, so we obviously have the machinery to
recognize SQL objects names and schema qualification. Replacing the
schema on-the-fly
On Jun 23, 2009, at 3:02 PM, Dimitri Fontaine wrote:
If we happen to accept the debian policy versioning scheme, then the
hard work is already done for us, it seems:
http://packages.debian.org/fr/sid/postgresql-8.3-debversion
As long as we don't need to implement a new data type, fine.
Rep
[Skipping most of it as I'd like to read what other people think about
it before going in lengthy thread already] :)
Le 23 juin 09 à 23:41, David E. Wheeler a écrit :
Yes, although as I said before, version numbers are hard to get
right. We should keep them very simple, with a strict requirem
On Jun 23, 2009, at 2:06 PM, Dimitri Fontaine wrote:
It'd be nice if it supported other core languages like PL/Perl, but
it's okay if it doesn't on the first round (I'd likely want to use
some CPAN modules in a PL/Perl extension, anyway).
At first sight I though you were talking about a non
Le 23 juin 09 à 20:30, David E. Wheeler a écrit :
On Jun 23, 2009, at 10:44 AM, Dimitri Fontaine wrote:
- support for home grown SQL/PLpgSQL only extensions in order to
make life
easier for in-house PG based development (you don't have to code
in C to
benefit from extensions)
It'd be ni
On Jun 23, 2009, at 10:44 AM, Dimitri Fontaine wrote:
The contenders are extension, module, bundle and package. My vote is
extension.
+1
== v1.0 goals
We're not trying to be feature complete on first round.
* must have
- dump & restore support (when upgrading a cluster or just restoring)
Hi,
= PostgreSQL Extensions
Here's the first round of User Design about PostgreSQL Extensions. I tried
to put together the ideas expressed by a lot of different people. The aim
here is to first agree on the naming and the goals, then talk about what
user design we propose.
== name
The contender
49 matches
Mail list logo
