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 patche
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, ...
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
"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 porta
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 reaso
> 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)
> );
>
>
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, Subt
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
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, b
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 real
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 fo
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 co
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
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
:)
--
Jona
"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. Wil
"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 Enterpr
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 databases
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
> >
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:
>
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 thin
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
>
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:
> > > > > A
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
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 approa
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 repositorie
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
> want
> -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:
> >>
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:
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 th
> -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:
> >
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
> -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 B
> -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
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 outsid
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 postgre
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.
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
"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
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 h
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 d
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
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 (
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 w
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?
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_pltempla
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
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:
>>> 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
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:
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 havin
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 i
"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
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 +030
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
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
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 -->
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 "last_up
> 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 wo
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 get
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 o
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
> lik
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.
>
"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 immediatel
* 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 gi
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 h
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
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 O
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 plpg
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
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.
pgScrip
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
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 executio
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 variab
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
rework
(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 aminsertc
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
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 enabl
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
78 matches
Mail list logo
