Re: [HACKERS] How can we tell how far behind the standby is?

On Fri, Nov 5, 2010 at 5:39 PM, Robert Haas wrote: > On Fri, Nov 5, 2010 at 2:46 PM, Josh Berkus wrote: >> I'm continuing in my efforts now to document how to deploy and manage >> replication on our wiki.  One of the things a DBA needs to do is to use >> pg_current_xlog_location() (and related fu

Re: [HACKERS] temporary functions (and other object types)

On Fri, Nov 5, 2010 at 4:02 PM, Tom Lane wrote: > Alvaro Herrera writes: >> A customer of ours has the need for temporary functions. > > You can do that now: > > regression=# create function pg_temp.foo(f1 int) returns int > regression-# as 'select $1+1' language sql; > CREATE FUNCTION > regressi

Re: [HACKERS] timestamp of the last replayed transaction

On Thu, Nov 4, 2010 at 9:00 PM, Fujii Masao wrote: > On Thu, Nov 4, 2010 at 10:27 AM, Fujii Masao wrote: >> On Tue, Nov 2, 2010 at 10:38 PM, Dimitri Fontaine >> wrote: >>> Fujii Masao writes: After 9.0 release, I've often heard that some people want to know how far transactions have b

Re: [HACKERS] How can we tell how far behind the standby is?

On Fri, Nov 5, 2010 at 2:46 PM, Josh Berkus wrote: > I'm continuing in my efforts now to document how to deploy and manage > replication on our wiki.  One of the things a DBA needs to do is to use > pg_current_xlog_location() (and related functions) to check how far > behind the master the standby

Re: [HACKERS] ALTER TABLE ... IF EXISTS feature?

On Fri, Nov 5, 2010 at 4:20 PM, Robert Haas wrote: > Can you give us a self-contained example of the problem you're talking about? Sure. Consider the following: CREATE TABLE t1 ( id integer PRIMARY KEY ); CREATE TABLE t2 ( id integer PRIMARY KEY, fk integer ); ALTER TABLE ONLY t2

Re: [HACKERS] ALTER TABLE ... IF EXISTS feature?

On Fri, Nov 5, 2010 at 4:48 PM, Daniel Farina wrote: > On Fri, Nov 5, 2010 at 1:31 PM, Tom Lane wrote: >> Daniel Farina writes: >>> On Fri, Nov 5, 2010 at 11:04 AM, Tom Lane wrote: Daniel Farina writes: > pg_dump --clean will successfully and silently wipe out a foreign key > righ

Re: [HACKERS] plpgsql execute vs. SELECT ... INTO

On 11/05/2010 06:54 PM, Tom Lane wrote: Andrew Dunstan writes: The comment on the commit says: EXECUTE of a SELECT ... INTO now draws a 'not implemented' error, rather than executing the INTO clause with non-plpgsql semantics as it was doing for the last few weeks/months. This

Re: [HACKERS] plpgsql execute vs. SELECT ... INTO

Andrew Dunstan writes: > The comment on the commit says: > EXECUTE of a SELECT ... INTO now draws a 'not implemented' error, > rather than executing the INTO clause with non-plpgsql semantics > as it was doing for the last few weeks/months. This keeps our options > open for makin

[HACKERS] plpgsql execute vs. SELECT ... INTO

(Prompted by a puzzled user on IRC) Ten years ago, nearly, we made this commit (see what a good thing it is we carefully got all the history transferred to git?) The comment on the commit says: EXECUT

Re: [HACKERS] "Make" versus effective stack limit in regression tests

Andrew Dunstan writes: > On 11/05/2010 05:45 PM, Tom Lane wrote: >> Anyway, what this points up is that we are making a very conservative >> assumption about what to do when getrlimit() returns RLIM_INFINITY. >> It does not seem real reasonable to interpret that as 100kB on any >> modern platform.

Re: [HACKERS] Simplifying replication

On Tue, 2010-10-19 at 10:31 +0200, Dimitri Fontaine wrote: > > 4. I can start a new replica off the master by running a single command-line > > utility on the standby and giving it connection information to the master. > > Using this connection, it should be able to start a backup snapshot, copy >

