Nathan Thatcher wrote:
So what options does that leave all of us who need to compile and run
our custom C functions in Windows?
Debug further :-)
Because it's certainly possible to do it. IIRC, PostGIS for 8.3 is
build with MingW and it works fine. And other extensions are known
working when
Nathan Thatcher wrote:
So what options does that leave all of us who need to compile and run
our custom C functions in Windows?
After a bit of sleep and with the advantage of a now-working brain I've
got it working, at least with 8.3 .
The problem was with DLL linkage, especially the
Hi,
I am not sure about the right place to post this question so I'm
trying here first:
We are using Postgres in our company successfully since 2001 but now
we arrived at the conclusion that we really need Materialized Views
for our further business. Also we decided that we should try to pay
Hi,
[EMAIL PROTECTED] wrote:
Hi,
I am not sure about the right place to post this question so I'm
trying here first:
We are using Postgres in our company successfully since 2001 but now
we arrived at the conclusion that we really need Materialized Views
for our further business. Also we
am Mon, dem 05.05.2008, um 0:43:46 -0700 mailte [EMAIL PROTECTED] folgendes:
Hi,
I am not sure about the right place to post this question so I'm
trying here first:
We are using Postgres in our company successfully since 2001 but now
we arrived at the conclusion that we really need
Hey Group,
i know what all will say but i need to recreate the = operator for
datatypes varchar and integer in PostgreSQL 8.3.
Our Software Project has Millions of Lines and so it would be difficult
to check all queries and Datatypes. Also it works really fine and we all
know the risk of
2008/5/5 Daniel Schuchardt [EMAIL PROTECTED]:
Hey Group,
i know what all will say but i need to recreate the = operator for
datatypes varchar and integer in PostgreSQL 8.3.
Our Software Project has Millions of Lines and so it would be difficult to
check all queries and Datatypes. Also it
ups;
i have this script but forgott to execute it in the new createt db
monday morning
thnx.
Filip Rembiałkowski schrieb:
2008/5/5 Daniel Schuchardt [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Hey Group,
i know what all will say but i need to recreate the = operator for
We're using a statement like this to dump between 500K and 5
million rows.
COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn '0')
TO '/dev/shm/SomeFile.csv'
Upon first run, this operation can take several minutes. Upon
second run, it will be complete in generally well
We're using a statement like this to dump between 500K and 5 million
rows.
COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn '0')
TO '/dev/shm/SomeFile.csv'
Upon first run, this operation can take several minutes. Upon second
run, it will be complete in generally well under a
Daniel Schuchardt wrote:
i know what all will say but i need to recreate the = operator for
datatypes varchar and integer in PostgreSQL 8.3.
Our Software Project has Millions of Lines and so it would be
difficult
to check all queries and Datatypes. Also it works really fine
and we all
I have a question related to the archive_command option of postgresql.conf.
In the documentation[1] I found examples that add a /dev/null at the
end of the cp command. I know what the redirection from /dev/null does
(send an EOF), but is it really needed? In [2] there are examples that
don't
Martin Marques [EMAIL PROTECTED] writes:
I have a question related to the archive_command option of postgresql.conf.
In the documentation[1] I found examples that add a /dev/null at the
end of the cp command. I know what the redirection from /dev/null does
(send an EOF), but is it really
On Mon, May 05, 2008 at 11:18:37AM +0200, Daniel Schuchardt wrote:
Hey Group,
i know what all will say but i need to recreate the = operator for
datatypes varchar and integer in PostgreSQL 8.3.
Our Software Project has Millions of Lines and so it would be
difficult to check all queries and
On Mon, May 5, 2008 at 6:18 AM, Hans Zaunere [EMAIL PROTECTED] wrote:
We're using a statement like this to dump between 500K and 5 million
rows.
COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn '0')
TO '/dev/shm/SomeFile.csv'
Upon first run, this operation can take
On Sun, May 4, 2008 at 5:11 PM, Hans Zaunere [EMAIL PROTECTED] wrote:
Hello,
We're using a statement like this to dump between 500K and 5 million rows.
COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn '0')
TO '/dev/shm/SomeFile.csv'
Wait, are you really creating a .csv file in shared
Hi,
I've searched the archives a fair amount on this topic, but have not
found quite the answer / explanation I'm looking for. I attribute this
to my eternal confusion over character encoding issues in all
environments, so I apologize in advance for what might be a stupid
question. :)
I'mm
On Mon, May 5, 2008 at 9:03 AM, Scott Marlowe [EMAIL PROTECTED] wrote:
On Sun, May 4, 2008 at 5:11 PM, Hans Zaunere [EMAIL PROTECTED] wrote:
Hello,
We're using a statement like this to dump between 500K and 5 million
rows.
COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn
Hi Lee,
On 05.05.2008, at 17:07, Lee Feigenbaum wrote:
INSERT INTO myTable VALUES (..., E'\x15\x1C\x2F\x00\x02...', ...) ;
try escaping the backslashes:
INSERT INTO myTable VALUES (..., E'\\x15\\x1C\\x2F\\x00\\x02...', ...) ;
Jan
--
Sent via pgsql-general mailing list
Craig Ringer wrote:
After a bit of sleep and with the advantage of a now-working brain I've
got it working, at least with 8.3 .
Awesome, thanks :)
- Dan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
David Fetter schrieb:
That technical debt is a risk to your whole project, and you need to
dedicate resources to paying it down.
http://en.wikipedia.org/wiki/Technical_debt
There are ways to get those automated casts, but they will only make
your situation worse in the long run.
Cheers,
Asche wrote:
Hi Lee,
On 05.05.2008, at 17:07, Lee Feigenbaum wrote:
INSERT INTO myTable VALUES (..., E'\x15\x1C\x2F\x00\x02...', ...) ;
try escaping the backslashes:
INSERT INTO myTable VALUES (..., E'\\x15\\x1C\\x2F\\x00\\x02...', ...) ;
Hi Jan,
Thanks for the suggestion. I should have
Hi Lee,
Thanks for the suggestion. I should have mentioned in my original
message that as per your suggestion and the suggestion in the
documentation, I have tried escaping the backslashes. When I do
this, I get the error:
ERROR: invalid input syntax for type bytea
I tried also doing
Hi,
Daniel Schuchardt wrote:
David Fetter schrieb:
That technical debt is a risk to your whole project, and you need to
dedicate resources to paying it down.
http://en.wikipedia.org/wiki/Technical_debt
There are ways to get those automated casts, but they will only make
your situation worse
On Mon, May 05, 2008 at 05:26:40PM +0200, Daniel Schuchardt wrote:
David Fetter schrieb:
That technical debt is a risk to your whole project, and you need
to dedicate resources to paying it down.
http://en.wikipedia.org/wiki/Technical_debt
There are ways to get those automated casts, but
I'm thinking that the answer is in the literal interpretation of the
error message, i.e. it doesn't like the specific byte 0x00, i.e. the
null byte. According to the docs (4.1.2.1. String Constants):
The character with the code zero cannot be in a string constant.
The reason may be that
No buts. If you create those automated casts, you are just putting
off the inevitable.
yes but than it will become a future project. (i think with postgres 8,5
or 8,6 :-P )
You're just confirming the fact that your project is in existential
trouble.
no, we would get trouble if we
yeah, its clear that an upgrade from 8.1 to 8.3 is impossible for us
without a major relase.
there are to many changes so the whole project has to be rechecked.
another example:
in 83:
postgres=# SELECT 1::INTEGER||1::INTEGER;
ERROR: operator does not exist: integer || integer at character
Tino Wildenhain schrieb:
Hi,
Daniel Schuchardt wrote:
David Fetter schrieb:
That technical debt is a risk to your whole project, and you need to
dedicate resources to paying it down.
http://en.wikipedia.org/wiki/Technical_debt
There are ways to get those automated casts, but they will only
David Fetter [EMAIL PROTECTED] writes:
On Mon, May 05, 2008 at 05:26:40PM +0200, Daniel Schuchardt wrote:
our db has about 500 functions, 300 tables, 1000 indexes, 1200 Views
that all use implicit casting. and: everything is working fine ;-)
:-P
How do you know? 8.3 removed the implicit
Asche wrote:
Hi Lee,
Thanks for the suggestion. I should have mentioned in my original
message that as per your suggestion and the suggestion in the
documentation, I have tried escaping the backslashes. When I do this,
I get the error:
ERROR: invalid input syntax for type bytea
I tried
paul rivers [EMAIL PROTECTED] wrote:
Short answer-- no.
Longer answer-- there's really no need for the Oracle-esque nomount
state in Pg. If you're doing media recovery, it's very much all or
nothing, cluster-wide. You are not going to do media recovery for a set
of tablespaces, for example.
Hi,
Daniel Schuchardt wrote:
Tino Wildenhain schrieb:
Hi,
...
Comparing int with text in general does not sound like a very good
idea to me. It should be quite easy to write a script to identify
such places so you can either change the datatypes (preferred) or
add the cast. Then rerun your
Hi,
Daniel Schuchardt wrote:
...
in 81:
postgres=# SELECT 1::INTEGER||1::INTEGER;
?column?
--
11
(1 row)
*shudder* is this actually a port of an application originally
targeted at M*Sql? ;)
Are you using those columns somewhere with their real type - as
integer? I mean if you use
Tino Wildenhain schrieb:
Hi,
Daniel Schuchardt wrote:
...
in 81:
postgres=# SELECT 1::INTEGER||1::INTEGER;
?column?
--
11
(1 row)
*shudder* is this actually a port of an application originally
targeted at M*Sql? ;)
Are you using those columns somewhere with their real type - as
Daniel Schuchardt wrote:
Tino Wildenhain schrieb:
Hi,
Daniel Schuchardt wrote:
...
in 81:
postgres=# SELECT 1::INTEGER||1::INTEGER;
?column?
--
11
(1 row)
*shudder* is this actually a port of an application originally
targeted at M*Sql? ;)
Are you using those columns somewhere
Just started a nice new project in mod_python with psycopg2, then discovered
that psycopg2 apparently does not support prepared statements. Is that true?
Any workarounds?
That ruins my whole day ...
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to
I got a warning from PostgreSQL 8.3.1 that said something to the effect of
checkpoints are happening to frequently... (-2484 seconds)
That part that confused me was the -2484. Is that just a hyphen in
a strange place? Or did it really calculate a negative value?
Is this expected?
Thanks,
Lee Feigenbaum [EMAIL PROTECTED] writes:
Would be nice if the bytea parser understood hex representation too, but
beggars can't be choosers :)
decode() might help you:
select decode('1200AB', 'hex');
decode
--
\022\000\253
(1 row)
regards, tom
Tino Wildenhain schrieb:
RETURN extract(year FROM $1)*100+extract(month FROM $1)-1;
was too clean and easy? ;))
Looks like a good oportunity to clean up your code before anything
unexpected happens :-)
Cheers
T.
LOL. Yes I don't like such easy things :-P
But you see i have a function
Dan Armbrust [EMAIL PROTECTED] writes:
I got a warning from PostgreSQL 8.3.1 that said something to the effect of
checkpoints are happening to frequently... (-2484 seconds)
That part that confused me was the -2484. Is that just a hyphen in
a strange place? Or did it really calculate a
On Monday 05 May 2008 14:28:47 Micah Yoder wrote:
Just started a nice new project in mod_python with psycopg2, then
discovered that psycopg2 apparently does not support prepared statements.
Is that true? Any workarounds?
Ah wait, do prepared statements not need any support from the client
We're using a statement like this to dump between 500K and 5
million rows.
COPY(SELECT SomeID FROM SomeTable WHERE SomeColumn '0')
TO '/dev/shm/SomeFile.csv'
Upon first run, this operation can take several minutes. Upon
second run, it will be complete in
Tom Lane schrieb:
David Fetter [EMAIL PROTECTED] writes:
On Mon, May 05, 2008 at 05:26:40PM +0200, Daniel Schuchardt wrote:
our db has about 500 functions, 300 tables, 1000 indexes, 1200 Views
that all use implicit casting. and: everything is working fine ;-)
:-P
How do
That part that confused me was the -2484. Is that just a hyphen in
a strange place? Or did it really calculate a negative value?
Yeah, it really did. AFAICS this could only happen if the value of time(2)
went backwards. Something fooling with your system clock?
Craig Ringer wrote:
I've tested this definition and it produces a DLL that links correctly
and does so without the warnings of inconsistent DLL linkage produced by
the original versions (which declared the function __declspec(dllimport)
then defined it).
Did you actually try to use those
Daniel Schuchardt wrote:
Tino Wildenhain schrieb:
RETURN extract(year FROM $1)*100+extract(month FROM $1)-1;
was too clean and easy? ;))
Looks like a good oportunity to clean up your code before anything
unexpected happens :-)
Cheers
T.
LOL. Yes I don't like such easy things :-P
RAISE
Craig Ringer wrote:
Which compiler did you use?
I've been using MinGW because I don't know how to turn off NLS to
compile with VC++.
- Dan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
Dan Heron Myers wrote:
Craig Ringer wrote:
I've tested this definition and it produces a DLL that links correctly
and does so without the warnings of inconsistent DLL linkage produced
by the original versions (which declared the function
__declspec(dllimport) then defined it).
Did you
Craig Ringer wrote:
I'm actually using a dummy header (just an empty file) for libintl.h .
None of the involved module code actually uses anything from libintl,
neither directly nor via any inlines/macros from postgresql's headers.
I'm not even sure PostgreSQL needs to include the header in
Dan Heron Myers wrote:
Craig Ringer wrote:
I'm actually using a dummy header (just an empty file) for libintl.h .
None of the involved module code actually uses anything from libintl,
neither directly nor via any inlines/macros from postgresql's headers.
I'm not even sure PostgreSQL needs to
Dan \Heron\ Myers [EMAIL PROTECTED] writes:
It seems odd that they can compile PostgreSQL with Visual Studio (according
to Magnus, anyway)
And according to several buildfarm machines, as well as quite a few
other folks who have managed to build things successfully. You need to
get over this
Craig Ringer [EMAIL PROTECTED] writes:
The other thing I had to do was add include guards on pg_config_os.h to
protect against repeat inclusion. VC++ 8.0 does not like the repeated
definition of `struct timezone' and `struct itimerval' (but 9.0 -
correctly - doesn't care). I have no idea
Craig Ringer wrote:
And in the server log files (PG_INSTALL_DIR\data\pg_log) ?
The log files contained no indication of an error, not even an oops,
the server crashed message.
I'd be interested in confirmation that you're able to get your code
working when you build it with VC++ .
I did
Dan Heron Myers wrote:
Tom Lane wrote:
You need to
get over this concept of Postgres is broken and try to identify a
specific reason why your DLL builds are not working.
I don't think I ever said Postgres was broken. I said Postgres was
crashing. I expressed doubt that Postgres' win32
Tom Lane wrote:
Craig Ringer [EMAIL PROTECTED] writes:
The other thing I had to do was add include guards on pg_config_os.h to
protect against repeat inclusion. VC++ 8.0 does not like the repeated
definition of `struct timezone' and `struct itimerval' (but 9.0 -
correctly - doesn't care). I
Dan Armbrust escribió:
I got a warning from PostgreSQL 8.3.1 that said something to the effect of
checkpoints are happening to frequently... (-2484 seconds)
That part that confused me was the -2484. Is that just a hyphen in
a strange place? Or did it really calculate a negative value?
Is
I have a custom C function that takes two text*s and returns a text*.
My problem is with this code:
PG_FUNCTION_INFO_V1(get_agent);
PGMODULEEXPORT Datum get_agent(PG_FUNCTION_ARGS)
{
if(!PG_ARGISNULL(0))
{
text* calling_party = PG_GETARG_TEXT_P(0);
58 matches
Mail list logo
