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:
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
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
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.
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
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
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
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
