Christopher Kings-Lynne wrote:
> > I've just realized that if we change the RI trigger arguments this way,
> > we will have a really serious problem with accepting pg_dump scripts
> > from prior versions. The scripts' representation of foreign key
> > constraints will contain commands like
> >
>
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
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 fine;
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 m
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
> 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
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 w
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
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)?
N
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 c
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 com
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-
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I think there are two ways of making this capability visible to users.
> > First, you could do:
> >
> > SET query_timeout = 5;
> >
> > and all queries after that would time out at 5 seconds. Another option
> > is:
> >
> > BEGIN WORK T
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 int
On Mon, 1 Apr 2002, Tom Lane wrote:
> This assumes that the query timeout should apply to each subsequent
> query, individually, until explicitly canceled. If you want a timeout
> that applies to only one query and is then forgotten, then maybe this
> wouldn't be the most convenient definition.
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.
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 subse
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
thi
Jessica Perry Hekman <[EMAIL PROTECTED]> writes:
> What's a GUC variable?
A parameter that you can set with SET.
> Would this apply to all subsequent statements? I
> think it needs to apply to just the specified statement.
Yes, if the JDBC spec expects this to be applied to just a single
statem
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
On Mon, 1 Apr 2002, Peter Eisentraut wrote:
> Does it time out only queries or any kind of statement?
Any kind, I believe.
FWIW, I took a look at the recommended JDBC driver for MySQL, hoping for
ideas; it does not implement query timeouts at all. I'll take a look at
mSQL next.
j
---
- 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 prepro
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 m
Bear Giles <[EMAIL PROTECTED]> writes:
> I recently discovered a problem inserting a user-defined type when
> going through a rule. ...
> The problem is that I can insert literal text:
> create table t ( cert x509 );
> insert into t values (' BEGIN CERTIFICATE ');
> but when I t
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
Bear Giles <[EMAIL PROTECTED]> writes:
> 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 any rule with a function
> that operates on one of the parame
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'
On Fri, Mar 29, 2002 at 12:39:01PM -0500, Peter Eisentraut wrote:
> * Running 'autoconf' is now very slow. Too bad.
But rerunning autoconf should be fast, thanks to autom4te.cache.
--
albert chin ([EMAIL PROTECTED])
---(end of broadcast)---
TIP
33 matches
Mail list logo
