Hi
One of reasons to get PL/proxy into core is to make it available to Windows
users also.
The idea is to get to the situation
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would like
to hear how.
Asko
On Fri, Jul 25, 2008 at 2:19 AM, Tom Lane [EMAIL
On Fri, 2008-07-25 at 10:00 +0900, ITAGAKI Takahiro wrote:
Simon Riggs [EMAIL PROTECTED] wrote:
* access to version number
* simple mechanism for conditional execution
* ability to set substitution variables from command execution
* conditional execution whether superuser or not
Can
On Thu, 2008-07-24 at 19:11 -0400, Tom Lane wrote:
There's some fairly squirrely logic in pg_dump/pg_restore that tries to
detect whether it's doing a data-only operation, ie, no schema
information is to be dumped or restored. The reason it wants to
know this is to decide whether to enable
On Thu, 2008-07-24 at 11:41 -0400, Tom Lane wrote:
Now, if you're suggesting we need a plugin hook somewhere in or around
default_reloptions, that's possibly reasonable; but a GUC like you're
suggesting seems quite pointless.
OK, I'll have a look, or perhaps Itagaki?
--
Simon Riggs
(a) that's not back-patchable and (b) it'll create a merge conflict with
your patch, if you're still going to add a new AM function column.
I think that aminsertcleanup per se isn't needed, but if we want an
amanalyze there'd still be a conflict. Where are we on that?
I'll revert
Theo Schlossnagle napsal(a):
On Jul 24, 2008, at 11:11 AM, Zdenek Kotala wrote:
I performed review and I prepared own patch which contains only probes
without any issue. I suggest commit this patch because the rest of
patch is independent and it can be committed next commit fest after
On Fri, Jul 25, 2008 at 08:16:59AM +0100, Simon Riggs wrote:
On Fri, 2008-07-25 at 10:00 +0900, ITAGAKI Takahiro wrote:
Simon Riggs [EMAIL PROTECTED] wrote:
* access to version number
* simple mechanism for conditional execution
* ability to set substitution variables from command
2008/7/25 Simon Riggs [EMAIL PROTECTED]:
On Fri, 2008-07-25 at 10:00 +0900, ITAGAKI Takahiro wrote:
Simon Riggs [EMAIL PROTECTED] wrote:
* access to version number
* simple mechanism for conditional execution
* ability to set substitution variables from command execution
* conditional
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
I understand. However I have another dumb idea/question - It seems to me that it
is client code. I think that it should be integrated into psql
command.
That doesn't seem like a particularly appropriate thing to do ... nor
do I see
On Fri, Jul 25, 2008 at 8:52 AM, daveg [EMAIL PROTECTED] wrote:
It seems to me that a sql-like client side scripting language should be as
similar as possible to plpgsql. Pgscript looks a bit like plpgsql, but is
pretty much incompatible with it for no particularly obvious reason.
pgScript
2008/7/25 Dave Page [EMAIL PROTECTED]:
On Fri, Jul 25, 2008 at 8:52 AM, daveg [EMAIL PROTECTED] wrote:
It seems to me that a sql-like client side scripting language should be as
similar as possible to plpgsql. Pgscript looks a bit like plpgsql, but is
pretty much incompatible with it for no
OK, I may be in a nitpicking mood today. :-)
IANAL, but it's my responsibility to check that Sun won't be violating
any copyright or licencing terms when delivering PostgreSQL with
(Open)Solaris.
I am now working on adding the regression tests (gmake check) to the
8.3 packages integrated into
On Fri, 2008-07-25 at 09:40 +0100, Dave Page wrote:
On Fri, Jul 25, 2008 at 9:36 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
2008/7/25 Dave Page [EMAIL PROTECTED]:
On Fri, Jul 25, 2008 at 8:52 AM, daveg [EMAIL PROTECTED] wrote:
It seems to me that a sql-like client side scripting language
Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2008-07-24 at 11:41 -0400, Tom Lane wrote:
Now, if you're suggesting we need a plugin hook somewhere in or around
default_reloptions, that's possibly reasonable; but a GUC like you're
suggesting seems quite pointless.
OK, I'll have a look,
On Fri, Jul 25, 2008 at 9:36 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
2008/7/25 Dave Page [EMAIL PROTECTED]:
On Fri, Jul 25, 2008 at 8:52 AM, daveg [EMAIL PROTECTED] wrote:
It seems to me that a sql-like client side scripting language should be as
similar as possible to plpgsql. Pgscript
* Jaime Casanova ([EMAIL PROTECTED]) wrote:
ok, seems this is the last one for column level patch
http://archives.postgresql.org/pgsql-patches/2008-04/msg00417.php
any one working it...
Yes, I'm working on it, but I'm not against having help, of course. The
past couple weeks have been given
Ryan Bradetich [EMAIL PROTECTED] writes:
My plans for the example above would be:
1. SELECT 15 + 15 -- Throws overflow error.
2. SELECT 15::uint4 + 15 -- Returns 30::uint4.
I think that wouldn't actually work. Postgres's parser immediately assigns
Am Friday, 25. July 2008 schrieb Ryan Bradetich:
PgFoundry already has an uint project:
http://pgfoundry.org/projects/uint/
Unfortunately this project seems to have not gone anywhere. Last
activity was late 2006 and there are not any files checked into the
SCM repository.
On Fri, 2008-07-25 at 09:37 +0300, Asko Oja wrote:
Hi
One of reasons to get PL/proxy into core is to make it available to
Windows users also.
The idea is to get to the situation
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would
like to hear
Asko Oja wrote:
Hi
One of reasons to get PL/proxy into core is to make it available to
Windows users also.
The idea is to get to the situation
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would
like to hear how.
The same way you would for any
Hi, hackers.
I've post a hash patch in a previous thread
http://archives.postgresql.org/pgsql-hackers/2008-07/msg00794.php
I do apologize for the bad readability of previous patch. Thank you all for
your comments.
Here is a new patch which fixed some bugs in the previous one.
I post it here to
On Fri, 2008-07-25 at 09:37 +0300, Asko Oja wrote:
One of reasons to get PL/proxy into core is to make it available to
Windows users also.
The idea is to get to the situation
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would
like to
Attached patch implements WHERE clauses for pg_dump.
This is useful for producing data samples of a database
e.g. pg_dump -w ctid '(1000,1)' or random() 0.1
and can also be used for taking incremental backups, if data columns
exist to make a partial dump sensible.
e.g. pg_dump -w
Hello Peter,
On Fri, Jul 25, 2008 at 5:14 AM, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Friday, 25. July 2008 schrieb Ryan Bradetich:
PgFoundry already has an uint project:
http://pgfoundry.org/projects/uint/
Unfortunately this project seems to have not gone anywhere. Last
Hello Greg,
On Fri, Jul 25, 2008 at 3:57 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
My plans for the example above would be:
1. SELECT 15 + 15 -- Throws overflow error.
2. SELECT 15::uint4 + 15 -- Returns
Gregory Stark escribió:
One other idea that's been mentioned before is treating integral constants
like 15 as type unknown like the quoted '15' constant is. That way
the parser would see uint4+unknown and could pick the uint4 operator. But that
would be a pretty massive semantics
Hi.
I tackled with hope temporarily. It seems that some adjustment is still
required.
http://winpg.jp/~saito/pg_work/plproxy/
However, windows user desires to use. Of course, it is also me.
Regards,
Hiroshi Saito
From: Joshua D. Drake [EMAIL PROTECTED]
On Fri, 2008-07-25 at 09:37 +0300,
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, if we do that, how would the system resolve something like this?
select 1000 + 1000
Well we have the same problem with 'foo' || 'bar'. The question I think is
whether the solution there scales to having two different fallback types.
There would
On Fri, Jul 25, 2008 at 4:51 AM, Stephen Frost [EMAIL PROTECTED] wrote:
* Jaime Casanova ([EMAIL PROTECTED]) wrote:
ok, seems this is the last one for column level patch
http://archives.postgresql.org/pgsql-patches/2008-04/msg00417.php
any one working it...
Yes, I'm working on it, but I'm
Gregory Stark escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, if we do that, how would the system resolve something like this?
select 1000 + 1000
Well we have the same problem with 'foo' || 'bar'. The question I think is
whether the solution there scales to having two
On Wed, 2008-07-23 at 10:49 +1000, Jens-Wolfhard Schicke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Riggs wrote:
Asynchronous commit controls whether we go to disk at time of commit, or
whether we defer this slightly. We have the same options with
replication: do we
Alvaro Herrera [EMAIL PROTECTED] wrote:
consider
alvherre=# select 0.42 + 1;
?column?
--
1.42
(1 ligne)
However, it would be neat if this behaved the same as
alvherre=# select '0.42' + 1;
ERROR: invalid input syntax for integer: 0.42
STATEMENT: select '0.42' +
Kevin Grittner escribió:
Alvaro Herrera [EMAIL PROTECTED] wrote:
consider
alvherre=# select 0.42 + 1;
?column?
--
1.42
(1 ligne)
However, it would be neat if this behaved the same as
alvherre=# select '0.42' + 1;
ERROR: invalid input syntax for
Hiroshi Saito wrote:
Hi.
I tackled with hope temporarily. It seems that some adjustment is
still required.
http://winpg.jp/~saito/pg_work/plproxy/
However, windows user desires to use. Of course, it is also me.
What is stopping you? Whether or not it works on Windows has (or should
have)
Alvaro Herrera [EMAIL PROTECTED] writes:
On Fri, 2008-07-25 at 09:37 +0300, Asko Oja wrote:
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would
like to hear how.
Sounds like you just need to get a new row in the standard pg_pltemplate.
When
Simon Riggs [EMAIL PROTECTED] writes:
Attached patch implements WHERE clauses for pg_dump.
I still have serious reservations about adding such an ugly,
non-orthogonal wart to pg_dump. Why is it not appropriate to just
do a COPY (SELECT ...) TO STDOUT when you need this?
What is stopping you? Whether or not it works on Windows has (or should
have) nothing to do with whether or not it is in core.
I think that plproxy is great. However, the windows user did not complain.
Because, build was not easy. Therefore, pginstaller has not chosen.
Then, I thought that I
On Fri, 2008-07-25 at 13:31 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Attached patch implements WHERE clauses for pg_dump.
I still have serious reservations about adding such an ugly,
non-orthogonal wart to pg_dump. Why is it not appropriate to just
do a COPY (SELECT
On Fri, 2008-07-25 at 19:33 +0100, Simon Riggs wrote:
On Fri, 2008-07-25 at 13:31 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Attached patch implements WHERE clauses for pg_dump.
I still have serious reservations about adding such an ugly,
non-orthogonal wart to
Yes, I'm relying on the assumption that backwards scan has the same cost as
forward scan, why shouldn't it?
Yet, all plan node types we are testing works with backwards scan (looking
on ExecSupportsBackwardScan). But, is there a easy way to make a query
execute only in backwards scan? How we can
On Fri, 2008-07-25 at 11:46 -0700, Joshua D. Drake wrote:
On Fri, 2008-07-25 at 19:33 +0100, Simon Riggs wrote:
On Fri, 2008-07-25 at 13:31 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Attached patch implements WHERE clauses for pg_dump.
I still have serious
Ryan Bradetich [EMAIL PROTECTED] writes:
On Fri, Jul 25, 2008 at 3:57 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
My plans for the example above would be:
1. SELECT 15 + 15 -- Throws overflow error.
2. SELECT 15::uint4 +
On Fri, 2008-07-25 at 20:26 +0100, Simon Riggs wrote:
On Fri, 2008-07-25 at 11:46 -0700, Joshua D. Drake wrote:
On Fri, 2008-07-25 at 19:33 +0100, Simon Riggs wrote:
Adding this feature gives a very fast capability to create sample
databases, or incremental backups for many cases.
On Tue, 2008-07-22 at 17:19 -0700, Martin Zaun wrote:
reviewing your patch
Current status is this:
* My understanding is that Dave and Andrew (and therefore Simon) think
the approach proposed here is an acceptable one. Heikki disagrees and
wants different approach. Perhaps I misunderstand.
Bjorn Munch [EMAIL PROTECTED] writes:
This file was checked in way back in July 1996, by Marc G. Fournier
but that doesn't mean he was the one who got the data from
somewhere. Does anyone know where it comes from? Or has this
information been lost in the mist of time?
It's in the postgres
Simon Riggs [EMAIL PROTECTED] writes:
I just wanted an easy way to write install scripts that work on various
releases/schemas/environments, works on core and on any platform.
The word easy is out of place in that sentence. Such scripts would
likely need information that's entirely outside the
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Friday, July 25, 2008 12:52 PM
To: Bjorn Munch
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Whence cometh the data in
src/test/regress/data/streets.data ?
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Friday, July 25, 2008 12:32 PM
To: Ryan Bradetich
Cc: Gregory Stark; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [RFC] Unsigned integer support.
Ryan Bradetich
Dann Corbit wrote:
CREATE DOMAIN usmallint AS SMALLINT CHECK(VALUE 0);
CREATE DOMAIN uinteger AS INTEGER CHECK(VALUE 0);
CREATE DOMAIN ubigint AS BIGINT CHECK(VALUE 0);
CREATE DOMAIN unumeric AS NUMERIC CHECK(VALUE 0);
s//=/g
cheers
andrew
--
Sent via pgsql-hackers mailing list
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Friday, July 25, 2008 1:11 PM
To: Dann Corbit
Cc: Tom Lane; Ryan Bradetich; Gregory Stark; pgsql-
[EMAIL PROTECTED]
Subject: Re: [HACKERS] [RFC] Unsigned integer support.
Dann Corbit wrote:
CREATE
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
AFAIK, there is nothing that requires pl/perl, pl/tcl or pl/python to be
in core either.
True, but I think it's a good idea to have at least one such in core,
as a prototype to help us track the issues associated with loading a
large
Dann Corbit wrote:
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Friday, July 25, 2008 1:11 PM
To: Dann Corbit
Cc: Tom Lane; Ryan Bradetich; Gregory Stark; pgsql-
[EMAIL PROTECTED]
Subject: Re: [HACKERS] [RFC] Unsigned integer support.
Dann Corbit wrote:
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Friday, July 25, 2008 1:28 PM
To: Dann Corbit
Cc: Tom Lane; Ryan Bradetich; Gregory Stark; pgsql-
[EMAIL PROTECTED]
Subject: Re: [HACKERS] [RFC] Unsigned integer support.
Dann Corbit wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 17:19 -0700, Martin Zaun wrote:
reviewing your patch
Current status is this:
* My understanding is that Dave and Andrew (and therefore Simon) think
the approach proposed here is an acceptable one. Heikki disagrees and
wants
Ron Mayer [EMAIL PROTECTED] writes:
Wouldn't it provide even more benefit if these were maintained
as independent modules *outside* of core but still by the core team.
This part of the core team isn't willing to do that. I've got enough
work to do without trying to keep multiple repositories
On Fri, 2008-07-25 at 16:31 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 17:19 -0700, Martin Zaun wrote:
reviewing your patch
Current status is this:
* My understanding is that Dave and Andrew (and therefore Simon) think
the approach proposed
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-07-25 at 16:31 -0400, Tom Lane wrote:
I thought the latest conclusion was that changing the behavior of
pg_standby itself wouldn't address the problem anyway, and that what we
need is just a docs patch recommending that people use safe copying
On Fri, Jul 25, 2008 at 08:26:35PM +0100, Simon Riggs wrote:
On Fri, 2008-07-25 at 11:46 -0700, Joshua D. Drake wrote:
On Fri, 2008-07-25 at 19:33 +0100, Simon Riggs wrote:
On Fri, 2008-07-25 at 13:31 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Attached patch
On Fri, 2008-07-25 at 16:58 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-07-25 at 16:31 -0400, Tom Lane wrote:
I thought the latest conclusion was that changing the behavior of
pg_standby itself wouldn't address the problem anyway, and that what we
need is
On Fri, 2008-07-25 at 14:11 -0700, daveg wrote:
On Fri, Jul 25, 2008 at 08:26:35PM +0100, Simon Riggs wrote:
- This can be done with a script.
Not really. The script would pretty much have to contain most of
pg_dump. That's more than a script.
Yes really. :) The only thing
On Fri, 2008-07-25 at 14:11 -0700, daveg wrote:
On Fri, Jul 25, 2008 at 08:26:35PM +0100, Simon Riggs wrote:
On Fri, 2008-07-25 at 11:46 -0700, Joshua D. Drake wrote:
On Fri, 2008-07-25 at 19:33 +0100, Simon Riggs wrote:
On Fri, 2008-07-25 at 13:31 -0400, Tom Lane wrote:
Simon
On Fri, 2008-07-25 at 14:29 -0700, Joshua D. Drake wrote:
- users could make partial dumps and be confused and lose data.
Yes, but they can already do that with -n, -t, and the new
pre-data
and post-data switches. This is one more case where the
default is
a full
Simon Riggs wrote:
Well, that is truly bizarre.
I had no idea about the existence of the other patch. I guess I must
have been busy that week.
This was designed a while back in conjunction with other related
thoughts. I still want an easy way to create a data sample for creating
dev
Manoel Henrique [EMAIL PROTECTED] writes:
Yes, I'm relying on the assumption that backwards scan has the same cost as
forward scan, why shouldn't it?
Because hard drives only spin one direction
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about
Joshua D. Drake [EMAIL PROTECTED] writes:
How do we deal with this?
pg_dump -w last_update_timestamp ... -t 'table*'
What I see is a recipe for inconsistent, un-restorable backups without a
user realizing what they have done. The only way to deal with the above
is:
1. Wildcards aren't
On Fri, Jul 25, 2008 at 6:10 PM, Gregory Stark [EMAIL PROTECTED] wrote:
Manoel Henrique [EMAIL PROTECTED] writes:
Yes, I'm relying on the assumption that backwards scan has the same cost as
forward scan, why shouldn't it?
Because hard drives only spin one direction
:)
--
Jonah H. Harris,
On Fri, 2008-07-25 at 19:31 -0400, Jonah H. Harris wrote:
On Fri, Jul 25, 2008 at 6:10 PM, Gregory Stark [EMAIL PROTECTED] wrote:
Manoel Henrique [EMAIL PROTECTED] writes:
Yes, I'm relying on the assumption that backwards scan has the same cost as
forward scan, why shouldn't it?
Joshua D. Drake escribió:
On Fri, 2008-07-25 at 19:31 -0400, Jonah H. Harris wrote:
On Fri, Jul 25, 2008 at 6:10 PM, Gregory Stark [EMAIL PROTECTED] wrote:
Manoel Henrique [EMAIL PROTECTED] writes:
Yes, I'm relying on the assumption that backwards scan has the same cost
as
Gregory Stark [EMAIL PROTECTED] writes:
Manoel Henrique [EMAIL PROTECTED] writes:
Yes, I'm relying on the assumption that backwards scan has the same cost as
forward scan, why shouldn't it?
Because hard drives only spin one direction
Good joke, but to be serious: we expect that forward scans
On Fri, Jul 25, 2008 at 11:17:20PM +0100, Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
How do we deal with this?
pg_dump -w last_update_timestamp ... -t 'table*'
What I see is a recipe for inconsistent, un-restorable backups without a
user realizing what they have
Tom Lane escribió:
Gregory Stark [EMAIL PROTECTED] writes:
Manoel Henrique [EMAIL PROTECTED] writes:
Yes, I'm relying on the assumption that backwards scan has the same cost as
forward scan, why shouldn't it?
Because hard drives only spin one direction
Good joke, but to be serious:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
Good joke, but to be serious: we expect that forward scans will result
in the kernel doing read-ahead, which will allow overlapping of
CPU work to process one page with the I/O to bring in the next page.
I wonder if this is spoiled
Zdenek Kotala wrote:
I performed review and I prepared own patch which contains only probes
without any issue. I suggest commit this patch because the rest of patch
is independent and it can be committed next commit fest after rework.
I found following issues:
I noticed that CLOG, Subtrans
Thanks for the patch :)
Now, I get a different problem, this time with the following code
intended to materialize paths on the fly and summarize down to a
certain depth in a tree:
CREATE TABLE tree(
id INTEGER PRIMARY KEY,
parent_id INTEGER REFERENCES tree(id)
);
INSERT INTO
Hello Dann,
On Fri, Jul 25, 2008 at 1:06 PM, Dann Corbit [EMAIL PROTECTED] wrote:
At the cost of one bit of storage, you have compatible types using
Thanks for your review and feedback! Unfortunately, I do need the full range
of the unsigned types for the project I am looking at. The reason
Ryan Bradetich [EMAIL PROTECTED] writes:
... I did have the following
concern looking through src/backend/utils/adt/int8.c: There is code that is
optionally compiled based on the INT64_IS_BUSTED pre-processor define.
Is this pre-processor define something I should worry about for portability
Tom,
On Fri, Jul 25, 2008 at 12:32 PM, Tom Lane [EMAIL PROTECTED] wrote:
Consider the idea of not having any uint4-specific arithmetic operators,
but instead providing the following:
* assignment casts from int4 and int8 to uint4
(these throw error if out of range, of
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Manoel Henrique [EMAIL PROTECTED] writes:
Yes, I'm relying on the assumption that backwards scan has the same cost as
forward scan, why shouldn't it?
G...we expect that forward scans will result
in the kernel doing read-ahead, ...
A
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
A backwards scan will get no such overlapping and thus be up to 2X
slower, unless the kernel is smart enough to do read-ahead for
descending-order read requests. Which seems not too probable.
Linux's old adaptive readahead patches claimed
79 matches
Mail list logo
