Hello Mika
Currently you can use dblink which queries a remote database and returns
the data as a table. This works nicely for PostgreSQL. There is also a
JDBC version in progress.
We have writte an Oracle version of dblink.
SELECT * FROM dblink('connectstr', 'SELECT ...') AS some_type;
This w
On 4 Jul 2003 at 18:56, MIka Santos wrote:
> said online registration. He wanted a multidatabase querying. For example, we
> knew that the following statements are posible,
> select *
> from t1, t2., t3;
> provided that t1 and t2, t3 are tables from a single database.
> Ourthesis is to make the
Hi all,
while implementing the protocol 3.0 I could get the data in text mode
setting the format to 0. (Thanks all for helping me out with flush message)
Now, I want to test the binary format. While some primitive types are
easy to realize, for example a int4 field will be encoded in 4 bytes,
Hello:
while implementing the protocol 3.0 I could get the data in text mode
setting the format to 0. (Thanks all for helping me out with flush message)
Now, I want to test the binary format. While some primitive types are
easy to realize, for example a int4 field will be encoded in 4 bytes,
I
Hi,
On Wed, Jul 02, 2003 at 03:49:19PM +0900, Kenji Sugita wrote:
> It seems that a value of addr->ai_socktype returned by getaddrinfo in
> pg_stat.c is not SOCK_DGRAM.
Please try the following untested patch:
--- pgstat.c.orig Thu Jun 12 16:36:51 2003
+++ pgstat.cMon Jul 7 00
On Mon, Jul 07, 2003 at 12:38:57AM +0900, [EMAIL PROTECTED] wrote:
> Hi,
>
> On Wed, Jul 02, 2003 at 03:49:19PM +0900, Kenji Sugita wrote:
> > It seems that a value of addr->ai_socktype returned by getaddrinfo in
> > pg_stat.c is not SOCK_DGRAM.
>
> Please try the following untested patch:
No, p
Carlos Guzman Alvarez wrote:
Hello:
while implementing the protocol 3.0 I could get the data in text mode
setting the format to 0. (Thanks all for helping me out with flush
message)
Now, I want to test the binary format. While some primitive types are
easy to realize, for example a int4 field
On Mon, Jul 07, 2003 at 12:38:57AM +0900, [EMAIL PROTECTED] wrote:
>
> On Wed, Jul 02, 2003 at 03:49:19PM +0900, Kenji Sugita wrote:
> > It seems that a value of addr->ai_socktype returned by getaddrinfo in
> > pg_stat.c is not SOCK_DGRAM.
>
> Please try the following untested patch:
[...]
> +
On Mon, Jul 07, 2003 at 12:55:06AM +0900, [EMAIL PROTECTED] wrote:
>
> When hints.ai_family is PF_UNSPEC, getaddrinfo() returns two entries,
> first one being IPv6 one, and the second one is IPv4 one, even if
> IPv6 support is not compiled in the kernel(this is true at least on
> my FreeBSD box).
On Sun, Jul 06, 2003 at 06:30:04PM +0200, Kurt Roeckx wrote:
> Try the attached patch instead.
Oops, that one was a little broken. I change it.
Try the attached one instead.
Kurt
Index: ./src/backend/postmaster/pgstat.c
===
RCS fi
Hello:
Yeah, while waiting for the response, I added support for the int4
datatype. It is really encoded as a 4 bytes value.
:)
Uhmmm, where did you take the 2000,1,1 as base from?
If the date is before 2000, days will have a negative value, so date is
calculated correctly backwards?
In the lit
Hi!
I'm sorry I haven't done any research beforehand, but are any such
materials regarding performance tuning available in the canned form on
the 'net for me to show to my boss? I believe statements like this will
greatly promote PostgreSQL if substantiated with concise "executive
summary" art
where can i find aliases to type , for example INT4 = INT = INTEGER ...
I realy need it to check if function is exists ..
Or how to get oid from same type , but no like select from pg_type
now about plpgsql
i think that will be nice , to possible declare var. with names started
from $ (like funct
Carlos Guzman Alvarez wrote:
Hello:
Hello
Yeah, while waiting for the response, I added support for the int4
datatype. It is really encoded as a 4 bytes value.
:)
Uhmmm, where did you take the 2000,1,1 as base from?
If the date is before 2000, days will have a negative value, so date
is cal
On Sun, Jul 06, 2003 at 10:15:37PM +0200, ivan wrote:
>
> where can i find aliases to type , for example INT4 = INT = INTEGER ...
> I realy need it to check if function is exists ..
> Or how to get oid from same type , but no like select from pg_type
Maybe this is helpful:
alvh=> select 'int'::r
On Fri, Jul 04, 2003 at 15:29:37 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> 3. What should be the set of tested values? I have it as
>buffers: first to work of 1000 900 800 700 600 500 400 300 200 100 50
>connections: first to work of 100 50 40 30 20 10
> but we could certainly argu
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Should the default max number of connections first try something greater
> than what Apache sets by default (256 for prefork, 400 for worker)?
We could do that. I'm a little worried about setting default values
that are likely to cause problems with e
> would be the right solution to make tsearch V2 to be fully incompatible
> with old tsearch (so both version could live in one database) and
> release tsearch v2 in separate directory. This way require some additional
> work but would not confuse people. As a bonus, people could start playing
> wi
I did a fresh CVS get (2003-07-07 12:30 UTC +10:00), attempted to build on
"OSF1 V4.0 1229 alpha" (Tru64 running on alpha) but build failed with:
In file included from ../../../../src/include/libpq/libpq-be.h:22,
from ../../../../src/include/libpq/libpq.h:21,
fro
Philip Yarra <[EMAIL PROTECTED]> writes:
> I did a fresh CVS get (2003-07-07 12:30 UTC +10:00), attempted to build on
> "OSF1 V4.0 1229 alpha" (Tru64 running on alpha) but build failed with:
> In file included from ../../../../src/include/libpq/libpq-be.h:22,
> from ../../../../s
On Mon, 7 Jul 2003 02:19 pm, Tom Lane wrote:
> Is type int64_t defined anywhere in your system headers? If so, where?
Er... no... this:
int main()
{
printf("sizeof is: %d\n", sizeof(int64_t));
}
fails with:
cc: Error: l.c, line 2: In this statement, "int64_t" is not declared.
(undecl
On Mon, 7 Jul 2003, Tom Lane wrote:
> Philip Yarra <[EMAIL PROTECTED]> writes:
> > I did a fresh CVS get (2003-07-07 12:30 UTC +10:00), attempted to build on
> > "OSF1 V4.0 1229 alpha" (Tru64 running on alpha) but build failed with:
>
> > In file included from ../../../../src/include/libpq/libpq-
Philip Yarra <[EMAIL PROTECTED]> writes:
> On Mon, 7 Jul 2003 02:19 pm, Tom Lane wrote:
>> Is type int64_t defined anywhere in your system headers? If so, where?
> Er... no... this:
> int main()
> {
> printf("sizeof is: %d\n", sizeof(int64_t));
> }
> fails with:
Without some #include's,
On Mon, 7 Jul 2003 02:53 pm, you wrote:
> Without some #include's, I'd expect it to fail, because int64_t isn't
> built into the C compiler. The question is exactly which #include
> are we missing.
Okay, got it: db.h
---(end of broadcast)---
T
Philip Yarra wrote:
But then, it doesn't work on Linux (intel 32-bit) either... What's this
int64_t supposed to be? We're not just talking about a long long are we?
I found it on my Red Hat 9 box in sys/types.h:
# if __GLIBC_HAVE_LONG_LONG
__extension__ typedef long long int int64_t;
# endif
I finally got Bison 1.875 installed on the alpha here, and tried running
regression tests:
== removing existing temp installation==
== creating temporary installation==
== initializing database system ==
If I createlang manually:
bash-2.03$ createlang plpgsql template1
ERROR: Load of file /home/chriskl/local/lib/postgresql/plpgsql.so failed:
dlopen '/home/chriskl/local/lib/postgresql/plpgsql.so' failed.
(/home/chriskl/local/lib/postgresql/plpgsql.so: Undefined symbol
"MakeExprContext")
createlang
On Mon, 7 Jul 2003 03:09 pm, Joe Conway wrote:
> I found it on my Red Hat 9 box in sys/types.h:
>
> # if __GLIBC_HAVE_LONG_LONG
> __extension__ typedef long long int int64_t;
> # endif
And on RedHat 7.3 it's in stdint.h - they must move it around to keep the
snipers guessing.
If you haven't h
Philip Yarra <[EMAIL PROTECTED]> writes:
> And on RedHat 7.3 it's in stdint.h - they must move it around to keep the
> snipers guessing.
Sometimes it seems that way :-(
> What's the best (most portable) way to fix this?
My vote is to rip out every last reference to int64_t and other
system-head
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> If I createlang manually:
> bash-2.03$ createlang plpgsql template1
> ERROR: Load of file /home/chriskl/local/lib/postgresql/plpgsql.so failed:
> dlopen '/home/chriskl/local/lib/postgresql/plpgsql.so' failed.
> (/home/chriskl/local/lib/postgr
On Mon, Jul 07, 2003 at 01:46:21AM -0400, Tom Lane wrote:
> Philip Yarra <[EMAIL PROTECTED]> writes:
> > And on RedHat 7.3 it's in stdint.h - they must move it around to keep the
> > snipers guessing.
>
> Sometimes it seems that way :-(
>
> > What's the best (most portable) way to fix this?
>
>
On Mon, 7 Jul 2003 04:30 pm, Kurt Roeckx wrote:
> I used int64_t because that's standard (C99). But int64 will do
> too.
Okay... looks like it's only in a couple of places. I'll fix for Tru64 when I
get a chance. I don't have commit access, so Tom, shall I send a patch to
you?
Regards, Philip.
hi,
when be meet error send string to fe. Is possible to be will send error
no. with this str, or only errors id ?
I mean, this basic errors, like when be crash, or connecting ...
It would be easyer and faster to check whats happend.
bye
ivan
---(end of broadcast)-
33 matches
Mail list logo
