Chapter 13 of the documentation on Rules versus Triggers says in part
"On the other hand a trigger that is fired on INSERT on a view can do the same as a
rule, put the data somewhere else and suppress the insert in the view."
However, it does not appear to be possible to set a trigger on a view,
On Sat, Aug 16, 2003 at 08:36:57PM -0400, Bruce Momjian wrote:
>
> Do we need to add a mention of the need for tuning to the install docs?
Wouldn't be a bad idea, as far as I'm concerned.
A
--
Andrew Sullivan 204-4141 Yonge St
dvise running the postmaster on a
dedicated machine, with no X or other nasty stuff running.
-
I do have a doc patch ready (with one sensible addition suggested by Jon
Jensen).
andrew
Josh Berkus wrote:
Andrew,
I see btw that no change has been made to the docs. That&
cumentation for both.
Tom's implementation of a new flex-based lexer for psql is a significant
source code change which should be mentioned.
cheers
andrew
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
illustrated earlier.
A similar problem occurs if a set-returning function passes
a large set of rows back to postgres via
return. You can avoid this
problem too by instead using return_next for
each row returned, as shown previously.
cheers
andrew
---(end of
have been
amalgamated to suit a publisher then I feel even more agrieved -- I
resent having to pay for padding and resent the waste of paper. With a
duplex printer the documentation fills two binders; printed simplex it
would be more like four!
Andrew Ford
ford-m
I am wondering we should make this warning more prominent - it would be
easily missed buried on the Oracle porting section, and I have seen
people caught by it lots of times.
cheers
andrew
Philip Yarra wrote:
Hi, I supplied a minor doco patch relating to porting pl/SQL to pl/pgSQL:
http
uot; because it's saving something different
> than the actual physical database. When you restore you get something
> (hopefully) logically equivalent but still physically different.
This seems fairly arbitrary. On that basis anything on a higher level than
dd is not a backup m
Jim C. Nasby wrote:
On Tue, Oct 03, 2006 at 12:13:46PM -0400, Andrew Dunstan wrote:
Perhaps it'd be better to provide a small table of recognized type
aliases, rather than inserting equivalent notes into three or four places.
you mean like the table here?
mes. Or if
you want to be get more advanced some sort of Ajax solution. But we need
some sort of nav bar that you can drill down on. Navigation now is just
horrible, IMNSHO.
cheers
andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Bruce Momjian wrote:
Well, if 'draft' was only for html, I could see suggesting just 'gmake
draft', but 'draft' can be used for Postscript and PDF too.
The maybe have targets draft-html, draft-postscript and draft-pdf ?
cheers
andrew
--
e.
I'm willing to write it, if there's a consensus that it would be worth
having.
Andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
gement is "if it works, don't change it". What
I'm looking for is something with which to convince people that the
risk of breakage is so low that it's outweighed by the risk of
remaining exposed to bugs which haven't caused them problems yet.
Andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
uilds for 8.0 and 8.1. I think this is related, but I haven't
figured out how we can express these ideas.
Andrew
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [
a user may encounter the community strongly
Or...
Minor releases are intended to minimize the risk associated with
change while addressing important stability or security bugs. All
users are strongly encouraged to keep abreast of minor releases as
their maintenance windows permit. ...
On 2/22/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
Andrew Hammond wrote:
> On 2/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
>> OK, the FAQ now has:
>>
>> The PostgreSQL team makes only bug fixes in minor releases,
>> so, for examp
eases listed on the front page under "Latest Releases" are
actually "Current minor release for branches which have not reached
EoL"? Perhaps instead of "Latest Releases" or "Actively Maintained
Releases" something like "Current Releases" says that better?
Andrew
---(end of broadcast)---
TIP 6: explain analyze is your friend
ed
directly from the FAQ. Updates to the text are always welcome ;-)
url please?
Andrew
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
eryone else.
Especially if you have cvsutils installed (can be found in many places
including fedora extras).
cheers
andrew
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.pos
ccess.
cheers
andrew
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
don't
see why there's a problem with using the command above. Or if you
prefer, use something like this to postprocess the file:
perl -ni -e 'print unless /^\?/;' diff-file
Bottom line - TIMTOWTDI
cheers
andrew
---(end of broadcast)-
e that happen next
release. Getting the modules properly documented is a very important
milestone along the way to getting that done. Maybe then the modules
will be considered more first class citizens (until the buildfarm came
along they were often hardly tested at all).
cheers
andrew
the contrib stuff in the main docs would remove one of the largest barriers
to people knowing about the contrib features.
I don't agree with Greg that we shouldn't make this docs improvement. I
do think we should do it in such a way that it will fit with our plans
fo
e thinks we should put it in Reference or Appendixes?
I would far rather have a new top level heading. Something like
"Standard Modules and Tools". (Please avoid the use of the word
"contrib"). If not, than as a sub-chapter of "References". I don't think
Peter Eisentraut wrote:
Am Mittwoch, 29. August 2007 20:27 schrieb Andrew Dunstan:
Also, let's recall what has previously been discussed for contrib,
namely that we break it out into standard modules
But that would also mean that the documentation system is somewhat
modula
the main distribution helps us to
validate the module process via buildfarm etc.
So this isn't just "moving everything to the main blob of things".
If you want to pay for market research then feel free ;-)
cheers
andrew
---(end of broadcast)-
27;re not making much sense here.
Tom is talking about partitioning and his analysis is correct *in the
partitioning case* AFAICS.
What basis do you have for saying he is not?
cheers
andrew
---(end of broadcast)---
TIP 9: In versions below 8.0
David Fetter wrote:
balanced
gradual
extended (I see you mention time-extended but wouldn't time be implicit
based on the actual docs and thus we only need extended?)
How about "smoothed?"
perhaps we should call it Jacob checkpointing, then.
n't see any reason, unless we're going to start doing that for all
contributions. 'contrib' is a serious misnomer anyway, and there's no
reason to think in general that the original author is specially
responsible for any of it. I think Tom's point is entirel
d implementation would be a nice addition, but it really doesn't
buy you much in functionality that you don't already have.
cheers
andrew
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
uld you be able
to validate against XML schema?
I would tent towards redundancy, and include the XML schema part.
Andrew Lardinois
Richard Huxton wrote:
Where do we go from here?
1. We can make use of some/all of this on the main site.
Yes please!
Richard, thanks a lot for your work on this.
cheers
andrew
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http
g the docs every day.
cheers
andrew
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
e this setting if we run into
it? If it's possible that seems to me like a much better way to go.
cheers
andrew
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
7;re not so readily usable, whereas
this way you can copy them out easily.
cheers
andrew
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
headaches, then +1.
I wondered that, specifically about Windows junction points, but we seem
to have support for it already in dirmod.c::pgreadlink(). Surely there's
no other currently supported platform where it would even be a question?
cheers
andrew
--
Sent via pgsql-docs mailing list (
'd be happy to hear about it. Maybe it
would be a good Google SOC project.
cheers
andrew
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
, will fix.
cheers
andrew
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
In most versions of Linux, the default hugepage size is 2m. Other Unix versions
may have different hugepage sizes, e.g. AIX, but Linux defaults to 2m
Sent from my iPad
> On Oct 21, 2016, at 11:43 AM, [email protected] wrote:
>
> The following documentation comment has been logged on
Alvaro,
Its been quite some years since I last followed the pam stuff. Since
the kernel.org breakin, pretty much everything there has been undone.
I can ask around about what might be salvagable, but Thorsten really
is the one to know where the latest copy of everything is.
Cheers
Andrew
On
40 matches
Mail list logo
