Hi,
I wonder why pg_standby requires libpq.so.5. We should get rid of
PG_LIB settings from contrib/pg_standby/Makefile? Here is the patch
to do so.
Am I missing something?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Index: contrib/pg_stand
Dear PostgreSQL Hackers,
I have a couple of user defined types, which have reference semantics.
One is more specialized, so by Liskov I can upcast both single values
and arrays of values.
-- no problem:
CREATE CAST (derived_refs AS base_refs) WITHOUT FUNCTION AS IMPLICIT;
-- ok with pg-8.3, erro
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
Peter Eisentraut writes:
>> Yeah, but the makefile protected that with "ifdef PERL", which stopped
>> failing as intended when someone forced some quotes into the value of
>> PERL. I'm about to commit something that hopefully will be a bit more
>> robust.
> So one would have only seen the differ
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
Hi All,
continued from discussion mail
http://archives.postgresql.org/pgsql-hackers/2009-06/msg00971.php
>
>
>> - Am I reading the patch correctly that you do not end up creating
>> indexes on the children tables? That is a big problem!
>
>
>
So what expected is when an index is created on Parti
I've just compiled and run the 8.4.RC2 code. For both of the following
queries I get "0009-03-01"
SELECT to_date(' 2009 03', ' MM') as extraspace; --returns
"0009-03-01"
SELECT to_date('2009 03', ' MM') as bogusspace; --returns "0009-03-01"
Was it the intention to imitate Oracle behavi
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
On Tuesday 23 June 2009 06:43:29 Tom Lane wrote:
> Andrew Dunstan writes:
> > Tom Lane wrote:
> >> Actually, further investigation discloses that someone broke the no-Perl
> >> defense in psql's makefile back in 8.0, and we hadn't noticed till now.
> >
> > Don't we ship sql_help.h in the tarball?
Stefan,
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
> Stephen Frost wrote:
>> What would be really useful would be "best case" and "worst case"
>> scenarios. Ideally, with profile information for this specific function
>> (in addition to full benchmark runs since those can show minima
Stephen Frost wrote:
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
FWIW: I'm able to measure an even more significant improvement of around
10%:
What would be really useful would be "best case" and "worst case"
scenarios. Ideally, with profile information for this specific function
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
> FWIW: I'm able to measure an even more significant improvement of around
> 10%:
What would be really useful would be "best case" and "worst case"
scenarios. Ideally, with profile information for this specific function
(in addition to ful
On Wednesday 24 June 2009 05:42:01 Itagaki Takahiro wrote:
> contrib/dblink in 8.4 supports a server name by CREATE SERVER for
> connection string, but it always requires an user-mapping (by CREATE USER
> MAPPING). However, I think it should work user-mappings because it works
> when the connection
2009/6/24 Jeremy Ford :
> I've just compiled and run the 8.4.RC2 code. For both of the following
> queries I get "0009-03-01"
>
> SELECT to_date(' 2009 03', ' MM') as extraspace; --returns
> "0009-03-01"
> SELECT to_date('2009 03', ' MM') as bogusspace; --returns "0009-03-01"
>
> Was it
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
27 matches
Mail list logo
