Re: [HACKERS] 8.5 release timetable, again

2009-08-24 Thread Rick Vernam 
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

2009-02-04 Thread Rick Vernam 
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 
 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

2009-02-03 Thread Rick Vernam 
On Tuesday 03 February 2009 3:06:27 pm Tom Lane wrote:
> Rick Vernam  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

2009-02-03 Thread Rick Vernam 
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

2009-01-26 Thread Rick Vernam 
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] 8.4 release planning

2009-01-26 Thread Rick Vernam 
On Monday 26 January 2009 2:12:02 pm Tom Lane wrote:
> Josh Berkus  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] Core team statement on replication in PostgreSQL

2008-05-29 Thread Rick Vernam 
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

2008-01-20 Thread Rick Vernam 
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