==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
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
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
On Sun, May 24, 2009 at 12:31 AM, Pavel Stehule pavel.steh...@gmail.com 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
On Sun, May 24, 2009 at 8:44 AM, Dave Page dp...@pgadmin.org wrote:
On Sun, May 24, 2009 at 12:31 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
why we develop a new syntax?
we should have a secondary function explain_query(query_string,
option) that returns setof some. Next
2009/5/24 Robert Haas robertmh...@gmail.com:
On Sun, May 24, 2009 at 8:44 AM, Dave Page dp...@pgadmin.org wrote:
On Sun, May 24, 2009 at 12:31 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
why we develop a new syntax?
we should have a secondary function
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
2009/5/24 Robert Haas robertmh...@gmail.com:
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
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
Tom Lane escribió:
Robert Haas robertmh...@gmail.com 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
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
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 helps to
Ben Ali Rachid souliman...@yahoo.fr 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,
...
) ;
Dmitry Koterov dmi...@koterov.ru 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
On Sun, May 24, 2009 at 11:57 AM, Andrew Dunstan and...@dunslane.net 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,
On Sun, May 24, 2009 at 11:34 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane escribió:
Robert Haas robertmh...@gmail.com writes:
We currently have a (really handy) facility to pull a message from the
archives by message-ID, eg:
Robert Haas robertmh...@gmail.com 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'
On Sun, May 24, 2009 at 3:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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) and
Pavel Stehule pavel.steh...@gmail.com 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).
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
On Sun, May 24, 2009 at 4:37 PM, Gevik Babakhani pg...@xs4all.nl 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
Robert Haas robertmh...@gmail.com writes:
On Sun, May 24, 2009 at 3:09 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas wrote:
On Sun, May 24, 2009 at 4:37 PM, Gevik Babakhani pg...@xs4all.nl 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
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
Gevik Babakhani wrote:
Robert Haas wrote:
On Sun, May 24, 2009 at 4:37 PM, Gevik Babakhani pg...@xs4all.nl
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 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 headers
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
Andrew Dunstan and...@dunslane.net 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
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 syntax . Who will use this
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
Alvaro Herrera alvhe...@commandprompt.com 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
--
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
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com 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
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Zdenek Kotala zdenek.kot...@sun.com 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
Kenneth Marshall k...@rice.edu 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.
Greg Smith gsm...@gregsmith.com 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,
Andrew Dunstan and...@dunslane.net 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
http://archives.postgresql.org/pgsql-hackers/2009-05/index.php and all
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:
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.
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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 :-(
On Sun, May 24, 2009 at 4:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, May 24, 2009 at 3:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You know about SET LOCAL, no? I don't think this argument is very
convincing.
I completely fail to see how that
On Sun, May 24, 2009 at 6:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith gsm...@gregsmith.com 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
On Sun, May 24, 2009 at 6:05 PM, Greg Smith gsm...@gregsmith.com 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
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
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
On Sun, May 24, 2009 at 06:53:29PM -0400, Tom Lane wrote:
Greg Smith gsm...@gregsmith.com 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
48 matches
Mail list logo
