OK but what is the recommended way to get TupleDesc for p_type? I am aware
of RelationNameGetTupleDesc but I shouldn't use it since it is deprecated.
However by using it the code would look something like this (I tested it and
it works as expected):
Datum demo(PG_FUNCTION_ARGS) {
float8 xi =
On Mon, Sep 27, 2010 at 10:55 AM, Robert Haas wrote:
> Again, I think the real question is how to handle values that need to
> be maintained PER SLAVE from values of which there is only one copy.
Yep. One idea is to support something like "pg_ctl standby" and "pg_ctl pitr".
If we do so, we would
sorry for my slow response.
(2010/09/24 21:13), Robert Haas wrote:
This is a good point. On the one hand, I do agree that the API for
simple things like processing CSV files shouldn't be overly complex.
So perhaps we could start with a simple API and extend it later. On
the other hand, underst
On Mon, Sep 27, 2010 at 9:35 AM, Jaime Casanova wrote:
> Maybe i'm missing something but this would be a problem if we put a
> trigger file and the recovery.conf gets renamed to recovery.done, no?
> at least that would be a problem for the standbys that still need to
> be standbys
That's not prob
On Mon, Sep 27, 2010 at 2:19 PM, Josh Berkus wrote:
> While working on some database maintenance, I was just tripped up by the
> fact that there is no good way to query reloptions for tables. By "no good
> way" I mean "no way which does not involve UNNEST and regexps or procedural
> code".
Can y
All,
While working on some database maintenance, I was just tripped up by the
fact that there is no good way to query reloptions for tables. By "no
good way" I mean "no way which does not involve UNNEST and regexps or
procedural code".
This puts us in the wierd place that while one can ALTE
On Sat, Sep 25, 2010 at 7:04 AM, KaiGai Kohei wrote:
> * The "dummy_esp" module and regression test for SECURITY LABEL statement.
> This module allows only four labels: "unclassified", "classified",
> "secret" and "top secret". The later two labels can be set by only
> superusers. The new regre
David Christensen writes:
> On Sep 26, 2010, at 2:24 PM, Tom Lane wrote:
>> We could perhaps fix that if there were an inexpensive way to get the
>> SHA1 of the master commit that each branch is sprouted from.
> Particularly with PostgreSQL's linear branch history, `git merge-base` will
> show y
On Sep 26, 2010, at 2:24 PM, Tom Lane wrote:
> I wrote:
>> I think we could get that behavior fairly easily by remembering the last
>> tag matching one of the commits on a branch, as we chase the branch
>> backwards.
>
> I find that this works just fine for the branches, but not so well for
> ma
Attached is the patch that tries to speedup prep_buildtree script, which is
used in VPATH builds, from our configure script.
The idea is to ask `find` to emit directory listing in depth-first order so
that the `mkdir -p` will create the deepest directory first and any
subsequent `mkdir -p` on an i
On Sun, Sep 26, 2010 at 9:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Sep 26, 2010 at 8:56 PM, Tom Lane wrote:
>>> Yeah. The original design for recovery.conf envisioned that it has only
>>> a short lifespan while you're doing an archive recovery. Putting
>>> parameters for slave o
On Mon, Sep 27, 2010 at 3:20 AM, Robert Haas wrote:
> On Sun, Sep 26, 2010 at 9:14 PM, Gurjeet Singh
> wrote:
> > On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas
> wrote:
> >>
> >> On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
> >> >
> >>
> >> I maintain that if someone else whacked around one
On Sun, Sep 26, 2010 at 9:14 PM, Gurjeet Singh wrote:
> On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas wrote:
>>
>> On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
>> >
>>
>> I maintain that if someone else whacked around one of your commits the
>> way you whacked this around, you'd bite their he
On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas wrote:
> On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
> >
>
> I maintain that if someone else whacked around one of your commits the
> way you whacked this around, you'd bite their head off.
>
>
:) Yes, he would. And you are not being any less for
Robert Haas writes:
> On Sun, Sep 26, 2010 at 8:56 PM, Tom Lane wrote:
>> Yeah. The original design for recovery.conf envisioned that it has only
>> a short lifespan while you're doing an archive recovery. Putting
>> parameters for slave operation into it has contorted things beyond
>> recognit
Robert Haas writes:
> On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
>> I looked at doing that but it didn't seem like an improvement. Take
>> a look at the new version and see what you think.
> I'm not really sure. I suppose I'll have to play with it for a while
> to really form a clear opi
On Sun, Sep 26, 2010 at 8:56 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> On Sun, Sep 26, 2010 at 6:29 PM, Fujii Masao wrote:
>>> On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown wrote:
I noticed that there's no way to specify the location of recovery.conf
in postgresql.conf.
>
>>> +1
>
On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane wrote:
>>> Hah, I have a plan. Let's just run git log for "master..RELx_y_STABLE"
>>> for each branch, rather than all the way back.
>
>> This doesn't seem more reliable to me in
Jaime Casanova writes:
> On Sun, Sep 26, 2010 at 6:29 PM, Fujii Masao wrote:
>> On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown wrote:
>>> I noticed that there's no way to specify the location of recovery.conf
>>> in postgresql.conf.
>> +1
>>
>> That parameter would be useful when user makes multi
On Sun, Sep 26, 2010 at 6:29 PM, Fujii Masao wrote:
> On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown wrote:
>> I noticed that there's no way to specify the location of recovery.conf
>> in postgresql.conf. The pg_hba and pg_ident files can be altered, so
>> I'm wondering why this file can't have a s
Marios Vodas writes:
> Is it posible? Either by using heap_form_tuple or BuildTupleFromCStrings.
heap_form_tuple followed by HeapTupleGetDatum should work; that's what's
done in ExecEvalRow() for instance. You've omitted to tell us just
what's going wrong for you.
regard
Robert Haas writes:
> On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane wrote:
>> Hah, I have a plan. Let's just run git log for "master..RELx_y_STABLE"
>> for each branch, rather than all the way back.
> This doesn't seem more reliable to me in any way. Looking at the
> actual commit history must sur
On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown wrote:
> I noticed that there's no way to specify the location of recovery.conf
> in postgresql.conf. The pg_hba and pg_ident files can be altered, so
> I'm wondering why this file can't have a specified location. In
> Ubuntu, all configuration files a
Ah, great. I missed looking there.
Thanks.
On Sun, Sep 26, 2010 at 4:19 PM, Fujii Masao wrote:
> On Mon, Sep 27, 2010 at 7:46 AM, fazool mein wrote:
> > I checked the code for the keepalive feature. It seems that the socket
> > options are only set on the primary's socket connection. The tcp
>
On Mon, Sep 27, 2010 at 7:46 AM, fazool mein wrote:
> I checked the code for the keepalive feature. It seems that the socket
> options are only set on the primary's socket connection. The tcp connection
> created on the secondary for walreceiver does not use the keepalive
> parameters from the con
Hello again,
I checked the code for the keepalive feature. It seems that the socket
options are only set on the primary's socket connection. The tcp connection
created on the secondary for walreceiver does not use the keepalive
parameters from the configuration.
Am I correct? Is this intended or
Hi,
I noticed that there's no way to specify the location of recovery.conf
in postgresql.conf. The pg_hba and pg_ident files can be altered, so
I'm wondering why this file can't have a specified location. In
Ubuntu, all configuration files are in a different location to the
cluster by default, s
On Sun, Sep 26, 2010 at 4:28 PM, Tom Lane wrote:
>> The reason I assumed we'd want to ignore these is because they're
>> automatically generated files - unlike *.rej files, which are never
>> going to end up in your tree as a result of make anything. It doesn't
>> actually matter that much to me
On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane wrote:
> I wrote:
>> We could perhaps fix that if there were an inexpensive way to get the
>> SHA1 of the master commit that each branch is sprouted from. However,
>> I'm inclined to propose that we instead manually place a tag at each
>> sprout point.
>
I wrote:
> We could perhaps fix that if there were an inexpensive way to get the
> SHA1 of the master commit that each branch is sprouted from. However,
> I'm inclined to propose that we instead manually place a tag at each
> sprout point.
Hah, I have a plan. Let's just run git log for "master..
Robert Haas writes:
> On Sun, Sep 26, 2010 at 3:45 PM, Tom Lane wrote:
>> -1. If the lack of an ignore causes a problem for you, it indicates
>> that you're trying to commit code that fails the regression tests.
>> Is it really a good idea to let that happen without any manual cleanup?
> I thin
Is it posible? Either by using heap_form_tuple or BuildTupleFromCStrings.
CREATE TYPE p_type AS
(
x double precision,
y double precision
);
CREATE TYPE d_type AS
(
i p_type,
e p_type,
id integer
);
CREATE OR REPLACE FUNCTION demo()
RETURNS d_type
AS '/home/user/PostgreSQL/9.0/lib/mylib','demo
On Sun, Sep 26, 2010 at 3:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> Seems like it's probably a good idea, but I wanted to double-check
>> that no one has a different thought.
>
> -1. If the lack of an ignore causes a problem for you, it indicates
> that you're trying to commit code that fa
Robert Haas writes:
> I think his question was - how do we feel about the massive catalog
> bloat this patch will create?
It's a fair question.
I can imagine designing things so that we don't create an explicit
pg_constraint row for the simplest case of an unnamed, non-inherited
NOT NULL constra
On Sun, Sep 26, 2010 at 3:24 PM, Tom Lane wrote:
> We could perhaps fix that if there were an inexpensive way to get the
> SHA1 of the master commit that each branch is sprouted from. However,
> I'm inclined to propose that we instead manually place a tag at each
> sprout point. Any thoughts ab
Robert Haas writes:
> Seems like it's probably a good idea, but I wanted to double-check
> that no one has a different thought.
-1. If the lack of an ignore causes a problem for you, it indicates
that you're trying to commit code that fails the regression tests.
Is it really a good idea to let t
Robert Haas writes:
> On Sun, Sep 26, 2010 at 2:07 PM, Tom Lane wrote:
>> ? It's not hard to offer an option for that, I guess, but I foresee an
>> argument about what the default is going to be.
> If there's no clear consensus, I'm OK with the time-honored tie-break
> of "he who does the work.
I wrote:
> I think we could get that behavior fairly easily by remembering the last
> tag matching one of the commits on a branch, as we chase the branch
> backwards.
I find that this works just fine for the branches, but not so well for
master, because more often than not the initial RELx_y_z tag
On Sun, Sep 26, 2010 at 2:11 PM, Bernd Helmle wrote:
> --On 25. September 2010 19:55:02 -0300 José Arthur Benetasso Villanova
> wrote:
>
>> One thing that I take notice is when you create a simple table like this
>> one: select count(*) from pg_constraint ; 12 rows appears in
>> pg_constraint, 10
On Sat, Sep 25, 2010 at 14:49, Robert Haas wrote:
> On Sat, Sep 25, 2010 at 8:28 AM, Michael Haggerty
> wrote:
>> It looks like your transition to git has been a success. Your very
>> careful conversion from CVS to git and your exacting scrutiny of the
>> results are a great check that cvs2git
Robert Haas wrote:
> Hmm... it is true that average will produce the same results on any
> ordering of the same set of input values, though.
Not exactly. For floating point approximations you get a more
accurate sum (and therefore a more accurate average) if you add the
values in ascending or
Do you think it would be better to change d_type to this?
CREATE TYPE d_type AS
(
xi double precision,
yi double precision,
xe double precision,
ye double precision,
id integer
);
*Note: This is NOT something I want to do but if there is no other way to
form d_type tuple from the variables...*
O
--On 25. September 2010 19:55:02 -0300 José Arthur Benetasso Villanova
wrote:
One thing that I take notice is when you create a simple table like this
one: select count(*) from pg_constraint ; 12 rows appears in
pg_constraint, 10 to the sequence. Is that ok?
Not sure i get you here, can y
Seems like it's probably a good idea, but I wanted to double-check
that no one has a different thought.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
gitignore-regression-failures.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list
On Sun, Sep 26, 2010 at 2:07 PM, Tom Lane wrote:
> [Do you really want the behavior you said you wanted?]
Yes.
> ? It's not hard to offer an option for that, I guess, but I foresee an
> argument about what the default is going to be.
If there's no clear consensus, I'm OK with the time-honored
Robert Haas writes:
> But I still want an option for the original behavior. I have been
> using it extensively and I like it.
You really think this:
Author: Tom Lane
Branch: master [872c1497f] 2005-05-24 18:02:31 +
Branch: REL9_0_STABLE [872c1497f] 2005-05-24 18:02:31 +
Branch: REL8_4_
> Hmm... it is true that average will produce the same results on any
> ordering of the same set of input values, though. Perhaps the word
> "partition" emcompass that, though then again maybe not.
>
> I'd be happy to fix this if I understand what to fix it to.
I wish I knew how to rephrase it so
Suppose I had the data that form the returning tuple in 5 variables like
this:
float8 xi = 1;
float8 yi = 2;
float8 xe = 3;
float8 ye = 4;
int32 id = 1;
In addition the function wouldn't have any input parameters. It just returns
a tuple of type d_type.
Can you tell me how it is possible to form t
On Sun, Sep 26, 2010 at 1:25 PM, Tom Lane wrote:
> I wrote:
>> If we could figure out how to show which major release a master-branch
>> commit antedated, and which point release a back-branch commit
>> antedated, I think we would have something that's actually significantly
>> more useful for bot
I wrote:
> If we could figure out how to show which major release a master-branch
> commit antedated, and which point release a back-branch commit
> antedated, I think we would have something that's actually significantly
> more useful for both purposes than either of these behaviors.
I think we c
Marios Vodas writes:
> //I need to get this working
> *values[0] = e;*
> *values[1] = i;*
Maybe you're missing HeapTupleGetDatum() there? Just from a data type
cleanliness standpoint, you shouldn't ever assign something to Datum or
vice versa without applying the correct conversion macro
Robert Haas writes:
> On Sun, Sep 26, 2010 at 12:08 PM, Tom Lane wrote:
>> Hm? As far as I can tell, this fixes that not breaks it. The problem
>> I was seeing was that commits would be attributed to a branch when in
>> fact they were made before the branch ever existed.
> But the commits are
I see what you mean and I changed the code BUT still my main problem is that
I want to know how to fill values array. I remind you that d_type contains
attributes of another composite type p_type.
I need a solution to that because I need to use it in other parts of the
code.
Datum d_swap(PG_FUNCTI
On Sun, Sep 26, 2010 at 12:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane wrote:
>>> Still more tweaking of git_changelog.
>
>> Uhm, could you stop massively changing the behavior of this script
>> with no discussion at all?
>
> Uh, there was no discuss
Hey Robert,
Yes, I am sure. I've tested it by test case in my original post.
Do you can compile and reproduce it please?
--
// Dmitriy.
Marios Vodas writes:
> My problem is that I don't know how to construct the d_type tuple in the c
> function.
Seems like the main problem with that function is that you're passing
an uninitialized "nulls" array to heap_form_tuple.
I kinda wonder why you are using a fixed-length values array toge
On Fri, Sep 24, 2010 at 9:13 AM, Dmitriy Igrishin wrote:
> Tell me please, why lo_write() returns me the number of bytes "actually
> written"
> when current write location is out of 2GB ? IMO, in this case it should
> returns
> at least zero.
> lo_read() returns zero in this case, and it is correc
Robert Haas writes:
> On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane wrote:
>> Still more tweaking of git_changelog.
> Uhm, could you stop massively changing the behavior of this script
> with no discussion at all?
Uh, there was no discussion of the original behavior of the script
either.
> I happe
On Thu, Sep 23, 2010 at 11:34 PM, Dennis Björklund wrote:
>> On Wed, Sep 22, 2010 at 6:03 AM, Dennis Björklund wrote:
>> But I confess that I'm sort of murky on how ORDER affects the window
>> frame, or how to rephrase this more sensibly.
>
> The rows included in the calculation of the window fun
On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane wrote:
> Still more tweaking of git_changelog.
>
> 1. Don't assume there's only one candidate match; check them all and use the
> one with the closest timestamp. Avoids funny output when someone makes
> several successive commits with the same log message
I have these types:
CREATE TYPE p_type AS
(
x double precision,
y double precision
);
CREATE TYPE d_type AS
(
i p_type,
e p_type,
id integer
);
CREATE OR REPLACE FUNCTION d_swap(d_type)
RETURNS d_type
AS '/home/user/PostgreSQL/9.0/lib/mylib','d_swap'
LANGUAGE C STRICT;
My problem is that I do
On Sun, Sep 26, 2010 at 15:39, Heikki Linnakangas
wrote:
> On 25/09/10 19:43, Peter Eisentraut wrote:
>>
>> I'm not subscribed to pgsql-committers, but apparently under the new
>> git-enabled setup, I'm getting a "Stalled post to pgsql-committers"
>> message for every commit. Fix that please.
>
>
On 25/09/10 19:43, Peter Eisentraut wrote:
I'm not subscribed to pgsql-committers, but apparently under the new
git-enabled setup, I'm getting a "Stalled post to pgsql-committers"
message for every commit. Fix that please.
Just subscribe with 'nomail'. That's what I did.
--
Heikki Linnakang
On 09/26/2010 09:37 AM, Greg Stark wrote:
We could have a
encoded_text data type which includes both the encoding and the string
and which any comparison function automatically handles conversion
based on the encoding of the collation requested -- but I wouldn't
want that to be the default text
On Sun, Sep 26, 2010 at 1:15 PM, Pavel Stehule wrote:
> Is there any reason why you prohibit a different encodings per one
> database? Actually people expect from collate per column a possibility
> to store a two or more different encodings per one database.
These are two completely separate prob
Hello Peter
Is there any reason why you prohibit a different encodings per one
database? Actually people expect from collate per column a possibility
to store a two or more different encodings per one database. Without
this possibility - only UTF8 is possible for practical work - and for
other enc
Hello,
there is updated version - with support of window clause. The limits
are work_mem for using inside window aggregate or unlimited when it is
used as standard query.
This patch needs a few work - can share a compare functionality with
tuplesort.c, but I would to verify a concept now.
Commen
Hello,
just doing an upgrade form PostgreSQL 8.4.4 on Windows 2007 64bit to
PostgreSQL 9.0 64bit on the same system.
I am working along
http://developer.postgresql.org/pgdocs/postgres/pgupgrade.html
There is written:
NET STOP postgresql-8.4
NET STOP postgresql-9.0
or
NET STOP pgsql-8.3 (Postg
68 matches
Mail list logo
