On Aug 2, 2006, at 12:47 , Joe Conway wrote:
regression=# create rule r2 as on update to src do insert into log
values(old.*, 'old'), (new.*, 'new');
ERROR: VALUES must not contain OLD or NEW references
Would it make sense to add a HINT as well, recommending the UNION
construct Tom mentio
pg_dump in HEAD is dumping the entire contents of system catalogs.
New feature? :-(
--
Michael Fuhr
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED]
Bruce Momjian wrote:
Should we wait for someone to actually ask for this before adding it
to the TODO list?
Probably worth adding it to the TODO list so it doen't get lost.
Does it cause a crash now?
Nope:
regression=# create table log(f1 int, f2 int, tag text);
CREATE TABLE
regression=# i
Martijn van Oosterhout writes:
>
> No kidding, it's quite a mess and really needs to be cleaned up. About
> the only thing we could do would be to merge the productions for types
> and functions. Or at least, make the productions look similar enough
> that bison can avoid deciding which it is un
Should we wait for someone to actually ask for this before adding it to
the TODO list? Does it cause a crash now?
---
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> What I'm inclined to do
I was thinking of something similar to our encryption section:
http://www.postgresql.org/docs/8.1/static/encryption-options.html
The idea being to define issues like multi/single master, async vs,
sync, and mention the projects which are in each category.
---
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What I'm inclined to do for 8.2 is to disallow OLD/NEW references in
>> multi-element VALUES clauses; the feature is still tremendously useful
>> without that.
> Given the timing, this sounds like a reasonable approach. I agree that
> th
Alvaro Herrera wrote:
> > >I don't think this sort of material belongs directly into the
> > > PostgreSQL documentation.
>
> Why not?
PostgreSQL documentation (or any product documentation) should be
factual: describe what the software does and give advice on its use.
This should be mostly inde
> > For db restoration (pg_dump), how do you restore to the same values as
> > previously if it is always regenerated? By making ALWAYS a suggestion
> > for some users instead of always enforced and providing an override
> > mechanism for it. I assume it only works for relation owners but I've
> >
Joshua D. Drake wrote:
> Alvaro Herrera wrote:
> >Joshua D. Drake wrote:
> >
> >>>I don't think this sort of material belongs directly into the PostgreSQL
> >>>documentation.
> >
> >Why not?
>
> Well Peter said that, not me :)
I know, but I though I'd post one message instead of two. (In fact I
Alvaro Herrera wrote:
Joshua D. Drake wrote:
I don't think this sort of material belongs directly into the PostgreSQL
documentation.
Why not?
Well Peter said that, not me :)
It might be interesting to have some links in the external projects area
for replication, but a section of its ow
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Greg Stark
> Sent: Tuesday, August 01, 2006 4:42 PM
> To: Hannu Krosing
> Cc: Andrew Dunstan; Gregory Stark; Tom Lane; Alvaro Herrera; Jim C. Nasby;
> Luke Lonergan; [EMAIL PROTECTED]; Bru
Joshua D. Drake wrote:
> >I don't think this sort of material belongs directly into the PostgreSQL
> >documentation.
Why not?
> It might be interesting to have some links in the external projects area
> for replication, but a section of its own doesn't seem relevant.
I disagree about "having
1. post information on pgsql-general
1.a. solicit comments
2. put information page on web site
3. link from documentation to web site
You seem to have short-circuited all that.
I don't think this sort of material belongs directly into the PostgreSQL
documentation.
It might be interesting to
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, T, 2006-08-01 kell 10:54, kirjutas Andrew Dunstan:
> > Gregory Stark wrote:
> > >
> > > I looked a while back and was suspicious about the actual hash functions
> > > too.
> > > It seemed like a lot of them were vastly suboptimal.
Chris Browne wrote:
> Here's a patch to add in the material on replication recently
> discussed on pgsql.docs. I'm not thrilled that there were only a few
> comments made; I'd be happy to see "slicing and dicing" to see this
> made more useful.
The agreed-to process was
1. post information on pg
Rod Taylor írta:
On Tue, 2006-08-01 at 18:10 +0200, Zoltan Boszormenyi wrote:
Hi,
I have progressed a bit with my pet project, a.k.a $SUBJECT.
Now GENERATED ALWAYS AS IDENTITY and
GENERATED ALWAYS AS ( expr ) work as
intended. Documentation was also extended.
I'm only commenting beca
Thanks for mentioning about pgpool!
> pgpool
>
> pgpool was initially created by
> Tatsuo Isshii as a portable alternative to Java connection pool
> modules. He subsequently observed that it wouldn't take very much
> effort to extend it to create a simple replication sy
On Tue, 2006-08-01 at 18:10 +0200, Zoltan Boszormenyi wrote:
> Hi,
>
> I have progressed a bit with my pet project, a.k.a $SUBJECT.
>
> Now GENERATED ALWAYS AS IDENTITY and
> GENERATED ALWAYS AS ( expr ) work as
> intended. Documentation was also extended.
I'm only commenting because I debated t
Ühel kenal päeval, T, 2006-08-01 kell 10:54, kirjutas Andrew Dunstan:
> Gregory Stark wrote:
> >
> > I looked a while back and was suspicious about the actual hash functions
> > too.
> > It seemed like a lot of them were vastly suboptimal. That would mean we're
> > often dealing with mostly empty
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Does it work if you do
> regression=# create rule r2 as on update to src do
> regression-# insert into log values(old.f1, old.f2, 'old'), (new.f1, new.f2,
> 'new');
No, that's not the problem. "*" expansion works just fine here, it's
the executor tha
Tom Lane wrote:
What I'm inclined to do for 8.2 is to disallow OLD/NEW references in
multi-element VALUES clauses; the feature is still tremendously useful
without that.
Given the timing, this sounds like a reasonable approach. I agree that
the feature has lots of interesting uses -- I'd hate
Tom Lane wrote:
> I've found a problem with the VALUES-as-RTE approach:
>
> regression=# create table src(f1 int, f2 int);
> CREATE TABLE
> regression=# create table log(f1 int, f2 int, tag text);
> CREATE TABLE
> regression=# insert into src values(1,2);
> INSERT 0 1
> regression=# create rule r2
I've found a problem with the VALUES-as-RTE approach:
regression=# create table src(f1 int, f2 int);
CREATE TABLE
regression=# create table log(f1 int, f2 int, tag text);
CREATE TABLE
regression=# insert into src values(1,2);
INSERT 0 1
regression=# create rule r2 as on update to src do
regression
Patch applied. Thanks.
---
Martin Pitt wrote:
-- Start of PGP signed section.
> Hi PostgreSQL developers,
>
> some time ago I started a discussion [1] here about modifying pg_dump
> to not restore TABLE DATA objects if th
On Tue, Aug 01, 2006 at 12:37:48PM -0500, Jim C. Nasby wrote:
> On Sun, Jul 30, 2006 at 11:27:33AM -0400, Tom Lane wrote:
> > David Fetter <[EMAIL PROTECTED]> writes:
> > > On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote:
> > >> The correct solution is for client-side libraries to provide
On Sun, Jul 30, 2006 at 11:27:33AM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote:
> >> The correct solution is for client-side libraries to provide the
> >> feature.
>
> > Not if the app is written in SQL, as the boot
Zoltan Boszormenyi wrote:
> BTW, is there anyone working on COPY FROM ( select ) feature?
I am, but it's in a too early stage to be in 8.2. Sorry :-(
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
On Tue, Aug 01, 2006 at 10:54:10AM -0400, Andrew Dunstan wrote:
> This is now sounding like a lot of low hanging fruit ... highly
> performant hash indexed tables could possibly be a very big win.
So does someone want to 'take up the cause' for them?
--
Jim C. Nasby, Sr. Engineering Consultant
Hi,
I have progressed a bit with my pet project, a.k.a $SUBJECT.
Now GENERATED ALWAYS AS IDENTITY and
GENERATED ALWAYS AS ( expr ) work as
intended. Documentation was also extended.
Some test cases are also included, that shows
that ALTER TABLE ALTER TYPE keeps both
the sequence and the GENERATE
On Tue, 2006-08-01 at 07:55 -0700, Luke Lonergan wrote:
> WRT hashing - we use FNV hash which is a very nice, very fast modern hash
> algorithm. We would contribute that if we worked on this.
We currently use Bob Jenkins' hash function[1], which is apparently
faster than FNV on most architectures
moises wrote:
Hello,
Maybe this question is not logic, but for me is very important.
I was tested some temporary tables and, of course are very fast,
because they are in memory.
But one table created by one connection, can´t be modified by others
connections?
I want to know if exist s
moises wrote:
> I want to know if exist some way to shared a temporary table between
> 2 connections.
No.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send a
Hello,
Maybe this question is not logic, but for me is very
important.
I was tested some temporary tables and, of course are
very fast, because they are in memory.
But one table created by one connection, can´t be
modified by others connections?
I want to know if exist some way to sh
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Would this do the trick?
I think Bruce changed the call convention for run_diff ... are you
looking at CVS tip? Otherwise it looks reasonable.
You're right. I had forgotten to do a cvs update. Fixed and committed.
cheer
Jim,
On 7/28/06 12:27 PM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> In that case, perhaps this is something Greenplum might be interested
> in, since it might fit nicely between bitmap and btree indexes.
I'm certainly following the thread.
We have talked about hash and btree organized tables
Gregory Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
I think the problem may well be that we use hash buckets that are too
large (ie, whole pages). After we fetch the page, we have to grovel
through every tuple on it to find the one(s) that really match the
query, whereas btree has a m
On Tue, Aug 01, 2006 at 06:47:31PM +0400, Teodor Sigaev wrote:
> >Not really, but that's another thing that seems unreasonably hard to
> >fix.
> >
> Sorry, but more problem:
No kidding, it's quite a mess and really needs to be cleaned up. About
the only thing we could do would be to merge the pr
Not really, but that's another thing that seems unreasonably hard to
fix.
Sorry, but more problem:
1)
postgres=# select 'as'::pg_catalog.char, 'as'::char, 'as'::char(2);
char | bpchar | bpchar
--++
a| a | as
(1 row)
postgres=# select 'as'::pg_catalog.char(2);
ERR
Tom Lane <[EMAIL PROTECTED]> writes:
> I think the problem may well be that we use hash buckets that are too
> large (ie, whole pages). After we fetch the page, we have to grovel
> through every tuple on it to find the one(s) that really match the
> query, whereas btree has a much more intellige
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Would this do the trick?
I think Bruce changed the call convention for run_diff ... are you
looking at CVS tip? Otherwise it looks reasonable.
regards, tom lane
---(end of broadcast)
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
One other thought I had was that we could have
pg_regress always allow a fallback to the canonical result file.
Hm, that's a good thought. Want to see how painful it is to code?
Would this do the trick?
cheers
andrew
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> postgres=# select text[] '{asd}';
> ERROR: syntax error at or near "]"
> LINE 1: select text[] '{asd}';
> Is it desired effect?
Not really, but that's another thing that seems unreasonably hard to
fix.
regards, tom lane
--
char(42) 'literal value here'
Playing around that I noticed:
postgres=# select '{asd}'::text[], '{asd}'::_text, _text '{asd}';
text | _text | _text
---+---+---
{asd} | {asd} | {asd}
(1 row)
postgres=# select text[] '{asd}';
ERROR: syntax error at or near "]"
LINE 1: se
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Andrew Dunstan wrote:
>
> > > It's not particularly clear to me. On its face this seems to me to imply
> > > something about how the index will be able to be used, not about how it
> > > is to be built.
> >
> > Yea, that was always a confusion.
Bruce Momjian wrote:
> Andrew Dunstan wrote:
> > It's not particularly clear to me. On its face this seems to me to imply
> > something about how the index will be able to be used, not about how it
> > is to be built.
>
> Yea, that was always a confusion. CREATE CONCURRENT INDEX has the same
>
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I thought about that too but it seems a very bad idea. small-is-zero is
>> distinctly "less correct" than the regular output, and I don't think we
>> want pg_regress to be blindly accepting it as OK on any platform.
> Yes, good point
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Maybe we need to abandon trying to map float8 results exactly in the
resultmap file, and just let pg_regress pick the best fit as we do with
some other tests.
I thought about that too but it seems a very bad idea. small-is-ze
On 01/08/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Maybe we need to abandon trying to map float8 results exactly in the
> resultmap file, and just let pg_regress pick the best fit as we do with
> some other tests.
I thought about that too but it seems a
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > CREATE [ UNIQUE ] INDEX name ON table
> > [ USING method ] [ [ENABLE] WRITE [ACCESS] ]
> > ( { column | ( expression ) } [ opclass ] [, ...] )
> > [ WITH ( storage_parameter = value [, ... ] ) ]
> >
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Maybe we need to abandon trying to map float8 results exactly in the
> resultmap file, and just let pg_regress pick the best fit as we do with
> some other tests.
I thought about that too but it seems a very bad idea. small-is-zero is
distinctly "les
Bruce Momjian <[EMAIL PROTECTED]> writes:
> CREATE [ UNIQUE ] INDEX name ON table
> [ USING method ] [ [ENABLE] WRITE [ACCESS] ]
> ( { column | ( expression ) } [ opclass ] [, ...] )
> [ WITH ( storage_parameter = value [, ... ] ) ]
> [ TABLESPACE tab
[ re cassowary buildfarm failure ]
"Adrian Maier" <[EMAIL PROTECTED]> writes:
> On 20/07/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> As for the regression test failure, it's odd because it looks to me that
>> the actual test output is an exact match to the default "float8.out"
>> file. I'm not sur
On 01/08/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
Adrian Maier wrote:
> On 20/07/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Apparently the regression test is comparing the results/float8.out
> with expected/float8-small-is-zero.out because of the following line
> in
> src/test/regress/res
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> > Consindering the syntax for this, we currently allow read access during
> > index creation, just not write access, so I think the new syntax should
> > be:
> >
> > CREATE [ UNIQUE ] INDEX name ON table
> > [ USING method ] [ [ENABLE] WR
Bruce Momjian wrote:
Consindering the syntax for this, we currently allow read access during
index creation, just not write access, so I think the new syntax should
be:
CREATE [ UNIQUE ] INDEX name ON table
[ USING method ] [ [ENABLE] WRITE [ACCESS] ]
( { column | ( expressi
Adrian Maier wrote:
On 20/07/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Reini Urban <[EMAIL PROTECTED]> writes:
> BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is
defined also.
You sure? INT64_IS_BUSTED should *not* be set in that case --- it's
only supposed to be set if we couldn't
Albe Laurenz wrote:
> Tim Allen wrote:
> >>>Patch included to implement xlog switching, using an xlog record
> >>>"processing instruction" and forcibly moving xlog pointers.
> >>>
> >>>1. Happens automatically on pg_stop_backup()
> >>
> >>
> >> Oh - so it will not be possible to do an online back
Consindering the syntax for this, we currently allow read access during
index creation, just not write access, so I think the new syntax should
be:
CREATE [ UNIQUE ] INDEX name ON table
[ USING method ] [ [ENABLE] WRITE [ACCESS] ]
( { column | ( expression ) } [
On 20/07/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Reini Urban <[EMAIL PROTECTED]> writes:
> BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is defined also.
You sure? INT64_IS_BUSTED should *not* be set in that case --- it's
only supposed to be set if we couldn't find any 64-bit-int ty
Now that it is August 1, we are in feature freeze. During the next
month, all outstanding patches will be reviewed and hopefully applied.
After that, we will start preparing for beta, hopefully to start in
September or October.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.
Albe Laurenz wrote:
Tim Allen wrote:
Patch included to implement xlog switching, using an xlog record
"processing instruction" and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch
Tim Allen wrote:
>>>Patch included to implement xlog switching, using an xlog record
>>>"processing instruction" and forcibly moving xlog pointers.
>>>
>>>1. Happens automatically on pg_stop_backup()
>>
>>
>> Oh - so it will not be possible to do an online backup
>> _without_ forcing a WAL switch
Albe Laurenz wrote:
Simon Riggs wrote:
Patch included to implement xlog switching, using an xlog record
"processing instruction" and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL swi
Simon Riggs wrote:
> Patch included to implement xlog switching, using an xlog record
> "processing instruction" and forcibly moving xlog pointers.
>
> 1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch any more?
Lau
On Aug 1, 2006, at 16:15 , Harald Armin Massa wrote:
As accepting 2006-02-31 as a valid date would require brainwashing
at least the entire core team, we should find a "recommended path
of date migration from different universes".
Have you checked out the mysql2pgsql[1] or my2postgres proj
66 matches
Mail list logo
