Title: Message
Without checking into details, this sounds like it could be a broken
ming/msys installation. Are you on the latest release
version?
Also,
check for the Makefile.port file manually. configure cleraly thinks it has
created it... If it's not there, check if you can create
Tom Lane said:
Andrew Dunstan [EMAIL PROTECTED] writes:
I am about to redo the patch that would allow tagging of log lines
with info via a printf-style string.
Any comments or suggestions before I start?
I think Bruce already applied the previous version of your patch.
Not that I can see.
-Original Message-
From: Shachar Shemesh [mailto:[EMAIL PROTECTED]
Sent: 18 February 2004 13:18
To: Hackers; PostgreSQL OLE DB development
Subject: [HACKERS] OIDs, CTIDs, updateable cursors and friends
Would adding OID to the rows returned by each Select
call, and then doing
Dave Page wrote:
-Original Message-
From: Shachar Shemesh [mailto:[EMAIL PROTECTED]
Sent: 18 February 2004 13:18
To: Hackers; PostgreSQL OLE DB development
Subject: [HACKERS] OIDs, CTIDs, updateable cursors and friends
Would adding OID to the rows returned by each Select
call, and
-Original Message-
From: Shachar Shemesh [mailto:[EMAIL PROTECTED]
Sent: 18 February 2004 14:10
To: Dave Page
Cc: Hackers; PostgreSQL OLE DB development
Subject: Re: [HACKERS] OIDs, CTIDs, updateable cursors and friends
I would, except I'm not sure how many queries I would
Dave Page wrote:
-Original Message-
From: Shachar Shemesh [mailto:[EMAIL PROTECTED]
Sent: 18 February 2004 14:10
To: Dave Page
Cc: Hackers; PostgreSQL OLE DB development
Subject: Re: [HACKERS] OIDs, CTIDs, updateable cursors and friends
I would, except I'm not sure how many queries
-Original Message-
From: Shachar Shemesh [mailto:[EMAIL PROTECTED]
Sent: 18 February 2004 14:56
To: Dave Page
Cc: Hackers; PostgreSQL OLE DB development
Subject: Re: [HACKERS] OIDs, CTIDs, updateable cursors and friends
I'll have a look at that. How would updateable cursors do
Without checking into details, this sounds like it could be
a broken
ming/msys installation. Are you on the latest release version?
Also, check for the Makefile.port file manually. configure cleraly
thinks it has created it... If it's not there, check if you
can create
The question is whether we should have a GUC variable to control no
waiting on locks or add NO WAIT to specific SQL commands.
Does anyone want to vote _against_ the GUC idea for nowait locking. (We
already have two voting for such a variable.)
I vote against. We got bit by both the regex
Larry Rosenman wrote:
-- Start of PGP signed section.
--On Wednesday, February 18, 2004 13:56:14 -0500 Bruce Momjian
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
The question is whether we should have a GUC variable to control no
waiting on locks or add NO WAIT to specific SQL
Hi all,
I'm looking at ways to improve PG performance where index scans are
concerned. The layout of our database and our access habits really hit PG's
index code square in the chops. Many of our queries spend way too much time
waiting for disk seeks, and I believe this is fully caused by the
Tatsuo Ishii wrote:
I agree with Tom here. I have used the Oracle NOWAIT feature in the
past and think it is a great feature IMHO. But when you need to use it,
you want it to apply very specifically to a single statement. Using a
sledge hammer when you need a tweezers isn't the right way to
Do these need to be fixed in backend/catalog/system_views.sql to have
pg_catalog. before everything?
eg.
CREATE VIEW pg_rules AS
SELECT
N.nspname AS schemaname,
C.relname AS tablename,
R.rulename AS rulename,
pg_get_ruledef(R.oid) AS definition
FROM
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Do these need to be fixed in backend/catalog/system_views.sql to have
pg_catalog. before everything?
No, because the references are all resolved when the views are created.
We do have to be cautious about qualifying references that appear
14 matches
Mail list logo
