Re: [HACKERS] Assert Levels
On Fri, 2008-09-19 at 17:33 -0400, Greg Smith wrote: On Fri, 19 Sep 2008, Greg Stark wrote: This is a good example of why running with assertions enabled on production might not be a good idea. But it's also a good example of why we should do our performance testing with assertions enabled if we can do it without invalidating the results. The performance impact of assertions is large enough The starting point of this was that the *current* performance impact of assertions is large enough that we turn them off. that I don't think that goal is practical. So we can't use that as an argument against doing something to enable the lighter checks in certain circumstances in the future. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] Assert Levels
On Fri, 2008-09-19 at 17:47 -0400, Tom Lane wrote: Greg Smith [EMAIL PROTECTED] writes: On Fri, 19 Sep 2008, Greg Stark wrote: This is a good example of why running with assertions enabled on production might not be a good idea. But it's also a good example of why we should do our performance testing with assertions enabled if we can do it without invalidating the results. The performance impact of assertions is large enough that I don't think that goal is practical. Well, there are certain things that --enable-cassert turns on that are outrageously expensive; notably CLOBBER_FREED_MEMORY and MEMORY_CONTEXT_CHECKING. It wouldn't be too unreasonable to decouple those things somehow (with a means more accessible than editing pg_config_manual.h). That's mostly what I'm hoping for. If we call the CLOBBER checks as class 3, all current Asserts as class 2 then we can invent a class 1 of specifically lightweight checks (only). We can then have --enable-cassert=X rather than just y or n I don't think anyone knows what the performance impact of just the regular Asserts is; it's been too long since these other things were stuck in there. Agreed. If we had a system in place, we would slowly move towards using it. It wouldn't happen overnight, but it would help. Many more people might be persuaded to be early adopters if there was an extra mode in place to catch problems. My thinking was that I want to put lots of checks into Hot Standby to prove it all works, but in places where I don't think they're really needed. An example of a current set of checks we do, that may not be needed are the tests for HeapTupleInvisible in HeapTupleSatisfiesUpdate(). Almost every time we do a TransactionIdIsInProgress() to see if the heap tuple is invisible. If it is we throw an ERROR. But we already did that earlier. Now I've never seen that ERROR reported anywhere, so I'm thinking that I'd like to downgrade that somehow, yet still retain the ability to check it when things go strange. There are a few other examples. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] macport for libpqxx
http://pqxx.org/development/libpqxx/ I'm in the process of creating a macport for libpqxx. I could use some help from anyone with experience in building postgresql or libpqxx on OSX, esp. against the macport libraries. Thanks, Darren -- 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] Where to Host Project
On Fri, Sep 19, 2008 at 10:38 PM, Josh Berkus [EMAIL PROTECTED] wrote: That's kind of what I'm doing now. But I'm wondering if I should bother with pgFoundry at all. It seems pretty dead (see Josh Berkus's reply). Actually, pgFoundry remains extremely popular. Currently, we're getting an average of 2-3 new projects a week. The issue with pgFoundry is that it's based on a hacked version of the GForge code, which had legacy problems to begin with and is now no longer upgradable. And while lots of people want to complain about it, nobody wants to put in the 15-25 hours of work required to fix it up so that it supports SVN and code snippets (including me). Well that's not strictly true - I persuaded one of the GForge developers to work on the upgrade. As far as I'm aware, we're still waiting for the hardware/OS platform to be sorted out after some initial problems. I suspect JD will tell me something different though - that being the case, perhaps we can work out the issues and get on with the upgrade. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.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] macport for libpqxx
On Sat, Sep 20, 2008 at 7:30 AM, Darren Weber [EMAIL PROTECTED] wrote: http://pqxx.org/development/libpqxx/ I'm in the process of creating a macport for libpqxx. I could use some help from anyone with experience in building postgresql or libpqxx on OSX, esp. against the macport libraries. Never built libpqxx or a MacPort), but I'm used to building Postgres and other PG apps and the fu required to get universal binaries. What do you need? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.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] Where to Host Project
Dave Page wrote: Well that's not strictly true - I persuaded one of the GForge developers to work on the upgrade. As far as I'm aware, we're still waiting for the hardware/OS platform to be sorted out after some initial problems. I suspect JD will tell me something different though - that being the case, perhaps we can work out the issues and get on with the upgrade. The machine is ready to go and as far as I know even has a jail. Stefan would know more. Joshua D. Drake -- 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] Where to Host Project
On Sat, Sep 20, 2008 at 8:37 AM, Joshua D. Drake [EMAIL PROTECTED] wrote: Dave Page wrote: Well that's not strictly true - I persuaded one of the GForge developers to work on the upgrade. As far as I'm aware, we're still waiting for the hardware/OS platform to be sorted out after some initial problems. I suspect JD will tell me something different though - that being the case, perhaps we can work out the issues and get on with the upgrade. The machine is ready to go and as far as I know even has a jail. Stefan would know more. OK, cool. Stefan; what's your take on where we're at? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.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] Do we really need a 7.4.22 release now?
Greg Sabino Mullane wrote: I guess I don't understand where Joe User was supposed to have gotten the message that 7.4 was on its last legs. If anything, the fact that it is on patchlevel 21 suggests otherwise. Us hackers and developers shudder at seeing a 7.4 database, but there are plenty of businesses who are still using it, and I think we owe it to them to give more advance warning that no more patchlevels are coming along than 3 months. The few postings I have noticed with users running 7.4 has been with a release several less than the newest. One of the first suggestions is always to install the newest update. Out of the users out there that still have 7.4 servers running, what percentage use the newest update? I am certain it's not 100% I doubt it would be much more that 50% I would think the old rule of don't fix what ain't broke would be fairly common among 7.4 users. The fact that it took 5 years to find a problem to be fixed would indicate that it isn't a show stopping issue that they need fixed. Supporting old versions is a great and noble thing but there comes a time when it is a waste of resources because the effort goes unused. -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz -- 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] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
[1] Make a consensus that different security mechanisms have differences in its decision making, its gulanuality and its scope I think it is the most straightforward answer. As operating system doing, DAC and MAC based access controls should be independently applied on accesses from users, and this model is widely accepted. These facilities can also have different results, gulanualities and scopes. [2] Make a new implementation of OS-independent fine grained access control If it is really really necessary, I may try to implement a new separated fine-grained access control mechanism due to the CommitFest:Nov. However, we don't have enough days to develop one more new feature from the scratch by the deadline. I reconsidered the above two options have no differences fundamentally. In other word, making a new enhanced security implementation based on requirements also means making a consensus various security mechanism can have its individual rules including guranuality of access controls. So, I'll decide to try to implement fine-grained-only security mechanism also, because someone have such a requirememt. However, its schedule is extremely severe, if is has to be submitted due to the deadline of CommitFest:Nov. It is my hope to concentrate development of SE-PostgreSQL in v8.4 development cycle, and I think the above fine-grained-only one should be pushed to v8.5 cycle. Thanks, -- KaiGai Kohei [EMAIL PROTECTED] -- 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] PostgreSQL future ideas
On Fri, 19 Sep 2008, Gevik Babakhani [EMAIL PROTECTED] writes: Has there been any idea to port PG to a more modern programming language like C++? Of course there are some minor obstacles like a new OO design, this being a gigantic task to perform and rewriting almost everything etc... I am very interested to hear your opinion. This topic was discussed many times before in the past. See mailing list archives. If you have any _alternative_ ideas to say to previous discussions, I think developers will be appreciated to hear it. Regards. -- 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] PostgreSQL future ideas
On Fri, 2008-09-19 at 16:37 -0400, D'Arcy J.M. Cain wrote: On Fri, 19 Sep 2008 20:57:36 +0100 Dave Page [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani [EMAIL PROTECTED] wrote: Has there been any idea to port PG to a more modern programming language like C++? Of course there are some minor obstacles like a new OO design, The plan is to start porting it to Java after the next release - probably at the beginning of April. I don't think that we should rush into any one language without checking the alternatives. Personally I think we should port everything to Intercal. We should rewrite it to something that has no visual noise, so attracting new developers would be easier. My choice would be whitespace , see http://en.wikipedia.org/wiki/Whitespace_(programming_language) - Hannu Krosing -- 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] PostgreSQL future ideas
On Sat, 20 Sep 2008 13:47:10 +0300 Hannu Krosing [EMAIL PROTECTED] wrote: On Fri, 2008-09-19 at 16:37 -0400, D'Arcy J.M. Cain wrote: I don't think that we should rush into any one language without checking the alternatives. Personally I think we should port everything to Intercal. My choice would be whitespace , see http://en.wikipedia.org/wiki/Whitespace_(programming_language) Hey, we could write two modules into each file, one in Intercal and another in Whitespace. :-) -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Assert Levels
Simon Riggs [EMAIL PROTECTED] writes: On Fri, 2008-09-19 at 17:47 -0400, Tom Lane wrote: Well, there are certain things that --enable-cassert turns on that are outrageously expensive; notably CLOBBER_FREED_MEMORY and MEMORY_CONTEXT_CHECKING. It wouldn't be too unreasonable to decouple those things somehow (with a means more accessible than editing pg_config_manual.h). That's mostly what I'm hoping for. If we call the CLOBBER checks as class 3, all current Asserts as class 2 then we can invent a class 1 of specifically lightweight checks (only). We can then have --enable-cassert=X rather than just y or n Hold on a minute. I don't mind refactoring the way that configure controls those existing build switches. I do object to complexifying routine uses of Assert when absolutely zero evidence of a benefit has been presented. How do you know that the run-of-the-mill Asserts aren't lightweight enough already? An example of a current set of checks we do, that may not be needed are the tests for HeapTupleInvisible in HeapTupleSatisfiesUpdate(). Yes, they are needed, think about concurrent updates: sure the tuple must have been visible awhile back, but we haven't been holding exclusive lock on its buffer continuously since then. There might be some places where test-and-elog checks could be downgraded to assertions, but I would tread very very carefully in that. If the original code author was sure it couldn't happen he'd have written it as an Assert to begin with. 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] Do we really need a 7.4.22 release now?
Shane Ambler [EMAIL PROTECTED] writes: The few postings I have noticed with users running 7.4 has been with a release several less than the newest. ... Supporting old versions is a great and noble thing but there comes a time when it is a waste of resources because the effort goes unused. Yeah, that's a really good point. An example is that Red Hat is still shipping/supporting 7.4.x in RHEL 4, but it's been quite a long time since I've been able to persuade them to push a 7.4.x update that didn't involve a security issue. (They're currently shipping 7.4.19, and I'm not even going to bother suggesting an update to .22.) Probably everyone has got their own slightly different set of hot-button considerations for whether it's worth updating to a new minor release, but it's really unclear that there's going to be any uptake at all for 7.4.22 as constituted, because the bugs it fixes are so minor. The suggestion I started this thread with amounted to not bothering with pushing 7.4.x updates in update cycles where we'd made no serious bug fixes in it; which is a very long way from desupport. Maybe an appropriate compromise is to announce now that 7.4 is in maintenance mode and will receive only really critical bug fixes (which are the only ones that 7.4.x users are going to pay attention to anyway, so nothing is lost); and that actual desupport will occur a year from now. 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] Assert Levels
On Sat, 2008-09-20 at 11:28 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: On Fri, 2008-09-19 at 17:47 -0400, Tom Lane wrote: Well, there are certain things that --enable-cassert turns on that are outrageously expensive; notably CLOBBER_FREED_MEMORY and MEMORY_CONTEXT_CHECKING. It wouldn't be too unreasonable to decouple those things somehow (with a means more accessible than editing pg_config_manual.h). That's mostly what I'm hoping for. If we call the CLOBBER checks as class 3, all current Asserts as class 2 then we can invent a class 1 of specifically lightweight checks (only). We can then have --enable-cassert=X rather than just y or n Hold on a minute. I don't mind refactoring the way that configure controls those existing build switches. I do object to complexifying routine uses of Assert when absolutely zero evidence of a benefit has been presented. How do you know that the run-of-the-mill Asserts aren't lightweight enough already? Well, we don't. That's why I'd suggest to do it slowly and classify everything as medium weight until proven otherwise. Also think we need to take code location into account, because a cheap test in a critical place could end up costing more than an expensive test that hardly ever gets executed. Anyway, if we do it at all, I think this probably should be classified as code cleanup and done later in release cycle. If you think it's a good idea after a couple of months we can start on it. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] macport for libpqxx
Hi Dave, Thanks for getting back to me. Please find attached a draft Portfile for libpqxx-2.6.9 (the stable version). It's easy to read the Portfile to see what is going on. I think it should work fine, but I would appreciate any advice about any configure options that should be enabled. I've got a problem within macports (not specific to pg or libpqxx). MacPorts will not locate the pg_config.sh file during the macport build. I can't just modify the $PATH env because the macport build ignores it. There is an internal variable called $binpath in macports, but it's read-only. I can't figure out how to get the macport configure process to find the right pg_config. Any help appreciated. Thanks, Darren PS, If you want to try out this Portfile, take a look at the macports guide (esp. sections 4,5): http://guide.macports.org/chunked/ Then follow the instructions to create your local repository here: http://guide.macports.org/chunked/development.local-repositories.html Then put this Portfile into databases/libpqxx within your repository. On Sat, Sep 20, 2008 at 12:27 AM, Dave Page [EMAIL PROTECTED] wrote: On Sat, Sep 20, 2008 at 7:30 AM, Darren Weber [EMAIL PROTECTED] wrote: http://pqxx.org/development/libpqxx/ I'm in the process of creating a macport for libpqxx. I could use some help from anyone with experience in building postgresql or libpqxx on OSX, esp. against the macport libraries. Never built libpqxx or a MacPort), but I'm used to building Postgres and other PG apps and the fu required to get universal binaries. What do you need? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com Portfile Description: video/flv -- 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] Do we really need a 7.4.22 release now?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Tom Lane wrote: The suggestion I started this thread with amounted to not bothering with pushing 7.4.x updates in update cycles where we'd made no serious bug fixes in it; which is a very long way from desupport. Maybe an appropriate compromise is to announce now that 7.4 is in maintenance mode and will receive only really critical bug fixes (which are the only ones that 7.4.x users are going to pay attention to anyway, so nothing is lost); and that actual desupport will occur a year from now. +1 Shall we set an exact date, such as October 1, 2009? - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200809201226 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkjVJDgACgkQvJuQZxSWSsjCuACgxGqmADfgGlHekGI+TXfQTAnr CroAnAuMs9sMcRvjBBDFlYV5+dY8wlra =c5fb -END PGP SIGNATURE- -- 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] Do we really need a 7.4.22 release now?
Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Tom Lane wrote: The suggestion I started this thread with amounted to not bothering with pushing 7.4.x updates in update cycles where we'd made no serious bug fixes in it; which is a very long way from desupport. Maybe an appropriate compromise is to announce now that 7.4 is in maintenance mode and will receive only really critical bug fixes (which are the only ones that 7.4.x users are going to pay attention to anyway, so nothing is lost); and that actual desupport will occur a year from now. +1 Shall we set an exact date, such as October 1, 2009? Let's include 8.0 in that announcement so we aren't having this discussion again in a year. Joshua D. Drake -- 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: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle
Ron Mayer wrote:
Tom Lane wrote:
...GUC that selected PG traditional, SQL-standard... interval output
format seems like it could be a good idea.
This is an update to the earlier SQL-standard-interval-literal output
patch that I submitted here:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
This version fixes a couple bugs in my last patch related to reltime output and
with the new GUC variable, and updated the regression tests to adjust the
new IntervalStyle guc to match the output of the previous regression tests
where the interval output depended on DateStyle.
I've also added it to the Nov CommitFest wiki page.
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***
*** 4090,4095 SET XML OPTION { DOCUMENT | CONTENT };
--- 4090,4117
/listitem
/varlistentry
+ varlistentry id=guc-intervalstyle xreflabel=IntervalStyle
+ termvarnameIntervalStyle/varname (typestring/type)/term
+ indexterm
+primaryvarnameIntervalStyle/ configuration parameter/primary
+ /indexterm
+ listitem
+para
+ Sets the display format for interval values.
+ The value literalsql_standard/ will output SQL Standard
+ strings when given intervals that conform to the SQL
+ standard (either year-month only or date-time only; and no
+ mixing of positive and negative components).
+ The value literalpostgres/ will output intervals in
+ a format that matches what old releases had output when
+ the DateStyle was set to literal'ISO'/.
+ The value literalpostgres_verbose/ will output intervals in
+ a format that matches what old releases had output when
+ the DateStyle was set to literal'SQL'/.
+/para
+ /listitem
+ /varlistentry
+
varlistentry id=guc-timezone xreflabel=timezone
termvarnametimezone/varname (typestring/type)/term
indexterm
*** a/doc/src/sgml/datatype.sgml
--- b/doc/src/sgml/datatype.sgml
***
*** 2213,2218 January 8 04:05:06 1999 PST
--- 2213,2305
/para
/sect2
+sect2 id=interval-output
+ titleInterval Output/title
+
+ indexterm
+ primaryinterval/primary
+ secondaryoutput format/secondary
+ seealsoformatting/seealso
+ /indexterm
+
+ para
+ The output format of the interval types can be set to one of the four
+ styles literalsql_standard/,
+ literalpostgres/, or literalpostgres_verbose/.The default
+ is the literalpostgres/ format.
+ xref
+ linkend=interval-style-output-table shows examples of each
+ output style.
+ /para
+
+ para
+ The literalsql_standard/ style will output SQL standard
+ interval literal strings where the value of the interval
+ value consists of only a year-month component or a datetime
+ component (as required by the sql standard). For an interval
+ containing both a year-month and a datetime component, the
+ output will be a SQL Standard unquoted year-month literal
+ string joined to a SQL Standard unquoted datetime literal
+ string with a space in between.
+ /para
+
+ para
+ The literalpostgres/ style will output intervals that match
+ the style PostgreSQL 8.3 outputed when the xref linkend=guc-datestyle
+ parameter was set to literalISO/.
+ /para
+
+ para
+ The literalpostgres_verbose/ style will output intervals that match
+ the style PostgreSQL 8.3 outputed when the xref linkend=guc-datestyle
+ parameter was set to literalSQL/.
+ /para
+
+ table id=interval-style-output-table
+ titleInterval Style Example/title
+ tgroup cols=2
+ thead
+ row
+ entryStyle Specification/entry
+ entryYear-Month Interval/entry
+ entryDateTime Interval/entry
+ entryNonstandardrd Extended Interval/entry
+ /row
+ /thead
+ tbody
+ row
+ entrysql_standard/entry
+ entry1-2/entry
+ entry3 4:05:06/entry
+ entry-1-2 +3 -4:05:06/entry
+ /row
+ row
+ entrypostgres/entry
+ entry1 year 2 mons/entry
+ entry3 days 04:05:06/entry
+ entry -1 years -2 mons +3 days -04:05:06/entry
+ /row
+ row
+ entrypostgres_verbose/entry
+ entry@ 1 year 2 mons/entry
+ entry@ 3 days 4 hours 5 mins 6 secs/entry
+ entry@ 1 year 2 mons -3 days 4 hours 5 mins 6 secs ago/entry
+ /row
+ /tbody
+ /tgroup
+ /table
+
+ para
+ Note that literalsql_standard/ style will only produce strictly
+ standards-conforming string sliterals when given a strictly SQL-standard interval
+ value - meaning that it needs to be a pure year-month or datetime
+ interval and not mix positive and negative components.
+ /para
+
+/sect2
+
+
+
sect2 id=datatype-timezones
titleTime Zones/title
*** a/src/backend/commands/variable.c
--- b/src/backend/commands/variable.c
Re: [HACKERS] Do we really need a 7.4.22 release now?
Joshua D. Drake wrote: Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Tom Lane wrote: The suggestion I started this thread with amounted to not bothering with pushing 7.4.x updates in update cycles where we'd made no serious bug fixes in it; which is a very long way from desupport. Maybe an appropriate compromise is to announce now that 7.4 is in maintenance mode and will receive only really critical bug fixes (which are the only ones that 7.4.x users are going to pay attention to anyway, so nothing is lost); and that actual desupport will occur a year from now. +1 Shall we set an exact date, such as October 1, 2009? Let's include 8.0 in that announcement so we aren't having this discussion again in a year. Are we ready enough to actually put a *timeline* on the website? Meaning, can we already put in preliminary dates for *all* released versions? //Magnus -- 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] Do we really need a 7.4.22 release now?
Magnus Hagander wrote: Shall we set an exact date, such as October 1, 2009? Let's include 8.0 in that announcement so we aren't having this discussion again in a year. Are we ready enough to actually put a *timeline* on the website? Meaning, can we already put in preliminary dates for *all* released versions? I would think so. IMO: 3 years - Maintenance mode only 5 years - End of life Of course we need to define what maintenance mode only means. Joshua D. Drake -- 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] Do we really need a 7.4.22 release now?
Joshua D. Drake wrote: 3 years - Maintenance mode only 5 years - End of life Of course we need to define what maintenance mode only means. We effectively put each release into maintenance mode on day 1, ISTM. 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] Do we really need a 7.4.22 release now?
Andrew Dunstan wrote: Joshua D. Drake wrote: 3 years - Maintenance mode only 5 years - End of life Of course we need to define what maintenance mode only means. We effectively put each release into maintenance mode on day 1, ISTM. True enough. Joshua d. Drake 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] Where to Host Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Le 20 sept. 08 à 09:42, Dave Page a écrit : On Sat, Sep 20, 2008 at 8:37 AM, Joshua D. Drake [EMAIL PROTECTED] wrote: Dave Page wrote: Well that's not strictly true - I persuaded one of the GForge developers to work on the upgrade. As far as I'm aware, we're still waiting for the hardware/OS platform to be sorted out after some initial problems. I suspect JD will tell me something different though - that being the case, perhaps we can work out the issues and get on with the upgrade. I suppose the plan is to upgrade to a newer GForge. Is it still time to propose something completely different? I have real good feedbacks about VHFFS, a perl based clean-room re-implementation of it, if you want to see it this way. http://www.vhffs.org/wiki/index.php http://fr.wikipedia.org/wiki/VHFFS (easy to grasp keywords) Hope this helps, regards, - -- dim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkjVUqcACgkQlBXRlnbh1bnuWwCgsWMSrYACh2lOt+xbeqa6DCbO j7AAnifgloNY7ldaA+54S9HLlLxqBvuC =LoLv -END PGP SIGNATURE- -- 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] PostgreSQL future ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Who can resist the programming language game? Le 19 sept. 08 à 22:37, D'Arcy J.M. Cain a écrit : On Fri, 19 Sep 2008 20:57:36 +0100 Dave Page [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani [EMAIL PROTECTED] wrote: Has there been any idea to port PG to a more modern programming language like C++? Of course there are some minor obstacles like a new OO design, The plan is to start porting it to Java after the next release - probably at the beginning of April. I don't think that we should rush into any one language without checking the alternatives. Personally I think we should port everything to Intercal. May I recall Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally- specified bug-ridden slow implementation of half of Common Lisp. Regards, - -- dim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkjVVZUACgkQlBXRlnbh1bl/6gCcDhLEAdy+pZnjGnKSly3jmZqC 5pYAoMbseRc3Di49dRnr4XLDIGJOApFz =Qj2e -END PGP SIGNATURE- -- 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] Do we really need a 7.4.22 release now?
2008/9/20 Joshua D. Drake [EMAIL PROTECTED]: Andrew Dunstan wrote: Joshua D. Drake wrote: 3 years - Maintenance mode only 5 years - End of life Of course we need to define what maintenance mode only means. We effectively put each release into maintenance mode on day 1, ISTM. True enough. Surely it should be x years from the release of the next major version or something Not x years from release. If we say End of Life is x years from release then don't get round to releasing for ages a version may reach end of life with nothing to replace it. (Which will happen if we ever exhaust the To Do list (bit pie in the sky but never mind)) Peter -- 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] PostgreSQL future ideas
On Sat, 2008-09-20 at 09:06 -0400, D'Arcy J.M. Cain wrote: On Sat, 20 Sep 2008 13:47:10 +0300 Hannu Krosing [EMAIL PROTECTED] wrote: On Fri, 2008-09-19 at 16:37 -0400, D'Arcy J.M. Cain wrote: I don't think that we should rush into any one language without checking the alternatives. Personally I think we should port everything to Intercal. My choice would be whitespace , see http://en.wikipedia.org/wiki/Whitespace_(programming_language) Hey, we could write two modules into each file, one in Intercal and another in Whitespace. :-) Good idea! if we are smart, we can interweave them so that the whitespace inside intercal forms the source code of the Whitespace program. That would almost be Literate Programming - if you are not sure, what some part of the program does, you can immediately look at the other implementation. --- Hannu -- 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] Do we really need a 7.4.22 release now?
Andrew Dunstan [EMAIL PROTECTED] writes: Joshua D. Drake wrote: Of course we need to define what maintenance mode only means. We effectively put each release into maintenance mode on day 1, ISTM. Well, that would depend on your definition of maintenance mode ;-) Your statement would be true if you define it as no new features but that is nowhere near what I have in mind here. I'm thinking something closer to we'll only fix critical security and data-loss risks; and it would only apply to releases that are approaching the end of their life cycle. In particular, we need to define things in a way that explains/justifies changing more stuff in 8.3 than in 7.4. Maintenance mode starts on day of release is not only unhelpful but counterproductive for that discussion. 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] Do we really need a 7.4.22 release now?
Joshua D. Drake [EMAIL PROTECTED] writes: Magnus Hagander wrote: Are we ready enough to actually put a *timeline* on the website? I would think so. IMO: 3 years - Maintenance mode only 5 years - End of life I'm not really in favor of a one-size-fits-all approach to this. Our various releases have had different levels of uptake and don't necessarily all deserve the same support lifespan. Case in point: we already obsoleted 8.0 and 8.1 for our Windows users. How sensible is it to argue that they'll deserve a lifespan equivalent to 8.2's? The above numbers seem reasonable as a rough guideline, but I think the actual decisions will need to be taken on a release-by-release basis. 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] [patch] fix dblink security hole
Marko Kreen wrote: In addition to breaking standard security policy, dblink exposes .pgpass/pg_service.conf contents of the OS user database is running under to the non-privileged database user. (Esp. passwords) I took a look and can partially see Marko's point. The scenario exists within this context: 1. superuser installs dblink on db1, running on postgres server under the superuser account 2. superuser has .pgpass file 3. the superuser .pgpass file is set up with wildcards, e.g. *:*:*:postgres:mypassword 4. superuser creates login for luser in db1 This depends on superuser to not only make use of .pgpass, but specifically to use it in an insecure way, i.e. using wildcards to specify that the login credentials should be sent to any arbitrary Postgres installation. So although it may make sense to lock this down for 8.4, I don't agree with backporting it due to the backward compatibility hit. Also, I think we still need a way that people who don't allow real end-users directly in their databases and don't care about Marko's threat scenario can get their work done with minimal pain. Attached is my version of a more complete patch. It aims to prevent any dblink connection by non-superusers. But it also creates _u versions of dblink() and dblink_exec(), and initially revokes privileges from public in a similar vain. dblink_u(), dblink_exec_u (), and the previously created dblink_connect_u() are all SECURITY_DEFINER functions that can be granted to trusted non-superuser logins. Beyond Marko and I, no one else has publicly weighed in on this. If I don't hear any objections, I'll apply to cvs HEAD *only* in about 24 hours. Thanks, Joe -- 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] fix dblink security hole
I'm clearly out of practice -- this time with the attachment
Marko Kreen wrote:
In addition to breaking standard security policy, dblink exposes
.pgpass/pg_service.conf contents of the OS user database is running
under to the non-privileged database user. (Esp. passwords)
I took a look and can partially see Marko's point. The scenario exists
within this context:
1. superuser installs dblink on db1, running on postgres server
under the superuser account
2. superuser has .pgpass file
3. the superuser .pgpass file is set up with wildcards, e.g.
*:*:*:postgres:mypassword
4. superuser creates login for luser in db1
This depends on superuser to not only make use of .pgpass, but
specifically to use it in an insecure way, i.e. using wildcards to
specify that the login credentials should be sent to any arbitrary
Postgres installation.
So although it may make sense to lock this down for 8.4, I don't agree
with backporting it due to the backward compatibility hit. Also, I think
we still need a way that people who don't allow real end-users directly
in their databases and don't care about Marko's threat scenario can get
their work done with minimal pain.
Attached is my version of a more complete patch. It aims to prevent any
dblink connection by non-superusers. But it also creates _u versions
of dblink() and dblink_exec(), and initially revokes privileges from
public in a similar vain. dblink_u(), dblink_exec_u (), and the
previously created dblink_connect_u() are all SECURITY_DEFINER functions
that can be granted to trusted non-superuser logins.
Beyond Marko and I, no one else has publicly weighed in on this. If I
don't hear any objections, I'll apply to cvs HEAD *only* in about 24 hours.
Thanks,
Joe
Index: dblink.c
===
RCS file: /opt/src/cvs/pgsql/contrib/dblink/dblink.c,v
retrieving revision 1.74
diff -c -r1.74 dblink.c
*** dblink.c 3 Jul 2008 03:56:57 - 1.74
--- dblink.c 10 Aug 2008 04:59:05 -
***
*** 93,99
static HeapTuple get_tuple_of_interest(Oid relid, int2vector *pkattnums, int16 pknumatts, char **src_pkattvals);
static Oid get_relid_from_relname(text *relname_text);
static char *generate_relation_name(Oid relid);
! static void dblink_security_check(PGconn *conn, remoteConn *rconn);
static void dblink_res_error(const char *conname, PGresult *res, const char *dblink_context_msg, bool fail);
/* Global */
--- 93,99
static HeapTuple get_tuple_of_interest(Oid relid, int2vector *pkattnums, int16 pknumatts, char **src_pkattvals);
static Oid get_relid_from_relname(text *relname_text);
static char *generate_relation_name(Oid relid);
! static void dblink_security_check(void);
static void dblink_res_error(const char *conname, PGresult *res, const char *dblink_context_msg, bool fail);
/* Global */
***
*** 164,169
--- 164,170
} \
else \
{ \
+ dblink_security_check(); \
connstr = conname_or_str; \
conn = PQconnectdb(connstr); \
if (PQstatus(conn) == CONNECTION_BAD) \
***
*** 175,181
errmsg(could not establish connection), \
errdetail(%s, msg))); \
} \
- dblink_security_check(conn, rconn); \
freeconn = true; \
} \
} while (0)
--- 176,181
***
*** 229,234
--- 229,237
if (connname)
rconn = (remoteConn *) palloc(sizeof(remoteConn));
+
+ /* only connect if superuser */
+ dblink_security_check();
conn = PQconnectdb(connstr);
MemoryContextSwitchTo(oldcontext);
***
*** 246,254
errdetail(%s, msg)));
}
- /* check password used if not superuser */
- dblink_security_check(conn, rconn);
-
if (connname)
{
rconn-conn = conn;
--- 249,254
***
*** 2232,2253
}
static void
! dblink_security_check(PGconn *conn, remoteConn *rconn)
{
if (!superuser())
{
! if (!PQconnectionUsedPassword(conn))
! {
! PQfinish(conn);
! if (rconn)
! pfree(rconn);
!
! ereport(ERROR,
! (errcode(ERRCODE_S_R_E_PROHIBITED_SQL_STATEMENT_ATTEMPTED),
! errmsg(password is required),
! errdetail(Non-superuser cannot connect if the server does not request a password.),
! errhint(Target server's authentication method must be changed.)));
! }
}
}
--- 2232,2246
}
static void
! dblink_security_check()
{
if (!superuser())
{
! ereport(ERROR,
! (errcode(ERRCODE_S_R_E_PROHIBITED_SQL_STATEMENT_ATTEMPTED),
! errmsg(superuser is required),
! errdetail(Non-superuser cannot connect remotely.),
! errhint(Use dblink_connect_u to connect as superuser.)));
}
}
Index: dblink.sql.in
===
RCS file: /opt/src/cvs/pgsql/contrib/dblink/dblink.sql.in,v
retrieving revision 1.17
diff -c
[HACKERS] Foreign key constraint for array-field?
Hello. Is it possible to create a foreign key constraint for ALL elements of an array field? CREATE TABLE a(id INTEGER); CREATE TABLE b(id INTEGER, a_ids INTEGER[]); Field b.a_ids contains a list of ID's of a table. I want to ensure that each element in b.a_ids exists in a in any time. Is it possible to create an automatic foreign key? According to http://www.postgresql.org/docs/current/static/catalog-pg-constraint.html , seems to me it is possible if I create a custom entry in pg_constraint with my custom conpfeqop, conppeqop and conffeqop fields. Am I right? -- 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] fix dblink security hole
Joe Conway [EMAIL PROTECTED] writes: I took a look and can partially see Marko's point. The scenario exists within this context: 1. superuser installs dblink on db1, running on postgres server under the superuser account 2. superuser has .pgpass file 3. the superuser .pgpass file is set up with wildcards, e.g. *:*:*:postgres:mypassword 4. superuser creates login for luser in db1 This depends on superuser to not only make use of .pgpass, but specifically to use it in an insecure way, i.e. using wildcards to specify that the login credentials should be sent to any arbitrary Postgres installation. It seems to me that this is a pretty far-fetched scenario; someone who'd set up his .pgpass that way would be at risk from his own typos, not just from nefarious users. I'm not sure how far out of our way we need to go to protect stupid DBAs. But anyway: The main thing that bothers me about the proposed patch is that it takes away the security mechanism that existed before. Now you have either no trust or 100% trust, you don't have the option to trust people who know a password. That's less secure, not more, if you ask me. Marko's original patch is just as bad. If I understand the complaint correctly, it is not that a luser can make a connection, it is that the password will be sent before dblink rejects the connection. So really this problem is not specific to dblink --- what it's saying is that PQconnectionUsedPassword is broken by design and we should deprecate using that for security purposes. I think there is an alternative solution, if we are only going to patch this in 8.4 and up: provide a new libpq conninfo-string option saying not to use .pgpass, and have dblink add that to the passed-in conninfo string instead of trying to check after the fact. Then we aren't changing dblink's API at all, only replacing a leaky security check with a better one. 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
[HACKERS] Predictable order of SQL commands in pg_dump
Hello. Utility pg_dump dumps the identical database schemas not always identically: sometimes it changes an order of SQL statements. E.g.: 1. Dump of database A: ALTER TABLE xxx ADD CONSTRAINT ...; ALTER TABLE yyy ADD CONSTRAINT ...; 2. Dump of database B which has identical structure as A (pg_dump A | psql -d B was executed) ALTER TABLE yyy ADD CONSTRAINT ...; ALTER TABLE xxx ADD CONSTRAINT ...; This behaviour is not good, because I cannot execute diff to visually view what was changed between databases A and B. (I use this diff only for visual detection, please do not refer I want to use this diff for schema migration - I don't want it!). Is it possible to make pg_dump more predictable in SQL ordering? What order does it use by default? -- 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] Predictable order of SQL commands in pg_dump
Dmitry Koterov [EMAIL PROTECTED] writes: Utility pg_dump dumps the identical database schemas not always identically: sometimes it changes an order of SQL statements. Please provide a concrete example. The dump order for modern servers (ie, since 7.3) is by object type, and within a type by object name, except where another order is forced by dependencies. And there is no random component to the dependency solver ;-). So it should be behaving the way you want. 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] [patch] fix dblink security hole
Tom Lane wrote: I think there is an alternative solution, if we are only going to patch this in 8.4 and up: provide a new libpq conninfo-string option saying not to use .pgpass, and have dblink add that to the passed-in conninfo string instead of trying to check after the fact. Then we aren't changing dblink's API at all, only replacing a leaky security check with a better one. Good point -- I'll look into that and post something tomorrow. How does requirepassword sound for the option? It is consistent with requiressl but a bit long and hard to read. Maybe require_password? Joe -- 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] Foreign key constraint for array-field?
On Sat, Sep 20, 2008 at 8:38 PM, Dmitry Koterov [EMAIL PROTECTED] wrote: Hello. Is it possible to create a foreign key constraint for ALL elements of an array field? CREATE TABLE a(id INTEGER); CREATE TABLE b(id INTEGER, a_ids INTEGER[]); Field b.a_ids contains a list of ID's of a table. I want to ensure that each element in b.a_ids exists in a in any time. Is it possible to create an automatic foreign key? Well, it is possible to basically do this with triggers. However, ISTM you are doing something that is much easier done with a map table: create table a_b_map ( a_id int references a(a_id), b_id int references b(b_id), primary key(a_id, b_id) ); Also, I would suggest not using columns named 'id' (as in the above example). For various reasons, it creates a mess. merlin -- 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] fix dblink security hole
Joe Conway [EMAIL PROTECTED] writes: Good point -- I'll look into that and post something tomorrow. How does requirepassword sound for the option? It is consistent with requiressl but a bit long and hard to read. Maybe require_password? Well, no, because it's not requiring a password. Perhaps ignore_pgpass? [ looks at code a moment... ] Actually, there's another possibility. I see that the code already allows the location of .pgpass to be specified via the environment variable PGPASSFILE, but very non-orthogonally fails to have an equivalent conninfo option. So here's a more concrete proposal: fix it so that pgpassfile is also a conninfo option, and allow pgpassfile = none to silently suppress use of the pgpass file. (You could almost get there today with putenv(PGPASSFILE=/dev/null), except that (a) it would generate complaints in the postmaster log, and (b) we probably don't want dblink messing up the backend environment settings for possible other uses of libpq.) BTW, a possible hole in this scheme would be if a user could supply a conninfo string that was intentionally malformed in a way that would cause a tacked-on pgpassfile option to be ignored by libpq. We might need to add some validity checks to dblink, or tighten libpq's own checks. 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] Common Table Expressions (WITH RECURSIVE) patch
PlanState.has_recursivescan seems like a complete kluge. Can't it just be removed? It looks to me like it is working around bugs that hopefully aren't there anymore. There is certainly no reason why a recursive CTE should be more in need of rescanning than any other kind of plan. I don't think so. Recursion plan needs the hash table used by sublan be re-created at each recursion loop stage. Remember that in each evaluation of recursive plan, the recursive name is replaced by a working table which is holding previous evalution result of recursion stage. Thus the hash table corresponding to the work table needs to be re-created. If it is needed then the current implementation is completely broken anyway, since it would only detect a RecursiveScan node that is directly underneath an agg or hash node. Yeah, that's right. What I have in my mind is to implement something similar to UpdateChangedParamSet family like mechanism which will inherit working table change event to child node. -- Tatsuo Ishii SRA OSS, Inc. Japan -- 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] Common Table Expressions (WITH RECURSIVE) patch
Tatsuo Ishii [EMAIL PROTECTED] writes: PlanState.has_recursivescan seems like a complete kluge. Can't it just be removed? It looks to me like it is working around bugs that hopefully aren't there anymore. There is certainly no reason why a recursive CTE should be more in need of rescanning than any other kind of plan. I don't think so. Recursion plan needs the hash table used by sublan be re-created at each recursion loop stage. Remember that in each evaluation of recursive plan, the recursive name is replaced by a working table which is holding previous evalution result of recursion stage. Thus the hash table corresponding to the work table needs to be re-created. Oh, I see. I keep getting confused about whether RecursiveScan is at the top or the bottom of the recursion plan tree :-(. Maybe it would help to use a different name for it? RecursionInjector or something like that? If it is needed then the current implementation is completely broken anyway, since it would only detect a RecursiveScan node that is directly underneath an agg or hash node. Yeah, that's right. What I have in my mind is to implement something similar to UpdateChangedParamSet family like mechanism which will inherit working table change event to child node. I think it could actually *be* UpdateChangedParamSet, if you just associate some otherwise-unused Param with each RecursiveScan node, and have the Recursion node signal a change of that Param when it revises the work table. In fact, why not combine that with getting rid of the klugy addition to ExecutorState? Make the param be actually useful: it could contain some internal datastructure that passes the work table down to the RecursiveScan node. 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] Foreign key constraint for array-field?
On Sun, Sep 21, 2008 at 04:38:56AM +0400, Dmitry Koterov wrote: Hello. Is it possible to create a foreign key constraint for ALL elements of an array field? Whether it's possible or not--it probably is--it's a very bad idea. Just normalize :) Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] Do we really need a 7.4.22 release now?
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Magnus Hagander wrote: Are we ready enough to actually put a *timeline* on the website? I would think so. IMO: 3 years - Maintenance mode only 5 years - End of life I'm not really in favor of a one-size-fits-all approach to this. Our various releases have had different levels of uptake and don't necessarily all deserve the same support lifespan. Case in point: we already obsoleted 8.0 and 8.1 for our Windows users. How sensible is it to argue that they'll deserve a lifespan equivalent to 8.2's? I believe those are different arguments though. The Windows product is still a relatively young and immature release. Our nix product is not. Besides there is always an exception to the rule :). I have no problem with, unless otherwise specified... The above numbers seem reasonable as a rough guideline, but I think the actual decisions will need to be taken on a release-by-release basis. Nod. Joshua D. Drake -- 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] Foreign key constraint for array-field?
David Fetter wrote: On Sun, Sep 21, 2008 at 04:38:56AM +0400, Dmitry Koterov wrote: Hello. Is it possible to create a foreign key constraint for ALL elements of an array field? Whether it's possible or not--it probably is--it's a very bad idea. Just normalize :) +1 Cheers, David. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
