Re: [HACKERS] generic options for explain

2009/5/25 Tom Lane : > Greg Smith writes: >> On Sun, 24 May 2009, Pavel Stehule wrote: >>> we should have a secondary function explain_query(query_string, >>> option) that returns setof some. > >> +1.  The incremental approach here should first be adding functions that >> actually do the work requ

Re: [HACKERS] proposal: SQL parser integration to PL/pgSQL

2009/5/24 Tom Lane : > Pavel Stehule writes: >> ==Steps== >> 1. add hook to analyser (transform stage) to substitute unknown >> columnref by param - when analyser detect unknown columnref, then call >> callback, that returns possible para node or NULL (when external >> environment doesn't have a v

Re: [HACKERS] generic options for explain

On Sun, May 24, 2009 at 06:53:29PM -0400, Tom Lane wrote: > Greg Smith writes: > > On Sun, 24 May 2009, Pavel Stehule wrote: > >> we should have a secondary function explain_query(query_string, > >> option) that returns setof some. > > > +1. The incremental approach here should first be adding f

[HACKERS] No sanity checking performed on binary TIME parameters.

When submitting a query via the V3 binary protocol (PQexecParams, paramFormats[n]=1), it appears the PostgreSQL server performs no range checking on the passed values. Passing values greater than 24 hours results in unpredictable results (dumps that cannot be restored, strange output when p

Re: [HACKERS] generic options for explain

On Sun, 24 May 2009, Tom Lane wrote: A serious problem with EXPLAIN via a function returning set, or with putting the result into a table, is that set results are logically unordered, just as table contents are. Fair enough; I think Pavel and myself were presuming an implied "line number" in

Re: [HACKERS] generic options for explain

On Sun, May 24, 2009 at 6:05 PM, Greg Smith wrote: > On Sun, 24 May 2009, Pavel Stehule wrote: > >> we should have a secondary function explain_query(query_string, >> option) that returns setof some. > > +1.  The incremental approach here should first be adding functions that > actually do the wor

Re: [HACKERS] generic options for explain

On Sun, May 24, 2009 at 6:53 PM, Tom Lane wrote: > Greg Smith writes: >> On Sun, 24 May 2009, Pavel Stehule wrote: >>> we should have a secondary function explain_query(query_string, >>> option) that returns setof some. > >> +1.  The incremental approach here should first be adding functions that

Re: [HACKERS] generic options for explain

On Sun, May 24, 2009 at 4:59 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, May 24, 2009 at 3:09 PM, Tom Lane wrote: >>> You know about SET LOCAL, no?  I don't think this argument is very >>> convincing. > >> I completely fail to see how that helps me. > > Mainly, what it does is avoid hav

Re: [HACKERS] pull raw text of a message by message-id

Tom Lane wrote: Alvaro Herrera writes: There already is one :-) Look at the headers -- after the Message-Id there is a link which says "text/plain". On the couple of messages I tried this on, that link leads to a page saying "not found" :-( Really? I

Re: [HACKERS] WAL archive, warm backup and read-only slave

pg...@mohawksoft.com writes: > How difficult would it be, and does anyone think it is possible to have a > continuous "restore_command" ala pg_standby running AND have the database > operational in a "read-only" mode? See all the discussion of "hot standby" over the past eight or so months.

[HACKERS] WAL archive, warm backup and read-only slave

How difficult would it be, and does anyone think it is possible to have a continuous "restore_command" ala pg_standby running AND have the database operational in a "read-only" mode? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] pull raw text of a message by message-id

Andrew Dunstan writes: > Tom Lane wrote: >> On the couple of messages I tried this on, that link leads to a page >> saying "not found" :-( > Really? I just tried 4 pages picked at random off the -hackers list > and all > the "tex

Re: [HACKERS] generic options for explain

Greg Smith writes: > On Sun, 24 May 2009, Pavel Stehule wrote: >> we should have a secondary function explain_query(query_string, >> option) that returns setof some. > +1. The incremental approach here should first be adding functions that > actually do the work required. Then, if there's a se

Re: [HACKERS] [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)

Kenneth Marshall writes: > On Sat, May 23, 2009 at 02:52:49PM -0400, Zdenek Kotala wrote: >>> Attached patch cleanups hash index headers to allow compile hasham for >>> 8.3 version. It helps to improve pg_migrator with capability to migrate >>> database with hash index without reindexing. > How d

Re: [HACKERS] integer overflow in reloption.h

Zdenek Kotala writes: > The problem is on the following lines > typedef enum relopt_kind > { > ... > RELOPT_KIND_MAX = (1 << 31) > } > enum is int datatype and 1 << 31 == -2147483648. It is reason why > compiler (sun studio) complains. > Is possible to change it to 1 << 30 to stop compi

Re: [HACKERS] pg_class and enum types

Tom Lane wrote: Andrew Dunstan writes: Gevik Babakhani wrote: select * from pg_class where relname='test_type' It's not so much that enum types are handled specially, but that composite types are. :-) Relations (tables) have always had both pg_class and pg_type entr

Re: [pgsql-www] [HACKERS] pull raw text of a message by message-id

Tom Lane escribió: > Alvaro Herrera writes: > > There already is one :-) Look at the headers -- after the Message-Id there > > is > > a link which says "text/plain". > > On the couple of messages I tried this on, that link leads to a page > saying "not found" :-( Probably you tried messages th

Re: [HACKERS] generic options for explain

On Sun, 24 May 2009, Pavel Stehule wrote: we should have a secondary function explain_query(query_string, option) that returns setof some. +1. The incremental approach here should first be adding functions that actually do the work required. Then, if there's a set of those that look to be

Re: [HACKERS] pull raw text of a message by message-id

Alvaro Herrera writes: > There already is one :-) Look at the headers -- after the Message-Id there is > a link which says "text/plain". On the couple of messages I tried this on, that link leads to a page saying "not found" :-( regards, tom lane -- Sent via pgsql-hack

[HACKERS] A couple of regression test anomalies

During PGCon, Teodor asked me about a couple of odd behaviors in the regression tests --- the output from Peter's code coverage tests was showing that some GIN code he expected to be exercised wasn't. After some poking around, I think we've narrowed it down to two separate issues: 1. In create_ind

Re: [HACKERS] generic options for explain

On Sun, May 24, 2009 at 11:57:13AM -0400, Andrew Dunstan wrote: > > > Robert Haas wrote: EXPLAIN ('hash_detail', 'on') query... >> >> Oops, I should have written EXPLAIN (hash_detail 'on') query... can't >> follow my own syntax. >> >> >>> I am sorry - this is really strange synt

Re: [HACKERS] pg_class and enum types

Andrew Dunstan writes: > Gevik Babakhani wrote: >> select * from pg_class where relname='test_type' > It's not so much that enum types are handled specially, but that > composite types are. :-) Relations (tables) have always had both pg_class and pg_type entries. The pg_class entry denotes the

Re: [HACKERS] pg_class and enum types

Andrew Dunstan wrote: Gevik Babakhani wrote: I was wondering why there is no pg_class record for the enum types. Do we treat the enum types differently? Why do you think we should? What would the record look like? cheers andrew I am not implying whether we should or we should not. I w

Re: [HACKERS] pull raw text of a message by message-id

Robert Haas escribió: > Oh, this is awesome. It would be handy to include a link on the HTML > version of the page for when people are trying to pull down a patch > that someone has foolishly included in the body of the email rather > than attaching it. There already is one :-) Look at the head

Re: [HACKERS] pg_class and enum types

Gevik Babakhani wrote: Robert Haas wrote: On Sun, May 24, 2009 at 4:37 PM, Gevik Babakhani wrote: I was wondering why there is no pg_class record for the enum types. Do we treat the enum types differently? Because types are stored in pg_type, not pg_class? ...Robert That is ce

Re: [HACKERS] pg_class and enum types

Gevik Babakhani wrote: I was wondering why there is no pg_class record for the enum types. Do we treat the enum types differently? Why do you think we should? What would the record look like? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chan

Re: [HACKERS] pg_class and enum types

Robert Haas wrote: On Sun, May 24, 2009 at 4:37 PM, Gevik Babakhani wrote: I was wondering why there is no pg_class record for the enum types. Do we treat the enum types differently? Because types are stored in pg_type, not pg_class? ...Robert That is certainly not true check

Re: [HACKERS] generic options for explain

Robert Haas writes: > On Sun, May 24, 2009 at 3:09 PM, Tom Lane wrote: >> You know about SET LOCAL, no? I don't think this argument is very >> convincing. > I completely fail to see how that helps me. Mainly, what it does is avoid having to know exactly what the old setting was.

Re: [HACKERS] pg_class and enum types

On Sun, May 24, 2009 at 4:37 PM, Gevik Babakhani wrote: > I was wondering why there is no pg_class record for the enum types. Do we > treat the enum types differently? Because types are stored in pg_type, not pg_class? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.

[HACKERS] pg_class and enum types

I was wondering why there is no pg_class record for the enum types. Do we treat the enum types differently? -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal: SQL parser integration to PL/pgSQL

Pavel Stehule writes: > ==Steps== > 1. add hook to analyser (transform stage) to substitute unknown > columnref by param - when analyser detect unknown columnref, then call > callback, that returns possible para node or NULL (when external > environment doesn't have a variable). Returned param sho

Re: [HACKERS] Oracle to Postgres : create type as object in Postgres

>No, we don't have any concept of member functions.  Just create the >composite type (I'm assuming it needs to be composite) and then create >functions that take it as parameter. > >Note that because PG allows function overloading, there's no conflict >between, say, to_string(D_Temp_Element) a

Re: [HACKERS] generic options for explain

On Sun, May 24, 2009 at 3:09 PM, Tom Lane wrote: > Robert Haas writes: >> I wouldn't mind having a GUC to set the *default* explain behavior - >> but I'd still like to be able to override it for a particular command >> if I so choose.  And that's not going to be possible with your syntax: >> if e

Re: [HACKERS] generic options for explain

Robert Haas writes: > I wouldn't mind having a GUC to set the *default* explain behavior - > but I'd still like to be able to override it for a particular command > if I so choose. And that's not going to be possible with your syntax: > if explain_format is set to 'xml, verbose' and I want plain

Re: [HACKERS] pull raw text of a message by message-id

On Sun, May 24, 2009 at 11:34 AM, Alvaro Herrera wrote: > Tom Lane escribió: >> Robert Haas writes: >> > We currently have a (really handy) facility to pull a message from the >> > archives by message-ID, eg: >> >> > http://archives.postgresql.org/message-id/603c8f070905202040v66cd3054t434c0b73aa

Re: [HACKERS] generic options for explain

On Sun, May 24, 2009 at 11:57 AM, Andrew Dunstan wrote: >> Oops, I should have written EXPLAIN (hash_detail 'on') query... can't >> follow my own syntax. >>> I am sorry - this is really strange syntax . Who will use this syntax? >>> For some parser is little bit better function call, than parametr

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

Dmitry Koterov writes: > No, I meant that in case of the row (1, NULL, NULL, 2, 3, NULL): > - the corresponding NULL bitmap is (100110...) > - the corresponding tuple is (1, 2, 3) > - t_natts=3 (if I am not wrong here) You are wrong --- t_natts would be six here. In general the length of the nul

Re: [HACKERS] Oracle to Postgres : create type as object in Postgres

Ben Ali Rachid writes: > I've a Oracle type that I must translate to Postgres. This Oracle type is > like below : > CREATE OR REPLACE > type D_Temp_Element as object > ( >    MEMBER FUNCTION to_string return Varchar2, >    MEMBER FUNCTION duration return D_Interval, >    ... > ) ; > How can I d

Re: [HACKERS] [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)

On Sat, May 23, 2009 at 02:52:49PM -0400, Zdenek Kotala wrote: > I forgot to fix contrib. Updated patch attached. > > Zdenek > > Zdenek Kotala pe v p?? 22. 05. 2009 v 16:23 -0400: > > Attached patch cleanups hash index headers to allow compile hasham for > > 8.3 version. It help

Re: [HACKERS] generic options for explain

Robert Haas wrote: EXPLAIN ('hash_detail', 'on') query... Oops, I should have written EXPLAIN (hash_detail 'on') query... can't follow my own syntax. I am sorry - this is really strange syntax . Who will use this syntax? For some parser is little bit better function call, than par

Re: [HACKERS] pull raw text of a message by message-id

Tom Lane escribió: > Robert Haas writes: > > We currently have a (really handy) facility to pull a message from the > > archives by message-ID, eg: > > > http://archives.postgresql.org/message-id/603c8f070905202040v66cd3054t434c0b73aa844...@mail.gmail.com > > > Could we possibly get a similar ty

[HACKERS] Oracle to Postgres : create type as object in Postgres

Hello, I've a Oracle type that I must translate to Postgres. This Oracle type is like below : CREATE OR REPLACE type D_Temp_Element as object (    MEMBER FUNCTION to_string return Varchar2,    MEMBER FUNCTION duration return D_Interval,    ... ) ; How can I do that in Postgres ? Is there somet

Re: [HACKERS] generic options for explain

2009/5/24 Robert Haas : >>> EXPLAIN ('hash_detail', 'on') query... > > Oops, I should have written EXPLAIN (hash_detail 'on') query... can't > follow my own syntax. > >> I am sorry - this is really strange syntax . Who will use this syntax? >> For some parser is little bit better function call, tha

Re: [HACKERS] generic options for explain

>> EXPLAIN ('hash_detail', 'on') query... Oops, I should have written EXPLAIN (hash_detail 'on') query... can't follow my own syntax. > I am sorry - this is really strange syntax . Who will use this syntax? > For some parser is little bit better function call, than parametrized > statement. Some

Re: [HACKERS] generic options for explain

2009/5/24 Robert Haas : > On Sun, May 24, 2009 at 8:44 AM, Dave Page wrote: >> On Sun, May 24, 2009 at 12:31 AM, Pavel Stehule >> wrote: >>> Hello >>> >>> why we develop a new syntax? >>> >>> we should have a secondary function explain_query(query_string, >>> option) that returns setof some. Nex

Re: [HACKERS] generic options for explain

On Sun, May 24, 2009 at 8:44 AM, Dave Page wrote: > On Sun, May 24, 2009 at 12:31 AM, Pavel Stehule > wrote: >> Hello >> >> why we develop a new syntax? >> >> we should have a secondary function explain_query(query_string, >> option) that returns setof some. Next function should be >> explain_qu

Re: [HACKERS] generic options for explain

On Sun, May 24, 2009 at 12:31 AM, Pavel Stehule wrote: > Hello > > why we develop a new syntax? > > we should have a secondary function explain_query(query_string, > option) that returns setof some. Next function should be > explain_query_xml. I thing so for typical use EXPLAIN statement is > enou

Re: [HACKERS] generic options for explain

Hi Robert, On 05/24/2009 02:47 AM, Robert Haas wrote: Well, here we are! Yet another thread about some piece of information that's omitted from EXPLAIN and can't easily be added because there are a zillion things we want to add to EXPLAIN and it's not OK to bury the user[1]! I've long been of

Re: [HACKERS] information_schema.columns changes needed for OLEDB

Josh Berkus wrote: On 5/23/09 7:37 PM, Konstantin Izmailov wrote: Number 4 is actually numeric_precision (I typed incorrectly). My recollection is that numeric_precision sometimes expressed in radix 2 and it caused issues for Windows apps. I agree on other issues. I was curious if database can

[HACKERS] proposal: SQL parser integration to PL/pgSQL

==Steps== 1. add hook to analyser (transform stage) to substitute unknown columnref by param - when analyser detect unknown columnref, then call callback, that returns possible para node or NULL (when external environment doesn't have a variable). Returned param should be typed or unknown (for poly