[HACKERS] clang and LLVM
Hi, I was wondering if there has been anyone experimenting to compile PG using LLVM/clang compiler tools. Regards, Gevik. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Question about FUNCDETAIL_MULTIPLE
Tom Lane wrote: Gevik Babakhani writes: I was wondering what the philosophy is behind letting an "ambiguous" function be created in the first place. Is this for backwards compatibility or perhaps for historical reasons? Neither; it's a feature, and one we quite like. For example, would you really prefer that the six different versions of abs() had to have different names? regression=# \df abs List of functions Schema | Name | Result data type | Argument data types | Type +--+--+-+ pg_catalog | abs | bigint | bigint | normal pg_catalog | abs | double precision | double precision| normal pg_catalog | abs | integer | integer | normal pg_catalog | abs | numeric | numeric | normal pg_catalog | abs | real | real| normal pg_catalog | abs | smallint | smallint| normal (6 rows) Even if you were willing to do that, what about the forty-seven distinct versions of "+"? Overloaded operators are not fundamentally different from overloaded functions. regards, tom lane I understand the value of this future. This basically means that one has to keep the function naming and argument types as simple as logically possible in order to avoid situations like I described in my previous example. (Sorry for bothering you with questions likes this. I am trying to understand PG) -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Question about FUNCDETAIL_MULTIPLE
I was wondering what the philosophy is behind letting an "ambiguous" function be created in the first place. Is this for backwards compatibility or perhaps for historical reasons? Could someone clarify this please? Consider the following example: ( FYI: parse_func.c->ParseFuncOrColumn->164 parse_func.c->ParseFuncOrColumn->810 parse_func.c->ParseFuncOrColumn->836 namespace.c->FuncnameGetCandidates->607 namespace.c->FuncnameGetCandidates->826 parse_func.c->ParseFuncOrColumn->224 ) - create or replace function foo1(int,int default 1,int default 2) returns int as $$ select $1+$2+$3 $$ language sql; create or replace function foo1(int,int default 1) returns int as $$ select $1+$2 $$ language sql; select * from foo1(10,10) ERROR: function foo1(integer, integer) is not unique LINE 15: select * from foo1(10,10) ^ HINT: Could not choose a best candidate function. You might need to add explicit type casts. ----- -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Question about STRICT
Tom Lane wrote: Gevik Babakhani writes: Perhaps it is an idea to have something like: "RAISE ERROR ON NULL INPUT" [ shrug... ] There's really been no demand for that. If you want a particular function to do it, you can put suitable tests and error reports into that function. I can't see us adding extra cycles into the core function-calling code (which is a very hot hot-spot) for a feature with so little demand. Understood. Thank you (Tom and Greg) for clarifying this. -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Question about STRICT
Greg Stark wrote: On Wed, Jun 3, 2009 at 11:04 AM, Gevik Babakhani wrote: The "RETURNS NULL ON NULL INPUT" is logical and does the above accordingly. But when a function is STRICT you kind of expect to have an notification, perhaps an error if a value for an argument is NULL. Uhm, you might but I'm not sure why. That's not what STRICT does. It's a synonym for RETURNS NULL ON NULL INPUT. Perhaps it is an idea to have something like: "RAISE ERROR ON NULL INPUT" -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Question about STRICT
Shouldn't we raise an error when calling a function with NULL arguments values if the function is created as STRICT? No, what they do is return NULL automatically. The function doesn't have to check for NULL arguments itself. The "RETURNS NULL ON NULL INPUT" is logical and does the above accordingly. But when a function is STRICT you kind of expect to have an notification, perhaps an error if a value for an argument is NULL. STRICT is sort of puzzling when you want to make sure a function is only called if none of the arguments are NULL. With STRICT, the function is "called" anyway and returns NULL, witch results the application code to happily execute further without noticing that calling the function did not do anything. I am thinking about the following situation: create table table1 ( col1 int, col2 varchar ); create or replace function insert_test(int,varchar) returns void as $$ insert into table1 (col1,col2) values ($1,$2); $$ language sql strict; select * from insert_test(null,'a'); select * from table1; -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A humble request
Thank you for making this available :) Bruce Momjian wrote: Gevik Babakhani wrote: please, please, please The video is here: http://hosting3.epresence.tv/fosslc/1/watch/121.aspx --- David Fetter wrote: On Fri, May 22, 2009 at 10:39:13AM +0200, Gevik Babakhani wrote: Hi, For the ones who couldn't attend to "How to Get Your PostgreSQL Patch Accepted", could someone please make a summary. (Tom? Bruce?) Thank you. Video will get posted pretty soon after, and expect tweets, blog posts, etc. :) Cheers, David. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Question about STRICT
Could someone please clarify the difference between "RETURNS NULL ON NULL INPUT" or "STRICT" when creating a function. Do both options exist because of historical reasons/SQL standard compliance? Shouldn't we raise an error when calling a function with NULL arguments values if the function is created as STRICT? (This would of course have an impact on checking for NULLs on arguments defaults if the above is implemented.) -- Regards, Gevik
Re: [HACKERS] usability of pg_get_function_arguments
Tom Lane wrote: Gevik Babakhani writes: I experimented with your example and noticed that pg_get_expr requires a hack --- it insists on having a relation OID argument, because all previous use-cases for it involved expressions that might possibly refer to a particular table. So you have to do something like regression=# select pg_get_expr(proargdefaults,'pg_proc'::regclass) from pg_proc where proname='f13'; pg_get_expr --- 10, 'hello'::character varying, '2009-01-01 00:00:00'::timestamp without time zone, 'comma here ,'::character varying (1 row) Unfortunately, there is no way to know to which argument(s) the values above belongs to. The last ones --- you can only omit arguments from the right, so it makes no sense to allow a nonconsecutive set of defaults. regards, tom lane Indeed. I did not see that earlier. Thank you. -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] usability of pg_get_function_arguments
That would be more work, not less, for the known existing users of the function (namely pg_dump and psql). It's a bit late to be redesigning the function's API anyway. I agree. The recommended way to do that is to use pg_get_expr --- it'd certainly be a bad idea to try to parse that string from client code. I experimented with your example and noticed that pg_get_expr requires a hack --- it insists on having a relation OID argument, because all previous use-cases for it involved expressions that might possibly refer to a particular table. So you have to do something like regression=# select pg_get_expr(proargdefaults,'pg_proc'::regclass) from pg_proc where proname='f13'; pg_get_expr --- 10, 'hello'::character varying, '2009-01-01 00:00:00'::timestamp without time zone, 'comma here ,'::character varying (1 row) Unfortunately, there is no way to know to which argument(s) the values above belongs to. After some searching, it looks like PgAdmin does the trick by hand parsing the string. Fortunately the result of pg_get_expr from above is ordered --- Perhaps by doing some find and replace, I can determine to which argument the returned default value belongs to. Thank you for your help :) -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] usability of pg_get_function_arguments
I am trying to extract function argument information using the pg_get_function_arguments() and it strikes me that despite of this function generating very useful information, it is actually not so user friendly. Consider the following: - create or replace function f13(int=10,varchar='hello',inout complex timestamp='01-01-2009'::timestamp,varchar='comma here ,') as $$ begin end; $$ language plpgsql; where the pg_get_function_arguments generates the following string: - "integer DEFAULT 10, character varying DEFAULT 'hello'::character varying, INOUT complex timestamp without time zone DEFAULT '2009-01-01 00:00:00'::timestamp without time zone, character varying DEFAULT 'comma here ,'::character varying" (good luck parsing that, I thought) - In order to make the data above usable, one has to write a custom parser to hopefully be able to make any use of the return data. Of course another option is to parse the pg_proc.proargdefaults which in turn is a challenge on its own. Perhaps it would be much better if pg_get_function_arguments returned the data is some kind of a structure than a blob of string like the above. BTW: The same goes for pg_get_function_identity_arguments. Any thoughts? -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_class and enum types
Tom Lane wrote: Andrew Dunstan writes: Gevik Babakhani wrote: select * from pg_class where relname='test_type' It's not so much that enum types are handled specially, but that composite types are. :-) Relations (tables) have always had both pg_class and pg_type entries. The pg_class entry denotes the relation proper, the pg_type entry denotes the relation's rowtype. Composite types have the same two entries, there's just a different notion of which one is primary. (The reason a composite type has to have a pg_class entry is that it has pg_attribute entries, and those have to have something in pg_class for their attrelid to link to.) regards, tom lane Thank you :) -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_class and enum types
Andrew Dunstan wrote: Gevik Babakhani wrote: I was wondering why there is no pg_class record for the enum types. Do we treat the enum types differently? Why do you think we should? What would the record look like? cheers andrew I am not implying whether we should or we should not. I was just looking for the logic behind it. Re-reading what I just wrote with your reply gives me hint. Thanx. -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_class and enum types
Robert Haas wrote: On Sun, May 24, 2009 at 4:37 PM, Gevik Babakhani wrote: I was wondering why there is no pg_class record for the enum types. Do we treat the enum types differently? Because types are stored in pg_type, not pg_class? ...Robert That is certainly not true check the following... create type test_type as ( field1 integer, field2 varchar ); select * from pg_class where relname='test_type' -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_class and enum types
I was wondering why there is no pg_class record for the enum types. Do we treat the enum types differently? -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] information_schema.columns changes needed for OLEDB
Josh Berkus wrote: On 5/23/09 7:37 PM, Konstantin Izmailov wrote: Number 4 is actually numeric_precision (I typed incorrectly). My recollection is that numeric_precision sometimes expressed in radix 2 and it caused issues for Windows apps. I agree on other issues. I was curious if database can help OLEDB driver (to make it simpler). Anyway it can emulate values for specific Windows apps on the fly. Thank you! You could, of course, create your own ms_information_schema which had ms_friendly views of the IS. This is what I have done for a past project. I do not think we should part from the standard SQL schema in order to satisfy a certain third party component. If the information_schema does not provide all the information, one could always query the pg_* tables for needed data. -- Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] question about pg_proc
Is there a historical reason why we have a "proargtypes" and a "proallargtypes"? It seems that "proallargtypes" is only set when out parameters exist. Could someone clarify this please? Regards, Gevik. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A humble request
please, please, please David Fetter wrote: On Fri, May 22, 2009 at 10:39:13AM +0200, Gevik Babakhani wrote: Hi, For the ones who couldn't attend to "How to Get Your PostgreSQL Patch Accepted", could someone please make a summary. (Tom? Bruce?) Thank you. Video will get posted pretty soon after, and expect tweets, blog posts, etc. :) Cheers, David. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] A humble request
Hi, For the ones who couldn't attend to "How to Get Your PostgreSQL Patch Accepted", could someone please make a summary. (Tom? Bruce?) Thank you. Regards, Gevik. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] view columns and pg_depend
Hi, I was wondering whether there is a way to see which column in a view depends on which column(s) in a table? If I am not mistaking pg_depend only provides information about which view depends on which tables columns only. (same as view_column_usage) Regards, Gevik. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Multiple parameters with the same name for functions.
No. I meant: create function foo(PAR1 varchar, PAR1 int, PAR1 uuid). Note PAR1 Jaime Casanova wrote: On Sun, Apr 26, 2009 at 3:32 PM, Gevik Babakhani wrote: Hi, As I was working on my code generator app, I noticed that one is able to create a function with multiple parameters with the same name. For example: you mean this http://www.postgresql.org/docs/current/static/xfunc-overload.html? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Multiple parameters with the same name for functions.
Hi, As I was working on my code generator app, I noticed that one is able to create a function with multiple parameters with the same name. For example: create or replace function func_test(id integer,id varchar, id timestamp) returns void as $$ begin raise notice '%',id; end; $$ language plpgsql; Is this a known behavior or a bug? Regards, Gevik. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL network discovery
I asked this question because I have a situation where a service like this would be very useful. If such a functionality would be accepted by the core team, I am willing to work on it. > -Original Message- > From: Alvaro Herrera [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 29, 2008 8:50 PM > To: Gevik Babakhani > Cc: 'PGSQL Hackers' > Subject: Re: [HACKERS] PostgreSQL network discovery > > Gevik Babakhani wrote: > > Hi, > > > > There is a nice little feature within MSSQL where it is possible to > > enumerate all MSSQL servers on the local network. > > I wonder how this can be made possible with PG. Pinging every > > IP:PGPORT within the current subnet is one of the options > but I guess > > that would be just a bad solution. Any thoughts? > > We have rendezvous support too. We need to update it to use > the newer Avahi library, but the one person who proposed > using the thread interface got scolded for that and fled :-) > The interface we'd need to use is complex and the patch would > be a lot bigger. > > If you want to work on it, you're welcome to do so :-) > > -- > Alvaro Herrera > http://www.CommandPrompt.com/ > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL network discovery
If I am not mistaken, it only works fine on OSX environments. (I might be very wrong here) > -Original Message- > From: Magnus Hagander [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 29, 2008 8:47 PM > To: Gevik Babakhani > Cc: 'PGSQL Hackers' > Subject: Re: [HACKERS] PostgreSQL network discovery > > Gevik Babakhani wrote: > > Hi, > > > > There is a nice little feature within MSSQL where it is possible to > > enumerate all MSSQL servers on the local network. > > I wonder how this can be made possible with PG. Pinging every > > IP:PGPORT within the current subnet is one of the options > but I guess > > that would be just a bad solution. Any thoughts? > > Isn't the bonjour support supposed to do this? > (Never used it myself though) > > //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PostgreSQL network discovery
Hi, There is a nice little feature within MSSQL where it is possible to enumerate all MSSQL servers on the local network. I wonder how this can be made possible with PG. Pinging every IP:PGPORT within the current subnet is one of the options but I guess that would be just a bad solution. Any thoughts? Regards, Gevik http://www.truesoftware.net/gevik/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Buildfarm Cardinal going down.
I am going to do some hardware upgrading on buildfarm Cardinal. It will be down for sometime. Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL future ideas
> Advantage of C++ is that it reduce lot of OO code written in > C in PostgreSQL, but it is so big effort to do that without > small gain. It will increase number of bugs. Do not forget > also that C++ compiler is not so common (so good) on > different platforms. If somebody interesting in that yes but > like a fork ( PostgreSQL++ :-). Reducing OO code that is written in C is one of my major interests. After some investigating myself it appears that having the codebase fully (rewritten in C++ will have an impact on the performance. So I guess such an effort will result the code being more C++ish and fully OO, being a mixture in C with some OO taste. > Better idea is to start to use C99 in PostgreSQL ;-). I have not investigated this yet. But I am very interested to know what the advantages would be to "upgrade" the code to C99 standards. Regards, Gevik http://www.truesoftware.net/gevik/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Preserve identifier case
PostgreSQL makes all identifiers to be lower-case except when putting an identifier between double-quotes. I have an special case where I would like to preserve the case-sensitivity without putting every column/table name inside double-quotes (The application is too big to change). Is this function the correct place to bypass the down casing for all identifiers? http://doxygen.postgresql.org/scansup_8c-source.html#l00129 Regards, Gevik http://www.truesoftware.net/gevik/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL future ideas
Thank you all for your opinion. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Andrew Dunstan > Sent: Saturday, September 20, 2008 12:53 AM > To: Gevik Babakhani > Cc: 'Joshua Drake'; 'Jonah H. Harris'; 'Dave Page'; 'PGSQL > Hackers'; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [HACKERS] PostgreSQL future ideas > > > > Gevik Babakhani wrote: > >> I think the better question about all of this is: > >> What is the problem we are trying to solve? > >> Providing solutions that are looking for problems doesn't help us. > >> Sincerely, > >> > > > > Perhaps the current codebase and design in C will serve us > for years > > and years to come. In fact there is no doubt about that and > switching > > to an OO design is no easy task. But times change and technologies > > evolve. So should any software solution that is hoping to > continue and > > compete with other competitors of the same kind. > > > > Procedural programming languages like C may have been languages of > > choice for many years but they gradually loose developer > audience just > > because of the reason above. I am afraid PG is no exception here. > > > > > > That's a two way street. I have far more experience in writing C than > C++. No doubt I could adapt, but it would certainly slow me down for a > while at least. > > Frankly, this looks like a solution in search of a problem. When OS > kernels are all written in C++ I might accept that there is a > good case, > but I see no sign of anything like that happening. > > cheers > > andrew > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL future ideas
> I think the better question about all of this is: > What is the problem we are trying to solve? > Providing solutions that are looking for problems doesn't help us. > Sincerely, Perhaps the current codebase and design in C will serve us for years and years to come. In fact there is no doubt about that and switching to an OO design is no easy task. But times change and technologies evolve. So should any software solution that is hoping to continue and compete with other competitors of the same kind. Procedural programming languages like C may have been languages of choice for many years but they gradually loose developer audience just because of the reason above. I am afraid PG is no exception here. > > Joshua D. Drake > > > -- > The PostgreSQL Company since 1997: > http://www.commandprompt.com/ PostgreSQL Community > Conference: http://www.postgresqlconference.org/ > United States PostgreSQL Association: > http://www.postgresql.us/ Donate to the PostgreSQL Project: > http://www.postgresql.org/about/donate > > > > -- > Sent via pgsql-hackers mailing list > (pgsql-hackers@postgresql.org) To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL future ideas
> Already done! > > http://www.postgresql.org/community/weeklynews/pwn20050401 > Yes, yes COBOL :) PostCobolSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL future ideas
> I don't think so. Firebird rewrote their entire kernel to be > C++ and in doing so, lost a lot of maturity along-the-way I would not make any sense to put/group functions in one or more classes without using the OO patterns. I guess this is what Firebird has done. > Similarly switching to another language would require > a large number of people not only familiar with Postgres > internals, but also in the new programming language; it > wouldn't make sense to switch to something like C++ and not > make full use of the language. True. It would be an enormous task... > I don't see how you think it will help. Most universities > (here in the US at least), are shying away from teaching > C/C++. So, in the long run, I don't see how that would > really help us get more developer involvement. Unless I am very off. C++ is a natural choice when porting (upgrading) ANSI C application. As far as I know, most universities teach some sort of OO programming language like JAVA or C# to help students understand OO programming. I understand that C++ is less popular but JAVA/C# would be the wrong choice for this. Regards, Gevik. > > -- > Jonah H. Harris, Senior DBA > myYearbook.com > > -- > Sent via pgsql-hackers mailing list > (pgsql-hackers@postgresql.org) To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jonah H. Harris > Sent: Friday, September 19, 2008 10:39 PM > To: Gevik Babakhani > Cc: Dave Page; PGSQL Hackers; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [HACKERS] PostgreSQL future ideas > > On Fri, Sep 19, 2008 at 4:32 PM, Gevik Babakhani > <[EMAIL PROTECTED]> wrote: > > It might look like an impossible goal to achieve.. But if > there is any > > serious plan/idea/ammo for this, I believe it would be very > beneficial > > to the continuity of PG. > > I don't think so. Firebird rewrote their entire kernel to be > C++ and in doing so, lost a lot of maturity along-the-way > IMHO. Similarly switching to another language would require > a large number of people not only familiar with Postgres > internals, but also in the new programming language; it > wouldn't make sense to switch to something like C++ and not > make full use of the language. > > I don't see how you think it will help. Most universities > (here in the US at least), are shying away from teaching > C/C++. So, in the long run, I don't see how that would > really help us get more developer involvement. > > -- > Jonah H. Harris, Senior DBA > myYearbook.com > > -- > Sent via pgsql-hackers mailing list > (pgsql-hackers@postgresql.org) To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL future ideas
It might look like an impossible goal to achieve.. But if there is any serious plan/idea/ammo for this, I believe it would be very beneficial to the continuity of PG. Regards, Gevik. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dave Page > Sent: Friday, September 19, 2008 9:58 PM > To: Gevik Babakhani > Cc: PGSQL Hackers > Subject: Re: [HACKERS] PostgreSQL future ideas > > On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani > <[EMAIL PROTECTED]> wrote: > > > > Dear PG hackers, > > > > Has there been any idea to port PG to a more modern programming > > language like C++? Of course there are some minor obstacles > like a new > > OO design, this being a gigantic task to perform and > rewriting almost everything etc... > > I am very interested to hear your opinion. > > The plan is to start porting it to Java after the next > release - probably at the beginning of April. > > :-p > > -- > Dave Page > EnterpriseDB UK: http://www.enterprisedb.com > > -- > Sent via pgsql-hackers mailing list > (pgsql-hackers@postgresql.org) To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PostgreSQL future ideas
Dear PG hackers, Has there been any idea to port PG to a more modern programming language like C++? Of course there are some minor obstacles like a new OO design, this being a gigantic task to perform and rewriting almost everything etc... I am very interested to hear your opinion. (You can take your M16 and start shooting now) Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Buildfarm: cardinal down for maintenance.
The "cardinal" in pgbuildfarm has been taken down for server/hardware maintenance. Regards, Gevik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with site doc search
> No, it's still on the TODO. Gevik has also been looking a bit > at it (I think - at least he's indicated that he is), and he > recently got some new parser code to look at to see if we can > use to fix it. > I have the new parser code. Next week I have some time reserved to look at it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-hackers
Re: [HACKERS] UUID data format 4x-4x-4x-4x-4x-4x-4x-4x
> > I am working on a patch to support this format (yes, it is a simple > > modification). There was a proposal and a discussion regarding how this datatype would be before I started developing it. We decided to go with the format proposed in RFC. Unless there is strong case, I doubt any non standard formatting will be accepted into core. IIRC we where also opposed to support java like formatted uuid's back then. This is no different. Regards, Gevik. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] about date/time parser
> Almost certainly neither workable nor an improvement if you > did make it work. Datetimes don't have enough structure to > make yacc useful, and it's not flexible enough either. Understood. Thank you :) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] about date/time parser
regarding http://archives.postgresql.org/pgsql-hackers/2008-02/msg00826.php I was wondering why we have a custom written parser to parse the date/time from/to string and vice versa? Is there a historical reason? Would a yacc/lex parser be better? Regards, Gevik ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] TO_DATE behavior!
> There are quite a few complaints in the archive about > to_date's incorrect or questionable behavior. I'm sure this > is one of them. This code needs a general, systematic review. I am working on a todo item. I'll report and fix anything I encounter there. Regards, Gevik ---(end of broadcast)--- TIP 1: 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] TO_DATE behavior!
I would like to have your opinion about the following behavior of TO_DATE.
Is this correct or a hidden feature?
case:
'mon 21-feb-2008' is obviously a bad date. It should be 'thu 21-feb-2008'
test:
testdb=# select to_date('mon 21-feb-2008','dy dd-mon-');
to_date
2008-02-21
(1 row)
No complains there!(?)
The opposite query results the correct date.
test:
testdb=# select to_char(to_date('mon 21-feb-2008','dy dd-mon-'),'dy
dd-mon-');
to_char
-
thu 21-feb-2008
(1 row)
Regards,
Gevik
---(end of broadcast)---
TIP 1: 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] Which MemoryContext?
> All local memory is safe to handle that way. In my case I am reallocating memory for a global variable between transactions. I wanted to make sure I don't leave allocated memory behind. > The problem only arises when you have memory to release _earlier_ than that. First I was looking for a way to free my allocated memory before exit. I found the proc_exit hook mechanism but I am not sure where to setup this hook. Given allocating memory in TopMemoryContext is the same as malloc, then I'll just leave my allocated memory to be freed automatically when exit. Thank you :) Regards, Gevik ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Which MemoryContext?
> On backend exit, everything in TopMemoryContext, like all > other non-shared memory, is automatically released. > So it is safe to not free the allocated memory in TopMemoryContext and leave it to be released on backend exit. Thank you for the help :) Regards, Gevik. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Which MemoryContext?
> TopMemoryContext sounds right. Be careful not to leak there. Thank you :) I have allocated memory using: MemoryContextAlloc(TopMemoryContext,n * sizeof(char*)); In pgsql/src/backend/utils/mmgr/README:142 is stated that memory allocated using above should be freed manually, Is this correct? Or does the system release everything allocated in TopMemoryContext automatically when exiting? I looked around and found examples where memory allocated using above is not freed! (datetime.c:3811, uhhh.. a bit confused here) Any thoughts? Regards, Gevik. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Which MemoryContext?
Hi, I want to keep an array of localized strings in memory. This array is dynamically allocated and is going to be used between transactions (that are not necessarily nested). It must be cleaned/freed when postmaster exists. In which context should this array be initialized? TopMemoryContext perhaps? Any thoughts? Regards, Gevik. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Question regarding TODO item:Allow to_date() and to_timestamp() accept localized month names
I have started to develop this item. I would like to see whether I am on the right track. 1. For this item we need an array of localized month/day names. I was thinking of (re)initializing the array item using palloc, repalloc pfree etc.. when SET LC_MESSAGES is called. Would this be correct? 2. In order to "know" when to return the localized values a DCH_S_TM (=0x10, suffix "TM") is provided at dch_date. This is where I want to check the localized array created above. Any thoughts? Regards, Gevik. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Getting available options
> I like option 1 the best. Minimally invasive, and probably > easier to handle on the client than 2. +1 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] NLS on MSVC strikes back!
> What this really means is that locale support is completely > broken in the MSVC build, i.e. you cannot get localized > strings at all (not just to_char()). Is this correct? If > so, this is a serious problem. > The way one could confirm this is by: 1. rename share/locale/de to share/locale/German_Germany 2. start a dosbox 3. before starting PG, set an env variable SET LANGUAGE=German_Germany in that dosbox, which will force all child threads to have that locale. 3. start PG form that dosbox and SET LC_MESSAGES to "es_ES" or "Spanish_Spain" or "es_ES.utf8" or anything else...; select to_char(now(),'TMDay TMMonth '); 4. The result will be in German and not Spanish as one expects. If handling locale in to_char will remain using gettext then I can start working on a patch to fix this. Regards, Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl ---(end of broadcast)--- TIP 1: 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] NLS on MSVC strikes back!
> to_char's month/day name localization is implemented with > gettext() not strftime(), which is why it depends on > LC_MESSAGES not LC_TIME. I seem to recall that we didn't > like the side-effects of the patch you are mentioning, and so > it ended up being rejected outright. Correct. I have been looking for the cause of this problem and these are my finding: 1. The platforms discussed and tested here are MS Windows XP and 2003 using Microsoft VC++ 2005 and NOT MINGW. 2. As Tom described above, to_char is implemented with gettext which depends on LC_MESSAGES. I guess this is okay. 3. Changing LC_MESSAGES is done in pg_locale.c:94:pg_perm_setlocale by setting LC_MESSAGES environment variable. This works for MINGW (tested by installing PG 8.2.6), but it does not work for MSVC++ due different locale handling of gettext. Please see gettext sources:1087:localenames.c 4. Locale names are different in MS Windows. I created a C app to test gettext on Windows. setting LC_MESSAGES to Spanisg_Spain and German_Germany works but es_ES and de_DE do not :( SET LC_MESSAGES to '' has no effect because: A. gettext compiled/linked in MSVC looks for the locale of the current thread and NOT the LC_MESSAGES,LANGIAGE,LANG... environment variables. See gettext's sources B. Given current thread's locale Spanish_Spain, gettext fails to find a directory called "Spanish_Spain" in share/locale. As result English names are returned. A possible solutions: - Keep to_char/LC_MESSAGES handling and create a fix for B. Because we do not want to change/maintain our own version of Gettext this would also involve creating a different directory/name structure for Windows. For example share\locale\de would be share\locale\German_Germany. Any thoughts, Regards, Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] NLS on MSVC strikes back!
> Right, I know that. But I didn't see you trying lc_time as > Andrew suggested. > Did that too, but no luck :( ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] NLS on MSVC strikes back!
> Well, that should be considered a bug, not a feature. > Perhaps it was fixed in 8.3. > This is 8.3 I am testing with. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] NLS on MSVC strikes back!
> Should that not be lc_time you are setting? lc_messages is > for, uh, messages. No. The same thing works on 8.2.6 ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] NLS on MSVC strikes back!
I have compiled 8.3 (CVS HEAD) with NLS on a XP box. But it seems that NLS support is broke. Could someone please confirm this. My test: Gevik=# Gevik=# show lc_messages ; lc_messages English_United States.1252 (1 row) Gevik=# Gevik=# set lc_messages TO 'de_DE.utf8'; SET Gevik=# show lc_messages ; lc_messages - de_DE.utf8 (1 row) Gevik=# select to_char(now(), 'TMDay, DD TMMonth '); to_char --- Tuesday, 12 February 2008 (1 row) Gevik=# Gevik=# set lc_messages TO 'es_ES.utf8'; SET Gevik=# show lc_messages ; lc_messages ----- es_ES.utf8 (1 row) Gevik=# select to_char(now(), 'TMDay, DD TMMonth '); to_char --- Tuesday, 12 February 2008 (1 row) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] TODO item:Allow to_date() and to_timestamp() accept localized month names
> I can't remember anyone asking for more sophisticated > solutions so it seems implementing #1 at this point is the > best approach. > OK. Then I'll start working on the first approach. Regards, Gevik. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] TODO item:Allow to_date() and to_timestamp() accept localized month names
>
> Surely it should be the inverse of the solution for output,
> eg TMMon selects localized input.
>
After some investigation in how gettext works, I would like to have your
opinion about how to
implement this TODO item.
Starting with TO_CHAR:
When the TM prefix is used in TO_CHAR (for example TMMonth),
the routine, internally calls functions like the localize_month and
localize_day to get the localized value.
These functions rely on the current locale category that is internally
loaded by GetText "engine".
The GetText engine does not load any other locate category unless SET
LC_MESSAGES or alike is given.
Now back to TO_DATE:
For this there are three solution that I can think of.
1. For TO_DATE to return localized data we can implement the TM prefix logic
which is already
implemented in TO_CHAR. Copying and modifying it for TO_DATE should be
feasible.
The downside of this solution is that TO_DATE will only return localized
values base on current locale. (no third parameter)
2. For TO_DATE to behave like Mr. Oracle's version of to_date (
to_date('01-OCT-99''DD-MON-YY,'nls_date_language = nl_NL'); ) We might (must
be tested to see if it is even possible) be able to have a smaller copy of
gettext engine that only contains day and month names and have TO_DATE use
it to return values based on the given locale. This solution is much harder
to implement of course.
3. Have TO_DATE to switch the locale back and forth by internally executing
SET LC_* to the given locale.
Please note that loading another locale category forced by SET LC_* is
costly. (look at GetText source).
Any thoughts?
Regards,
Gevik Babakhani
PostgreSQL NL http://www.postgresql.nl
TrueSoftware BV http://www.truesoftware.nl
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Peter Eisentraut
> Sent: Tuesday, February 05, 2008 9:04 AM
> To: pgsql-hackers@postgresql.org
> Cc: Alvaro Herrera; Tom Lane; Gevik Babakhani
> Subject: Re: [HACKERS] TODO item:Allow to_date() and
> to_timestamp() accept localized month names
>
> Alvaro Herrera wrote:
> > Nevertheless, I think there's something interesting missing here,
> > which is a sort of strftime's %c format string.
>
> I think the Oracle way to do that would be to_char() with one
> argument and setting NLS_DATE_FORMAT.
>
> --
> Peter Eisentraut
> http://developer.postgresql.org/~petere/
>
> ---(end of
> broadcast)---
> TIP 6: explain analyze is your friend
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PostgreSQL 8.4 development plan
The plan looks great. I am +1 > -Original Message- > From: [EMAIL PROTECTED] > > ---(end of > broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org > ---(end of broadcast)--- TIP 1: 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] Where is share\locale dir on Win?
Is it my imagination or the share\locale directory for nls support just does not get installed on Windows. (Even with NLS option chosen). It does for 8.2 Regards, Gevik. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Possible BUG in MSVC Install.pm in GenerateNLSFiles
> The traces from buildfarm baiji seem to indicate that at > least some NLS files are installed. > Those three dots are printed as default. (looking at Install.pm:456) Regards, Gevik. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Possible BUG in MSVC Install.pm in GenerateNLSFiles
Hi, Is it only on my system or the Install.pm:GenerateNLSFiles just does not copy any NLS files. It seems that in Install.pm:468:next.po$/); does not let anything through. Can someone please confirm? Regards, Gevik. ---(end of broadcast)--- TIP 1: 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] path with spaces in config.pl
> Or we should fix it, if we can figure out why. Is it the fact > that it only works with what happens to be the directory > layout I use, or is it the space in the filename that's > breaking something? Can you test a third case to figure that out? > I think it is the darn msbuild which accepts spaces in "include" but not in "lib" Attached is a quick patch that fixed the link error on my machine. Regards, Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl patch-0.2-combined.patch Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] path with spaces in config.pl
Hi, I would like report an observations regarding compilation with msvc++ I was trying to compile with nls=>'C:\Program Files\GnuWin32\' (of course with GetText installed and everything) The build process breaks on link with missing "Program.obj" error. When I changed nls='C:\prog\pgsql\depend\gettext' everything compiled just fine. Perhaps we should document this. Regards, Gevik. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO item:Allow to_date() and to_timestamp() accept localized month names
(I really should stop reading the code after 12:00AM) So if I understand correctly, the proper solution would be to handle the localized (TM) format within to_date (seq_search). This means that prior calling to_date a SET LC_MESSAGES must be given. but if we are following Oracle, (http://www.techonthenet.com/oracle/functions/to_date.php) a third parameter to enforce the nls_language is required. Please advice. Regards, Gevik. > -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 05, 2008 2:29 AM > To: Gevik Babakhani > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] TODO item:Allow to_date() and > to_timestamp() accept localized month names > > "Gevik Babakhani" <[EMAIL PROTECTED]> writes: > >> Surely it should be the inverse of the solution for > output, eg TMMon > >> selects localized input. > > > Of cource. But how would TM enforce a localized formatting. > (perhaps I > > am off 2:10 am...) Lets say I have en_US database but > the dates I > > am trying to format is nl_NL. > > If I am not mistaking SET LC_MESSAGES won't help. > > Works for me: > > postgres=# show lc_messages ; > lc_messages > - > de_DE.utf8 > (1 row) > > postgres=# select to_char(now(), 'TMDay, DD TMMonth '); > to_char > - > Montag, 04 Februar 2008 > (1 row) > > postgres=# set lc_messages TO 'es_ES.utf8'; SET postgres=# > select to_char(now(), 'TMDay, DD TMMonth '); > to_char > > Lunes, 04 Febrero 2008 > (1 row) > > > regards, tom lane > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TODO item:Allow to_date() and to_timestamp() accept localized month names
> Surely it should be the inverse of the solution for output, > eg TMMon selects localized input. Of cource. But how would TM enforce a localized formatting. (perhaps I am off 2:10 am...) Lets say I have en_US database but the dates I am trying to format is nl_NL. If I am not mistaking SET LC_MESSAGES won't help. Regards, Gevik ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] TODO item:Allow to_date() and to_timestamp() accept localized month names
Hi,
I would like to start a discussion for a solution regarding this item.
At this moment these functions only accept English month/day names due
formatting.c:172:months_full[] and datetime.c:53-58 months[], days[].
The values are predetermined. (hardcoded sounds bahhh...)
What do we think about a solution that would be like:
1. Add an extra (optional) parameter to to_date and to_timestamp which would
indicate the locale we are trying to parse.
For example to_date('10 okt 2008','DD Mon ','nl-NL')
2. If the third parameter exists, read the month/day names for a list of
some kind.
3. Pass the list to formatting.c:1615:seq_search to parse the string with
these localized names list.
My questions:
Is step 1 acceptable/correct to start with? If yes, what would you recommend
for step 2?
Regards,
Gevik Babakhani
PostgreSQL NL http://www.postgresql.nl
TrueSoftware BV http://www.truesoftware.nl
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] How to use VB6 for store image to postgresql?
I guess the fastest way is to: - create a column of type text. ex. create table foo( myimage text ); - read the contents of your image from file and encode it in base64 using: http://www.vbforums.com/attachment.php?s=42957f48bac95dd18ca8bffcf7578dcc <http://www.vbforums.com/attachment.php?s=42957f48bac95dd18ca8bffcf7578dcc&a ttachmentid=49287&d=1152543402> &attachmentid=49287&d=1152543402 - save the base64 encoded string in the database I hope this helps. Regards, Gevik. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Premsun Choltanwanich Sent: Tuesday, January 29, 2008 10:28 AM To: pgsql-hackers@postgresql.org Subject: [HACKERS] How to use VB6 for store image to postgresql? Dear All, Have you ever store image to postgresql using VB6? Could you give me an example? Thank you, Premsun NETsolutions Asia Limited +66 (2) 237 7247 <http://www.nsasia.co.th> NETsolutions Asia Limited <>
Re: [HACKERS] system catalog constraints question
Thank you :) > -Original Message- > From: Heikki Linnakangas [mailto:[EMAIL PROTECTED] > Sent: Monday, January 28, 2008 5:35 PM > To: Gevik Babakhani > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] system catalog constraints question > > Gevik Babakhani wrote: > > Is there a way to query the column constraints between the > tables of > > system catalog. > > For example pg_attribute.atttypid>pg_type.oid. This is > described > > in the docs of course , but does the system use something like > > pg_constaint or the system catalog constraints are enforced > only in the code? > > There is pg_depend, which is kind of like constraints, but > enforced in code. > > -- >Heikki Linnakangas >EnterpriseDB http://www.enterprisedb.com > ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] system catalog constraints question
Hi, Is there a way to query the column constraints between the tables of system catalog. For example pg_attribute.atttypid>pg_type.oid. This is described in the docs of course , but does the system use something like pg_constaint or the system catalog constraints are enforced only in the code? Regards, Gevik. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] MSVC Build error
> Do you have the dumpbin command available in the path?
>
> //Magnus
>
:) yes. This is why I do not understand why the command does not run
correctly!
=
I:\pgdev>dumpbin
Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
usage: DUMPBIN [options] [files]
options:
/ALL
/ARCHIVEMEMBERS
/CLRHEADER
/DEPENDENTS
/DIRECTIVES
/DISASM[:{BYTES|NOBYTES}]
/ERRORREPORT:{NONE|PROMPT|QUEUE|SEND}
/EXPORTS
/FPO
/HEADERS
/IMPORTS[:filename]
/LINENUMBERS
/LINKERMEMBER[:{1|2}]
/LOADCONFIG
/OUT:filename
/PDATA
/PDBPATH[:VERBOSE]
/RANGE:vaMin[,vaMax]
/RAWDATA[:{NONE|1|2|4|8}[,#]]
/RELOCATIONS
/SECTION:name
/SUMMARY
/SYMBOLS
/TLS
/UNWINDINFO
I:\pgdev>
Regards,
Gevik Babakhani
PostgreSQL NL http://www.postgresql.nl
TrueSoftware BV http://www.truesoftware.nl
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[HACKERS] MSVC Build error
Hi, I get the following error when: build.bat DEBUG somehow dumpbin is not called. analyze.c Compiling resources... Generate DEF file Generating POSTGRES.DEF from directory Debug\postgres ...Could not call dumpbin at src\tools\msvc\gendef.pl line 22. Project : error PRJ0019: A tool returned an error code from "Generate DEF file" Build log was saved at "file://i:\pgdev\pgsql\Debug\postgres\BuildLog.htm" postgres - 1 error(s), 0 warning(s) The command exited with code 1. Done executing task "VCBuild" -- FAILED. Done building target "postgres" in project "pgsql.sln" -- FAILED. Target "ValidateSolutionConfiguration" skipped. Previously built successfully. Target "postgres" skipped. Previously built unsuccessfully. Target "ValidateSolutionConfiguration" skipped. Previously built successfully. Target misc\libpgport: Task "VCBuild" Regards, Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL Programmer's Guide Books
thank you :)
> -Original Message-
> From: Robert Treat [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 26, 2008 4:29 PM
> To: pgsql-hackers@postgresql.org
> Cc: Gevik Babakhani
> Subject: Re: [HACKERS] PostgreSQL Programmer's Guide Books
>
> On Friday 25 January 2008 19:02, Gevik Babakhani wrote:
> > Hi,
> >
> > I was wondering how accurate there books are (perhaps not
> so much) ,
> > if one wants to learn more about the internals?
> > http://www.postgresql.org/docs/7.3/static/programmer.html
> > http://www.cs.helsinki.fi/u/laine/postgresql/programmer/
> >
> >
>
> These are basically old versions of the documentation, so
> thier relevance, and what you can get out of them, probably
> is strictly dependent on how much the code has changed in any
> given area. Note there are some style differences that could
> make areas of the old docs more helpful (depending on thier
> accuracy), but that's more a style thing:
>
> http://www.cs.helsinki.fi/u/laine/postgresql/programmer/arch-p
g.htm#PGARCH-CONNECTIONS
> http://www.postgresql.org/docs/7.3/static/arch-pg.html#PGARCH-
> CONNECTIONS
> http://www.postgresql.org/docs/8.3/static/connect-estab.html
>
> --
> Robert Treat
> Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
>
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[HACKERS] PostgreSQL Programmer's Guide Books
Hi, I was wondering how accurate there books are (perhaps not so much) , if one wants to learn more about the internals? http://www.postgresql.org/docs/7.3/static/programmer.html http://www.cs.helsinki.fi/u/laine/postgresql/programmer/ Regards, Gevik ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] .NET or Mono functions in PG
> I did look at this at some earlier point as well. One big > problem at that time was that once you embedded mono, you had > all sorts of threads running in your backend ;-) yes, threads running around could become a show stopper for both Mono and MS.NET This is something I want to be sure of before I begin. > Another way to do it is "the PL/J" way (I think). Which is > starting up a separate process with the VM in it and then do > RPC of some kind to it. > Which has more overhead per call, but lower per backend etc. > And a lot less "dangerous". This is actually my plan B, hence it is less dangerous. I am thinking the "started process" can stay alive and act as a service of some kind to handle/answer calls form multiple backends and shutdown itself after a period of time being idle. Regards, Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] .NET or Mono functions in PG
It would we great. Thank you. Regards, Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jonah H. Harris > Sent: Friday, November 30, 2007 4:10 PM > To: Gevik Babakhani > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] .NET or Mono functions in PG > > On Nov 30, 2007 9:20 AM, Jonah H. Harris > <[EMAIL PROTECTED]> wrote: > > Yeah, I have a copy of the old PL/.NET backed up somewhere. > IIRC, it > > needs to be rewritten, but it would be possible to make it work for > > both Mono and .NET. > > Actually, it was PL/Mono. I'll dig through my stuff and post > it somewhere for you. > > -- > Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 > EnterpriseDB Corporation| fax: 732.331.1301 > 499 Thornall Street, 2nd Floor | > [EMAIL PROTECTED] > Edison, NJ 08837| http://www.enterprisedb.com/ > > ---(end of > broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq > ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] .NET or Mono functions in PG
I am investigating the possibility of having stored procedures and functions written in .NET language flavors. I remember a long time ago there was a gborg project wanting to implement it, but that is long gone I guess. anyway I think there are two possibilities: a) Use of MS.NET core and implement it only for Windows. b) Use of Mono core and have the possibility to run it also on *nix systems. c) Or perhaps a hybrid of the above would be possible. Any implementation would require to invoke/call an external runtime (Mono or MS.CRL). I wonder what the performance would be. I would like to have your opinion about this idea. Regards, Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] quotas once again
After reading the thread of 2004 regarding user quotas, I understand why the discussion moved towards having a tablespace quota as a solution. My reason to start this discussion was due the need of controlling database size. Having tablespace quotas could allow one to create a database in a given tablespace and then limit the size of the tablespace. Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jonah H. Harris > Sent: Thursday, November 29, 2007 3:55 AM > To: Alvaro Herrera > Cc: Gevik Babakhani; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] quotas once again > > On Nov 28, 2007 8:09 PM, Alvaro Herrera > <[EMAIL PROTECTED]> wrote: > > Did you publish it in pgsql-patches? If so, it can be fished from > > there. > > Unfortunately, no. IIRC, I believe the topic moved to being > non-user-based quotas and more tablespace-oriented. > > -- > Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 > EnterpriseDB Corporation| fax: 732.331.1301 > 499 Thornall Street, 2nd Floor | > [EMAIL PROTECTED] > Edison, NJ 08837| http://www.enterprisedb.com/ > > ---(end of > broadcast)--- > TIP 2: Don't 'kill -9' the postmaster > ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] quotas once again
> Uh, he was asking about "quotas", not "quotes". No, we don't > have user quotas yet. > Thank you. I read we have a "Allow per-tablespace quotas". But the more I think about this the more complex it gets. I guess implementing a user quota is a very different story than quotas per-tablespace. ---- Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl > > > > > > Regards > > Pavel Stehule > > > > On 28/11/2007, Gevik Babakhani <[EMAIL PROTECTED]> wrote: > > > Sometime ago there was a discussion about user/database quota and > > > IIRC there was also some patch for this (probably got rejected). > > > > > > Does anyone know to which direction we went for having quotas? > > > > > > Regards, > > > Gevik > > > > > > Gevik Babakhani > > > > > > PostgreSQL NL http://www.postgresql.nl > > > TrueSoftware BV http://www.truesoftware.nl > > > > > > > > > > > > ---(end of > > > broadcast)--- > > > TIP 1: 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 > > > > > > > ---(end of > > broadcast)--- > > TIP 3: Have you checked our extensive FAQ? > > > >http://www.postgresql.org/docs/faq > > -- > Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us > EnterpriseDB > http://postgres.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] quotas once again
Sometime ago there was a discussion about user/database quota and IIRC there was also some patch for this (probably got rejected). Does anyone know to which direction we went for having quotas? Regards, Gevik Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl ---(end of broadcast)--- TIP 1: 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] PG 7.3 is five years old today
> At some point back, I seem to recall the reason for bothering > to backpatch to 7.3 is that it had to be maintained for > RedHat anyway, so things might as well be backpatched? If > that requirements is gone, I think it's time to drop it. +1 > And +1 on pushing out one final "end of the tree" release > since there's stuff there. > +1 ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Need for advice and direction (again)
Hello Tom, I would like to know your opinion about the way we should refer to composite type params in functions. For example: CREATE TABLE emp ( nametext, salary numeric, age integer, cubicle point ); CREATE FUNCTION double_salary(emp) RETURNS numeric AS $$ SELECT $1.salary * 2 AS salary; $$ LANGUAGE SQL; How should we refer to emp in the following example. CREATE FUNCTION double_salary(PARAM1 emp) RETURNS numeric AS $$ -- At this moment PARAM1.salary will fail because PARAM1 -- is compared to the name of this function SELECT PARAM1.salary * 2 AS salary; -- Would this be correct? SELECT double_salary.PARAM1.salary * 2 AS salary; $$ LANGUAGE SQL; Regards, Gevik. Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Throw error and ErrorContext question.
Hello Tom, I have a solution by adding two parameters (skip_error and skipped_sqlerrorcode) to qualifiedNameToVar,transformWholeRowRef,addImplicitRTE,warnAutoRange. It still needs a bit of refining before I can send the patch for full review. When in context of parsing functions for refname.colname: If refname is unknown, skip_error=true makes sure the error is skipped. I use skipped_sqlerrorcode to record what went wrong in qualifiedNameToVar and transformWholeRowRef. The effect is that de default behavior, including implicit RTE is kept. For example, when parsing the function below: 1. qualifiedNameToVar skips the error for the unknown refx and sets skipped_sqlerrorcode. 2. transformWholeRowRef also skips the error for the unknown refx and sets skipped_sqlerrorcode. 3. at this point the callabck also returns with error, because refx is not the function's name (myfunc) So I think an error like "missing FROM-clause entry for table "refx" would be appropriate here In normal circumstance qualifiedNameToVar would have reported the same. create function myfunc(par1 integer) $$ select refx.par1 from tbl1 a where a.field1 = 1; $$ language sql; I am working on all possible test scenarios I can think of to be sure the implementations is working correctly. Regards, Gevik. ---- Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl > -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 08, 2007 2:32 AM > To: Gevik Babakhani > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Throw error and ErrorContext question. > > "Gevik Babakhani" <[EMAIL PROTECTED]> writes: > > I have considered a noError boolean too. > > > but please considered the following: > > > step 1: call qualifiedNameToVar(noError = true), which generates an > > error but gets suppressed by noError parameter. > > > step 2: process function parameter name for funct1.param1, check > > "funct1" == , which "funct1" is > > unknown/ambiguous (the name of the current function was "func" for > > example). > > > In the case above I thought I somehow re-throw the error that was > > originally generated at step 1. > > Yeah, you'd throw the same error number and message as that > routine would have thrown, but matching that is not rocket > science ;-). > I don't see any value in trying to have only one instance of the > ereport() call instead of two --- it's going to cost you > *more* lines of code and *more* intellectual complexity to > try to trap and re-throw the error than it will cost to just > have two identical > ereport() calls. > > Although quite frankly I don't see any need to be touching > qualifiedNameToVar at all. It's already defined to return > NULL if it doesn't find the name anyplace in the query, which > seems to me to be what you want anyway. The only > non-internal error it might raise is "ambiguous name" which > is fine. That's an error condition, and the possibility that > there is a function variable visible at an outer name scoping > level doesn't make it not an error. > > The place where you need to be refactoring is probably in or > around the transformWholeRowRef/ParseFuncOrColumn sequence. > > One thing that we need to think about is what is the priority > of function-variable matching compared to implicit RTE > creation. I'm inclined to think we should allow function > variables to go first... > > regards, tom lane > ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Feature Request: inline comments
> Feature freeze was six months ago, and no this wouldn't be a > "small add" even if it was the best idea since sliced bread. +1 ---(end of broadcast)--- TIP 1: 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] Throw error and ErrorContext question.
Thank you Tom. I have considered a noError boolean too. but please considered the following: step 1: call qualifiedNameToVar(noError = true), which generates an error but gets suppressed by noError parameter. step 2: process function parameter name for funct1.param1, check "funct1" == , which "funct1" is unknown/ambiguous (the name of the current function was "func" for example). In the case above I thought I somehow re-throw the error that was originally generated at step 1. Regards, Gevik. ---- Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Thursday, November 08, 2007 12:25 AM > To: Gevik Babakhani > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Throw error and ErrorContext question. > > "Gevik Babakhani" <[EMAIL PROTECTED]> writes: > > I am trying to catch and copy an error to be re-thrown later. > > This is certainly not the right way to go about solving your problem. > If you need to refactor some of the column lookup routines to > make this patch work, then do so, but don't try to make an > already-thrown error not be an error. (One good reason for > that is that you don't really know what error you are > catching --- it might be a report of some low-level problem > such as out-of-memory, for instance.) > > The pattern you might want to follow is adding a noError > boolean parameter to functions you want to be able to get > failure returns back from. > > regards, tom lane > > ---(end of > broadcast)--- > TIP 6: explain analyze is your friend > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Throw error and ErrorContext question.
Hi,
Regarding the function parameter ref TODO:
I am trying to catch and copy an error to be re-thrown later.
I have the following questions:
1. Is the catch part in the following safe?
2. How do I re-throw the copied error when I am not in ErrorContext anymore?
I cannot use ReThrowError because of Assert.
3. If I have to use something like: ereport(ERROR,mysaved_error->message ...
mysaved_error->detail .. );
then how do I FreeErrorData(mysaved_error) after calling the ereport
above?
First:
MemoryContext parseMemCtx = CurrentMemoryContext;
Then:
/* Try to identify as a once-qualified column */
PG_TRY();
{
node = qualifiedNameToVar(pstate, NULL, name1, name2, true,
cref->location);
/* status set to 0 or 1 */
qualified_status = (node != NULL);
}
PG_CATCH();
{
/* copy this error for later use */
errorMemCtx = CurrentMemoryContext;
MemoryContextSwitchTo(parseMemCtx);
qualifiedErrData = CopyErrorData();
FlushErrorState();
MemoryContextSwitchTo(errorMemCtx);
/* status is set to error */
qualified_status = 2;
}
PG_END_TRY();
----
Gevik Babakhani
PostgreSQL NL http://www.postgresql.nl
TrueSoftware BV http://www.truesoftware.nl
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
[HACKERS] Opinion / advice needed for TODO: function params ref by name
Hello, This is about: http://archives.postgresql.org/pgsql-patches/2007-11/msg00028.php In order to resolve . the check in transformColumnRef goes into case 2 which is A.B The ideal way to resolve the func.param in this case is to perform the callback (hook) after ALL the checks (like qualifiedNameToVar) are performed. Unfortunately for func.param is this problematic because qualifiedNameToVar and transformWholeRowRef/ParseFuncOrColumn internally call RTE functions which justifiably throw an "ambiguous column error". I would like your opinion about the following implementations: Only when parsing functions and only in case of A.B: a) Check for func.param before qualifiedNameToVar and transformWholeRowRef/ParseFuncOrColumn result: func.param resolves correctly, but: in case of a function name/parameter name being the same as a table name / column name, the func.param will be resolved first. for example: create table func( id int, fld1 varchar ); create function func( id int, fld1 varchar ) ... as $$ select func.id from func where func.id = func.id; $$ language sql; above will produce the unexpected result hence . will be resolved first. b) step 1. call qualifiedNameToVar with implicitRTEOK = FALSE; step 2. if no results then perform callback; step 3. Next if no results then qualifiedNameToVar with implicitRTEOK = TRUE (default); step 4. if no result then continue as ParseFuncOrColumn result: func.param resolves correctly but: the order will be qualifiedNameToVar , CallBack , ParseFuncOrColumn. I have tested both options (a) and (b) Current regression test + new tests pass on Win and RH. Any thoughts? Regards, Gevik. ---- Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Slow regression tests on windows
I am trying to run regression tests on both windows and RH. It looks like that the tests on windows run slower than linux using two machines with same hardware config. Is this known? Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Continue [PATCHES] V0.1 patch for TODO Item: SQL-language reference parameters by name.
Hello, > You seem not to have understood my recommendation to use a > callback function. This patch might work nicely for SQL > functions but there will be no good way to use it for > plpgsql, or probably any other PL function language. If > we're going to change the parser API then I'd like to have a > more general solution. > Perhaps I did not look well enough, but is there any callback mechanism like the error_context_stack etc... in the parser? ( If not, I guess one has to be created :) ) Thank you. Gevik. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Proposal TODO Item: SQL-language reference parameters by name
Thank you Tom. After running a create function statement (language sql), the final check for a column is done in parse_expr.c:transformColumnRef in case 1. Would this be the correct place to implement functionality for a final match? Regards, Gevik. - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Gevik Babakhani" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, October 31, 2007 4:36 AM Subject: Re: [HACKERS] Proposal TODO Item: SQL-language reference parameters by name "Gevik Babakhani" <[EMAIL PROTECTED]> writes: I think the most likely implementation would involve adding hooks in the parser at places where "unknown column" errors are about to be thrown, so that a function language could check for a match to one of its variable names only after the query-exposed names are checked. Would this be the right path to follow? Assuming we are allowed to include parameter names into ParseState, we can match the "non existing" colnames against the list of parameter names when transformColumnRef (or someware safe in that path). You are assuming that the function language isn't interested in taking some extra action when a reference to a parameter is recognized. This is demonstrably false for plpgsql, for one --- it wants to build a list of just which variables it will have to pass into each SQL command. A hook function can take care of that, a passive data structure can't. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Proposal TODO Item: SQL-language reference parameters by name
Thank you Tom. I think the most likely implementation would involve adding hooks in the parser at places where "unknown column" errors are about to be thrown, so that a function language could check for a match to one of its variable names only after the query-exposed names are checked. Would this be the right path to follow? Assuming we are allowed to include parameter names into ParseState, we can match the "non existing" colnames against the list of parameter names when transformColumnRef (or someware safe in that path). I Think this way we at least can parse a function when CreateFunction is called. If the above is correct to implement then the check should have low precedence in order to not break the current functionality (first colnames, then $n params and then parameter names) Regards, Gevik. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Proposal TODO Item: SQL-language reference parameters by name
Hi all, I am working a lot with custom procedures/functions which are implemented in "language sql". At the moment function parameter refs cannot work with parameter names. I would like to try to implement this. The actual TODO item is: Allow SQL-language functions to reference parameters by parameter name Currently SQL-language functions can only refer to dollar parameters, e.g. $1 After a quick look at how ref parameters in plpgsql and sql function are handled, I would like to start a discussion about the following implementation plan. Implementation of the name parameter parsing in scan.l/gram.y can be achieved by adopting the same mechanism as plpgsql does. If I am not mistaking plpgsql parser creates a stack to store parameter identifiers. Correct me if this would be wrong or not possible, but I am thinking of mapping the name references to the parameter numbers (par2 => $2) this way I hope to keep the implementation small and perhaps extend "struct ParamRef" to hold a possible parameter name. Then there is the issue of error reporting for ambiguous parameter names (non existing parameter names and names which conflict with actual column names). I guess this can be handeled in "fmgr_sql_validator" Please let me know your opinion. Regards, Gevik.
[HACKERS] buildfarm fail "cardinal"
Hi, I would like to know why the test stats on "pgbuildfarm/cardinal" fails? Regards, Gevik xml ... ok test stats... FAILED test tablespace ... ok ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] VC2005 build and pthreads
pthreads in needed to buold PG in vc++ 2005 please read pgsql/src/tools/msvc/README Have a nice day. On Fri, 2007-01-26 at 21:47 +0100, Martijn van Oosterhout wrote: > On Fri, Jan 26, 2007 at 09:34:10PM +0100, Gevik Babakhani wrote: > > Folks, > > > > I would like to build pg on VC2005. How do I use pthreads that is > > mentioned in the README file. Do I need the DLL? Sources? LIB? > > Where do I install or copy them.. > > Err, pthreads is a threads library for Unix, I don't think Windows has > that, nor can I think of a situation where you'd need to worry about > threads anyway? > > Have a nice day. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] VC2005 build and pthreads
Folks, I would like to build pg on VC2005. How do I use pthreads that is mentioned in the README file. Do I need the DLL? Sources? LIB? Where do I install or copy them.. Regards, Gevik ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] unused_oids?
Folks, At this moment the following is the list of the unused OIDs. For the uuid datatype I use a script for generating catalog entries. I can close some gaps there if the "masters" are okay with this. Are any OIDs reserved for later or any range can be used in this case? 2 - 9 32 86 - 88 90 100 193 - 199 276 321 - 328 376 432 - 433 820 - 828 1004 1972 - 1973 1980 1998 2003 - 2004 2039 2096 2230 2746 2758 - 2780 2858 - 2859 2922 - Regards, Gevik ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Protocol specs
Folks, Does anyone know where I can find information about the PG communication protocol specifications between backend and frontend? Regards, Gevik. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] MVCC question
Folks, How long are we supporting MVCC? It is from the beginning or is it added later to PG -- Regards, Gevik Babakhani www.postgresql.nl www.truesoftware.nl ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Extending tablespaces
Okay, thank you. On Thu, 2006-10-19 at 15:56 -0400, Tom Lane wrote: > Gevik Babakhani <[EMAIL PROTECTED]> writes: > > Now I am thinking what it would take to give pg the functionality to > > extend tablespaces automatically. > > It's called LVM ... and no, we are not interested in reimplementing > filesystem-level functionality ... > > regards, tom lane > > ---(end of broadcast)--- > TIP 1: 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 > ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Extending tablespaces
Recently I ran into a "disk full" problem with my database. I had to play with the tablespaces and locations symlinks... until the disk could be cleaned just enough for the database to continue operation. I had plenty of space on another disk but found no *easy* way to humbly ask postgres to continue using other empty disk. I read the partitioning at http://www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html but this unfortunately is not an option. Now I am thinking what it would take to give pg the functionality to extend tablespaces automatically. Something like "ALTER TABLESPACE foo ADD LOCATION '/bar'" and then PG can continue operation without notifying the disk is full... I yet have to dive more deeply into the storage system to gain more knowledge. I also realize that implementing something like this will effect many things like VACUUM, pg_dump, indexing, sorting and the entire storage system etc..etc.. I very much would like to know the communities opinion and thoughts about this. Would this even be possible? Or I am just dreaming (again) and scaring everyone else. -- Regards, Gevik Babakhani www.postgresql.nl www.truesoftware.nl ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Row IS NULL question
> I wrote: > > Moving makeRowNullTest() doesn't seem like a big deal, but changing > > ExecEvalNullTest would take some added code. Do we want to tackle that > > during beta, or hold off till 8.3? An argument for doing it now is that > > we just added nulls-in-arrays in 8.2, and it'd be good if the semantics > > of that were right the first time rather than changing later. > > Now that I look more closely, makeRowNullTest() is actually WRONG even > for the cases it handles. SQL99/SQL2003 define thus: > > 1) Let R be the value of the . > > 2) If every value in R is the null value, then "R IS NULL" is true; > otherwise, it is false. > > 3) If no value in R is the null value, then "R IS NOT NULL" is > true; otherwise, it is false. > > makeRowNullTest() is set up to return TRUE for an IS NOT NULL test if > *any* element of R is non null: > > regression=# explain select * from int8_tbl x where row(x.q1,x.q2) is not > null; > > QUERY PLAN > --- > Seq Scan on int8_tbl x (cost=0.00..1.05 rows=5 width=16) >Filter: ((q1 IS NOT NULL) OR (q2 IS NOT NULL)) > (2 rows) > > So this is clearly a bug and clearly one of long standing --- we've been > getting this wrong since PG 7.3 :-( > > regards, tom lane > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings > Would it be correct to do the null test in ExecEvalNullTest (I would like to learn what happens but somehow I just cannot get the debugger on makeRowNullTest in gram.c) On Thu, 2006-09-28 at 14:38 -0400, Tom Lane wrote: -- Regards, Gevik Babakhani http://www.postgresql.nl http://www.truesoftware.nl ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Row IS NULL question
Thank you for the explanation. On Thu, 2006-09-28 at 12:06 -0400, Tom Lane wrote: > Gevik Babakhani <[EMAIL PROTECTED]> writes: > > Does this have anything to do with ExecEvalWholeRowVar? > > Yeah, the construct > > >> Seq Scan on int8_tbl x (cost=0.00..1.05 rows=1 width=16) > >> Filter: (x.* IS NULL) > > is really ExecEvalNullTest applied to the result of ExecEvalWholeRowVar. > > If we simply push makeRowNullTest() to later in the parser, this case > will work as expected, but there is still the issue of IS [NOT] NULL > applied to rowtype values that are not coming from ROW() constructs, > such as the result of a rowtype-returning function. Likewise, null > tests on arrays really would have to be handled in the executor to > work per spec --- we can hardly break them down into scalar isnull > tests at parse time, which is what makeRowNullTest() is trying to do. > > regards, tom lane > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster > -- Regards, Gevik Babakhani http://www.postgresql.nl http://www.truesoftware.nl ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Row IS NULL question
Please excuse me for jumping in like this... but just for my understanding... Does this have anything to do with ExecEvalWholeRowVar? On Thu, 2006-09-28 at 11:45 -0400, Tom Lane wrote: > Teodor Sigaev <[EMAIL PROTECTED]> writes: > > % echo 'SELECT count(*) FROM tst WHERE ROW(tst.*) IS NULL;' | psql wow > > SET > > count > > --- > > 0 > > (1 row) > > Hm, it turns out that this works: > select * from int8_tbl x where row(x.q1,x.q2) is null; > but not this: > select * from int8_tbl x where row(x.*) is null; > > EXPLAIN tells the tale: > > regression=# explain select * from int8_tbl x where row(x.q1,x.q2) is null; > QUERY PLAN > --- > Seq Scan on int8_tbl x (cost=0.00..1.05 rows=1 width=16) >Filter: ((q1 IS NULL) AND (q2 IS NULL)) > (2 rows) > > regression=# explain select * from int8_tbl x where row(x.*) is null; > QUERY PLAN > --- > Seq Scan on int8_tbl x (cost=0.00..1.05 rows=1 width=16) >Filter: (x.* IS NULL) > (2 rows) > > Apparently what's happening is that gram.y's makeRowNullTest() bursts > the RowExpr apart into individual isnull tests. Now that RowExpr > expansion can change the number of items in the row, it's clearly > premature to do that processing in gram.y --- we should move it to > parse analysis. > > Part of the issue is that ExecEvalNullTest simply tests for whether the > presented Datum is null, which I think is impossible for a whole-row Var > coming from a table (but it could happen for a row-returning function's > result, for example). I think that according to the letter of the spec, > an IS [NOT] NULL test should "drill down" into rowtype datums and check > nullness of the individual row fields. Probably the same is true for > array datums. > > Moving makeRowNullTest() doesn't seem like a big deal, but changing > ExecEvalNullTest would take some added code. Do we want to tackle that > during beta, or hold off till 8.3? An argument for doing it now is that > we just added nulls-in-arrays in 8.2, and it'd be good if the semantics > of that were right the first time rather than changing later. > > regards, tom lane > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend > -- Regards, Gevik Babakhani http://www.postgresql.nl http://www.truesoftware.nl ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
