Christopher Kings-Lynne wrote:
Yeah, although it'd still be a good idea probably to convert the dump form
to ALTER TABLE in any case. The one downside that was brought up in the
past was the time involved in checking dumped (presumably correct) data
when the constraint is added to very
Patch against 7,2 submitted for comment.
It's a little messy; I had some trouble trying to reconcile the code
style of libpq which I copied from, and odbc.
Suggestions on what parts look ugly, and or where to send this
(is there a separate ODBC place?) are welcome.
This seems to work just
Rod Taylor wrote:
2) re-check any constraint inserted into the database
There should not be any if it was accepted, however if it's a new
constraint it doesn't get applied to data that already exists. A dump
and restore will ignore these as well (with good reason).
Please don't make
Jan Wieck [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
Why can't we just hack up the CREATE CONSTRAINT TRIGGER code to look up
the OIDs, etc. for the arguments and convert them internally to an ALTER
TABLE/ADD CONSTRAINT or whatever...
And what language hack do you
On Sat, 30 Mar 2002, Tom Lane wrote:
Au contraire, it is not assuming anything. It is sending off a cancel
request and then waiting to see what happens. Maybe the query will be
Okay, I see now: when processCancelRequest() is called, a return of 127 is
sent. That would indeed work;
Jessica Perry Hekman wrote:
On Sat, 30 Mar 2002, Tom Lane wrote:
Au contraire, it is not assuming anything. It is sending off a cancel
request and then waiting to see what happens. Maybe the query will be
Okay, I see now: when processCancelRequest() is called, a return of 127 is
Jessica Perry Hekman [EMAIL PROTECTED] writes:
My other question was how to send the timeout value to the backend.
I would imagine that the most convenient way to handle it would be as
a SET variable:
SET query_timeout = n;
Establishes a time limit on subsequent queries (n expressed
On Mon, 1 Apr 2002, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
Why can't we just hack up the CREATE CONSTRAINT TRIGGER code to look up
the OIDs, etc. for the arguments and convert them internally to an ALTER
TABLE/ADD CONSTRAINT or whatever...
I said:
The table OIDs in pg_trigger would do fine if the trigger function could
get at them, but it can't; so we need to copy them into the trigger
arguments. (Hmm, I suppose another option is to extend the Trigger
data structure to include tgconstrrelid, and just ignore the table names
in
Stephan Szabo [EMAIL PROTECTED] writes:
Sorry, I must have misunderstood you. I thought you were backing away
from changing the arguments that were created for the trigger. Or did
you mean using the stored info on the two oids we already have in the
record (tgrelid and tgconstrrelid)?
No, I
Stephan Szabo [EMAIL PROTECTED] writes:
Well, there is another place where the current name behavior
causes problems so we'd need to be sticking in the fully qualified
name, otherwise creating a table in your search path earlier than
the intended table would break the constraint. This
Bruce Momjian [EMAIL PROTECTED] writes:
... It will be tricky to manage multiple
alarms in a single process, but it can be done by creating an alarm
queue.
I would argue that we should only support *one* kind of timeout, either
transaction-level or statement-level, so as to avoid that
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
... It will be tricky to manage multiple
alarms in a single process, but it can be done by creating an alarm
queue.
I would argue that we should only support *one* kind of timeout, either
transaction-level or statement-level, so
On Mon, 1 Apr 2002, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Well, there is another place where the current name behavior
causes problems so we'd need to be sticking in the fully qualified
name, otherwise creating a table in your search path earlier than
the intended
On Mon, 1 Apr 2002, Bruce Momjian wrote:
I don't know which people want, and maybe this is why we need both GUC
and BEGIN WORK timeouts. I don't remember this distinction in previous
discussions but it may be significant. Of course, the GUC could behave
at a transaction level as well. It
Tom Lane wrote:
Jessica Perry Hekman [EMAIL PROTECTED] writes:
My other question was how to send the timeout value to the backend.
I would imagine that the most convenient way to handle it would be as
a SET variable:
SET query_timeout = n;
Establishes a time limit on subsequent
Jessica,
My reading of the JDBC spec would indicate that this is a statement
level property (aka query level) since the method to enable this is on
the Statement object and is named setQueryTimeout(). There is nothing I
can find that would indicate that this would apply to the transaction in
On Mon, 1 Apr 2002, Jan Wieck wrote:
Why don't we use two separate GUC variables and leave the
BEGIN syntax as is completely?
SET transaction_timeout = m;
SET statement_timeout = n;
What's a GUC variable? Would this apply to all subsequent statements? I
think
Barry Lind writes:
My reading of the JDBC spec would indicate that this is a statement
level property (aka query level) since the method to enable this is on
the Statement object and is named setQueryTimeout(). There is nothing I
can find that would indicate that this would apply to the
The spec isn't clear on that point, but my interpretation is that it
would apply to all types of statements not just queries.
--Barry
Peter Eisentraut wrote:
Barry Lind writes:
My reading of the JDBC spec would indicate that this is a statement
level property (aka query level) since the
- Original Message -
From: Nicolas
Bazin
To: PostgreSQL-development
Cc: Tom
Lane ; Bruce Momjian ; Michael
Meskes
Sent: Thursday, March 28, 2002 9:30 AM
Subject: Always the same ecpg bug - please (re)apply
patch
Here is the description:
When a macro is replaced by the
I recently discovered a problem inserting a user-defined type when
going through a rule. I'm not sure if it's a -hackers or -users question,
but since it involves the interaction of a user-defined type and rules
I thought it envitable that I would end up here anyway.
The object in question is
Hi,
I created a schema *inoue* and tried the following.
# create table inoue.t1 (id serial primary key, dt text);
NOTICE: CREATE TABLE will create implicit sequence 't1_id_seq'
for SERIAL column 't1.id'
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
't1_pkey' for table
I'm using 7.1.3 currently, but am building and installing 7.2.1 tonight
to see if this fixes the problem.
I don't know the standard types and functions well enough to be able to
whip out a test case, but I think I do have an idea on what the problem
is. If I'm right, the problem is triggered by
Hiroshi Inoue [EMAIL PROTECTED] writes:
# create table inoue.t1 (id serial primary key, dt text);
NOTICE: CREATE TABLE will create implicit sequence 't1_id_seq'
for SERIAL column 't1.id'
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
't1_pkey' for table 't1'
25 matches
Mail list logo
