Hi All,
I am now trying to implement pg_get_domaindef() function which is in the TODO
list and ran into a minor issue.
When the following command is given
CREATE DOMAIN testdomain AS text CONSTRAINT testconstraint NOT NULL;
I couldn't find the CONSTRAINT name ('testconstraint' in this case) be
Joshua D. Drake wrote:
Cesar Suga wrote:
Hi,
I also wrote Bruce about that.
It happens that, if you 'freely advertise' commercial solutions (rather
than they doing so by other vehicles) you will always happen to be an
'updater' to the docs if they change their product lines, if they change
Jim C. Nasby wrote:
> Something else worth doing though is to have a paragraph explaining why
> there's no built-in replication. I don't have time to write something
> right now, but I can do it later tonight if no one beats me to it.
I thought that was implied in the early paragraph about why the
I wrote:
> I've been analyzing Ed L's recent report of index corruption:
> http://archives.postgresql.org/pgsql-general/2006-10/msg01183.php
After some thought, it still seems to me to be impractical to delete the
rightmost child of a btree page while other children remain. Doing this
would requi
On Wed, Oct 25, 2006 at 04:42:17PM -0400, Bruce Momjian wrote:
> Dawid Kuroczko wrote:
> > Bruce, I've read Your documentation and I was left a bit with a feeling
> > that it's a bit too generic. It's almost as if it could be about just about
> > any major database, not PostgreSQL specific. I fee
FYI, I am leaving Friday for a two-week trip for EnterpriseDB. I am
going to Tokyo, Islamabad (Pakistan), and Pune (India). I return on
Friday, November 10. I will have Internet connectivity, but of course I
will not be online as frequently as usual.
--
Bruce Momjian [EMAIL PROTECTED]
En
James Robinson <[EMAIL PROTECTED]> writes:
> Seems that plpgsql in 8.2B1 thinks that selects of the form '
> and foo not in (select ... )' should be function calls, not
> subselects. These worked fine in 8.1.
Fixed, thanks. It's not actually plpgsql's fault ...
Josh Berkus wrote:
> Bruce,
>
> > Most people didn't want a list because there is no way to keep it
> > current in the docs, and a secondary web site was suggested for the
> > list.
>
> So, like www.postgresql.org/docs/techdocs/replication? That would work.
Yes.
--
Bruce Momjian [EMAIL P
Bruce,
> Most people didn't want a list because there is no way to keep it
> current in the docs, and a secondary web site was suggested for the
> list.
So, like www.postgresql.org/docs/techdocs/replication? That would work.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
-
Dawid Kuroczko wrote:
> Bruce, I've read Your documentation and I was left a bit with a feeling
> that it's a bit too generic. It's almost as if it could be about just about
> any major database, not PostgreSQL specific. I feel that, when I'm
> reading PostgreSQL docs I would like to know how to
Josh Berkus wrote:
> Bruce,
>
> > It isn't designed for that. It is designed for people to understand
> > what they want, and then they can look around for solutions. I think
> > most agree we don't want a list of solutions in the documentation,
> > though I have a few as examples.
>
> Do the
Bruce,
> It isn't designed for that. It is designed for people to understand
> what they want, and then they can look around for solutions. I think
> most agree we don't want a list of solutions in the documentation,
> though I have a few as examples.
Do they? I've seen no discussion of the
On 10/25/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> >>> I think this is a good reason not to list *any* of the products by name
> >>> in the documentation, but instead refer to
Josh Berkus wrote:
> Bruce,
>
> > > > ftp://momjian.us/pub/postgresql/mypatches/replication
>
> I'm still not seeing anything in this patch that tells users where they can
> get replication solutions for PostgreSQL, either OSS or commercial.
It isn't designed for that. It is designed f
Richard Troy wrote:
>
> > Here is a new replication documentation section I want to add for 8.2:
> >
> > ftp://momjian.us/pub/postgresql/mypatches/replication
> >
>
> ...Read the document, as promissed...
>
> First paragraph, "(fail over)" is inconsistent with title, "failover", as
> are oth
Bruce,
> > > ftp://momjian.us/pub/postgresql/mypatches/replication
I'm still not seeing anything in this patch that tells users where they can
get replication solutions for PostgreSQL, either OSS or commercial.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Alexey Klyukin wrote:
> Hi,
>
> A typo:
> ("a write to any server has to be _propogated_")
> s/propogated/propagated
Thanks, fixed.
---
>
> Bruce Momjian wrote:
> > Here is a new replication documentation section I want t
> Here is a new replication documentation section I want to add for 8.2:
>
> ftp://momjian.us/pub/postgresql/mypatches/replication
>
...Read the document, as promissed...
First paragraph, "(fail over)" is inconsistent with title, "failover", as
are other spots throughout the document. The wh
This is a server bug, I will post to hackers for you,
Please provide a complete test case. I tried to reproduce the failure
in libpq, with
tom, i've just noticed this is the exact same error message & errorcode as i
get when updating a table that contains a tsearch2 vector column
2006-10-2
Yes, the problem is gone in 8.2 beta2.
Thanks all for an outstanding product and support,
Jean-Pierre Pelletier
From: Tom Lane <[EMAIL PROTECTED]>
To: "JEAN-PIERRE PELLETIER" <[EMAIL PROTECTED]>
CC: pgsql-hackers@postgresql.org, [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [HACKERS] [JDBC
I've been analyzing Ed L's recent report of index corruption:
http://archives.postgresql.org/pgsql-general/2006-10/msg01183.php
(thanks to Ed for letting me have the actual index to study).
I think I've figured out what happened to it. nbtree/README says
: The notion of a half-dead page means tha
Totally agree. The docs will tend to outlive whatever projects or
websites they mention. Best to not bake that into stone.
-Casey
On Oct 25, 2006, at 3:36 AM, Magnus Hagander wrote:
I don't think the PostgreSQL documentation should be
mentioning commercial solutions.
I think maybe the Post
David Fetter wrote:
> On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote:
>
> > Can we name the chapter "Fail-over, Load-Balancing and Replication
> > Options"? That would fit everything and contain the necessary buzz words.
> ...
>
> > IMHO, it does not make sense to speak of a
Seems that plpgsql in 8.2B1 thinks that selects of the form '
and foo not in (select ... )' should be function calls, not
subselects. These worked fine in 8.1.
Here's a smallish script which reproduces the problem on 8.2RC1 / OSX:
If you comment out the 'and NEW.id not in (select t1_id
On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote:
> Can we name the chapter "Fail-over, Load-Balancing and Replication
> Options"? That would fit everything and contain the necessary buzz words.
...
> IMHO, it does not make sense to speak of a synchronous replication for a
>
Hi Hannu, everyone,
I apologize for not having read the document in question - will do
shortly. My comments are brought about by the dialogue I read on list this
morning...
> > Here is a new replication documentation section I want to add for 8.2:
> >
> > ftp://momjian.us/pub/postgresql/mypa
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> >>> I think this is a good reason not to list *any* of the products by name
> >>> in the documentation, but instead refer to a page on say techdocs that
> >>> can be more easily up
Bruce Momjian wrote:
> Tom Lane wrote:
>> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
>>> I think this is a good reason not to list *any* of the products by name
>>> in the documentation, but instead refer to a page on say techdocs that
>>> can be more easily updated.
>> I agree with that. If we
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > I think this is a good reason not to list *any* of the products by name
> > in the documentation, but instead refer to a page on say techdocs that
> > can be more easily updated.
>
> I agree with that. If we have statements about
Hi,
Jim C. Nasby wrote:
Those to statements are at odds with each other, at least based on
everyone I've ever talked to in a commercial setting. People will use
terms like 'replication', 'HA' or 'clustering' fairly interchangably.
Usually what these folks want is some kind of high-availability
s
Jim C. Nasby wrote:
> On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote:
> > I can't really get excited about the exclusion of the term
> > 'replication', because it's what most people are looking for. It's a
> > well known term. Sorry if it sounded that way, but I've not meant
Markus Schiltknecht wrote:
> Hi,
>
> Bruce Momjian wrote:
> > I have updated the text. Please let me know what else I should change.
> > I am unsure if I should be mentioning commercial PostgreSQL products in
> > our documentation.
>
> I support your POV and vote for not including any pointers
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> I think this is a good reason not to list *any* of the products by name
>> in the documentation, but instead refer to a page on say techdocs that
>> can be more easily updated.
>
> I agree with that. If we have statements about ot
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> I think this is a good reason not to list *any* of the products by name
> in the documentation, but instead refer to a page on say techdocs that
> can be more easily updated.
I agree with that. If we have statements about other projects in our
docs,
On Wed, Oct 25, 2006 at 09:24:16AM +0530, rajesh boppana wrote:
> i want to implement materialized views in postgresql . to do as i
> want to modify the code in backend but i don't know what r the files i have
> to modify. so please help me by mentioning about the backend code.
If you're g
>>> they change their business model, if and if.
>> That is no different than the open source offerings. We have
>> had several open source offerings that have died over the
>> years. Replicator, for example has always been Replicator and
>> has been around longer than any of the current replic
> > I also wrote Bruce about that.
> >
> > It happens that, if you 'freely advertise' commercial solutions
> > (rather than they doing so by other vehicles) you will
> always happen
> > to be an 'updater' to the docs if they change their product
> lines, if
> > they change their business mode
Bruce Momjian wrote:
> I would think that companies that sell closed-source solutions for
> PostgreSQL would be modest enough not to push their own agenda for the
> documentation. I think they should just sit back and hope others
> suggest it.
>
> [ Josh Berkus recently left Green Plum for Sun. ]
I have added this text:
Commercial Solutions
Because PostgreSQL is open source and easily extended, a number of
companies have taken PostgreSQL and created commercial closed-source
solutions with unique failover, replication, a
I would think that companies that sell closed-source solutions for
PostgreSQL would be modest enough not to push their own agenda for the
documentation. I think they should just sit back and hope others
suggest it.
[ Josh Berkus recently left Green Plum for Sun. ]
--
Cesar Suga wrote:
> Hi,
>
> I also wrote Bruce about that.
>
> It happens that, if you 'freely advertise' commercial solutions (rather
> than they doing so by other vehicles) you will always happen to be an
> 'updater' to the docs if they change their product lines, if they change
> their busines
Hi, Cesar,
Cesar Suga wrote:
> If people (who read the documentation) professionally work with
> PostgreSQL, they may already have been briefed by those commercial
> offerings in some way.
>
> I think only the source and its tightly coupled (read: can compile along
> with, free as PostgreSQL) com
"JEAN-PIERRE PELLETIER" <[EMAIL PROTECTED]> writes:
> 08:47:19.296 (1) FE=> Parse(stmt=null,query="select $1 from (select * from
> pg_database) t",oids={23})
Actually, now that I look closely, this command is almost certainly
triggering this beta1 bug:
http://archives.postgresql.org/pgsql-commit
>> A big part of the value of Postgresql is the applications and extensions
>> that support it. Hiding the existence of some subset of those just
>> because of the way they're licensed is both underselling postgresql
>> and doing something of a disservice to the user of the document.
>
> OK, does
>
> I am not inclined to add commercial offerings. If people wanted
> commercial database offerings, they can get them from companies that
> advertize. People are coming to PostgreSQL for open source solutions,
> and I think mentioning commercial ones doesn't make sense.
>
> If we are to add th
On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote:
> I can't really get excited about the exclusion of the term
> 'replication', because it's what most people are looking for. It's a
> well known term. Sorry if it sounded that way, but I've not meant to
> avoid that term.
> I
On Wed, Oct 25, 2006 at 08:22:25PM +0930, Shane Ambler wrote:
> Bruce Momjian wrote:
>
> >OK, does that mean we mention EnterpriseDB in the section about Oracle
> >functions? Why not mention MS SQL if they have a better solution? I
> >just don't see where that line can clearly be drawn on what t
Tom Lane ha scritto:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Limit (50)
Sort (key: pse_lastlogin)
Result
Append
Limit (50)
SeqScan tbl_profile_search
Limit (50)
Indexscan tbl_profile_search_interest_1
Limit (50)
Here is what I get with loglevel=2
08:47:18.718 (1) PostgreSQL 8.2devel JDBC3 with SSL (build 503)
08:47:18.718 (1) Trying to establish a protocol version 3 connection to
localhost:5432
08:47:18.859 (1) FE=> StartupPacket(user=postgres, database=main,
client_encoding=UNICODE, DateStyle=ISO)
0
Bruce Momjian wrote:
OK, does that mean we mention EnterpriseDB in the section about Oracle
functions? Why not mention MS SQL if they have a better solution? I
just don't see where that line can clearly be drawn on what to include.
Do we mention Netiza, which is loosely based on PostgreSQL?
> I don't think the PostgreSQL documentation should be
> mentioning commercial solutions.
I think maybe the PostgreSQL documentation should be careful about
trying to list a "complete list" of commercial *or* free solutions.
Instead linking to something on the main website or on techdocs that can
Hi,
Bruce Momjian wrote:
I have updated the text. Please let me know what else I should change.
I am unsure if I should be mentioning commercial PostgreSQL products in
our documentation.
I support your POV and vote for not including any pointers to commercial
extensions in the official docu
Ühel kenal päeval, T, 2006-10-24 kell 22:57, kirjutas Bruce Momjian:
> I don't think the PostgreSQL documentation should be mentioning
> commercial solutions.
IMNSHO, having commercial solutions based on postgresql which extend
postgres in directions not (yet?) done by core postgres is nothing to
Hi,
While we are at async i/o. I think direct i/o and concurrent i/o also deserve a look at. The archives suggest that Bruce had some misgivings about dio because of no kernel caching, but almost all databases seem to (carefully) use dio (Solaris, Linux, ?) and cio (AIX) extensively nowadays.
54 matches
Mail list logo
