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
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
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'
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
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
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
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
- 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
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
---
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
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
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
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,
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
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
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.
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, 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
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
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-
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
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
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
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
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
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
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
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
> 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;
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
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;
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
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
> >
>
33 matches
Mail list logo
