[HACKERS] O_DIRECT in freebsd
I noticed this in the FreeBSD 5.1 release notes: A new DIRECTIO kernel option enables support for read operations that bypass the buffer cache and put data directly into a userland buffer. This feature requires that the O_DIRECT flag is set on the file descriptor and that both the offset and length for the read operation are multiples of the physical media sector size. [MERGED] MERGED means that it should also appear in FreeBSD 4.9. Will PostgreSQL pick this up automatically, or do we need to add extra checks? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Our FLOAT(p) precision does not conform to spec
On 16 Jun 2003 at 18:15, Tom Lane wrote: This is a straightforward change and would not break pg_dump files, since fortunately pg_dump always references the underlying types and never refers to anything as FLOAT(p). But I wonder whether it is likely to break many existing applications. There is a hazard of some existing app asking for (what it thinks is) float8 and getting float4 instead. Especially apps. which rely on number(3) not to accept anything greate than +/- 999. I hate the syntax of putting decimal digits as range checkers in SQL field. But oracle does that and consequently lot of oracle apps rely on it. I won't be surprised if float(p) notion brings same assurance to such app developers. I think this would become and FAQ after changes are implemented. Who reads release notes anyway?..:-) Is it worth trying to provide some sort of backwards-compatibility mode? We could imagine adding a GUC variable to select binary or decimal precision, but I really don't want to. It would increase the amount of work needed by more than an order of magnitude, and this problem doesn't seem worth it. I'd rather just list this under Incompatibilities in the 7.4 release notes. Is it possible to have float-2(p) and float-10(p)? Would it be adding code sections instead of replacing it? That would be cleaner than GUC variable. Everything defaults to float-10(p) for backward compatibility for a period of a release and in 7.5, it gets switched to float-2(p). In the meantime, the behaviour remains available who cares to read the docs and notes. Just a thought.. Bye Shridhar -- Genderplex, n.: The predicament of a person in a restaurant who is unable to determine his or her designated restroom (e.g., turtles and tortoises). -- Rich Hall, Sniglets ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] O_DIRECT in freebsd
I noticed this in the FreeBSD 5.1 release notes: A new DIRECTIO kernel option enables support for read operations that bypass the buffer cache and put data directly into a userland buffer. This feature requires that the O_DIRECT flag is set on the file descriptor and that both the offset and length for the read operation are multiples of the physical media sector size. [MERGED] MERGED means that it should also appear in FreeBSD 4.9. Will PostgreSQL pick this up automatically, or do we need to add extra checks? Extra checks, though I'm not sure why you'd want this. This is the equiv of a nice way of handling raw IO for read only operations... which would be bad. Call me crazy, but unless you're on an embedded device with a non-existent FS cache or are Oracle and are handling the IO buffer in user space, the buffer cache is what helps speed up PostgreSQL since PostgreSQL leaves all of the caching operations and optimization/alignment of pages up to the OS (much to the behest of madvise() which could potentially speed up access of the VM, but I won't get into that... see TODO.mmap). -sc -- Sean Chittenden ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] O_DIRECT in freebsd
Will PostgreSQL pick this up automatically, or do we need to add extra checks? Extra checks, though I'm not sure why you'd want this. This is the equiv of a nice way of handling raw IO for read only operations... which would be bad. Call me crazy, but unless you're on The reason I mention it is that Postgres already supports O_DIRECT I think on some other platforms (for whatever reason). Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] information Windows - PostgreSQL
Hi, I would like to participate to PostgreSQL under Windows platform. What can i do to help ? x04001 __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_get_triggerdef in pg_dump
Christopher Kings-Lynne wrote: We make pg_get_xxx2 functions that return a formatted version. Internally, we just add an extra boolean parameter to the pg_get_triggerdef() function in ruleutils and we call that true or false depending... That's what I got too! Several weeks ago I proposed such functions as contribute module to this list, with no result. Seems I'm not the only one that wants to read his/her trigger/view/rules after pushing them into pgsql... Difference from Christopher's solution is that mine utilizes completely separatated (copied) code, so ruleutils code is still unchanged. This was a concession to Tom who claimed concerns about pg_dump not being able to reproduce things correctly if there was *any* error in it. Maybe we get some progress now on this topic? Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] client encodings
On Mon, 16 Jun 2003, Peter Eisentraut wrote: However, if you want to produce a utf-8 file, how should that work with respect to gettext()? If the message catalog is in latin1 then we need to know that and convert that into utf-8. I don't think all gettext implementations support automatic character set conversion. I agree. They don't. We might have to roll our own sometime That was why I asked if we could simply have all message catalogs as utf-8, then we know what charset the strings are in and can easily convert it to whatever we have set our client encoding to. but for now it's not an option. What has to be decided is if we are going to generate output that is only in the client encoding or not. If you just output the strings in the message catalog then we will not produce validating output. Then the best thing we can do is simply to take the message catalog string and discard everything that does not work in the current client encoding. -- /Dennis ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] confused with encodings
On Tue, 17 Jun 2003, Tatsuo Ishii wrote: Tatsuo, recently I tried to understand why I can't get sorting works properly with cyrillic characters in UTF8 datbase. I figure out the reason of my confusion - I thought I could specify different encodings for different databases and these encodings will be used in text operations (sort, upper,lower), not just for conversion. But, actually, the only encoding is important for text operations - the one specified with 'initdb' command ! Is't true ? If so, it's a big issue :) After I created separate storage for unicode (initdb -E utf8) and restarted postmaster I got success with 'order by', but upper(), lower() functions still fails. [I assume you enable the locale support.] isn't it enabled by default ? Dont't ask me. These are locale support problems. Sorry, I just wanted to understand where I get confused. You're right, utf8 locale support in glibc is broke, I've tested simple C-program with glibc 2.2.5 and 2.3.1 on Linux system and toupper, tolower functions are broken. btw, did you try libutf8 library ? http://www.haible.de/bruno/packages-libutf8.html -- Tatsuo Ishii Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] confused with encodings
On Tue, 17 Jun 2003, Tatsuo Ishii wrote:
[I assume you enable the locale support.]
isn't it enabled by default ?
It can be off by using ---no-locale option with initdb.
what's the benefit of this for non-ascii world :?
Dont't ask me. These are locale support problems.
Sorry, I just wanted to understand where I get confused.
You're right, utf8 locale support in glibc is broke,
I've tested simple C-program with glibc 2.2.5 and 2.3.1 on
Linux system and toupper, tolower functions are broken.
btw, did you try libutf8 library ?
http://www.haible.de/bruno/packages-libutf8.html
No. BTW, upper() will never work even glibc works fine with UTF-8. See
the code fragment below(utils/adt/oracle_compat.c);
char *ptr;
:
:
while (m-- 0)
{
*ptr = toupper((unsigned char) *ptr);
ptr++;
}
Apparently this is not multibyte aware...
I see. Hope someone is aware on making postgresql unicode compatible.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] O_DIRECT in freebsd
On Tue, 17 Jun 2003, Christopher Kings-Lynne wrote: A new DIRECTIO kernel option enables support for read operations that bypass the buffer cache and put data directly into a userland buffer Will PostgreSQL pick this up automatically, or do we need to add extra checks? You don't want it to. It's more efficent just to use mmap, because then all the paging and caching issues are taken care of for you. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] confused with encodings
Oleg Bartunov writes: I thought I could specify different encodings for different databases and these encodings will be used in text operations (sort, upper,lower), not just for conversion. But, actually, the only encoding is important for text operations - the one specified with 'initdb' command ! Is't true ? Absolutely not, but you may find that in order to allow LC_CTYPE operations (namely sort, upper, lower) in UTF8, you need a locale that supports that, namely the xx_XX.utf8 kind. So realistically, you are kind of stuck with one encoding for the entire cluster. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pg_get_triggerdef in pg_dump
Andreas Pflug [EMAIL PROTECTED] writes: Difference from Christopher's solution is that mine utilizes completely separatated (copied) code, so ruleutils code is still unchanged. This was a concession to Tom who claimed concerns about pg_dump not being able to reproduce things correctly if there was *any* error in it. I recall objecting to someone who wanted to remove unnecessary parentheses, but I can't see any risk in inserting unnecessary whitespace. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] O_DIRECT in freebsd
Christopher Kings-Lynne [EMAIL PROTECTED] writes: The reason I mention it is that Postgres already supports O_DIRECT I think on some other platforms (for whatever reason). [ sounds of grepping... ] No. The only occurrence of O_DIRECT in the source tree is in TODO: * Consider use of open/fcntl(O_DIRECT) to minimize OS caching I personally disagree with this TODO item for the same reason Sean cited: Postgres is designed and tuned to rely on OS-level disk caching, and bypassing that cache is far more likely to hurt our performance than help it. However, if someone wants to do some experimentation with O_DIRECT, I'd be as interested as anyone to find out what happens... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pg_get_triggerdef in pg_dump
Tom Lane wrote: I recall objecting to someone who wanted to remove unnecessary parentheses, but I can't see any risk in inserting unnecessary whitespace. That someone was me indeed, and as I mentioned the code is completely separated from the code that pg_dump uses. Thus, there's *no way* that this could break backup integrity. I consider these original functions as pg_dump helper functions, not meant to be human readable. There are *many* parentheses that are not necessary, and the code trying to figure out is quite conservative. All is decided in one single routine, depending on two parameters only, and thus failing to locate several cases when parentheses would be avoidable (not even */ over +- will be noticed!). I've been trying hard to make pgsql as maintainable as mssql, and there's only this point left. Any attempts to contribute this so far just have been answered with dunno but there might eventually perhaps maybe some problem without having a look at that function. I feel that I am asked to prove the validity of my code, which is as impossible as it is for software in general, but I haven't seen any case where my solution failed to reproduce correctly. If you know one, tell me. If you know a case where my core routine decides falsely, tell me. What I *really* want is having the original source stored, including comments, version info, ... Currently, it's argued that underlying table and column might change, braking the view/rule. This could be restricted, or source could be dropped (alter table ... cascaded). Is it really only me who tries to put complicated views into pgsql and wants to understand them 10 days later? We do have an enterprise grade RDBMS, don't we? Regards, Andreas ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Errors compiling hba.c in current CVS
On Mon, Jun 16, 2003 at 17:21:01 -0400, Bruce Momjian [EMAIL PROTECTED] wrote: Does the following patch fix the problem? It doesn't use sa_family_t anymore. I tried using the pacth and it didn't help. I am going to get a fresh CVS copy and see if that works. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Errors compiling hba.c in current CVS
On Mon, Jun 16, 2003 at 05:21:01PM -0400, Bruce Momjian wrote: Does the following patch fix the problem? It doesn't use sa_family_t anymore. ! sa_family_t ss_family; /* address family */ [...] ! char dummy_sa_family[SIZEOF_SOCKADDR_FAMILY]; That is NOT going to work. Not only did you change the only member of the struct we use, you changed it into an array. Something like this might do it: #if SIZEOF_SOCKADDR_FAMILY == 1 uint8_t ss_family; #elif SIZEOF_SOCKADDR_FAMILY == 2 uint16_tss_family; #else #error unsupported sa_family size #endif And isn't this patch more for an other thread anyway? Kurt ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Errors compiling hba.c in current CVS
On Mon, Jun 16, 2003 at 17:21:01 -0400, Bruce Momjian [EMAIL PROTECTED] wrote: Does the following patch fix the problem? It doesn't use sa_family_t anymore. I tried current CVS and current CVS with the patch you attached and it still didn't work. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Table functions and AS clauses ...
Hans-Jürgen Schönig wrote: However, my question is: Is there a way to implement it in a way that does not depend on the remote data structure? Is there a way to get rid of the AS without having to define a type? Unfortunately, no. The parse and planning stages need defined types, so waiting for the function to execute is too late. We've discussed it a time or two before (as recently as within the last week), but the conclusion has been that there is no easy answer to the problem. Joe ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Domains and function arguments
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Admittedly, we have trouble resolving the type to use when a function is overloaded with both a domain and a base type, but that's hardly surprising. Even if you try to work it out, it's going to be a mess. During resolution, you would have to look inside the data to figure out which domain, if any, it might fit into. No, we'd just use the declared type of the input to determine what to do, same as we do now. If you want a domain-specific function to be applied, you need to have the input be already of that domain, or you coerce to it. If you insist on allowing domains in argument lists, then I think the best approach is this: For purpose of function resolution, types and all domains defined over them are equivalent. That would mean, for example, that if you define positive_int as domain over int, then you cannot define foofunc(int) and foofunc(positive_int) as the same time. I think that'd be throwing the baby out with the bathwater. The above is, more or less, *exactly* what you want to do in typical scenarios. foofunc(int) is the general case, foofunc(positive_int) offers some sort of performance or other advantage for the special case. We do have some usable functionality in this area today: regression=# create domain positive_int as int check (value 0); CREATE DOMAIN regression=# create function foofunc(int) returns int as 'select 1' language sql; CREATE FUNCTION regression=# create function foofunc(positive_int) returns int as 'select 2' language sql; CREATE FUNCTION regression=# select foofunc(1); foofunc - 1 (1 row) regression=# select foofunc(1::positive_int); foofunc - 2 (1 row) regression=# Prohibiting this setup would take away usable if limited functionality, in return for what? The fact that foofunc(1::int2) doesn't work without an explicit cast is annoying, but it's not significantly different in my mind from the fact that to_hex(1::int2) doesn't work. We're not going to forbid users from supplying both int4 and int8 versions of a function, so we shouldn't forbid base and domain versions either. I think we could make most of the problems you cite go away if, at the top of func_select_candidate() where we chop input types to base types, we also discard any candidates that take domain types. They're guaranteed not to match at that point, so we aren't losing any cases that work. The overhead of doing this is a tad annoying, but maybe we can combine it with some other catalog lookup. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_get_triggerdef in pg_dump
What I *really* want is having the original source stored, including comments, version info, ... Currently, it's argued that underlying table and column might change, braking the view/rule. This could be restricted, or source could be dropped (alter table ... cascaded). Is it really only me who tries to put complicated views into pgsql and wants to understand them 10 days later? We do have an enterprise grade RDBMS, don't we? You could argue that comments should be converted to an 'information' node within the query structure which contains comments. They would then be dumped back out to the user. But I think you would be dissapointed if you were returned the view that is no longer correct since someone renamed the tables. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
[HACKERS] ss_family in hba.c
I was looking at this some more and now think there is something wrong with the references to ss_family rather than a missing inlcude file. Perhaps those were supposed to be references to sa_family or there is a missing field from the socket_storage type definition. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Extending PostgreSQL in C or C++
Hi,
I need to extend postgreSQL to support some specific function I will
code in C (ideally C++ if it can work!). I'm trying to run some simple
test and it doesn't seem to work. Here is the C code:
--
#include postgres.h
#include string.h
int
add_one(int arg)
{
return arg + 1;
}
--
Which is compiled with:
gcc -fpic -c -I/[ThePath]/postgresql-7.3.2/include/server/ pgsql_bio.c
gcc -shared -o pgsql_bio.so pgsql_bio.o
It compiles fine.
And then in postgreSQL as user postgres in database template1:
CREATE FUNCTION add_one(int4) RETURNS int4
AS '/[PathToTheObject]/pgsql_bio.so' LANGUAGE C
WITH (isStrict);
Then I get:
ERROR: Can't find function add_one in file /[PathToTheObject]/pgsql_bio.so
I'm using PostgreSQL 7.3.2 on Redhat 7.2 (linux 2.4.7-10) and compiling
with gcc 2.95.3.
Following some suggestions I found on usenet, I ran 'nm' on the library
and I got the expected entry for my function:
0700 T add_one
Anyone has an idea about what I am doing wrong? Any suggestion will be
welcome!
thanks,
--
Sebastien Lemieux
Bioinformatics, post-doc
Elitra-canada
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ss_family in hba.c
On Tue, Jun 17, 2003 at 03:32:32PM -0500, Bruno Wolff III wrote: I was looking at this some more and now think there is something wrong with the references to ss_family rather than a missing inlcude file. Perhaps those were supposed to be references to sa_family or there is a missing field from the socket_storage type definition. The struct sockaddr_storage should only have 1 field you can use and that is ss_family. The other fields are there just to get the right size and padding. Does your system have it's own (broken?) struct sockaddr_storage maybe? Kurt ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ss_family in hba.c
My system has the same problem - struct sockaddr_storage is defined in
/usr/include/bits/socket.h :
struct sockaddr_storage
{
__SOCKADDR_COMMON (__ss_); /* Address family, etc. */
__ss_aligntype __ss_align; /* Force desired alignment. */
char __ss_padding[_SS_PADSIZE];
};
Where SOCKADDR_COMMON is defined in sockaddr.h as :
#define __SOCKADDR_COMMON(sa_prefix) \
sa_family_t sa_prefix##family
That means on my machine it needs __ss_family and not ss_family
Kernel 2.4.18
SuSE 7.1
I changed ss_family to __ss_family and it compiles fine (also in an ip.c
fe-connect.c IIRC) ...
On Tuesday 17 June 2003 9:49 pm, Kurt Roeckx wrote:
On Tue, Jun 17, 2003 at 03:32:32PM -0500, Bruno Wolff III wrote:
I was looking at this some more and now think there is something wrong
with the references to ss_family rather than a missing inlcude file.
Perhaps those were supposed to be references to sa_family or there
is a missing field from the socket_storage type definition.
The struct sockaddr_storage should only have 1 field you can use
and that is ss_family. The other fields are there just to get
the right size and padding.
Does your system have it's own (broken?) struct sockaddr_storage
maybe?
Kurt
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Extending PostgreSQL in C or C++
Sebastien Lemieux wrote: Hi, I need to extend postgreSQL to support some specific function I will code in C (ideally C++ if it can work!). Be very carefull with using C++ functions inside postgresql. If the C++ code throws an exception the postgresql backend will get a SIGABRT and terminate. You can solve this by linking the std c++ library to the postmaster. We tried everything we could think of to fix this, but this was the only solution that worked. For a complete discussion, you can read the PostGIS (GIS spatial objects for Postgresql) mailing list (http://postgis.refractions.net) and the GEOS (Geometry Engine, Open Source) mailing list (http://geos.refractions.net). dave ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Extending PostgreSQL in C or C++
Sebastien Lemieux [EMAIL PROTECTED] writes: Then I get: ERROR: Can't find function add_one in file /[PathToTheObject]/pgsql_bio.so Hmm. I can't see anything wrong with what you did, either. It's possible that the dynamic linker has printed additional messages to the backend's stderr. Make sure that you have stderr set up to go someplace useful (not /dev/null) and look there to see if you can learn more. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] pg_get_triggerdef in pg_dump
Rod Taylor wrote: What I *really* want is having the original source stored, including comments, version info, ... Currently, it's argued that underlying table and column might change, braking the view/rule. This could be restricted, or source could be dropped (alter table ... cascaded). Is it really only me who tries to put complicated views into pgsql and wants to understand them 10 days later? We do have an enterprise grade RDBMS, don't we? You could argue that comments should be converted to an 'information' node within the query structure which contains comments. They would then be dumped back out to the user. But I think you would be dissapointed if you were returned the view that is no longer correct since someone renamed the tables. Rod, this arguments are quite academic. On one side, this could be restricted, thats what pg_depends is good for (this already happens for inherited tables). On the other side, how often do you rename columns or tables? On mssql, nobody cares. If you fool around with names, your views will be broken without warning. pgsql could be better easily. I'd really prefer to have full view sources available rather than the gimmick of stable views despite renamed cols/tabs. Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Extending PostgreSQL in C or C++
David Blasby wrote:
Sebastien Lemieux wrote:
Hi,
I need to extend postgreSQL to support some specific function I
will code in C (ideally C++ if it can work!).
Be very carefull with using C++ functions inside postgresql. If the
C++ code throws an exception the postgresql backend will get a SIGABRT
and terminate.
You can solve this by linking the std c++ library to the postmaster.
We tried everything we could think of to fix this, but this was the
only solution that worked.
For a complete discussion, you can read the PostGIS (GIS spatial
objects for Postgresql) mailing list (http://postgis.refractions.net)
and the GEOS (Geometry Engine, Open Source) mailing list
(http://geos.refractions.net).
If you try C++, you will find some nasty name/reserved words collisions,
but it will work:
#define using __using
#define typeid __typeid
#define typename __typename
#define namespace __namespace
#define delete __delete
extern C
{
#include postgres.h
#include executor/spi.h
#include funcapi.h
}
#undef using
#undef typeid
#undef typename
#undef namespace
#undef delete
Fortunately, my code didn't use exceptions...
Regards,
Andreas
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Our FLOAT(p) precision does not conform to spec
Shridhar Daithankar [EMAIL PROTECTED] writes: On 16 Jun 2003 at 18:15, Tom Lane wrote: This is a straightforward change and would not break pg_dump files, since fortunately pg_dump always references the underlying types and never refers to anything as FLOAT(p). But I wonder whether it is likely to break many existing applications. There is a hazard of some existing app asking for (what it thinks is) float8 and getting float4 instead. I hate the syntax of putting decimal digits as range checkers in SQL field. But oracle does that and consequently lot of oracle apps rely on it. I won't be surprised if float(p) notion brings same assurance to such app developers. You are confusing NUMERIC --- which does allow exact precision limits to be specified --- with FLOAT, which does no such thing. It has never been the case in Postgres that FLOAT(p) would restrict you to exactly p digits. The underlying implementation is that there are just two kinds of float (single and double precision) and you get whichever can hold at least p digits. This is per spec, which states that you get at least p digits, not exactly p digits. Our only problem is that whoever wrote that code failed to notice that p is supposed to be measured differently for FLOAT than for NUMERIC. AFAICT, other databases get this right (at least Oracle and DB2 do), so expectations of developers are more likely to be that we conform to the spec than that we don't. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Our FLOAT(p) precision does not conform to spec
Peter Eisentraut [EMAIL PROTECTED] writes: Considering that the data type float(x) isn't documented anywhere, I'm not worried. Good point ... I'll fix that while I'm at it ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Our FLOAT(p) precision does not conform to spec
Tom Lane writes: This is a straightforward change and would not break pg_dump files, since fortunately pg_dump always references the underlying types and never refers to anything as FLOAT(p). But I wonder whether it is likely to break many existing applications. There is a hazard of some existing app asking for (what it thinks is) float8 and getting float4 instead. Considering that the data type float(x) isn't documented anywhere, I'm not worried. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] O_DIRECT in freebsd
On Tue, 17 Jun 2003, Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: The reason I mention it is that Postgres already supports O_DIRECT I think on some other platforms (for whatever reason). [ sounds of grepping... ] No. The only occurrence of O_DIRECT in the source tree is in TODO: * Consider use of open/fcntl(O_DIRECT) to minimize OS caching I personally disagree with this TODO item for the same reason Sean cited: Postgres is designed and tuned to rely on OS-level disk caching, and bypassing that cache is far more likely to hurt our performance than help it. DB2 and Oracle, from memory, allow users to pass hints to the planner to use/not use file system caching. This could be useful if you had an application retrieving a large amount of data on an adhoc basis. The large retrieval would empty out the disk cache there by negatively impacting upon other applications operating on data which should be cached. Gavin ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] sa_family_t in cygwin compile of cvs
Jason Tishler wrote: On Sun, Jun 15, 2003 at 04:54:21PM +0100, deststar wrote: On cygwin sa_family_t was undeclared, adding the following line: typedef unsigned short sa_family_t; to both: src/port/getaddrinfo.c src/include/libpq/pqcomm.h Isn't the attached or fixing Cygwin itself a better approach? Yes it does seem better, attached is a proposed patch to cygwin.h configure.in (incase cygwin gets it in future) Have tested with make installcheck it works fine. If you see no problems I will sumit to patches thanks, - Stuart *** src/include/port/cygwin.h.orig Thu May 22 18:20:28 2003 --- src/include/port/cygwin.h Tue Jun 17 22:31:04 2003 *** *** 21,23 --- 21,28 #else #define DLLIMPORT __declspec (dllimport) #endif + + #ifndef HAVE_SA_FAMILY_T + typedef unsigned short sa_family_t; + #endif + *** configure.in.orig Sun Jun 15 05:07:58 2003 --- configure.inTue Jun 17 22:22:24 2003 *** *** 855,860 --- 855,866 [$ac_includes_default #include netinet/in.h]) + AC_CHECK_TYPE(sa_family_t, + [AC_DEFINE(HAVE_SA_FAMILY_T,1,[Cygwin does not have sa_family_t defined so test])], + [], + [$ac_includes_default + #include netinet/in.h]) + AC_CACHE_CHECK([for PS_STRINGS], [pgac_cv_var_PS_STRINGS], [AC_TRY_LINK( [#include machine/vmparam.h ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] sa_family_t in cygwin compile of cvs
I am confused why you didn't like the following patch I posted, which
pulls the family data type length right out of the structure, rather than
having to configure it for every OS that doesn't have sa_family_t?
---
deststar wrote:
Jason Tishler wrote:
On Sun, Jun 15, 2003 at 04:54:21PM +0100, deststar wrote:
On cygwin sa_family_t was undeclared, adding the following line:
typedef unsigned short sa_family_t;
to both:
src/port/getaddrinfo.c
src/include/libpq/pqcomm.h
Isn't the attached or fixing Cygwin itself a better approach?
Yes it does seem better, attached is a proposed patch to cygwin.h
configure.in (incase cygwin gets it in future)
Have tested with make installcheck it works fine.
If you see no problems I will sumit to patches
thanks,
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/include/libpq/pqcomm.h
===
RCS file: /cvsroot/pgsql-server/src/include/libpq/pqcomm.h,v
retrieving revision 1.86
diff -c -c -r1.86 pqcomm.h
*** src/include/libpq/pqcomm.h 12 Jun 2003 07:36:51 - 1.86
--- src/include/libpq/pqcomm.h 16 Jun 2003 21:11:09 -
***
*** 43,57
/*
* Definitions used for sockaddr_storage structure paddings design.
*/
! #define _SS_PAD1SIZE(_SS_ALIGNSIZE - sizeof (sa_family_t))
! #define _SS_PAD2SIZE(_SS_MAXSIZE - (sizeof (sa_family_t) + \
_SS_PAD1SIZE + _SS_ALIGNSIZE))
struct sockaddr_storage {
#ifdef SALEN
uint8_t __ss_len;/* address length */
#endif
! sa_family_t ss_family; /* address family */
char __ss_pad1[_SS_PAD1SIZE];
/* 6 byte pad, this is to make implementation
--- 43,60
/*
* Definitions used for sockaddr_storage structure paddings design.
*/
! /* Some platforms don't have sa_family_t, so we compute it ourselves */
! #define SIZEOF_SOCKADDR_FAMILYsizeof(((struct sockaddr
*)0)-sa_family)
!
! #define _SS_PAD1SIZE(_SS_ALIGNSIZE - SIZEOF_SOCKADDR_FAMILY)
! #define _SS_PAD2SIZE(_SS_MAXSIZE - (SIZEOF_SOCKADDR_FAMILY + \
_SS_PAD1SIZE + _SS_ALIGNSIZE))
struct sockaddr_storage {
#ifdef SALEN
uint8_t __ss_len;/* address length */
#endif
! char dummy_sa_family[SIZEOF_SOCKADDR_FAMILY];
char __ss_pad1[_SS_PAD1SIZE];
/* 6 byte pad, this is to make implementation
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_get_triggerdef in pg_dump
this arguments are quite academic. You what! On one side, this could be restricted, thats what pg_depends is good for (this already happens for inherited tables). On the other side, how often do you rename columns or tables? You what! On mssql, nobody cares. You what! If you fool around with names, your views will be broken without warning. pgsql could be better easily. I'd really prefer to have full view sources available rather than the gimmick of stable views despite renamed cols/tabs. Gimmick! You what!! ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Fields float4 don't return any row when selecting a value with a.
Hi all, I'm using the 7.4 cvs version on cygwin and I noticed that if I have a table with a field of float4 type and try to do a simple select: select * from table where field_float4 = 4.4 it doesn't return any rows. In the same table I have a float8 field and it works ok. If I try with a value without the . in the float4 field it also works. The only way I could get the field_float4 to work was to add '' in the value. Summary of results: Table created as: create table tableD(field_float4 float4, field_float8 float8); insert into tableD values (3.3, 4.4); insert into tableD values (4, 3); select * from tableD where field_float4 = 3.3 == 0 rows returned select * from tableD where field_float8 = 4.4 -- 1 row returned. select * from tableD where field_float4 = '3.3' == 1 row returned. Can someone confirm that for me? Thanks in advance. -- Regards, Francisco Figueiredo Jr. -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Fields float4 don't return any row when selecting a value with a .
On Tue, Jun 17, 2003 at 23:26:07 -0300, Francisco Figueiredo Jr. [EMAIL PROTECTED] wrote: Hi all, I'm using the 7.4 cvs version on cygwin and I noticed that if I have a table with a field of float4 type and try to do a simple select: select * from table where field_float4 = 4.4 it doesn't return any rows. In the same table I have a float8 field and it works ok. If I try with a value without the . in the float4 field it also works. I believe that is because the constant 4.4 is originally a float 8 value and the comparison to the float4 value is done by promoting to float8. And the nearest float4 value to 4.4 is not the same as the nearest float8 value to 4.4. I think both quoting the 4.4 or casting it to float4 will solve your problem. Note that under many circumstances equality tests between floating values doesn't make a lot of sense. If you really want to do this, you might want to consider using the numeric type. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ss_family in hba.c
On Tue, Jun 17, 2003 at 22:49:00 +0200, Kurt Roeckx [EMAIL PROTECTED] wrote: On Tue, Jun 17, 2003 at 03:32:32PM -0500, Bruno Wolff III wrote: I was looking at this some more and now think there is something wrong with the references to ss_family rather than a missing inlcude file. Perhaps those were supposed to be references to sa_family or there is a missing field from the socket_storage type definition. The struct sockaddr_storage should only have 1 field you can use and that is ss_family. The other fields are there just to get the right size and padding. Does your system have it's own (broken?) struct sockaddr_storage maybe? I am going to look around a bit and see if I can figure this out. Things worked fine before Bruce changed this stuff. Presumably the changed code is working for the core or the change would have been reverted days ago. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] lots of configure failures on freebsd/alpha
configure: WARNING: sys/select.h: present but cannot be compiled configure: WARNING: sys/select.h: check for missing prerequisite headers? configure: WARNING: sys/select.h: proceeding with the preprocessor's result checking for sys/select.h... yes checking sys/sem.h usability... no checking sys/sem.h presence... yes configure: WARNING: sys/sem.h: present but cannot be compiled configure: WARNING: sys/sem.h: check for missing prerequisite headers? configure: WARNING: sys/sem.h: proceeding with the preprocessor's result checking for sys/sem.h... yes checking sys/socket.h usability... no checking sys/socket.h presence... yes configure: WARNING: sys/socket.h: present but cannot be compiled configure: WARNING: sys/socket.h: check for missing prerequisite headers? configure: WARNING: sys/socket.h: proceeding with the preprocessor's result checking for sys/socket.h... yes checking sys/shm.h usability... no checking sys/shm.h presence... yes configure: WARNING: sys/shm.h: present but cannot be compiled configure: WARNING: sys/shm.h: check for missing prerequisite headers? configure: WARNING: sys/shm.h: proceeding with the preprocessor's result checking for sys/shm.h... yes checking sys/un.h usability... no checking sys/un.h presence... yes configure: WARNING: sys/un.h: present but cannot be compiled configure: WARNING: sys/un.h: check for missing prerequisite headers? configure: WARNING: sys/un.h: proceeding with the preprocessor's result checking for sys/un.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking utime.h usability... no checking utime.h presence... yes configure: WARNING: utime.h: present but cannot be compiled configure: WARNING: utime.h: check for missing prerequisite headers? configure: WARNING: utime.h: proceeding with the preprocessor's result ... configure: WARNING: netinet/in.h: present but cannot be compiled configure: WARNING: netinet/in.h: check for missing prerequisite headers? configure: WARNING: netinet/in.h: proceeding with the preprocessor's result ... checking types of arguments for accept()... configure: error: could not determine argument types gmake: *** [config.status] Error 1 Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ss_family in hba.c
On Tue, Jun 17, 2003 at 22:49:00 +0200, Kurt Roeckx [EMAIL PROTECTED] wrote: On Tue, Jun 17, 2003 at 03:32:32PM -0500, Bruno Wolff III wrote: I was looking at this some more and now think there is something wrong with the references to ss_family rather than a missing inlcude file. Perhaps those were supposed to be references to sa_family or there is a missing field from the socket_storage type definition. The struct sockaddr_storage should only have 1 field you can use and that is ss_family. The other fields are there just to get the right size and padding. Does your system have it's own (broken?) struct sockaddr_storage maybe? My system does have its own sockaddr_storage definition. I think it uses __ss_ as the prefix. Also, after looking at the fallback definition in pqcomm.h, I don't see where that defines ss_family and hence don't see how that could work. I am going to see if adding __ works as suggested by someone else who replied. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ss_family in hba.c
On Tue, Jun 17, 2003 at 23:01:27 -0500, Bruno Wolff III [EMAIL PROTECTED] wrote: I am going to see if adding __ works as suggested by someone else who replied. This worked. I think the reason auth.c compiled was because the reference to ss_family was in conditional code that isn't used on my system. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] lots of configure failures on freebsd/alpha
Christopher Kings-Lynne [EMAIL PROTECTED] writes: configure: WARNING: sys/select.h: present but cannot be compiled configure: WARNING: sys/select.h: check for missing prerequisite headers? [many similar] bare ass guess do these headers assume sys/types.h as a prerequisite on your system? Not sure why it'd have just now broken, though. Take a look at the most recent commits to the configure stuff if you need clues. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] lots of configure failures on freebsd/alpha
bare ass guess do these headers assume sys/types.h as a prerequisite on your system? I don't know - I'll check Not sure why it'd have just now broken, though. Take a look at the most recent commits to the configure stuff if you need clues. I haven't tried a build for a few weeks... Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Domains and function arguments
Tom, If you insist on allowing domains in argument lists, then I think the best approach is this: For purpose of function resolution, types and all domains defined over them are equivalent. That would mean, for example, that if you define positive_int as domain over int, then you cannot define foofunc(int) and foofunc(positive_int) as the same time. As a heavy PL/pgSQL function user, the above sounds completely reasonable workable to me. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] ECPG still having thread problems
Hi all, it looks like Lee's ECPG (and libpq) thread-safety patches
have been applied, and configure --with-threads is also added. I
have been doing some testing, and I still encounter a
threading problem.
I have done the following:
1) cvs update
2) ./configure --with-threads make su -c make install
3) compiled cn.pgc as follows:
a) ecpg -t cn.pgc
b) gcc -I/usr/local/pgsql/include -L/usr/local/pgsql/lib \
-lecpg -lpgtypes -lpthread cn.c
4) ./a.out - one thread runs to completion (inserts 5 records),
the other hangs (manages one insert, then blocks forever)
Using gdb, I attached to the LWP that has locked up, and the backtrace
looks like this:
(gdb) backtrace
#0 0x420e0187 in poll () from /lib/i686/libc.so.6
#1 0x4007d8cc in pqSocketPoll () from /usr/local/pgsql/lib/libpq.so.3
#2 0x4007d7ed in pqSocketCheck () from /usr/local/pgsql/lib/libpq.so.3
#3 0x4007d71f in pqWaitTimed () from /usr/local/pgsql/lib/libpq.so.3
#4 0x4007d6f5 in pqWait () from /usr/local/pgsql/lib/libpq.so.3
#5 0x4007bb53 in PQgetResult () from /usr/local/pgsql/lib/libpq.so.3
#6 0x4007bcbb in PQexec () from /usr/local/pgsql/lib/libpq.so.3
#7 0x40026d81 in ECPGexecute () from /usr/local/pgsql/lib/libecpg.so.4
#8 0x4002724c in ECPGdo () from /usr/local/pgsql/lib/libecpg.so.4
#9 0x08048927 in ins2 ()
#10 0x40043faf in pthread_start_thread () from /lib/i686/libpthread.so.0
(The other threads are waiting to pthread_join)
I'd really appreciate it if someone could try this sample app to
confirm whether I am doing something wrong, or my environment is
faulty, or if there is still a thread problem.
Build env:
Linux 2.4.18-3
gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-113)
Philip Yarra.
/* on linux, you can compile with:
ecpg cn.pgc gcc -I/usr/local/pgsql/include -L/usr/local/pgsql/lib -lpgtypes -lecpg -lpthread cn.c
and you'll need this table:
CREATE TABLE foo (
message character(40)
);
*/
#include pthread.h
int main();
void ins1();
void ins2();
int main()
{
pthread_t thread1, thread2;
pthread_create(thread1, NULL, (void *) ins1, NULL);
pthread_create(thread2, NULL, (void *) ins2, NULL);
pthread_join(thread1, NULL);
pthread_join(thread2, NULL);
printf(Done!);
return 0;
}
void ins1()
{
int i;
EXEC SQL BEGIN DECLARE SECTION;
char* cs = [EMAIL PROTECTED];
char* bar = one!;
EXEC SQL END DECLARE SECTION;
EXEC SQL WHENEVER sqlerror sqlprint;
EXEC SQL CONNECT TO :cs AS test1;
EXEC SQL SET AUTOCOMMIT TO ON;
for (i = 0; i 5; i++)
{
printf(thread1 inserting\n);
EXEC SQL INSERT INTO foo VALUES(:bar);
printf(==thread1 insert done\n);
}
EXEC SQL DISCONNECT test1;
printf(done!\n);
}
void ins2()
{
int i;
EXEC SQL BEGIN DECLARE SECTION;
char* cs = [EMAIL PROTECTED];
char* bar = two!;
EXEC SQL END DECLARE SECTION;
EXEC SQL WHENEVER sqlerror sqlprint;
EXEC SQL CONNECT TO :cs AS test2;
EXEC SQL SET AUTOCOMMIT TO ON;
for (i = 0; i 5; i++)
{
printf(thread2 inserting\n);
EXEC SQL INSERT INTO foo VALUES(:bar);
printf(==thread2 insert done\n);
}
EXEC SQL DISCONNECT test2;
printf(done!\n);
}
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] O_DIRECT in freebsd
On Wed, Jun 18, 2003 at 10:01:37AM +1000, Gavin Sherry wrote: On Tue, 17 Jun 2003, Tom Lane wrote: * Consider use of open/fcntl(O_DIRECT) to minimize OS caching I personally disagree with this TODO item for the same reason Sean cited: Postgres is designed and tuned to rely on OS-level disk caching, and bypassing that cache is far more likely to hurt our performance than help it. DB2 and Oracle, from memory, allow users to pass hints to the planner to use/not use file system caching. This could be useful if you had an application retrieving a large amount of data on an adhoc basis. The large retrieval would empty out the disk cache there by negatively impacting upon other applications operating on data which should be cached. Might it make sense to do this for on-disk sorts, since sort_mem is essentially being used as a disk cache (at least for reads)? -- Jim C. Nasby (aka Decibel!)[EMAIL PROTECTED] Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
