Hi, thanks for the comment!
On Mon, Dec 8, 2008 at 11:04 PM, Simon Riggs [EMAIL PROTECTED] wrote:
Could we start with pictures and some descriptions first, so we know
we're on the right track? I foresee no coding issues.
My understanding is that we start with a normal log shipping
On Sun, 7 Dec 2008, Alex Hunsaker wrote:
(dual core machine, --enable-debug, --enable-cassert build)
pgbench -c 2 -T60 -n -f test.sql
HEAD: tps = 9.674423
PATCH: tps = 9.695784
Two general suggestions here, not specific to this patch:
While it's good to do most testing with debug and
if I may request one simple change/addition, Probably trivial to add,
but I don't have too much time to give away now to any other project
than one that pays my debts.
The default param that's in the middle. Would it be hard, or do anyone
objects against adding 'default' keyword there, so
2008/12/9 Grzegorz Jaskiewicz [EMAIL PROTECTED]:
if I may request one simple change/addition, Probably trivial to add, but I
don't have too much time to give away now to any other project than one that
pays my debts.
The default param that's in the middle. Would it be hard, or do anyone
Grzegorz Jaskiewicz wrote:
if I may request one simple change/addition, Probably trivial to add,
but I don't have too much time to give away now to any other project
than one that pays my debts.
The default param that's in the middle. Would it be hard, or do anyone
objects against adding
Hi Tom,
On Mon, 8 Dec 2008, Tom Lane wrote:
Date: Mon, 08 Dec 2008 13:15:28 -0500
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Heikki Linnakangas [EMAIL PROTECTED],
Zdenek Kotala [EMAIL PROTECTED],
pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] cvs
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
I saw a report at .br mailing list [1] complaining about the message's title.
I do not try to investigate it. Am I missing something?
euler=# select attname from pg_attribute where attnum 0 and attnum
ALL(select conkey from pg_constraint
Grzegorz Jaskiewicz wrote:
Ok, how about
CREATE FUNCTION FOO (one int, two float8 default 3.14, three int[]
default '{6,7,8,90}');
and than SELECT FOO( 777, DEFAULT, '{1,2,3,4,5}');
Yeah, that could be a useful feature.
--
Sent via pgsql-hackers mailing list
[EMAIL PROTECTED] napsal(a):
I first misread your mail, and added only the first fprintf , while I
was uploading a 400M initdb.log, I went back to add the second one.
Guess what! with the fprintf .. descending node... in place, everything
goes well. The optimizer definitly does something
Grzegorz Jaskiewicz [EMAIL PROTECTED] writes:
The default param that's in the middle. Would it be hard, or do anyone
objects against adding 'default' keyword there, so one doesn't have to
substitute default param 3, when he only wants to override 2nd in
funct(1,2,3) ?
Yes, and yes. We
On Tue, 2008-12-09 at 17:15 +0900, Fujii Masao wrote:
But what is p.7? It's even more complex than the original. Forgive me,
but I don't understand that. Can you explain?
p.7 shows one of the system configuration examples. Some people don't
want to share an archive between two servers
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I thought that output of new counters are too wide and it brakes
compatibility of EXPLAIN ANALYZE. On the other hand, we don't have to
think of compatibility in EXPLAIN ANALYZE VERBOSE because it is newly
added in 8.4. However, overheads should be
Decibel! wrote:
On Nov 30, 2008, at 12:04 PM, David E. Wheeler wrote:
Agreed, default values should not be a part of function signatures,
although it might be nice if ALTER FUNCTION to allow default values to
be changed.
It would be VERY nice. I routinely cut and paste an entire function
Simon Riggs wrote:
For clarity: I don't think its acceptable to have the archiver send
files to the archive at the same time as we're streaming data. In normal
running we should not duplicate the data paths - its just too much data
volume and/or bandwidth.
What if you want to run archiving for
Ok, how about
CREATE FUNCTION FOO (one int, two float8 default 3.14, three int[]
default '{6,7,8,90}');
and than SELECT FOO( 777, DEFAULT, '{1,2,3,4,5}');
I have no idea what SQL standard says in that case, all I know is that
keyword DEFAULT exists in it, and is used in queries for
Josh Williams wrote:
The patch adds a query against pg_depend, then fakes an extra column
owned_by in the output:
Please send a context diff (diff -c)
Index: src/bin/psql/describe.c
===
RCS file:
2008/12/9 Grzegorz Jaskiewicz [EMAIL PROTECTED]:
Ok, how about
CREATE FUNCTION FOO (one int, two float8 default 3.14, three int[] default
'{6,7,8,90}');
and than SELECT FOO( 777, DEFAULT, '{1,2,3,4,5}');
I have no idea what SQL standard says in that case, all I know is that
keyword
[EMAIL PROTECTED] writes:
Guess what! with the fprintf .. descending node... in place, everything
goes well. The optimizer definitly does something weird along the
definition/assignement of leftok/rightok..
Hmm, so the problem is in that second loop. The trick is to pick some
reasonably
Alex Hunsaker wrote:
On Fri, Dec 5, 2008 at 14:22, Andrew Chernow [EMAIL PROTECTED] wrote:
Alex Hunsaker wrote:
On Fri, Dec 5, 2008 at 13:58, Andrew Chernow [EMAIL PROTECTED] wrote:
Who anyone be opposed to ssldir = path as a connection option?
Currently,
there is no way to change the
Fujii Masao wrote:
Hi,
On Mon, Dec 8, 2008 at 11:39 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
To set or clear the flag from PGPROC, to send or handle a signal, we have
to acquire ProcArrayLock. Is that safe to do in a signal
Alvaro Herrera [EMAIL PROTECTED] writes:
Josh Williams wrote:
The patch adds a query against pg_depend, then fakes an extra column
owned_by in the output:
Please send a context diff (diff -c)
Don't bother --- it's a really bad idea as designed anyway. owned_by
is not a column of a sequence
Magnus Hagander wrote:
* Renamed PGROOTCERT to PGSSLROOTCERT
+primaryenvarPGROOTCERT/envar/primary
Looks like the old env name is still being used in the sgml docs.
I like the flexibility this patch offers.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Pavel Stehule [EMAIL PROTECTED] writes:
select foo(777, three= '{1,2,3,4,5});
it's more safe and more readable.
... and it breaks an operator that's already in use.
I did some test, and I thing so it is implementable. I had to solve
problem with hstore module. There is defined operator =
Andrew Chernow wrote:
Magnus Hagander wrote:
* Renamed PGROOTCERT to PGSSLROOTCERT
+primaryenvarPGROOTCERT/envar/primary
Looks like the old env name is still being used in the sgml docs.
Yes - I did say I hadn't updated the docs yet :-)
//Magnus
--
Sent via pgsql-hackers
On Mon, Dec 8, 2008 at 5:15 PM, Merlin Moncure [EMAIL PROTECTED] wrote:
Hello,
I've been bit by this about a million times:
select (func()).* executes the function once per each field in the
returned tuple. See the example below:
create function foo_func() returns foo as
$$
declare f
2008/12/9 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
select foo(777, three= '{1,2,3,4,5});
it's more safe and more readable.
... and it breaks an operator that's already in use.
I did some test, and I thing so it is implementable. I had to solve
problem with
On Dec 8, 2008, at 5:15 PM, Merlin Moncure wrote:
Hello,
I've been bit by this about a million times:
select (func()).* executes the function once per each field in the
returned tuple. See the example below:
I ran into this exact problem a week or two ago.
I didn't dig too far into it
Here's an update to eliminate two small bitrot conflicts.
posix_fadvise_v22.diff.gz
Description: Binary data
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
--
Sent via pgsql-hackers mailing list
Tom Lane escreveu:
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
I saw a report at .br mailing list [1] complaining about the message's title.
I do not try to investigate it. Am I missing something?
euler=# select attname from pg_attribute where attnum 0 and attnum
ALL(select
Heikki Linnakangas [EMAIL PROTECTED] writes:
Thank you. Looks good to me, committed with minor changes.
I don't think this patch is anywhere near ready to apply. In the first
place, touching the PGPROC like that without any lock seems completely
unsafe --- among other things, you're relying on
Magnus Hagander [EMAIL PROTECTED] writes:
I would also like to look this over completely - we only support loading
the KEY from the smartcard, but you still have to manually copy the
certificate to your machine. I don't know exactly how you're supposed to
do this in OpenSSL - some googling
Attached patch replaces the SSL BIO wrapper code we have now, with one
that directly calls the send() and recv() functions instead. THis means
that they get passed through the rewrite macros to our internal
functions on Win32, and I think this will fix some of the strange errors
that seem to be
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I would also like to look this over completely - we only support loading
the KEY from the smartcard, but you still have to manually copy the
certificate to your machine. I don't know exactly how you're supposed to
do this in OpenSSL -
Pavel Stehule [EMAIL PROTECTED] writes:
2008/12/9 Tom Lane [EMAIL PROTECTED]:
... and it breaks an operator that's already in use.
what is acceptable workaround? I unhappy, so this symbol was used for
this minor contrib module (for this operator doesn't exists regress
test).
If you could
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
Tom Lane escreveu:
It's entirely right: there's no such operator.
Out of curiosity, why the other queries work?
The behavior is different depending on whether the argument of ANY/ALL
is a sub-SELECT or not. If it is, then the comparisons
On the other hand, we don't have to
think of compatibility in EXPLAIN ANALYZE VERBOSE because it is newly
added in 8.4.
Uh, it exists for me in 8.2.9.
Welcome to psql 8.2.9, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
2008/12/9 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
2008/12/9 Tom Lane [EMAIL PROTECTED]:
... and it breaks an operator that's already in use.
what is acceptable workaround? I unhappy, so this symbol was used for
this minor contrib module (for this operator doesn't
Pavel Stehule [EMAIL PROTECTED] writes:
2008/12/9 Tom Lane [EMAIL PROTECTED]:
If you could prove that it were *only* being used by this contrib module
then I might hold still for replacing it. But you can't. The odds are
good that people have custom data types using similarly-named
it means, so we must not implement any new operator?
If the operator were called [EMAIL PROTECTED], I think you could make a good
argument that no one else is likely using that for anything.
Surely the same cannot be said of =
Of course, [EMAIL PROTECTED] is not a very convenient name for an
2008/12/9 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
2008/12/9 Tom Lane [EMAIL PROTECTED]:
If you could prove that it were *only* being used by this contrib module
then I might hold still for replacing it. But you can't. The odds are
good that people have custom
On Tue, 2008-12-09 at 09:32 -0500, Tom Lane wrote:
I think the place that such information could most naturally be squeezed
into psql's \d commands would be to add another type of footer
information to \dt, eg
Table foo.bar
...
Indexes:
bari ...
Following a failed BIOS flash on one of our machines, the Windows
buildfarm members Mastodon, Baiji, Narwahl and Vaquita are offline.
The box is under warranty, so I hope to have it fixed within a few
days (timing being largely dependent upon persuading an engineer to
visit at the same time as I'm
Pavel Stehule [EMAIL PROTECTED] writes:
what is problematic on GUC?
Basically, it's a bad idea to have GUCs that silently make significant
changes in the syntactic meaning of a query. We've learned that lesson
the hard way I think. There are places where we've been forced to do
it because of
Pavel Stehule [EMAIL PROTECTED] writes:
2008/12/9 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
2008/12/9 Tom Lane [EMAIL PROTECTED]:
... and it breaks an operator that's already in use.
what is acceptable workaround? I unhappy, so this symbol was used for
this minor
Magnus Hagander [EMAIL PROTECTED] writes:
Attached patch replaces the SSL BIO wrapper code we have now, with one
that directly calls the send() and recv() functions instead. THis means
that they get passed through the rewrite macros to our internal
functions on Win32, and I think this will fix
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Thank you. Looks good to me, committed with minor changes.
I don't think this patch is anywhere near ready to apply.
Ok, I'll revert it if you feel that strongly.
In the first
place, touching the PGPROC like that without any
Robert Haas [EMAIL PROTECTED] writes:
On the other hand, we don't have to
think of compatibility in EXPLAIN ANALYZE VERBOSE because it is newly
added in 8.4.
Uh, it exists for me in 8.2.9.
The current behaviour is newly added in 8.4. In 8.2 it meant something
completely different and quite
Robert Haas [EMAIL PROTECTED] writes:
On the other hand, we don't have to
think of compatibility in EXPLAIN ANALYZE VERBOSE because it is newly
added in 8.4.
Uh, it exists for me in 8.2.9.
EXPLAIN VERBOSE has existed at least back to 7.0, probably further.
However, we've felt free to whack
Hi,
I hope I'm not disturbing hackers at work by talking about completely
unrelated things but...
Le mardi 09 décembre 2008, Tom Lane a écrit :
I think we need something closer to the postmaster signal multiplexing
mechanism, wherein there is a dedicated shared memory area of static
layout
Dimitri Fontaine escribió:
Le mardi 09 décembre 2008, Tom Lane a écrit :
I think we need something closer to the postmaster signal multiplexing
mechanism, wherein there is a dedicated shared memory area of static
layout that holds the signaling flags. And it needs to be driven off
of
How would a user recognise which of these are legal operator names?
Incidentally -- EDB selling Oracle compatibility may put me in a questionable
position here -- the more Oracle incompatibilities in stock Postgres the
better for us. But afaik we don't emulate = anyways so that hardly
Andrew Chernow wrote:
Looks like the ArchiveHandle variable 'AH' and the TocEntry
'next_work_item' are not being deep copied at line 315 of your patch,
where you prepare the RestoreArgs struct for the thread. Every thread
is accessing and possibly updating the members of these structs
As stuff matures and becomes indispensable we could consider moving it to the
regular EXPLAIN or implement some way to specify precisely which data the user
wants. Or just say XML/table data/whatever will solve the problem for us.
I think some way to specify precisely which data the user wants
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'm surprised you feel that way. You suggested earlier
(http://archives.postgresql.org/message-id/[EMAIL PROTECTED])
that a solution that only works for processes attached to shared memory
would probably suffice for now.
Well, I wasn't
On Tue, 9 Dec 2008, Tom Lane wrote:
Date: Tue, 09 Dec 2008 09:23:06 -0500
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Heikki Linnakangas [EMAIL PROTECTED],
Zdenek Kotala [EMAIL PROTECTED],
pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] cvs head
I'm not sure what the best way is though. I don't think continuing to
add keywords between EXPLAIN and the start of the query is very
scalable. Putting parentheses around the option list seems like it
might eliminate a lot of grammar headaches:
Do you think it is required to invent special
Would it be reasonable to turn of optimization for this file?
Ken
On Tue, Dec 09, 2008 at 05:47:47PM +0100, [EMAIL PROTECTED] wrote:
On Tue, 9 Dec 2008, Tom Lane wrote:
Date: Tue, 09 Dec 2008 09:23:06 -0500
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Heikki Linnakangas
[EMAIL PROTECTED] writes:
On Tue, 9 Dec 2008, Tom Lane wrote:
Hmm, so the problem is in that second loop. The trick is to pick some
reasonably non-ugly code change that makes the problem go away.
I tried that and moving leftok,rightok declaration outside the loop, and
refactor the
Parts of AH need deep cloning, notably the formatData member, which is
done in _ReopenArchive().
Is it okay to clone this from within the thread?
The reopen() appears to mess with AH-FH, which mutltiple threads are
calling fclose on. The second thread is going to fail and the first
Hello,
I'm writing my bachelor thesis and I can't find anywhere what exactly means
the third parameter in ScanKeyword in pgsql/src/backend/parser/keywords.c -
specificly UNRESERVED_KEYWORD, RESERVED_KEYWORD, TYPE_FUNC_NAME_KEYWORD,
COL_NAME_KEYWORD. Could someone explain it to me? Thank you
Kind
Pavel Stehule [EMAIL PROTECTED] writes:
PL/pgSQL PL/SQL ADA so using '=' is only consistent and natural.
And it is my goal.
[ shrug... ] Don't be too surprised when the patch gets rejected.
Oracle compatibility is nice when we can get it, but we aren't going
to break existing behavior for
On Tue, Dec 9, 2008 at 01:20, Greg Smith [EMAIL PROTECTED] wrote:
On Sun, 7 Dec 2008, Alex Hunsaker wrote:
(dual core machine, --enable-debug, --enable-cassert build)
pgbench -c 2 -T60 -n -f test.sql
HEAD: tps = 9.674423
PATCH: tps = 9.695784
Two general suggestions here, not specific to
On Mon, Dec 8, 2008 at 23:28, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Alex Hunsaker [EMAIL PROTECTED] wrote:
I was assigned to review this.
Thanks for your reviewing.
I assume that the basic concepts are ok and focus of discussion is in:
- New counters in struct Instrumentation.
Andrew Chernow wrote:
Parts of AH need deep cloning, notably the formatData member, which
is done in _ReopenArchive().
Is it okay to clone this from within the thread?
I don't see why not.
The reopen() appears to mess with AH-FH, which mutltiple threads are
calling fclose on. The
Yes this is one reasonable option, as is the idea of using XML or a
table and making it the client's problem. Neither are going to happen
for this release I think.
And in any case it will always be useful to have an option to print
all the available information anyways so we make as well
Andrew Dunstan wrote:
No, as this fragment shows, fclose() is NOT called on Windows.
Oooppps. I'm the village idiot today.
The program dies with a nasty dialog box when restoring a dump of the
regression database after the second COPY thread disconnects.
I'll poke around but
On Tue, Dec 9, 2008 at 8:53 PM, Robert Haas [EMAIL PROTECTED] wrote:
On Tue, Dec 9, 2008 at 12:44 PM, Greg Stark [EMAIL PROTECTED]
wrote:
Yes this is one reasonable option, as is the idea of using XML or a table
and making it the client's problem. Neither are going to happen for this
[EMAIL PROTECTED] writes:
FWIW, I have attached the 2 generated .s. Someone with knowledge of asm
may want to have a look..
Hmm. It looks to me like the compiler is getting confused by the
interaction between nodeno, leftnodeno, and rightnodeno. Try this
patch to see if it gets around it.
On Tue, Dec 9, 2008 at 12:44 PM, Greg Stark [EMAIL PROTECTED] wrote:
Yes this is one reasonable option, as is the idea of using XML or a table
and making it the client's problem. Neither are going to happen for this
release I think.
Agreed.
And in any case it will always be useful to have an
Parts of AH need deep cloning, notably the formatData member, which
is done in _ReopenArchive().
Is it okay to clone this from within the thread?
I don't see why not.
Because another thread may be modifying the memory you are trying to
clone. If no one modifies the formatData struct,
2008/12/9 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
PL/pgSQL PL/SQL ADA so using '=' is only consistent and natural.
And it is my goal.
[ shrug... ] Don't be too surprised when the patch gets rejected.
Oracle compatibility is nice when we can get it, but we
On Sun, Dec 7, 2008 at 19:13, Alex Hunsaker [EMAIL PROTECTED] wrote:
On Tue, Dec 2, 2008 at 02:35, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Here is an update version of contrib/pg_stat_statements.
Hello again!
I was assigned to review this.
... Some other things I accidentally left out.
Andrew Chernow wrote:
Parts of AH need deep cloning, notably the formatData member, which
is done in _ReopenArchive().
Is it okay to clone this from within the thread?
I don't see why not.
Because another thread may be modifying the memory you are trying to
clone. If no one
On Tue, Dec 9, 2008 at 10:46 AM, Josh Williams [EMAIL PROTECTED] wrote:
On Tue, 2008-12-09 at 09:32 -0500, Tom Lane wrote:
I think the place that such information could most naturally be squeezed
into psql's \d commands would be to add another type of footer
information to \dt, eg
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Attached patch replaces the SSL BIO wrapper code we have now, with one
that directly calls the send() and recv() functions instead. THis means
that they get passed through the rewrite macros to our internal
functions on Win32, and I
Andrew Dunstan wrote:
Andrew Chernow wrote:
Parts of AH need deep cloning, notably the formatData member, which
is done in _ReopenArchive().
Is it okay to clone this from within the thread?
I don't see why not.
Because another thread may be modifying the memory you are trying to
Dear Postgres Folk,
In working with tsvectors (added in 8.3), I've come to a place where
my syntax-fu has failed me. I've resorted to turning a result set of
records into strings so that I can regexp out the record fields I
need, rather than access them directly, as I'm sure it's possible
Magnus Hagander [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
I'll try. It's unfortunately not as simple as it sounds, because of the
way the abstractions are arranged. I can't count the number of times I
have had to stop and try to clear my head while working on this code.
That's what
try
select * from ts_stat()
btw, performance of ts_stat() was greatly improved in 8.4.
Oleg
On Tue, 9 Dec 2008, Dan Chak wrote:
Dear Postgres Folk,
In working with tsvectors (added in 8.3), I've come to a place where my
syntax-fu has failed me. I've resorted to turning a result set of
Dan Chak [EMAIL PROTECTED] writes:
If I say stat.word (instead of subscripting), I get 'missing FROM-
clause entry for table stat'. If I say foo.stat.word, I get
'ERROR: schema foo does not exist'.
I think the syntax you need is (stat).word etc. See Field Selection
here:
Oleg,
This syntax works fine until I also want to get the sentence_id
column in there as well, so that I can differentiate one set of
ts_stat results from another. With the syntax where ts_stat is
treated like a table, it isn't possible to run ts_stat separately on
multiple tsvectors as
That works perfectly!
Thanks,
Dan
On Dec 9, 2008, at 3:13 PM, Tom Lane wrote:
Dan Chak [EMAIL PROTECTED] writes:
If I say stat.word (instead of subscripting), I get 'missing FROM-
clause entry for table stat'. If I say foo.stat.word, I get
'ERROR: schema foo does not exist'.
I think the
Josh Williams wrote:
On Tue, 2008-12-09 at 09:32 -0500, Tom Lane wrote:
I think the place that such information could most naturally be squeezed
into psql's \d commands would be to add another type of footer
information to \dt, eg
Table foo.bar
...
Indexes:
On Tue, 9 Dec 2008, Dan Chak wrote:
Oleg,
This syntax works fine until I also want to get the sentence_id column in
there as well, so that I can differentiate one set of ts_stat results from
another. With the syntax where ts_stat is treated like a table, it isn't
possible to run ts_stat
Peter Eisentraut wrote:
Attached is my current patch after surgery. I have mainly worked on
making naming better and more consistent.
Thanks.
Problem: You have implemented foreign-data wrappers and foreign servers
as schema-qualified objects, but the standard has them outside schemas,
ok, here is a function ( credits to Teodor )
CREATE OR REPLACE FUNCTION ts_stat(tsvector, OUT word text, OUT ndoc
integer, OUT nentry integer)
RETURNS SETOF record AS
$$
SELECT ts_stat('SELECT ' || quote_literal( $1::text ) || '::tsvector');
$$ LANGUAGE SQL RETURNS NULL ON NULL INPUT
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
I'll try. It's unfortunately not as simple as it sounds, because of the
way the abstractions are arranged. I can't count the number of times I
have had to stop and try to clear my head while working on this code.
Magnus Hagander [EMAIL PROTECTED] writes:
The logic in it is identical to the original import of code in OpenSSL.
It originally had #ifdefs around how the BIO interface worked. That was
tidied up in a commit back in 2001. I think it's fair to say it's been
pretty stable.
Fair enough.
Do you
Hello all,
FOSDEM 2009 will take place february 7-8 2009 in Brussels, Belgium.
We want to continue the great success from last year and again we have
a booth, and a devroom together with the BSD groups.
Please submit your talk(s) to [EMAIL PROTECTED] until 2009-01-02,
include the topic and the
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
I'll try. It's unfortunately not as simple as it sounds, because of the
way the abstractions are arranged. I can't count the number of times I
have had to stop and try to clear my head while
Tom Lane wrote:
I think pretty much everybody except Philip Warner has found the stuff
around the TOC data structure and the archiver API to be confusing.
I'm not immediately sure about a better design though, at least not if
you don't want to duplicate a lot of code between the plain pg_dump
Philip Warner wrote:
Tom Lane wrote:
I think pretty much everybody except Philip Warner has found the stuff
around the TOC data structure and the archiver API to be confusing.
I'm not immediately sure about a better design though, at least not if
you don't want to duplicate a lot of code
Hi all,
While I was trying to find the right place to add a new page on the
wiki, I found the document of Simon on partitioning requirements
(http://wiki.postgresql.org/wiki/Image:Partitioning_Requirements.pdf)
referenced from http://wiki.postgresql.org/wiki/Development_projects
I think this
i have a view of code, and find a question.There is a variable named
'bloom_pruning set to be
'false' outside function 'bloom_filter_init' in file 'bloomfn.c', and there is
a stataments
if (bloom_pruning == false)
return;
at begin of the function bloom_filter_init.
And i don't find any
Hi,
On Wed, Dec 10, 2008 at 10:02 AM, Unicron [EMAIL PROTECTED] wrote:
i have a view of code, and find a question.There is a variable named
'bloom_pruning set to be
'false' outside function 'bloom_filter_init' in file 'bloomfn.c', and there
is a stataments
if (bloom_pruning == false)
Tom Lane [EMAIL PROTECTED] wrote:
Please split this into two separate patches that can be separately
evaluated.
Sure. I want to disucuss only where to add counters of buffer usage
and cpu usage, or they should not be added. However, it seems to
affect future of EXPLAIN ANALYZE, so we might
Alex Hunsaker [EMAIL PROTECTED] wrote:
#define GUCNAME(name) (statistics. name)
Why statistics?
Would not something like stat_statements make more sense? Statistics
seems fairly arbitrary...
Not to use duplicated statements words;
variable names contains statements already.
-
On Tuesday 09 December 2008 15:49:17 Alvaro Herrera wrote:
Josh Williams wrote:
On Tue, 2008-12-09 at 09:32 -0500, Tom Lane wrote:
I think the place that such information could most naturally be
squeezed into psql's \d commands would be to add another type of footer
information to \dt,
On Mon, Dec 8, 2008 at 10:24 AM, Gregory Stark [EMAIL PROTECTED] wrote:
I tried a different query, trying to get quadratic growth and again failed. It
The profiling results I sent the other day show an exactly-linear
increase in the number of times eqjoinsel invokes FunctionCall2.
Reading
I've been assigned to review this patch, but I confess I'm a little
murky on what problem it's trying to solve. Can you explain what I
need to do to recreate the problem?
In postgreSQL, Plugin modules should be installed in (Installation
dir)lib/plugins to run properly. There is logic in
1 - 100 of 103 matches
Mail list logo
