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:
ht
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 tha
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 referen
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 mai
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
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-co
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 b
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 ..
