"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Anyway, the point is that some of the simple views should be straight
> forward to reversing automatically if someone has the will and the
> time it can be done. A while back a list of 'views which cannot be
> reversed' was created and included things su
> > > This would be a potential feature of being able to insert into
> views
> > > in general. Reversing the CREATE VIEW statement to accept
> inserts,
> > > deletes and updates.
> > Definitely not a 'potential' feature, but a existing and
documented
> one.
> > Read up on rules, especially 'ON IN
> > This would be a potential feature of being able to insert into
views
> > in general. Reversing the CREATE VIEW statement to accept
inserts,
> > deletes and updates.
> Definitely not a 'potential' feature, but a existing and documented
one.
> Read up on rules, especially 'ON INSERT DO INSTEAD'
Matthew Hagerty <[EMAIL PROTECTED]> writes:
> So then how would I code for the exception, i.e. the backend goes down just
> before or during my call to PQsendQuery()? If I am non-blocking then I can
> determine that my query did not go (PQsendQuery() or PQflush() returns an
> error) and attemp
On Mon, 2 Jul 2001, Alex Pilosov wrote:
> Erm, forgot to attach the patch. Here it is.
(yow) don't even bother looking at this patch. mail server delayed this
message by almost a week, and by now, the code is totally changed.
I took Tom's suggestion and made RTE a union. So, the below is a new
d
On Sat, 7 Jul 2001, Rod Taylor wrote:
> This would be a potential feature of being able to insert into views
> in general. Reversing the CREATE VIEW statement to accept inserts,
> deletes and updates.
Definitely not a 'potential' feature, but a existing and documented one.
Read up on rules, esp
This would be a potential feature of being able to insert into views
in general. Reversing the CREATE VIEW statement to accept inserts,
deletes and updates.
If true, focus on that. Theres lots of views that cannot be reversed
properly -- unions come to mind -- but perhaps this type of simple
jo
On Sat, 7 Jul 2001, David Bennett wrote:
> -
> In a nutshell you are recommending:
> -
>
> create table contact_type (
> codeint2,
> typechar(16),
> PRIMARY KEY ( code )
> );
>
> create table contact (
> numberserial,
> name char(32),
>
At 03:46 PM 7/7/2001 -0400, Tom Lane wrote:
>Matthew Hagerty <[EMAIL PROTECTED]> writes:
> > If I don't call PQsetnonblocking() will that affect any of the async
> > functions I'm dealing with?
>
>PQsetnonblocking has nothing to do with the
>PQconsumeInput/PQisBusy/PQgetResult family of functions.
I said:
> Also, unless you are sending more than one
> query in a query string, the backend is going to be absorbing the
> data as fast as it can anyway; so even if you do block it's only
> going to be for a network transit delay, not for database processing.
Actually, forget the "unless" part --
Matthew Hagerty <[EMAIL PROTECTED]> writes:
> If I don't call PQsetnonblocking() will that affect any of the async
> functions I'm dealing with?
PQsetnonblocking has nothing to do with the
PQconsumeInput/PQisBusy/PQgetResult family of functions. The point of
the latter is to avoid blocking whil
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> Would 7.2 maintain performance when updating a row repeatedly (update,
> commit)?
You'll still need to VACUUM to get rid of the obsoleted versions of the
row. The point of the planned 7.2 changes is to make VACUUM cheap and
nonintrusive enough so that y
At 02:13 PM 7/7/2001 -0400, Tom Lane wrote:
>Matthew Hagerty <[EMAIL PROTECTED]> writes:
> > Only applications that have used PQsetnonblocking have a need for this."
>
> > Since I use PQsetnonblocking(), I included PQflush().
>
>Hmm. My opinions about the PQsetnonblocking patch are on record:
>it
Matthew Hagerty <[EMAIL PROTECTED]> writes:
> Only applications that have used PQsetnonblocking have a need for this."
> Since I use PQsetnonblocking(), I included PQflush().
Hmm. My opinions about the PQsetnonblocking patch are on record:
it's broken and needs fundamental redesign before it ha
Thanks for the response Tom! Does anyone ever tell you how much you are
appreciated? If not, I will. When I post to pgHackers I know I will get a
response (usually) from many knowledgeable people, and for that I thank
everyone. But I *always* receive a response from Tom, and for that I am
Matthew Hagerty <[EMAIL PROTECTED]> writes:
> I'm working with pqlib in asynchronous mode and I have a question about
> PQgetResult. I have this situation:
> submit a query via PQsendQuery()
> flush to the backend with PQflush()
I think the flush is not necessary; PQsendQuery should do it.
>
On Friday 06 July 2001 18:51, Naomi Walker wrote:
> If PostgreSQL is run on a system that has a file size limit (2 gig?), where
> might cause us to hit the limit?
Since PostgreSQL automatically segments its internal data files to get around
such limits, the only place you will hit this limit wil
On Thursday 05 July 2001 10:51, Víctor Romero wrote:
> I am running postgresql 7.1 on a SMP Linux box. It runs, but it never pass
> a loadavg of 0.4, no matter how I try to overload the system.
> The same configuration, the same executable, the same test on a non-SMP
> machine gives a loadavg o
At 05:59 PM 7/6/01 -0400, Bruce Momjian wrote:
>
>OK, I just talked to Tom on the phone and here is his idea for 7.2. He
>says he already posted this, but I missed it.
>
>His idea is that in 7.2 VACUUM will only move rows within pages. It
>will also store unused space locations into shared memor
19 matches
Mail list logo
