[HACKERS] clang and LLVM

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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.

[Gevik Babakhani]

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.

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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.

[Gevik Babakhani]

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

[Gevik Babakhani]

> 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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

> 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

[Gevik Babakhani]

> 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

[Gevik Babakhani]

> 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

[Gevik Babakhani]

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

[Gevik Babakhani]

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.

[Gevik Babakhani]

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

[Gevik Babakhani]

> 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

[Gevik Babakhani]

> > 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

[Gevik Babakhani]

> 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

[Gevik Babakhani]

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!

[Gevik Babakhani]

> 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!

[Gevik Babakhani]

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?

[Gevik Babakhani]

> 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?

[Gevik Babakhani]

> 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?

[Gevik Babakhani]

> 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?

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

> 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!

[Gevik Babakhani]

> 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!

[Gevik Babakhani]

> 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!

[Gevik Babakhani]

> 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!

[Gevik Babakhani]

> 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!

[Gevik Babakhani]

> 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!

[Gevik Babakhani]

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

[Gevik Babakhani]

> 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

[Gevik Babakhani]

> 
> 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

[Gevik Babakhani]

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?

[Gevik Babakhani]

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

[Gevik Babakhani]

 > 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

[Gevik Babakhani]

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

[Gevik Babakhani]

> 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

[Gevik Babakhani]

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

[Gevik Babakhani]

(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

[Gevik Babakhani]

> 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

[Gevik Babakhani]

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?

[Gevik Babakhani]

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
 &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 

  NETsolutions Asia Limited 

<>

Re: [HACKERS] system catalog constraints question

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

> 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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

> 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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

> 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

[Gevik Babakhani]

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

[Gevik Babakhani]

> 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)

[Gevik Babakhani]

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.

[Gevik Babakhani]

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

[Gevik Babakhani]

> 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.

[Gevik Babakhani]

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.

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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.

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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"

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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?

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

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

[Gevik Babakhani]

> 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

[Gevik Babakhani]

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

[Gevik Babakhani]

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