[HACKERS] Why does pg_standby require libpq.so.5?
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_standby/Makefile === RCS file: /projects/cvsroot/pgsql/contrib/pg_standby/Makefile,v retrieving revision 1.4 diff -c -r1.4 Makefile *** contrib/pg_standby/Makefile 10 Nov 2007 23:59:51 - 1.4 --- contrib/pg_standby/Makefile 25 Jun 2009 04:39:38 - *** *** 4,10 OBJS = pg_standby.o PG_CPPFLAGS = -I$(libpq_srcdir) - PG_LIBS = $(libpq_pgport) ifdef USE_PGXS PG_CONFIG = pg_config --- 4,9 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] array casts that worked in 8.3 no longer work
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, error with pg-8.4-b2: CREATE CAST (_derived_refs AS _base_refs) WITHOUT FUNCTION AS IMPLICIT; -- ERROR: 42P17: array data types are not binary-compatible -- LOCATION: CreateCast, functioncmds.c:1648 Reading the comment in functioncmds: /* * We know that composite, enum and array types are never binary- * compatible with each other. They all have OIDs embedded in them. */ I'm guessing that what I was doing was not safe although I have been getting away with it quite nicely for several years. Unfortunately I do this all over the place (I have a master ref type and lots of specializations of it). Is there an efficient (and maybe even easy) way to legally convert such arrays? Thanks for any suggestions you may have, _Greg J. Greg Davidson P.S. If you want a more complete example to refer to, here it is: CREATE TYPE base_refs; CREATE OR REPLACE FUNCTION base_ref_in(cstring) RETURNS base_refs AS 'pg-array-problem.so' LANGUAGE 'c' STRICT; CREATE OR REPLACE FUNCTION base_ref_out(base_refs) RETURNS cstring AS 'pg-array-problem.so' LANGUAGE 'c' STRICT; CREATE TYPE base_refs ( INTERNALLENGTH = 8, ALIGNMENT = double, input = base_ref_in, output = base_ref_out, PASSEDBYVALUE ); CREATE TYPE derived_refs; CREATE OR REPLACE FUNCTION derived_ref_in(cstring) RETURNS derived_refs AS 'pg-array-problem.so' LANGUAGE 'c' STRICT; CREATE OR REPLACE FUNCTION derived_ref_out(derived_refs) RETURNS cstring AS 'pg-array-problem.so' LANGUAGE 'c' STRICT; CREATE TYPE derived_refs ( INTERNALLENGTH = 8, ALIGNMENT = double, input = derived_ref_in, output = derived_ref_out, PASSEDBYVALUE ); -- ** Safe Upcasts -- no problem: CREATE CAST (derived_refs AS base_refs) WITHOUT FUNCTION AS IMPLICIT; -- error with pg-8.4-b2: CREATE CAST (_derived_refs AS _base_refs) WITHOUT FUNCTION AS IMPLICIT; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] building without perl
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 difference if there was a timestamp skew in > the unpacked tarball, or indeed perl was indeed missing. Well, the case we're really trying to deal with (as in, fail cleanly on) is a build from CVS without perl. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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. There have been suggestions in the past about throwing a bunch of things overboard, sometimes out of a passion for neatness more than anything else ISTM, but there have been good arguments against as well, particularly in the case of the PLs, which are tied so closely to the backend. Exemplars are good if they behave in the same way as non-core extensions. So it might be good for the core to maintain contrib extensions, although I would urge them to keep the size down quite low, and to be very conservative about adding new extensions. Part of the issue Perl ran into is that it was too liberal about adding new stuff to core, especially modules with large dependency trees. Anything in core should be kept very simple, both to avoid bloat and to minimize the maintenance overhead for the core team. 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. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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 in the past about throwing a bunch of things overboard, sometimes out of a passion for neatness more than anything else ISTM, but there have been good arguments against as well, particularly in the case of the PLs, which are tied so closely to the backend. Exemplars are good if they behave in the same way as non-core extensions. So it might be good for the core to maintain contrib extensions, although I would urge them to keep the size down quite low, and to be very conservative about adding new extensions. Part of the issue Perl ran into is that it was too liberal about adding new stuff to core, especially modules with large dependency trees. Anything in core should be kept very simple, both to avoid bloat and to minimize the maintenance overhead for the core team. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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: "tested with pg vX.XX", "not ready for production", etc... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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 are not very far away from it in the number of things we currently ship. They want to drop everything except for tools to download, build, test, and install other modules. That's the limitation. 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 in the past about throwing a bunch of things overboard, sometimes out of a passion for neatness more than anything else ISTM, but there have been good arguments against as well, particularly in the case of the PLs, which are tied so closely to the backend. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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 from it in the number of things we currently ship. They want to drop everything except for tools to download, build, test, and install other modules. That's the limitation. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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, chromatic, Allison, etc. regard the Standard Modules as a mistake and are talking about moving away from having any for Perl 6. On the other hand, their main reason for doing this (the issues with maintaining the included version and the CPAN version separately) wouldn't apply to us. 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 from it in the number of things we currently ship. On the third hand, having "all modules equal, just some recommended" approach woudl make it far easier to drop a module which went unmaintained, e.g. CUBE. But some people may regard this as a misfeature. I would happily push cube out of the nest now :-) cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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 contrib/, which could maybe become examples/? No, it would not be distributed with core at all. They could all be packaged up together in a single distribution of recommended modules, however. This may not be necessary if simple download-unzip-and-install is simple enough. I hope it'll get simple enough, yes, as simple as current PGXS modules from source are: - cvs up or wget - tar xzf ... && cd ... - make install - psql -f ... mydb Then it could also be easily scripted, too. PGXS has it covered, and we're not yet there, but I'm thinking PGXS should be a pre requisite of the extension facility as far as extensions authors are concerned. Then packagers will make it so that users won't typically face those details. +1. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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 there should be very few extensions distributed with the core, as keeping them in sync is a giant PITA and in part responsible for the duration of time between releases. A separate distribution of "recommended extensions" would fill the same need, but not bind core to the schedule of extension updates. 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. Agreed. Perl does not have such a thing. PHP does, and it's no doubt part of the reason that PEAR has so few modules. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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, etc. regard the Standard Modules as a mistake and are talking about moving away from having any for Perl 6. On the other hand, their main reason for doing this (the issues with maintaining the included version and the CPAN version separately) wouldn't apply to us. On the third hand, having "all modules equal, just some recommended" approach woudl make it far easier to drop a module which went unmaintained, e.g. CUBE. But some people may regard this as a misfeature. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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 of an addon.
Agreed.
Quite apart from anything else, having some extensions maintained by
core will help in validating the extension mechanism.
Good candidates for core-supported extensions would include
PL{Perl,Python,Tcl}, pgcrypto and hstore, IMNSHO. Between them they
illustrate a number of the major extension paradigms.
That read as a good start, even if I'd maybe like to add ltree and
plproxy, maybe more for convenience than anything else.
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.
I think what Josh is referring too is to have the standard core
extensions whose aim is to show how extensions work, provided
maintained examples etc, *and* a community list of useful extensions
(temporal, prefix, oracfe, pgtap, you name it) that users will
probably want to find.
This list will have to provide some more information, ones that are
implicit within the first group: is the software maintained, by whom,
is it production ready, feature complete, is it a community endorsed
product, etc.
While I'm all for avoiding bureaucracy, I'd like us to be able to show
how rich and trustworthy the PostgreSQL overall solution and community
is. Core-supported extensions won't allow that on their own.
Regards,
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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 pg_dump to issue an INSTALL EXTENSION command with specific version needed, right? - supporting more than one version of the same module installed in the same time, possibly (I suppose always but...) in different schemas We can put this off until we have a use-case for it. I can't imagine one. Good for me :) - custom variables? Don't we have these already? It's a matter of exposing a way to attach them to a specific extension. Are GUCs a possible element of pg_depend? - PostGIS complete support, with user data dependancy, even if an extensible typmod system would certainly solve this problem in a better place. Maybe someone will come up with another existing extension sharing the problem and not the typmod solution? Or we just fix that issue for 8.5. That'd make my day. - 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 code should be maintained and released separately until it gets some more field exposure... (think plproxy). 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 contrib/, which could maybe become examples/? - CPAN or ports like infrastructure for auto downloading a more or less prepared "bundle", place it at the right place on the filesystem and install it in the database(s) of choice This may not be necessary if simple download-unzip-and-install is simple enough. I hope it'll get simple enough, yes, as simple as current PGXS modules from source are: - cvs up or wget - tar xzf ... && cd ... - make install - psql -f ... mydb begin; install extension foo with search_path = foo; Needs install file location: No, extensions meta-data are in foo.sql and already loaded into the database by the time you get to INSTALL EXTENSION. That's a part I like because it makes it simple to handle meta-data and to declare that SQL objects from the script are part of the extension. I also dislike the CREATE EXTENSION which is not INSTALLing it... maybe a WITH INSTALL syntax option could do? 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 is solved. I think that the user should be able to put the extension file download anywhere in their filesystem, and on install PostgreSQL should copy the files to the appropriate place. That is, they shouldn't have to first copy the files to /pg_source_dir/contrib/. Maybe you had that covered, but I didn't see it explicitly. PGXS has it covered, and we're not yet there, but I'm thinking PGXS should be a pre requisite of the extension facility as far as extensions authors are concerned. Then packagers will make it so that users won't typically face those details. Also, this means that we'll want to make sure that PGXS is included in all existing packages of PostgresQL. Is it? Only those packages you want to have extension support from source ;) -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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 code should be
maintained and
released separately until it gets some more field exposure... (think
plproxy).
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.
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.
Quite apart from anything else, having some extensions maintained by
core will help in validating the extension mechanism.
Good candidates for core-supported extensions would include
PL{Perl,Python,Tcl}, pgcrypto and hstore, IMNSHO. Between them they
illustrate a number of the major extension paradigms.
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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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 are largely examples or hacker tools; if we don't cover those it's OK. * would be great (target later commit fest) - versioning support with upgrade in place facility (hooks?) We need versioning support right now, separate from any UIP support. Otherwise the dump/reload won't work. - supporting more than one version of the same module installed in the same time, possibly (I suppose always but...) in different schemas We can put this off until we have a use-case for it. I can't imagine one. - custom variables? Don't we have these already? - PostGIS complete support, with user data dependancy, even if an extensible typmod system would certainly solve this problem in a better place. Maybe someone will come up with another existing extension sharing the problem and not the typmod solution? Or we just fix that issue for 8.5. - 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 code should be maintained and released separately until it gets some more field exposure... (think plproxy). 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. - CPAN or ports like infrastructure for auto downloading a more or less prepared "bundle", place it at the right place on the filesystem and install it in the database(s) of choice This may not be necessary if simple download-unzip-and-install is simple enough. - complex support for ad-hoc bootstrap of uncommon modules such as pljava - dependancy graph solving and automatic installation, with depends, recommends and suggest sections and with rules/setup to choose what to pull in by default... Uh-huh. That'll be the day ... === 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'; == 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 is solved. I think that the user should be able to put the extension file download anywhere in their filesystem, and on install PostgreSQL should copy the files to the appropriate place. That is, they shouldn't have to first copy the files to /pg_source_dir/contrib/. Maybe you had that covered, but I didn't see it explicitly. Also, this means that we'll want to make sure that PGXS is included in all existing packages of PostgresQL. Is it? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] how can we propagate fk constraints?
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 Partitioned table it should automatically create indexes on individual partitions with same attributes, - name of the index on partition can be base index name appended with tableoid, - tablespace can be the same that of partition or tablespace specified in create index statement. Similarly we need to propagate foreign keys from partitioned table to individual partitions. so when we add new partition, how to create fkconstraint structure based on pg_constraint tuple? a Get the foreign key constraints from pg_constraint tuples for partitioned table, heap_modify_tuple to store relationid of newly added partition, Insert the new tuple directly into pg_constraint assuming required checks are happened at the time creating constraint on base table. update dependencies OR b call ATAddForeignKeyConstraint with recreated FkConstraint based on pg_constraint tuple. Is there any better way? In both cases I have to create FkConstraint structure, Creating FkConstraints will also be helpful in adding FkTriggers. I am not sure about how to create fkconstraint->pk_attrs and fkconstraint->fk_attrs? probably we can use something similar to decompile_column_index_array. We can get remaing variables from pg_constraint tuple. any suggestions appreciated. Thanks, Shrish
[HACKERS] Re: [BUGS] BUG #4862: different results in to_date() between 8.3.7 & 8.4.RC1
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 behavior for these two cases in this
release? (8.3.7 returns "0009-03-01" as well)
The others in that set of queries all work as expected ("2009-03-01"):
SELECT to_date(' 2009 03', 'MM') as nospace; --returns "2009-03-01"
SELECT to_date(' 2009 03', ' MM') as monthspace; --returns "2009-03-01"
SELECT to_date(' 2009 03', ' MM') as bothspaces; --returns "2009-03-01"
cheers, jeremy.
On Tue, Jun 23, 2009 at 3:55 AM, Tom Lane wrote:
> Brendan Jurd writes:
> > Here's a one-line patch to fix a regression in the new from_char code
> > I introduced into 8.4.
>
> > Versions <= 8.3 skipped over any whitespace immediately preceding any
> > integer field, and this behaviour was lost in HEAD when my from_char
> > patch was committed back in September '08 [1].
>
> Applied along with some regression test additions. Thanks for the
> quick response.
>
>regards, tom lane
>
Re: [HACKERS] Extensions User Design
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 continue doing what they have been doing... forever? Right, in an independent distribution. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] building without perl
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? I thought that's all the perl > > was used for in psql. > > 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 difference if there was a timestamp skew in the unpacked tarball, or indeed perl was indeed missing. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] backend: compare word-at-a-time in bcTruelen
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 minimal >> performance improvments due to other constraints, locking, etc). > > not sure what you are after here - my testcase is one specific query run > in parallel on 16 processes (running it in a single process yields > similiar improvements our scaling is pretty good here). What I'm suggesting is to test what happens when strings sent to bcTruelen are at different memory addresses (there's only 4 or 8 different possibilities here, then different lengths should be tested of less-than-1-word, 1-word, >1-word, and then different ending points at different memory addresses) and compare the new function to the old. The main point here being to try and find out if there are any pathological cases where the new function is much worse, or even somewhat worse, so we can weigh that against the places where it performs better. This isn't something you can do from in PG. :) > I was simply testing the patch Jeremy provided on that workload(the > upthread mentioned query is mostly affected by that on others there is > no measurable difference) Certainly, your performance numbers are good justification if there's no downside. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [PATCH] backend: compare word-at-a-time in bcTruelen
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 (in addition to full benchmark runs since those can show minimal performance improvments due to other constraints, locking, etc). not sure what you are after here - my testcase is one specific query run in parallel on 16 processes (running it in a single process yields similiar improvements our scaling is pretty good here). Have you tried pulling this function out and running tests with all alignment possibilities to see how it compares to the original? There's only so many options and showing that this change always improves performance, or at least doesn't degrade it in the worst case, would certainly go a long way towards getting it accepted. again I'm not exactly sure on what you want to get tested specifically - the original problem report was because I noticed a significant performance improvement from using varchar() instead of char(n) and that showed bcTruelen() on the very top of the profile. I was simply testing the patch Jeremy provided on that workload(the upthread mentioned query is mostly affected by that on others there is no measurable difference) Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] backend: compare word-at-a-time in bcTruelen
* 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 full benchmark runs since those can show minimal performance improvments due to other constraints, locking, etc). Have you tried pulling this function out and running tests with all alignment possibilities to see how it compares to the original? There's only so many options and showing that this change always improves performance, or at least doesn't degrade it in the worst case, would certainly go a long way towards getting it accepted.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] dblink for 8.4 should work without user-mappings
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 string is passed directly. I had looked into this the other day. I *think* that SQL/MED requires a user mapping to be present. There are cases where either behavior might be useful, but we should think about this carefully. It's not simply a question of security, as you appear to imply. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [BUGS] BUG #4862: different results in to_date() between 8.3.7 & 8.4.RC1
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 the intention to imitate Oracle behavior for these two cases in this
> release? (8.3.7 returns "0009-03-01" as well)
I think, at this stage (so close to release) we're just trying to keep
up a reasonable compatibility with 8.3 and earlier. The fact that the
"bogus space" case doesn't match the Oracle behaviour might be fertile
ground for future improvement in the 8.5 cycle.
Thanks for testing!
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
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 will make them available as extensions, but to have contrib/ made extensions and have core if possible continue doing what they have been doing... forever? > maybe a community approved list of extensions or maybe we can have > some kind of jury (just like patch reviewers) that could test and mark > as tested... i remember a conversation about this very point Having other sources of extensions apart from contrib seems to me a very good idea. -- Dimitri Fontaine PostgreSQL DBA, Architecte -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