Re: [HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

On 11/5/10 3:31 PM, Tom Lane wrote: > Josh Berkus writes: >> What plaforms do we need to test to get a reasonable idea? Solaris, >> FreeBSD, Windows? > > At least. I'm hoping that Greg Smith will take the lead on testing > this, since he seems to have spent the most time in the area so far. I c

Re: [HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

Josh Berkus writes: > What plaforms do we need to test to get a reasonable idea? Solaris, > FreeBSD, Windows? At least. I'm hoping that Greg Smith will take the lead on testing this, since he seems to have spent the most time in the area so far. regards, tom lane -- Se

Re: [HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

> I think the original idea was that if you had a dedicated WAL drive then > sync-on-write would be reasonable. But that was a very long time ago > and I'm not sure that the system's behavior is anything like what it was > then; for that matter I'm not sure we had proof that it was an optimal > c

Re: [HACKERS] "Make" versus effective stack limit in regression tests

On 11/05/2010 05:45 PM, Tom Lane wrote: Anyway, what this points up is that we are making a very conservative assumption about what to do when getrlimit() returns RLIM_INFINITY. It does not seem real reasonable to interpret that as 100kB on any modern platform. I'm inclined to interpret it a

Re: [HACKERS] CREATE CONSTRAINT TRIGGER

Alvaro Herrera writes: > Some time ago, CREATE CONSTRAINT TRIGGER was a deprecated command and it > was slated for obsolence or removal. > Recent developments have turned it back into non-deprecated mode; it's > not going anywhere, and it needs to be fully documented. > It seems to me that it ma

Re: [HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

On Friday 05 November 2010 22:53:37 Greg Smith wrote: > > If open_dsync is so bad for performance on Linux, maybe it's bad > > everywhere? Should we be rethinking the default preference order? > > > > > > And I've seen the expected sync write performance gain over fdatasync on > a system with

Re: [HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

Andres Freund writes: > On Friday 05 November 2010 19:13:47 Tom Lane wrote: >> If open_dsync is so bad for performance on Linux, maybe it's bad >> everywhere? Should we be rethinking the default preference order? > I fail to see how it could be beneficial on *any* non-buggy platform. > Especiall

Re: [HACKERS] Query Plan Columns

Josh Berkus writes: >> 960 ExplainPropertyFloat("Plan Rows", plan->plan_rows, 0, es); >> >> Should rows really be a float? > Yeah, since PropertyInteger is 32-bit. Yes, plan_rows is a float. We might need to represent very large values, and we do not need high accuracy, so it's rea

Re: [HACKERS] CREATE CONSTRAINT TRIGGER

On Fri, Nov 5, 2010 at 2:37 PM, Alvaro Herrera wrote: > Recent developments have turned it back into non-deprecated mode; it's > not going anywhere, and it needs to be fully documented. >From what I recall, there isn't anything in the trigger documentation or CREATE CONSTRAINT TRIGGER documentat

Re: [HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

Tom Lane wrote: If open_dsync is so bad for performance on Linux, maybe it's bad everywhere? Should we be rethinking the default preference order? And I've seen the expected sync write performance gain over fdatasync on a system with a battery-backed cache running VxFS on Linux, because w

[HACKERS] "Make" versus effective stack limit in regression tests

I wondered why some of the buildfarm machines were showing max_stack_depth = 100kB, and Andrew Dunstan kindly lent me the use of "dungbeetle" to check it out. What I found out: 1. max_stack_depth has the expected value (equal to ulimit -s) in any manually started postmaster. It only drops to 100

[HACKERS] CREATE CONSTRAINT TRIGGER

Some time ago, CREATE CONSTRAINT TRIGGER was a deprecated command and it was slated for obsolence or removal. Recent developments have turned it back into non-deprecated mode; it's not going anywhere, and it needs to be fully documented. It seems to me that it makes more sense to merge its docume

Re: [HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

On Fri, Nov 5, 2010 at 22:16, Tom Lane wrote: > I don't really think that "change the default on Linux" is that > much nicer than "change the default everywhere" when it comes to > what we ought to consider back-patching.  In any case, you're getting > ahead of the game: we need to decide on the d

Re: [HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

On Friday 05 November 2010 19:13:47 Tom Lane wrote: > Marti Raudsepp writes: > > PostgreSQL's default settings change when built with Linux kernel > > headers 2.6.33 or newer. As discussed on the pgsql-performance list, > > this causes a significant performance regression: > > http://archives.post

Re: [HACKERS] Query Plan Columns

> 960 ExplainPropertyFloat("Plan Rows", plan->plan_rows, 0, es); > > Should rows really be a float? Yeah, since PropertyInteger is 32-bit. -- -- Josh Berkus PostgreSQL Experts Inc.

Re: [HACKERS] Query Plan Columns

On Nov 5, 2010, at 1:42 PM, David E. Wheeler wrote: > On Nov 5, 2010, at 1:38 PM, Dimitri Fontaine wrote: > >> It seems that you need to read through ExplainNode in >> src/backend/commands/explain.c: >> >> http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/backend/commands/explain.c;

Re: [HACKERS] ALTER TABLE ... IF EXISTS feature?

On Fri, Nov 5, 2010 at 1:31 PM, Tom Lane wrote: > Daniel Farina writes: >> On Fri, Nov 5, 2010 at 11:04 AM, Tom Lane wrote: >>> Daniel Farina writes: pg_dump --clean will successfully and silently wipe out a foreign key right now, should it exist, >>> >>> No, it will not, because we d

Re: [HACKERS] Query Plan Columns

On Nov 5, 2010, at 1:38 PM, Dimitri Fontaine wrote: > It seems that you need to read through ExplainNode in > src/backend/commands/explain.c: > > > http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/backend/commands/explain.c;h=f494ec98e510c23120e072bd5ee8821ea12738a4;hb=HEAD#l617

Re: [HACKERS] Query Plan Columns

On Nov 5, 2010, at 1:36 PM, Andrew Dunstan wrote: > Of course, there are containers too, which are not in your list at all. How > do you intend to represent the tree-ish structure in a flat table? So far I see only two containers: Subplans and Sot Keys. The latter is represented as an array. Th

Re: [HACKERS] Query Plan Columns

> Of course, there are containers too, which are not in your list at all. > How do you intend to represent the tree-ish structure in a flat table? Andrew: we'll use a proximity tree. -- -- Josh Berkus PostgreSQL Experts Inc

Re: [HACKERS] Query Plan Columns

"David E. Wheeler" writes: > * Is there some place in the source with a canonical list? It seems that you need to read through ExplainNode in src/backend/commands/explain.c: http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/backend/commands/explain.c;h=f494ec98e510c23120e072bd5ee

Re: [HACKERS] Query Plan Columns

On 11/05/2010 04:27 PM, David E. Wheeler wrote: Fellow Hackers, I'm writing a function to turn an EXPLAIN plan into a table with columns. As such, I need to have a complete list of the various bits of each plan node and their types for the table. Here's what I've got so far: "Node Type

Re: [HACKERS] ALTER TABLE ... IF EXISTS feature?

Daniel Farina writes: > On Fri, Nov 5, 2010 at 11:04 AM, Tom Lane wrote: >> Daniel Farina writes: >>> pg_dump --clean will successfully and silently wipe out a foreign key >>> right now, should it exist, >> >> No, it will not, because we don't use CASCADE in the drop commands. > I know it does

[HACKERS] Query Plan Columns

Fellow Hackers, I'm writing a function to turn an EXPLAIN plan into a table with columns. As such, I need to have a complete list of the various bits of each plan node and their types for the table. Here's what I've got so far: "Node Type" TEXT, "Strategy"TEXT,

Re: [HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

Marti Raudsepp writes: > On Fri, Nov 5, 2010 at 21:20, Tom Lane wrote: >> What's that got to do with it? > I'm not sure what you're asking. > Surely changing the default wal_sync_method for all OSes in > maintenance releases is out of the question, no? Well, if we could leave well enough alone

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Alvaro Herrera writes: > Basically you're saying that the owner of the schema in which the > extension is installed can drop the extension ... even though, according > to your previous argument, the extension is not "in" said schema :-) Yeah it's a case of defining things. The extension is not in

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Excerpts from Dimitri Fontaine's message of vie nov 05 16:58:00 -0300 2010: > dim=> drop schema bob cascade; > NOTICE: drop cascades to extension unaccent > DROP SCHEMA > > dim=> \c - dim > You are now connected to database "dim" as user "dim". > dim=# select installed from pg_extensions where n

Re: [HACKERS] temporary functions (and other object types)

Alvaro Herrera writes: > A customer of ours has the need for temporary functions. You can do that now: regression=# create function pg_temp.foo(f1 int) returns int regression-# as 'select $1+1' language sql; CREATE FUNCTION regression=# select pg_temp.foo(1); foo - 2 (1 row) You do hav

Re: [HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

On Fri, Nov 5, 2010 at 21:20, Tom Lane wrote: > Marti Raudsepp writes: >> On Fri, Nov 5, 2010 at 20:13, Tom Lane wrote: >>> If open_dsync is so bad for performance on Linux, maybe it's bad >>> everywhere?  Should we be rethinking the default preference order? > >> So I think we should aim to fix

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Tom Lane writes: > You're mistaken, and this case definitely does need more thought. > A schema owner is presumed to have the unconditional right to > drop anything in his schema, whether he owns it or not. Here a paste of how it works with current code. dim=# create schema bob authorization bob

Re: [HACKERS] temporary functions (and other object types)

On Nov 5, 2010, at 12:36 PM, Alvaro Herrera wrote: > Hi, > > A customer of ours has the need for temporary functions. The use case > is writing test cases for their databases: the idea being that their > code creates a temp function which then goes away automatically at > session end, just like

Re: [HACKERS] temporary functions (and other object types)

On 5 November 2010 20:36, Alvaro Herrera wrote: > Hi, > > A customer of ours has the need for temporary functions. The use case > is writing test cases for their databases: the idea being that their > code creates a temp function which then goes away automatically at > session end, just like a t

[HACKERS] temporary functions (and other object types)

Hi, A customer of ours has the need for temporary functions. The use case is writing test cases for their databases: the idea being that their code creates a temp function which then goes away automatically at session end, just like a temp table. It's said that this makes things generally easier

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Dimitri Fontaine writes: > Tom Lane writes: >> Here's another question: if an extension's objects live (mostly or >> entirely) in schema X, what happens if the possibly-unprivileged owner >> of schema X decides to drop it? If the extension itself is considered >> to live within the schema, then

Re: [HACKERS] ALTER TABLE ... IF EXISTS feature?

On Fri, Nov 5, 2010 at 11:04 AM, Tom Lane wrote: > Daniel Farina writes: >> I am somewhat sympathetic to this argument, except for one thing: > >> pg_dump --clean will successfully and silently wipe out a foreign key >> right now, should it exist, > > No, it will not, because we don't use CASCADE

Re: [HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

Marti Raudsepp writes: > On Fri, Nov 5, 2010 at 20:13, Tom Lane wrote: >> If open_dsync is so bad for performance on Linux, maybe it's bad >> everywhere?  Should we be rethinking the default preference order? > So I think we should aim to fix old versions first. Do you disagree? What's that go

Re: [HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

On Fri, Nov 5, 2010 at 20:13, Tom Lane wrote: > I'm less than convinced this is the right approach ... > > If open_dsync is so bad for performance on Linux, maybe it's bad > everywhere?  Should we be rethinking the default preference order? Sure, maybe for PostgreSQL 9.1 But the immediate proble

[HACKERS] How can we tell how far behind the standby is?

Folks, I'm continuing in my efforts now to document how to deploy and manage replication on our wiki. One of the things a DBA needs to do is to use pg_current_xlog_location() (and related functions) to check how far behind the master the standby is. However, there's some serious problems with th

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Tom Lane writes: >> Are you proposing that an extension object is schema qualified? > > Dunno, I'm just asking the question. If it isn't, why not? Because extension are much like languages for stored procedure, on the utility side rather than on the query side. The only queries that uses languag

Re: [HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

Marti Raudsepp writes: > PostgreSQL's default settings change when built with Linux kernel > headers 2.6.33 or newer. As discussed on the pgsql-performance list, > this causes a significant performance regression: > http://archives.postgresql.org/pgsql-performance/2010-10/msg00602.php > NB! I am

Re: [HACKERS] ALTER TABLE ... IF EXISTS feature?

Daniel Farina writes: > I am somewhat sympathetic to this argument, except for one thing: > pg_dump --clean will successfully and silently wipe out a foreign key > right now, should it exist, No, it will not, because we don't use CASCADE in the drop commands. The case I'm thinking about is wher

Re: [HACKERS] ALTER TABLE ... IF EXISTS feature?

On Fri, Nov 5, 2010 at 10:04 AM, Tom Lane wrote: > What you're proposing would maybe be useful for overwriting a database > that contains portions of what is in the source database, but what's > the use of that?  You could just as well dropdb and start fresh.  The > interesting case here is where

[HACKERS] [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

Hi list, PostgreSQL's default settings change when built with Linux kernel headers 2.6.33 or newer. As discussed on the pgsql-performance list, this causes a significant performance regression: http://archives.postgresql.org/pgsql-performance/2010-10/msg00602.php NB! I am not proposing to change

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Dimitri Fontaine writes: > Tom Lane writes: >> BTW, I'm not even 100% convinced that the schema shouldn't be part of >> the extension's name, if we're going to make it work like this. Is >> there a reason I shouldn't be able to have both public.myextension >> and testing.myextension? If we're c

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Tom Lane writes: > I'm with Alvaro on this. If we're going to have an ALTER EXTENSION SET > SCHEMA operation, then extensions must have a well-defined schema > property, and it would be good if that connection were explicitly > represented in the catalogs. Digging stuff out of pg_depend sucks; >

Re: [HACKERS] ALTER TABLE ... IF EXISTS feature?

Daniel Farina writes: > Well, why not? I was in the middle of writing it. But I'm open to > other approaches, the real motivating issue could be stated simply as: > "pg_dump --clean should produce output that can be run on empty, full > or partially-full databases in a transaction without a non-z

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Dimitri Fontaine writes: > Alvaro Herrera writes: >> Frankly, the get_extension_namespace bit still feels wrong to me. I >> would have the namespace be present in the pg_extension catalog, even if >> it's not part of the primary key. > Well, I'm thinking that: > - namespace columns in the cata

Re: [HACKERS] ALTER TABLE ... IF EXISTS feature?

On Fri, Nov 5, 2010 at 8:44 AM, Tom Lane wrote: > That spells "large maintenance burden" to me, even if any one command > would be relatively simple to fix.  And we haven't even reached the > question of whether pg_dump could use these things usefully; I suspect > that the bottom-line issue there

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Alvaro Herrera writes: > Frankly, the get_extension_namespace bit still feels wrong to me. I > would have the namespace be present in the pg_extension catalog, even if > it's not part of the primary key. This would let you answer the > question: what schema did I install this extension in? (and

Re: [HACKERS] Fix for seg picksplit function

Hello Yeb, Thank you for review and code refactoring. PS: when comparing with gbt_num_picksplit, I noticed that that one does not > update v->spl_ldatum and spl_rdatum to the union datums, but initializes > these to 0 at the beginning and never seems to update them. Not sure if this > is a proble

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

Excerpts from Jan Urbański's message of vie nov 05 04:19:07 -0300 2010: > PS: I'm wondering if there's any noticable slowdown from always starting > a subxact before doing SPI. Plperl users seemed not to notice, so I > guess I shouldn't worry. I think it's more "plperl users have to put up with i

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Excerpts from Dimitri Fontaine's message of vie nov 05 06:49:34 -0300 2010: > Alvaro Herrera writes: > > Hmm, seeing the amount of new includes in extension.c, I wonder if it'd > > be better to move AlterExtensionNamespace to alter.c. > > It was mainly missing includes cleanup. The guts of the fu

Re: [HACKERS] Fix for seg picksplit function

Hello Alexander, Here follows a review of your patch. Hackers, Seg contrib module contains the same bug in picksplit function as cube contrib module. Good catch! :-) Also, Guttman's split algorithm is not needed in unidimensional case, because sorting based algorithm is good in this case.

Re: [HACKERS] ALTER TABLE ... IF EXISTS feature?

Robert Haas writes: > On Nov 5, 2010, at 10:49 AM, Tom Lane wrote: >> I think you've phrased the question backwards. Why *should* we support >> that large increment of complexity? The use-cases seem pretty few and >> far between. > Obviously we have different definitions of "a large increment

Re: [HACKERS] ALTER TABLE ... IF EXISTS feature?

On Nov 5, 2010, at 10:49 AM, Tom Lane wrote: > Daniel Farina writes: >> Is there any reason why Postgres should not support an "ALTER TABLE >> tablename [IF EXISTS]" feature? > > I think you've phrased the question backwards. Why *should* we support > that large increment of complexity? The us

Re: [HACKERS] ALTER TABLE ... IF EXISTS feature?

Daniel Farina writes: > Is there any reason why Postgres should not support an "ALTER TABLE > tablename [IF EXISTS]" feature? I think you've phrased the question backwards. Why *should* we support that large increment of complexity? The use-cases seem pretty few and far between.

Re: [HACKERS] SQL/MED estimated time of arrival?

Shigeru HANADA writes: > Thanks, now I see your point. Current FdwRoutine has no appropriate > function because Open is called from ExecutorStart which is used by > EXPLAIN too. > But then we have mismatch between executor node interface and FDW > interface about BeginScan. Should we add new fu

Re: [HACKERS] SQL/MED estimated time of arrival?

On Fri, 5 Nov 2010 16:27:49 +0900 Itagaki Takahiro wrote: > On Fri, Nov 5, 2010 at 4:00 PM, Shigeru HANADA > wrote: > >> > * am_beginscan()        -> first call of FdwRoutine.Iterate()? > >> It might be good to have a separated "beginscan" method if we use > >> asynchronous scans in multiple fore

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Alvaro Herrera writes: > Hmm, seeing the amount of new includes in extension.c, I wonder if it'd > be better to move AlterExtensionNamespace to alter.c. It was mainly missing includes cleanup. The guts of the function is now so short I can inline it in this mail: targetObjects = listDepe

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Alvaro Herrera writes: > The has_privs_of_role() call has the wrong ACL_KIND argument in the > error report. Ah yes, I missed the acl_kind. It's a parameter of the function in the v7 patch, attached. > (Nitpick: don't use "e.g." at the end of the phrase. It seems strange > to me.) Fixed too. I

Re: [HACKERS] todo: plpgsql - tool to track code coverage

2010/11/5 Pavel Stehule : > Hello > > I am looking on http://kputnam.github.com/piggly/ site. I am thinking, > so can be very easy write low level support to plpgsql. And this can > to solve a some issue of plpgsql with lazy SQL full checking. > > A raising syntax error of some SQL inside plpgsql a

[HACKERS] ALTER TABLE ... IF EXISTS feature?

Hello List, Is there any reason why Postgres should not support an "ALTER TABLE tablename [IF EXISTS]" feature? (And similar for other ALTER OBJECTTYPE) For example, a hypothetical statement that attempts to drop a constraint in a *completely* optional manner would look like the following: ALT

Re: [HACKERS] SQL/MED estimated time of arrival?

On Fri, Nov 5, 2010 at 4:00 PM, Shigeru HANADA wrote: >> > * am_beginscan()        -> first call of FdwRoutine.Iterate()? >> It might be good to have a separated "beginscan" method if we use >> asynchronous scans in multiple foreign servers in one query > > You mean that separated beginscan (FdwRo

[HACKERS] todo: plpgsql - tool to track code coverage

Hello I am looking on http://kputnam.github.com/piggly/ site. I am thinking, so can be very easy write low level support to plpgsql. And this can to solve a some issue of plpgsql with lazy SQL full checking. A raising syntax error of some SQL inside plpgsql after a months of production usage is s

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

On 04/11/10 20:43, Hannu Krosing wrote: > On Thu, 2010-11-04 at 11:07 -0600, Alex Hunsaker wrote: >> On Thu, Nov 4, 2010 at 03:54, Hannu Krosing wrote: > try: > plpy.execute("insert into foo values(1)") > except plpy.UniqueViolation, e: > plpy.notice("Ooops, you got yoursel

Re: [HACKERS] SQL/MED estimated time of arrival?

On Thu, 4 Nov 2010 18:22:52 +0900 Itagaki Takahiro wrote: > On Thu, Nov 4, 2010 at 6:04 PM, Shigeru HANADA > wrote: > > For example: > > * PRIMARY ACCESS_METHOD -> HANDLER of FOREIGN DATA WRAPPER > > * am_scancost()         -> FdwRoutine.EstimateCosts() > > * am_open()             -> FdwRoutine.O