Thanks Joe. Yes, that is exactly what I need.
Jack
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Thanks Rajesh. It 's very useful reference site.
Jack
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing lis
Stephan ,
Both of two suggestion work. Thank you very much!
Jack
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Sun, 2003-03-09 at 16:04, Rod Taylor wrote:
> How about a variable that turns on or off spec enforcement (case #1 or
> #2). On for 7.4, off for 7.5 the next release, and make it disappear
> after that.
Yeah, that sounds like the best solution to me.
IMHO there is a case to be made for skipping
Rod Taylor <[EMAIL PROTECTED]> writes:
> Enforcing spec seems like the least confusing mode to operate under,
> especially given it could break simply by changing the plan -- which
> happens automagically (seemingly random).
Keep in mind though that complaints about the current bugs have been
fair
> I'm presently leaning to #2, even though it exposes implementation
> details. I'm open to discussion though. Any preferences? Other ideas?
How about a variable that turns on or off spec enforcement (case #1 or
#2). On for 7.4, off for 7.5 the next release, and make it disappear
after that.
E
Tom,
> Postgres' implementation of cursors has always had a problem with doing
> MOVE or FETCH backwards on complex queries.
Coincidnetally enough, I was just chatting with one of my contractors
yesterday about how the one thing that Transact-SQL has to offer is a really
good cursor implementa
Postgres' implementation of cursors has always had a problem with doing
MOVE or FETCH backwards on complex queries. It works okay for simple
seqscans and indexscans, but fails for plans involving joins,
aggregates, and probably other cases. This happens because the executor
routines for those pla
First a single quote in text, when a backforward slash in a file path, what other
special characters need padded in two
backslashes before using the data in a SQL statement?
After hours' search in the PostgreSQL archive, I find a releted information on the
http://www.ca.postgresql.org/users-
l
