Radek Strnad wrote:
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? Th
Radek Strnad escreveu:
> 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
Hi,
Thanks for explaining the architecture in detail!
> If we want to include that as an option, yes. If it is "always on" then
> no, not everybody wants that.
Yes. I also think that archiving should be optional on each servers.
> The best way to implement that is to archive from the standby, n
>> 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
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 thro
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
> > > informat
"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"
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
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)
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 p
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
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
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_
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 whil
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 l
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.
>
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 o
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 IMMUTABL
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,
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 s
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"
> > ...
> >
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
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 a
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:
http:/
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 r
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
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
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 b
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
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
>>
>
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 modifie
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
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
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,
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 ha
[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 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 th
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 apparently
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 do
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
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 Instrumen
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, n
"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 behavio
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
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
fclo
[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
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 Linnak
>
> 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 spe
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
Subject: Re: [HACKERS] cvs head initdb hangs on unixware
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 comp
> 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 wan
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 that
>
> 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
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
>
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
"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
"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
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 l
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 wil
"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
"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
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
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:
> "ba
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 peo
> 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
"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-nam
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
> 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
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 compar
"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 y
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
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 pla
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 googlin
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 o
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 <>
>> AL
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 (pgsql-hackers@postgr
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 bu
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
>>
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
> $$
>
Andrew Chernow wrote:
> Magnus Hagander wrote:
>> * Renamed PGROOTCERT to PGSSLROOTCERT
>>
>> +PGROOTCERT
>
> 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 mailing list (pgsql-hack
"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 opera
Magnus Hagander wrote:
* Renamed PGROOTCERT to PGSSLROOTCERT
> +PGROOTCERT
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/
--
Sent via pgsql-hackers mailin
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
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 sign
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 w
[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 n
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
>
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: /projects/cvsroot/pgsql
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 b
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.
[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 we
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 (pgsql-hackers@postgresql.o
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_con
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
Subject: Re: [HACKERS] cvs head initdb hangs on un
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 sim
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 'defau
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
hea
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
>
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 one
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
1 - 100 of 103 matches
Mail list logo
