Maybe the following item would look good in a 'new features' list
targeted at the less technically oriented audience:
- LDAP support for authentication and centralized connection management.
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 9: In ve
Hi,
we have a large export here, I made an in-house benchmark
between Informix, plain PostgreSQL-8.1.4 and
8.2devel+COPY(SELECT) using the same data and query.
Find the results below for the two PostgreSQL versions.
With PostgreSQL 8.1.4, I used this:
begin;
select ... into temp myquery1;
copy my
"Guillaume Smet" <[EMAIL PROTECTED]> wrote:
> There is a mention in autovacuum doc:
> http://www.postgresql.org/docs/8.1/interactive/maintenance.html#AUTOVACUUM
>
> Last sentence of the first paragraph is:
> "Also, it's important to allow a slot for the autovacuum process when
> choosing the val
Tom Lane <[EMAIL PROTECTED]> writes:
> At the moment it may be moot, because I've realized that validate_index
> doesn't work anyway. It is scanning the index and then assuming that
> any tuple inserted into the index subsequent to that scan will still be
> INSERT_IN_PROGRESS when the heapscan r
Oops. Fixed.
Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
Fixed in 8.1 and HEAD. Thank you
This appears to have created a regression test failure:
*** ./expected/tsearch2.out Sun Jun 18 12:55:28 2006
--- ./results/tsearch2.out Thu Aug 24 14:30:02 2006
***
**
Jeff Davis wrote:
Which doesn't work very well in the case of two groups of servers set up
in two physical locations. I can see two possibilities:
(1) You require a quorum to be effective, in which case your cluster of
databases is only as reliable as the location which holds more servers.
(2) Yo
Summarizing this thread, I see support for the following:
- autovacuum set to on by default in 8.2.
- stats_row_level also defaults to on.
(Perhaps stats_block_level should also default to on so it's not inconsistent,
seeing that everything else in on, too.)
- Delayed vacuum and delayed autova
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
>> Hmmm. Or is that true. The problem may be somewhat easier since at least you
>> can be sure every tuple in the heap is in the index. So if you see a
>> DELETE_IN_PROGRESS either it *was* a constraint violation prior t
Hello!
I’m installing postgresql in a O.S. Linux Ubuntu
6.06 and I have the next printout at installation process:
Setting up postgresql-7.4
(7.4.12-3) ...
Error: cluster configuration
already exists
I can’t find information about how I can solv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> Does anyone know what is supposed to go into the interval_type field?
> INTERVAL_TYPE IN
> ( 'YEAR', 'MONTH', 'DAY', 'HOUR', 'MINUTE', 'SECOND',
> 'YEAR TO MONTH', 'DAY TO HOUR', 'DAY TO MINUTE',
> 'DAY TO SECOND', 'HOUR TO MINUTE',
> 'HOUR
Am Mittwoch, 23. August 2006 19:04 schrieb Miguel Pedreño Saura:
> Setting up postgresql-7.4 (7.4.12-3) ...
> Error: cluster configuration already exists
Report this issue to the Ubuntu packager.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of bro
Hi there,
I guess many - if not most - here have tried
pgcluster. For those who didn't, postgresql is pretty
much the equivalent of pgcluster configured without
load balancer or replicator, in read-write standalone
mode. From a user point of view, that's three maximum
additional configuration file
Gregory Stark <[EMAIL PROTECTED]> writes:
> Because of the way the AM API works changing how the initial heap scan works
> is a bit of a pain. It would require either having some global state or
> passing the concurrent flag through the AM methods or alternatively having a
> whole new AM method.
Y
=?iso-8859-2?Q?B=F6sz=F6rm=E9nyi_Zolt=E1n?= <[EMAIL PROTECTED]> writes:
> With PostgreSQL 8.1.4, I used this:
> begin;
> select ... into temp myquery1;
> copy myquery1 to stdout csv delimiter '|';
> rollback;
The performance of this would doubtless vary a lot with the temp_buffers
setting. Did y
Do we want something like this? I just made this error myself so unless I'm
special (pauses for jokes) I imagine others would be prone to it as well.
I would normally be pretty leery of code like this but it seems unlikely
anyone would actually want an index named "concurrently" and the consequen
We've seen more than one report of corruption of PG databases that
seemed to be due to the willingness of the RPM init script to run
initdb if it thinks the data directory isn't there. This is pretty
darn risky on an NFS volume, for instance, which might be offline
at the instant the script looks.
Gregory Stark wrote:
Do we want something like this? I just made this error myself so unless I'm
special (pauses for jokes) I imagine others would be prone to it as well.
I would normally be pretty leery of code like this but it seems unlikely
anyone would actually want an index named "concurren
Am Freitag, 25. August 2006 15:19 schrieb Tom Lane:
> I don't really want to remove the auto-initdb feature from the script,
> because it's important not to drive away newbies by making Postgres
> hard to start for the first time. But I think we'd better think about
> ways to make it more bulletpr
> Böszörményi Zoltán <[EMAIL PROTECTED]> writes:
>> With PostgreSQL 8.1.4, I used this:
>
>> begin;
>> select ... into temp myquery1;
>> copy myquery1 to stdout csv delimiter '|';
>> rollback;
>
> The performance of this would doubtless vary a lot with the temp_buffers
> setting. Did you try diffe
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I see we have:
> CREATE index_opt_unique INDEX CONCURRENTLY index_name ...
> which explains how this error occurs.
Maybe to you, but I'm still caffeine-deprived and don't exactly see what
it was that Greg mistyped. AFAICS he'd have to type CONCURRENTL
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I see we have:
CREATE index_opt_unique INDEX CONCURRENTLY index_name ...
which explains how this error occurs.
Maybe to you, but I'm still caffeine-deprived and don't exactly see what
it was that Greg mistyped. AFAICS he'd ha
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> I see we have:
>> CREATE index_opt_unique INDEX CONCURRENTLY index_name ...
>> which explains how this error occurs.
>
> Maybe to you, but I'm still caffeine-deprived and don't exactly see what
> it was that Greg mistyped. AFAICS he
> I don't really want to remove the auto-initdb feature from the
> script, because it's important not to drive away newbies by making
> Postgres hard to start for the first time. But I think we'd better
> think about ways to make it more bulletproof.
Why does initdb have to happen on startup? Wou
> It'd also be interesting to time the same way (with a temp table) in
> devel. I don't remember whether we did any performance work on the
> COPY CSV data path in this cycle, or whether that was all present in
> 8.1. In any case it'd be worth proving that the COPY SELECT patch isn't
> degrading
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> I don't really want to remove the auto-initdb feature from the
>> script, because it's important not to drive away newbies by making
>> Postgres hard to start for the first time. But I think we'd better
>> think about ways to make it more bulletproo
Tom Lane wrote:
We've seen more than one report of corruption of PG databases that
seemed to be due to the willingness of the RPM init script to run
initdb if it thinks the data directory isn't there. This is pretty
darn risky on an NFS volume, for instance, which might be offline
at the instant
Hi,
> If this were a bulletproof solution then I'd consider it anyway, but
> AFAICS it's got the very same vulnerabilities as the flag-file method,
> ie, if you RPM install or upgrade while your mountable data directory
> is offline, you can still get screwed.
Isn't the most bulletproof solution
Sander Steffann wrote:
Hi,
If this were a bulletproof solution then I'd consider it anyway, but
AFAICS it's got the very same vulnerabilities as the flag-file method,
ie, if you RPM install or upgrade while your mountable data directory
is offline, you can still get screwed.
Isn't th
On Fri, 25 Aug 2006 at 10:20, Tom Lane wrote:
> If this were a bulletproof solution then I'd consider it anyway, but
> AFAICS it's got the very same vulnerabilities as the flag-file
> method, ie, if you RPM install or upgrade while your mountable data
> directory is offline, you can still get s
Am Freitag, 25. August 2006 16:20 schrieb Tom Lane:
> It eats rather a lot of disk space for a package that might just be
> getting loaded as part of a system install, with no likelihood of
> actually being used.
Wouldn't the system install start the init script at the end of the
installation pro
Am Freitag, 25. August 2006 16:31 schrieb Reinhard Max:
> But shouldn't mountpoints always have 000 permissions to prevent
> writing into the directory as long as nothing is mounted to it?
That's an interesting point, but in practice nobody does that. And we're
trying to defend exactly against t
Reinhard Max writes:
> Another flaw of the flag-file method is, that PGDATA might have been
> changed by the sysadmin between installing the RPM and calling the
> init script for the first time.
What problem do you see there? With either of these methods, a manual
change in PGDATA would requir
Tom Lane <[EMAIL PROTECTED]> writes:
> Comments? Anyone see a better way?
Well the truly bullet-proof mechanism would be to check every data file on
every open. You could have a header with some kind of unique tag generated at
initdb time and the backend could ensure it matches the same tag in
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 25. August 2006 16:20 schrieb Tom Lane:
>> It eats rather a lot of disk space for a package that might just be
>> getting loaded as part of a system install, with no likelihood of
>> actually being used.
> Wouldn't the system install start
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > I see we have:
> > CREATE index_opt_unique INDEX CONCURRENTLY index_name ...
> > which explains how this error occurs.
>
> Maybe to you, but I'm still caffeine-deprived and don't exactly see what
> it was that Greg mistyped. AFAICS
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The original thinking was to use CONCURRENT, and CREATE CONCURRENT INDEX
> sounded like a different type of index, not a different way to build the
> index. I don't think CONCURRENTLY has that problem, so CREATE
> CONCURRENTLY INDEX sounds good. To read
On 8/21/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On Mon, 2006-08-21 at 19:27 +0300, Martin Atukunda wrote:
> >> If readline is used by psql, a history file is automatically used.
> >> This patch adds the special file name 'none', w
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The original thinking was to use CONCURRENT, and CREATE CONCURRENT INDEX
> sounded like a different type of index, not a different way to build the
> index. I don't think CONCURRENTLY has that problem, so CREATE
> CONCURRENTLY INDEX sounds good. To rea
Am Donnerstag, 24. August 2006 00:52 schrieb Tom Lane:
> A possible solution therefore is to have psql or libpq drive the
> client_encoding off the client's locale environment instead of letting
> it default to equal the server_encoding.
I got started on this and just wanted to post an intermediat
Gregory Stark wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > The original thinking was to use CONCURRENT, and CREATE CONCURRENT INDEX
> > sounded like a different type of index, not a different way to build the
> > index. I don't think CONCURRENTLY has that problem, so CREATE
> > CONCUR
Merhaba,
On Fri, Aug 25, 2006 at 10:30:56AM -0400, Andrew Dunstan wrote:
> It is extremely careful. The point is that the NFS mount will hide the
> existing datadir from initdb.
Am I the only one who believes that PostgreSQL project is not supposed
to fix (or include workarounds for) some other
Am Freitag, 25. August 2006 17:17 schrieb Enver ALTIN:
> Am I the only one who believes that PostgreSQL project is not supposed
> to fix (or include workarounds for) some other systems that actually
> don't work very well?
Yes.
> If NFS is causing trouble, let it be.
NFS is not the trouble.
--
Am Freitag, 25. August 2006 16:54 schrieb Tom Lane:
> No, it doesn't. (The Red Hat RPMs in fact did that ... for about
> a week ... until I was told in no uncertain terms that we don't
> start unnecessary daemons by default.)
Well, there seem to be philosophical differences between the various op
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What bothers me about what we have now is that we have optional keywords
> before and after INDEX, rather than only between CREATE and INDEX.
Yeah, putting them both into that space seems consistent to me, and
it will fix the problem of making an omitted
Am Freitag, 25. August 2006 17:03 schrieb Martin Atukunda:
> hmm, setting HISTFILE to /dev/null doesn't work on my MacOSX here.
Please elaborate on "doesn't work".
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)-
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What bothers me about what we have now is that we have optional keywords
> > before and after INDEX, rather than only between CREATE and INDEX.
>
> Yeah, putting them both into that space seems consistent to me, and
> it will fix the
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The problem is that what the qualifier is doing is modifying the
> operation itself, not the properties of the index to be created, like
> UNIQUE, which modifies the index.
Right, which was the same point Bruce made earlier. And really you
can't respec
On Fri, Aug 25, 2006 at 05:07:03PM +0200, Peter Eisentraut wrote:
> I got started on this and just wanted to post an intermediate patch. I have
> taken the logic from initdb and placed it into libpq and refined the API a
> bit. At this point, there should be no behaviorial change. It remains t
Peter Eisentraut wrote:
Summarizing this thread, I see support for the following:
- autovacuum set to on by default in 8.2.
Yes.
- stats_row_level also defaults to on.
Yes.
(Perhaps stats_block_level should also default to on so it's not inconsistent,
seeing that everything else in on, t
Am Freitag, 25. August 2006 17:32 schrieb Matthew T. O'Connor:
> While there is talk of removing this all together, I think it was also
> agreed that as long as these values are there, they should be reduced.
> I think the defaults in 8.1 are 1000/500, I think 200/100 was suggested.
I'm thinking l
Gregory Stark wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
The original thinking was to use CONCURRENT, and CREATE CONCURRENT INDEX
sounded like a different type of index, not a different way to build the
index. I don't think CONCURRENTLY has that problem, so CREATE
CONCURRENTLY INDEX s
Am Freitag, 25. August 2006 17:30 schrieb Martijn van Oosterhout:
> Umm, why export all these functions. For starters, does this even need
> to be in libpq?
Where else would you put it?
> In fact, the only thing you need is PQsetClientEncodingFromLocale(),
> anything else is just sugar. Why would
On Fri, Aug 25, 2006 at 05:38:20PM +0200, Peter Eisentraut wrote:
> > In fact, the only thing you need is PQsetClientEncodingFromLocale(),
> > anything else is just sugar. Why would the user care about what the OS
> > calls it? We have a "pg_enc" enum, so lets use it.
>
> initdb has different requ
"Matthew T. O'Connor" writes:
> Peter Eisentraut wrote:
>> - Leave base thresholds alone (pending further analysis that might remove
>> them
>> altogether?)
> While there is talk of removing this all together, I think it was also
> agreed that as long as these values are there, they should be
On 8/25/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
Am Freitag, 25. August 2006 17:03 schrieb Martin Atukunda:
> hmm, setting HISTFILE to /dev/null doesn't work on my MacOSX here.
Please elaborate on "doesn't work".
without any .psqlrc file I get the following error when quitting a psql s
Tom Lane wrote:
"Matthew T. O'Connor" writes:
While there is talk of removing this all together, I think it was also
agreed that as long as these values are there, they should be reduced.
I think the defaults in 8.1 are 1000/500, I think 200/100 was suggested.
ISTM that if we don't w
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 25. August 2006 17:30 schrieb Martijn van Oosterhout:
>> Umm, why export all these functions. For starters, does this even need
>> to be in libpq?
> Where else would you put it?
> ...
> initdb has different requirements. Let me know if yo
Tom Lane wrote:
> "Matthew T. O'Connor" writes:
> > Peter Eisentraut wrote:
> >> - Leave base thresholds alone (pending further analysis that might remove
> >> them
> >> altogether?)
>
> > While there is talk of removing this all together, I think it was also
> > agreed that as long as these v
"Martin Atukunda" <[EMAIL PROTECTED]> writes:
> On 8/25/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
>> Please elaborate on "doesn't work".
> without any .psqlrc file I get the following error when quitting a psql
> session:
> could not save history to file "/Users/matlads/.psql_history": Inva
On Fri, 2006-08-25 at 11:23 +0200, Markus Schiltknecht wrote:
> Jeff Davis wrote:
> > Which doesn't work very well in the case of two groups of servers set up
> > in two physical locations. I can see two possibilities:
> > (1) You require a quorum to be effective, in which case your cluster of
> >
On 8/25/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> When I set HISTFILE to /dev/null I get the following:
> could not save history to file "/dev/null": Operation not permitted
Hm. ktrace shows this happening:
23279 psql CALL open(0x302d70,0x601,0x1b6)
23279 psql NAMI "/dev/null"
232
>
> Am Freitag, 25. August 2006 16:31 schrieb Reinhard Max:
> > But shouldn't mountpoints always have 000 permissions to prevent
> > writing into the directory as long as nothing is mounted to it?
>
> That's an interesting point, but in practice nobody does
> that. And we're
> trying to defend
> > What bothers me about what we have now is that we have optional
> > keywords before and after INDEX, rather than only between
> CREATE and INDEX.
>
> Yeah, putting them both into that space seems consistent to
> me, and it will fix the problem of making an omitted index
> name look like a
Hi,
Böszörményi Zoltán írta:
Böszörményi Zoltán <[EMAIL PROTECTED]> writes:
With PostgreSQL 8.1.4, I used this:
begin;
select ... into temp myquery1;
copy myquery1 to stdout csv delimiter '|';
rollback;
The performance of this would doubtless vary a lot with the temp_buffer
Zeugswetter Andreas DCP SD wrote:
>
> > > What bothers me about what we have now is that we have optional
> > > keywords before and after INDEX, rather than only between
> > CREATE and INDEX.
> >
> > Yeah, putting them both into that space seems consistent to
> > me, and it will fix the proble
"Martin Atukunda" <[EMAIL PROTECTED]> writes:
> On 8/25/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> There's probably no way to get Apple's libedit to not try the fchmod,
>> so what do we want to do here? Maybe special-case the string
>> "/dev/null"?
> If this is OK, I can up with a patch that spec
"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
> precedent syntax (Oracle, Informix) uses the keyword ONLINE at the end:
> CREATE INDEX blabla_x0 ON blabla (a,b) ONLINE;
We rejected that one already ...
regards, tom lane
---(end of broad
> > precedent syntax (Oracle, Informix) uses the keyword ONLINE
> at the end:
> > CREATE INDEX blabla_x0 ON blabla (a,b) ONLINE;
>
> That was what the patch originally used, but it was changed
> because it made difficult for psql to auto-complete that.
That is imho not enough of a reason to d
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> That was what the patch originally used, but it was changed because it
> made difficult for psql to auto-complete that.
Psql has to be able to parse it not for auto-completion but because it needs
to know that it's not a transactional command. The regu
"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
>> That was what the patch originally used, but it was changed
>> because it made difficult for psql to auto-complete that.
> That is imho not enough of a reason to divert.
My recollection is that the principal argument against ONLINE was
On 8/25/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Martin Atukunda" <[EMAIL PROTECTED]> writes:
> On 8/25/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> There's probably no way to get Apple's libedit to not try the fchmod,
>> so what do we want to do here? Maybe special-case the string
>> "/dev/null"?
Tom Lane wrote:
> Um, but initdb doesn't use libpq, so it's going to need its own copy
> anyway.
initdb certainly links against libpq.
> I agree with Martijn that putting these into libpq's API
> seems like useless clutter.
Where else to put it? We need it in libpq anyway if we want this
beha
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I agree with Martijn that putting these into libpq's API
>> seems like useless clutter.
> Where else to put it? We need it in libpq anyway if we want this
> behavior in all client applications (by default).
Having the code in li
On Fri, Aug 25, 2006 at 08:13:39PM +0200, Peter Eisentraut wrote:
> > I agree with Martijn that putting these into libpq's API
> > seems like useless clutter.
>
> Where else to put it? We need it in libpq anyway if we want this
> behavior in all client applications (by default).
Is that so? I
Martijn van Oosterhout writes:
> And as a counter-example: pg_dump should absolutly not use the client
> locale, it should always dump as the same encoding as the server...
Sure, but pg_dump should set that explicitly. I'm prepared to believe
that looking at the locale is sane for all normal cli
Tom Lane wrote:
> Martijn van Oosterhout writes:
> > And as a counter-example: pg_dump should absolutly not use the client
> > locale, it should always dump as the same encoding as the server...
>
> Sure, but pg_dump should set that explicitly. I'm prepared to believe
> that looking at the local
Here is an new XML section for our SGML documentation. It explains the
various XML capabilities, if we support them, and how to use them.
Comments?
---
XML Document Support
XML support is not one capab
On Fri, Aug 25, 2006 at 07:46:57PM -0400, Bruce Momjian wrote:
> Here is an new XML section for our SGML documentation. It explains
> the various XML capabilities, if we support them, and how to use
> them.
>
> Comments?
This looks hauntingly similar to Peter's presentation at the
conference. :)
David Fetter wrote:
> On Fri, Aug 25, 2006 at 07:46:57PM -0400, Bruce Momjian wrote:
> > Here is an new XML section for our SGML documentation. It explains
> > the various XML capabilities, if we support them, and how to use
> > them.
> >
> > Comments?
>
> This looks hauntingly similar to Peter
On Fri, Aug 25, 2006 at 12:16:33PM -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > "Matthew T. O'Connor" writes:
> > > Peter Eisentraut wrote:
> > >> - Leave base thresholds alone (pending further analysis that might
> > >> remove them
> > >> altogether?)
> >
> > > While there is talk of rem
On Sun, Aug 20, 2006 at 12:58:31PM -0400, Gene wrote:
> Keep in mind if you have multiple rules for a master table, it won't return
> the number of affected rows as you might expect. This screws up Hibernate
> which I'm using for my application. It checks the return value to make sure
> it was inse
On Fri, Aug 25, 2006 at 06:57:58PM +0100, Gregory Stark wrote:
> I'll use this opportunity to plug that feature again. I think most people
> should use autocommit off with on_error_rollack on for most of their daily
> use. Being able to double check the results of my ad-hoc updates before
> committ
On Fri, Aug 25, 2006 at 11:25:43AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The problem is that what the qualifier is doing is modifying the
> > operation itself, not the properties of the index to be created, like
> > UNIQUE, which modifies the index.
>
> Right, whi
Euler Taveira de Oliveira wrote:
> Bruce Momjian wrote:
>
> > Here is an new XML section for our SGML documentation. It explains the
> > various XML capabilities, if we support them, and how to use them.
> >
> > Comments?
> >
> +1. Users often ask this in the mailing lists. Where are you want t
On Fri, Aug 25, 2006 at 05:40:09AM -0700, Chahine Hamila wrote:
> Hi there,
>
> I guess many - if not most - here have tried
> pgcluster. For those who didn't, postgresql is pretty
I think you need to guess again. :)
> much the equivalent of pgcluster configured without
> load balancer or replic
Bruce Momjian wrote:
> Here is an new XML section for our SGML documentation. It explains the
> various XML capabilities, if we support them, and how to use them.
>
> Comments?
>
+1. Users often ask this in the mailing lists. Where are you want to
put this? I'll suggest: FAQ. What do you all th
Is this being kept for 8.3?
---
Tom Lane wrote:
> A couple months ago we were discussing partitioning the buffer mapping
> table so as to reduce contention for the BufMappingLock. The discussion
> stalled after I complained
Has this been addressed?
---
Joe Conway wrote:
> Tom Lane wrote:
> > The reason we could safely list_free inside transformInsertRow is that
> > we know all its callers have just built the passed-in list and so there
> > are
Michael Fuhr wrote:
> In README.pgcrypto, Section 2.3 "Deprecated functions" says that
> digest_exists(), hmac_exists(), and cipher_exists() are planned to
> be removed in PostgreSQL 8.2. Those functions still exist -- should
> they be removed or does that section need updating?
Yes, I see this t
Is there anything to do for 8.2 here?
---
ITAGAKI Takahiro wrote:
> This is an additional information.
>
> I wrote:
> > If we want to resolve the probmen fundamentally, we might have to
> > improve SubTrans using a better b
I am still waiting for an actual patch to the developer's FAQ for this.
---
Gregory Stark wrote:
>
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>
> > I use more or less what is in the developers' FAQ (not surprising, since
> Indexing
>
> Because XML documents are stored as text, full-text indexing tool
> /contrib/tsearch2 can be used to index XML documents. Of
> course, the searches are text searches, with no XML
> awareness, but tsearch2 can be used with other XML
> capabilities to dramatically reduce t
Jim C. Nasby wrote:
> I thought we had agreed it would be a good idea to turn autovac_delay
> on?
We had not, because there was no experience available about where to put
the default numbers.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadc
Bruce Momjian wrote:
> XML Document Support
>
> XML support is not one capability, but a variety of features
> supported by a database.
database system
> Storage
> ---
> PostgreSQL stores XML documents as ordinary text documents.
It is "possible" to do that, but this sou
On 8/26/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
Bruce Momjian wrote:
> Validation
> --
> /contrib/xml2 has a function called xml_valid() that can be used in
> a CHECK constraint to enforce that a field contains valid XML. It
> does not support validation against a specific XML sc
95 matches
Mail list logo
