On Mon, May 21, 2007 at 11:58:35PM -0400, Tom Lane wrote:
> The intent of the FP binary I/O code we have is that for platforms
> supporting IEEE-compliant FP formats, the on-the-wire representation
> should be uniformly big-endian, same as is true for integers. So
> I would concur with a patch tha
I really appreciate for the modification.
I also believe XLOG_NOOP is cool to maintains XLOG format consistent.
I'll continue to write a code to produce incremental log record from
the full page writes as well as too maintain CRC, XLOOG_NOOP and
other XLOG locations,I also found that you've
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> As for the ARM architecture, I've pulled my sources, and the answer is
> this: ARM doesn't have one standard floating point format. Different ARM
> architectures will use different formats. Most architectures will
> actually use IEEE, but some will use
Hi all
I installed the source of PostgreSQL 8.2.3 on a linux machine. The installation
process ended successfully but when I try to create the database cluster using
the initdb command I get the following error:
"
creating conversions ... sh: line 1: 1838 Segmentation fault (core
dumped)
Hi Usama,
On May 21, 2007, at 9:20 AM, Usama Munir wrote:
i wanted to submit a patch for this, IFF the community wants this
function. The rationale is obviously to help Application developers
writing applications like pgAdmin. Currently this part of SQL needs
to be constructed manually for
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> As for the ARM architecture, I've pulled my sources, and the answer is
> this: ARM doesn't have one standard floating point format. Different ARM
> architectures will use different formats.
So how will you know which one is in use, which I'd think you'
>>> On Mon, May 21, 2007 at 9:02 AM, in message <[EMAIL PROTECTED]>,
Shachar Shemesh <[EMAIL PROTECTED]> wrote:
>
>> We have fought many years to get closer to IEEE 754
>> conformance.
>
> Please notice that the format I offered *is* IEEE. In fact, what I'm
> offering is to export the binary i
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
> On 05/19/2007 12:41:47 PM, Tom Lane wrote:
>> There's been previous discussion of allowing BEFORE INSERT triggers
>> on views, so long as the triggers always return NULL to suppress
>> the actual insertion attempt (ie, we'd move the "can't insert into
>>
"Usama Munir" <[EMAIL PROTECTED]> writes:
> I guess the way forward for me would be to crawl back in my corner,
> write up a mini - spec of how i intend to implement it and get back to
> you guys.
Well, the *first* thing to do is read pg_dump for awhile. Until you've
grokked what it does to sup
I looked into the curious planner behavior described in this thread:
http://archives.postgresql.org/pgsql-performance/2007-05/msg00388.php
and after a bit of experimentation was able to duplicate it in the
regression database:
regression=# explain select * from int4_tbl a where f1 in (select hundr
On 05/21/2007 01:59:36 PM, Tom Lane wrote:
I think that the wave of the future is probably to figure out a way to
provide trigger support for views.
I put forward a possible way to do trigger support
for views in a previous email and would appreciate comment.
(http://archives.postgresql.org/p
Usama Munir wrote:
I think using pg_dump in some cases is a good option , but not all the
time, having a function makes it much cleaner to use
That's why having a shared pgdump library as has been previously
mentioned is by far the best solution.
We have discussed this before, and factorin
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
> When I say I write and execute an INSERT statement I mean
> that the INSERT statement into the view is executed just as if the user
> wrote it -- it is passed through the rule system and turns into
> whatever INSERT or other statements the user has
> ass
Usama Munir wrote:
Got it. Thanks for the clarification , i suppose the way you described
it , it needs to go over libpq for the database interface, not the
HeapTuple / Form_pg_* , way.
Yes, for many reasons including those mentioned in Tom's email on this
subject today.
cheers
and
Got it. Thanks for the clarification , i suppose the way you described
it , it needs to go over libpq for the database interface, not the
HeapTuple / Form_pg_* , way.
I guess the way forward for me would be to crawl back in my corner,
write up a mini - spec of how i intend to implement it a
I mean as a shared library - a .so for Unix (or whatever the flavor of
unix uses instead) or a DLL on WIndows. And no, it would not be in
contrib - as I mentioned in another thread yesterday I want to propose
that contrib disappear.
Certainly pg_dump would use the library, and retain all the
When you say pgdump library, do you mean taking all catalog querying
functionality into a contrib like module , exposed as functions and
then have a simple pgdump executable which calls those functions to dump
to a file, because you would still need a pgdump executable i suppose
for people to
On 05/21/2007 12:17:38 PM, Jim C. Nasby wrote:
On Mon, May 21, 2007 at 05:02:29PM +, Karl O. Pinc wrote:
>
> On 05/21/2007 11:23:57 AM, Jim C. Nasby wrote:
>
> >What about adding COPY support to rules? ISTM if you want to copy
into
> >a
> >view you probably want to insert into it as well, so
On Mon, May 21, 2007 at 05:02:29PM +, Karl O. Pinc wrote:
>
> On 05/21/2007 11:23:57 AM, Jim C. Nasby wrote:
>
> >What about adding COPY support to rules? ISTM if you want to copy into
> >a
> >view you probably want to insert into it as well, so why not use the
> >same mechanism? Presumably a
On 05/21/2007 11:23:57 AM, Jim C. Nasby wrote:
What about adding COPY support to rules? ISTM if you want to copy into
a
view you probably want to insert into it as well, so why not use the
same mechanism? Presumably a COPY rule would also be faster than a
trigger.
I'd say there's no differenc
On Sat, May 19, 2007 at 01:41:47PM -0400, Tom Lane wrote:
> > I _could_ make tables that "correspond"
> > to the views and put BEFORE INSERT triggers on them and
> > have the triggers insert into the views (or the equalivent),
> > but then the users would have to use the views for most
> > things a
I think using pg_dump in some cases is a good option , but not all the
time, having a function makes it much cleaner to use
Consider pgAdmin lets say (and there are many such applications out
there) , you need to show object DDL on the RHP and its nicely
formatted and you can copy paste it and
Naz Gassiep <[EMAIL PROTECTED]> writes:
> Just a question, is there any advantage to having this then building a
> function in applications that wrap and use pg_dump with a few options?
> Surely that's a more appropriate way to achieve this functionality?
Refactoring pg_dump into some sort of libr
On 05/19/2007 12:41:47 PM, Tom Lane wrote:
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
> I don't really want to do this. I really want my users
> to be able to use the COPY statement without worrying
> about whether they are copying into a table or a view.
But ... but ... the proposed feature e
Just a question, is there any advantage to having this then building a
function in applications that wrap and use pg_dump with a few options?
Surely that's a more appropriate way to achieve this functionality?
- Naz.
Usama Munir wrote:
> Hi,
>
> i was following a thread some time ago where adding
On Mon, May 21, 2007 at 10:00:50AM +0100, Dave Page wrote:
> Hi Michael,
>
> Looks like your latest commit fixed the problem. Thanks for working on it.
Thanks for your help. Just in case anyone wonders, I don't know exactly
which call caused it, but the candidates are only localtime and mktime.
Peter Eisentraut wrote:
> "I want to use the binary format but I don't like what it does."
It doesn't do anything. The set of circumstances under which it is
useful has been limited, on purpose, and, as far as I can see, without
any good reason. Spending not much time (and I suggested to spend it
Csaba Nagy wrote:
> If you care about the +/- for +/-Infinity, you must also care about +/-0
> too, so you get the right type of infinity if you divide with 0... so +0
> and -0 are far from being semantically identical.
>
> Cheers,
> Csaba.
>
>
My suggestion accommodates that.
Shachar
> In other words, if I can assure that data exported and then imported
> will always, under all circumstances, compare the same to the original,
> would that be enough of a requirement? In other words, if I offer a
> format that is assured of preserving both mantissa and exponent
> precision and ra
Akmal Akmalhojaev wrote:
It doesn't mean if there is "inherit" flag. I'm looking for a C function
like SearchSysCache() or smth.
Ah - I think the file you neeed to look in is backend/utils/adt/acl.c -
I think it's looking at things the other way around. That is - is the
current role a member
Am Montag, 21. Mai 2007 07:04 schrieb Shachar Shemesh:
> In other words, if I offer a
> format that is assured of preserving both mantissa and exponent
> precision and range, as well as all extra attributes (+/-Infinity and
> NaN), but does not guarantee that the semantically identical constructs
>
Hi,
i was following a thread some time ago where adding a function pg_get_tabledef
was one of the TODOs for 8.2, but it somehow didn't make it to the
release perhaps because the functionality was not clearly defined? not
sure.
Anyway i happen to come up with a function for pg_get_tabledef w
Joachim Wieland wrote:
> On Thu, May 17, 2007 at 10:14:45PM +0200, Magnus Hagander wrote:
>> IIRC, Joachim had started working on the ecpg part. (Which is one of the
>> reasons I haven't looked at it myself yet)
>
>> Joachim, did you ever get anywhere with that?
>
> I have ecpg tests somehow runn
Akmal Akmalhojaev wrote:
Hello! I have the following question.
For example I have a role ID1 with members ID2 and ID3.
Role ID2 has also members ID4 and ID5. It means that roles ID4 and ID5 are
members of ID1.
The question: Is there any function in PostgreSQL, that finds all the
members of role
Hello! I have the following question.
For example I have a role ID1 with members ID2 and ID3.
Role ID2 has also members ID4 and ID5. It means that roles ID4 and ID5 are
members of ID1.
The question: Is there any function in PostgreSQL, that finds all the
members of role ID1 - even such members, a
Dave Page a écrit :
Hi Michael,
Looks like your latest commit fixed the problem. Thanks for working on it.
But it breaks 8.2 and 8.1 branches. See
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=kite&dt=2007-05-21%2007:47:01.
I've send a patch on pgsql-patch that fixes it.
Regards.
--
Hi Michael,
Looks like your latest commit fixed the problem. Thanks for working on it.
Regards, Dave
Original Message
Subject: PGBuildfarm member vaquita Branch HEAD Status changed from
ECPG-Check failure to OK
Date: Sun, 20 May 2007 14:24:34 -0700 (PDT)
From: PG Build Farm
37 matches
Mail list logo
