Re: [HACKERS] 8.5 release timetable, again
On Monday 24 August 2009 3:51:31 pm Bruce Momjian wrote: folks were expecting it in 8.4. That is a slightly alarmist. Who are we going to lose these users to? the insane asylum? -- 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] LIMIT NULL
On Wednesday 04 February 2009 8:41:55 am Svenne Krap wrote: Andrew Dunstan wrote: Me neither. I wonder how many other long term users (I have used pgsql for more than a decade - 6.2 was my first version if memory serves) and have never caught that nuance either. Maybe that should be printed as a note on the narrative description pages.. something like: Note this is a simplified introduction to the subject. For authorative description please see topic x in section y (and link to it of course ;)) In effect it does say that - perhaps not quite as explicitly as you might have wanted. It says: The information in this part is presented in a narrative fashion in topical units. Readers looking for a complete description of a particular command should look into Part VI. (the PART VI is a link). Well... I meant on EVERY single page outside section VI (or whatever is considered cannonical) I believe most users today search instead of browse documentation... I certainly do... that I have a decade of postgresql experience just helps me to know that section VI.I is extremly important (but I learned that through trial and error not by reading a small hint). If I google postgresql limit the second link links to http://www.postgresql.org/docs/8.3/interactive/queries-limit.html (for some reason google strongly prefers version 7.3). That page (which is the first you see if you search your way in) gives me the following impressions (i.e. given my information gathering heuristics): - domain postgresql.org (=official) - in the page title it states: PostgreSQL 8.3.5 Documentation (=yeah, right place) - Chapter 7. Queries (=reasonable) - 7.6. LIMIT and OFFSET (= home free ;) Which gives me every indication that I am the right place. Nowhere on this page is the note, that there exists a better place (experience has shown me, that the SELECT page in the SQL reference is far more detailed, but that is unknown for a newbie user). Exactly what lead me to my conclusions. I picked up PG during the 8.0 betas - so I've not been around too long, but I've done enough that I no longer consider myself a newbie user ... For the purpose of providing a use case from some random user: I might have also arrived at the queries-limit page from: http://www.postgresql.org/docs/current/static/ then clicking on II.7. taking me to: http://www.postgresql.org/docs/current/static/queries.html then clicking on 7.6, taking me to: http://www.postgresql.org/docs/current/static/queries-limit.html None of those pages say anything about the depth which the subject is covered, or the status of the page as reference. Of all the (apparently reference) docs I've read, I've never arrived at them through VI. Reference at http://www.postgresql.org/docs/current/static/reference.html So this is very educating for me - would it be out of line to ask, in this forum, how one such as myself would know when arriving at http://www.postgresql.org/docs/8.3/interactive/queries-limit.html from Google or via the above described steps that the page is a not meant to be reference only? Further, when one starts at the top of http://www.postgresql.org/docs/current/static/ and starts reading down, what leads one to the reference page (at section VI) so that they may see that statement about the depth of coverage when the topic they're looking for is in section II? -- 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] LIMIT NULL
On Tuesday 03 February 2009 3:06:27 pm Tom Lane wrote: Rick Vernam ri...@hobi.com writes: If looking for information about limits, I would go here: http://www.postgresql.org/docs/8.3/static/queries-limit.html and consider it to be an authoritative source. The reference documentation is *always* intended to be more complete and more authoritative than the narrative description. If you don't think so then you need to readjust your expectations. regards, tom lane very well, I did not know that. expectations readjusted. thanks. -- 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] LIMIT NULL
On Tuesday 03 February 2009 10:42:30 am David E. Wheeler wrote: On Feb 3, 2009, at 8:40 AM, Andrew Dunstan wrote: We have one page per main SQL verb (e.g. SELECT or CREATE TABLE). I don't think we want to break it up more than that. One page for each clause would be a nightmare to maintain. Then should the LIMIT/OFFSET page go away? Best, David I agree that it's confusing when one piece of LIMIT documentation is not with the rest. If looking for information about limits, I would go here: http://www.postgresql.org/docs/8.3/static/queries-limit.html and consider it to be an authoritative source. If somebody told me something about LIMIT that was not on that page, I'd say to them to go back and double check the docs... -- 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] 8.4 release planning
On Monday 26 January 2009 2:12:02 pm Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: So, some feedback to make this decision more difficult: Users: care about HS more than anything else in the world. I don't think this is correct. There are certainly a lot of users who would like an in-core replication solution, but HS by itself is not that --- you also need (near) real-time log shipping, which we have already decided to punt to 8.5. Precisely. Thank you. That being the case, I think the argument that HS is a must-have feature for 8.4 is actually rather weak. I am just one person, representing one company...but I do agree, fwiw. -- 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] 8.4 release planning
On Monday 26 January 2009 6:31:48 pm Ron Mayer wrote: Tom Lane wrote: [...snip...] The second problem is that we're not sure it's really the right thing, because we have no one who is competent to review the design from a security standpoint. But unless we get past the first problem the second one is moot. Are we underestimating Kaigai Kohei? I seem to see him credited on the NSA's SELinux pages: http://www.nsa.gov/research/selinux/contrib.shtml and it seems his patches there related to postgresql were pretty widely discussed on the SELinux lists: http://www.nsa.gov/research/selinux/list-archive/0805/index.shtml#26163 I'm pretty sure that when he says review that it is implied to be a peer review -- 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] Core team statement on replication in PostgreSQL
On Thursday 29 May 2008 09:54:03 am Marko Kreen wrote: On 5/29/08, Tom Lane [EMAIL PROTECTED] wrote: The Postgres core team met at PGCon to discuss a few issues, the largest of which is the need for simple, built-in replication for PostgreSQL. Historically the project policy has been to avoid putting replication into core PostgreSQL, so as to leave room for development of competing solutions, recognizing that there is no one size fits all replication solution. However, it is becoming clear that this policy is hindering acceptance of PostgreSQL to too great an extent, compared to the benefit it offers to the add-on replication projects. Users who might consider PostgreSQL are choosing other database systems because our existing replication options are too complex to install and use for simple cases. In practice, simple asynchronous single-master-multiple-slave replication covers a respectable fraction of use cases, so we have concluded that we should allow such a feature to be included in the core project. We emphasize that this is not meant to prevent continued development of add-on replication projects that cover more complex use cases. We believe that the most appropriate base technology for this is probably real-time WAL log shipping, as was demoed by NTT OSS at PGCon. We hope that such a feature can be completed for 8.4. +1 Although I would explain it more shortly - we do need a solution for lossless failover servers and such solution needs to live in core backend. +1 for lossless failover (ie, synchronous) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] select statement details
I'm trying to determine if a select statement:
1 - causes execution of a Volatile function
- or -
2 - causes execution of a nextval function (same/similar as #1 above?)
from within tcop / postgres.c ??
Things like QueryIsReadOnly imply that select nextval('some_sequence') are
read-only ... which is not read-only in the sense that the database is in a
different state after the nextval runs.
I've been looking through PortalDesc NodeTag, but haven't been able to find
anything...
suggestions?
If nothing exists, I'd need to create something.
Any suggestions where to start?
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
