[PATCHES] Patch for %Allow per-database permissions to be set via GRANT

2006-04-26 Thread Gevik Babakhani
This patch implements the TODO Item: %Allow per-database permissions to be set via GRANT Implementation details: 1. A privilege ACL_CONNECT has been added to the ACL bits 2. The ACL_CONNECT can be recognized by character c in pg_database/dataacl 3. The patch implements: GRANT CONNECTION ON

Re: [PATCHES] Patch for %Allow per-database permissions to be set

2006-04-30 Thread Gevik Babakhani
On Sun, 2006-04-30 at 15:29 -0400, Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Documentation added, patch attached and applied. Thanks. I just got around to reading this patch. Why is the syntax GRANT CONNECTION and not GRANT CONNECT? Privilege names are generally verbs

[PATCHES] Patch for UUID datatype (beta)

2006-09-17 Thread Gevik Babakhani
Folks, The following patch implements the UUID datatype. I would like to send this beta patch to see if I still am on the right track. Please send your comments. Description of UUID: - The type is called uuid. - btree and hash indexes are supported. - uuid array is supported. - uuid text i/o is

Re: [PATCHES] Patch for UUID datatype (beta)

2006-09-18 Thread Gevik Babakhani
On Mon, 2006-09-18 at 09:21 +0200, Andreas Pflug wrote: Gevik Babakhani wrote: - new_guid() function is supported. This function is based on V4 random uuid value. It generated 16 random bytes with uuid 'variant' and 'version'. It is not guaranteed to produce unique values Isn't

Re: [PATCHES] Patch for UUID datatype (beta)

2006-09-18 Thread Gevik Babakhani
Completely agreed. I can remove the function from the patch. The temptation was just too high not to include the new_guid() in the patch :) On Mon, 2006-09-18 at 10:33 -0400, Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: Isn't guaranteed uniqueness the very attribute that's

Re: [PATCHES] Patch for UUID datatype (beta)

2006-09-18 Thread Gevik Babakhani
If you have trouble with duplicate OIDs Please use patch-0.2 for testing. I have changed the OIDs to 5000 range. You can download it from: http://www.truesoftware.net/pgsql/uuid/patch-0.2/ On Mon, 2006-09-18 at 01:00 +0200, Gevik Babakhani wrote: Folks, The following patch implements

[PATCHES] new patch for uuid datatype

2006-09-19 Thread Gevik Babakhani
Folks, I would like to submit an updated patch for the uuid datatype. I have removed the new_guid() function assuming we want a generator function in the contrib. I also have included a regression test and added the default copyright header for the new files. If this patch gets accepted then I

[pgsql-patches] guid/uuid datatype

2007-01-19 Thread Gevik Babakhani
Hi, While ago (sep-2006) I sent a patch for the UUID datatype, Did anyone have time to review it yet? Here it is again :) Regards, Gevik *** ./backend/utils/adt/Makefile.orig 2006-09-19 12:05:41.0 +0200 --- ./backend/utils/adt/Makefile 2006-09-19 12:06:47.0 +0200

Re: [pgsql-patches] guid/uuid datatype

2007-01-19 Thread Gevik Babakhani
I confess I haven't followed the discussion around this patch, but is there a compelling reason to include this in the backend proper, rather than contrib/? AFAIK, It is/was part of the TODO for the core. ---(end of broadcast)--- TIP 5: don't

Re: [pgsql-patches] guid/uuid datatype

2007-01-20 Thread Gevik Babakhani
I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? This is also a point I remember from the last discussions. To not to include the generator in the core. The generation of the uuid is then going to be on the client side. The uuid type is

Re: [pgsql-patches] guid/uuid datatype

2007-01-20 Thread Gevik Babakhani
But does it really help if you don't have the generator? I don't use UUIDs much myself, but I think in all cases I've seen that use the uuid type in SQL Server they're also using the generator function. Those that just store UUIDs in the database often just uses varchar - in order to be

Re: [pgsql-patches] guid/uuid datatype

2007-01-20 Thread Gevik Babakhani
what is the next step now? is there going to be review by a committer? if so, please note that the OIDs in the patch have to be changed. Regards, Gevik ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate

Re: [pgsql-patches] guid/uuid datatype

2007-01-20 Thread Gevik Babakhani
I already suggested a few things you could improve in the patch. If this discussion concludes that the patch should be included in the core backend and you submit a revised patch, I'd be happy to review and apply it. So.. do we agree for uuid to be included in the core? If so.. I will change

Re: [pgsql-patches] guid/uuid datatype

2007-01-25 Thread Gevik Babakhani
I thought the consensus was to provide the only atatype initially and look into providing the generator functions later or via an external project (pgfoundry or contrib/). This was my understanding too... to include the uuid in the core and let the actual value be generated

[pgsql-patches] uuid patch 2.0 (8.3devel)

2007-01-25 Thread Gevik Babakhani
provide comments. Regards, Gevik ### # Patch created by PostgreSQL Patch Generator 1.0 # Written by Gevik Babakhani 2007 (BSD) # # Apply this patch: # cd ./mydir.../pgsql/ # patch -p0 this.patch.file.diff # # Date

[pgsql-patches] uuid patch 3.0 (8.3devel)

2007-01-26 Thread Gevik Babakhani
for readability. Done. Any more comments? Regards, Gevik. ### # Patch created by PostgreSQL Patch Generator 1.0 # Written by Gevik Babakhani 2007 (BSD) # # Apply this patch: # cd ./mydir.../pgsql/ # patch -p0

Re: [pgsql-patches] uuid patch 3.0 (8.3devel)

2007-01-28 Thread Gevik Babakhani
uuid.c header is missing $PostgreSQL$ line, so is uuid.h, copyright notice in the latter seems wrong too. I left this part because it is not clear to me what to put there. Is the following OK? * IDENTIFICATION * $PostgreSQL$ *

Re: [PATCHES] V0.1 patch for TODO Item: SQL-language reference parameters by name.

2007-11-02 Thread Gevik Babakhani
Noted. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Dunstan Sent: Friday, November 02, 2007 4:19 PM To: Gevik Babakhani Cc: pgsql-patches@postgresql.org Subject: Re: [PATCHES] V0.1 patch for TODO Item: SQL-language reference

[PATCHES] V0.1 patch for TODO Item: SQL-language reference parameters by name.

2007-11-02 Thread Gevik Babakhani
Hello all, Hereby an alpha version regarding the: TODO Item: SQL-language reference parameters by name. I am sending this patch to check if I am on the right track. So please take a look at this if possible. What does this patch do? As discussed in thread:

Re: [PATCHES] V0.1 patch for TODO Item: SQL-language reference parameters by name.

2007-11-02 Thread Gevik Babakhani
Hi, what about name's collision? Maybe is better use some prefix, like $ or :. Without it we only propagate one problem from plpgsql to others languages. Please explain. Perhaps I am wrong, but plpgsql handles arsgument names before it passes the query to be executed. Please see:

[PATCHES] V0.2 patch for TODO Item: SQL-language reference parameters by name.

2007-11-03 Thread Gevik Babakhani
Hello All, This patch implements a (generic) callback functionality in the parser. The mechanism can be used to send callback messages from within the parser to external functions. I would like to know your opinion about the following: In previous discussion Tom referred to: One point here is

Re: [PATCHES] V0.2 patch for TODO Item: SQL-language referenceparameters by name.

2007-11-03 Thread Gevik Babakhani
I think a prefix of ':' would be good, as it's already a standard, kinda. Anybody who names a database object :foo deserves whatever happens to them :P I for one like something less cryptic than ':' besids going with ':' means extra hack in gram.y (Ones we get to implement packages I

Re: [PATCHES] V0.2 patch for TODO Item: SQL-language referenceparameters by name.

2007-11-03 Thread Gevik Babakhani
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 Gregory Stark Sent: Saturday, November 03, 2007

Re: [PATCHES] V0.2 patch for TODO Item: SQL-language referenceparameters by name.

2007-11-03 Thread Gevik Babakhani
Gevik Babakhani [EMAIL PROTECTED] writes: So where do we go from here? a. function name.arg name b. this.arg name c. ':'argname d. just argname We must support both a and d. Then a and d it is :) Regards, Gevik Gevik Babakhani

[PATCHES] proposed patch for function parameters name refs

2007-11-27 Thread Gevik Babakhani
is implemented in transformColumnRef/ case 1 and case 2 - patch is created using VC++ 2005, tested on Win32 and RH4 Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl

[PATCHES] V1.1 patch for TODO Item: SQL-language reference parameters by name.

2007-11-28 Thread Gevik Babakhani
Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl patch-1.1-combined.patch Description: Binary data ---(end of broadcast

Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable

2008-01-27 Thread Gevik Babakhani
release cycle, I thought I'd better post it for comment anyway. +1 I liked the synchronized_sequential_scans idea myself. But otherwise, sure. this will save some hackwork I have to do for a import/export project I am doing. +1, please Regards, Gevik Babakhani

[PATCHES] Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)

2008-02-14 Thread Gevik Babakhani
for all supported locales. - Create docs for supported locale names on Windows. (Values of the static table) Regards, Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl

Re: [PATCHES] Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)

2008-02-14 Thread Gevik Babakhani
Haven't looked into the details of the patch yet, will do so. But the first thing I notice - you say this is only for MSVC, right? But the patch will also change the behaviour for the mingw build. Since you say you haven't tested on it, does the documentation imply that it would work on

Re: [PATCHES] Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)

2008-02-14 Thread Gevik Babakhani
Thank you. Is there any reason why JP locale files are not in normal installation? -Original Message- From: Hiroshi Saito [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 8:00 PM To: Magnus Hagander; Gevik Babakhani Cc: pgsql-patches@postgresql.org Subject: Re: [PATCHES

Re: [PATCHES] Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)

2008-02-14 Thread Gevik Babakhani
We have a directive called WIN32_ONLY_COMPILER that's used for this. It'll pick up MSVC and Borland C++ which normally behave at least almost the same. I am installing mingw to test the patch there. Chances are it will break because mingw does __declspec(dllimport) differently than

Re: [PATCHES] Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVCstrikes back!)

2008-02-14 Thread Gevik Babakhani
Hmm, interestingly you lost the diacritics here. The output is mangled for Saturday and Wednesday, which should read Sábado and Miércoles respectively. It is not good that the system allows you to output invalidly encoded data. What happens if you try setting lc_messages to

[PATCHES] Fix for MSVC compile error (--htmldir)

2008-02-19 Thread Gevik Babakhani
At this moment 8.3 does not compile with MSVC due missing HTMLDIR preprocessor directive which was added for --htmldir Please see buildfarm. PS: There are also other warnings but those I consider to be separate issues. (I am working on a fix) Regards, Gevik Babakhani

[PATCHES] Fix for compiler warnings on MSVC

2008-02-19 Thread Gevik Babakhani
this is a fix for the compiler warnings on MSVC due differences in declaration and implementation of _yconv in strfime.c. I have testing this patch on: - MSVC 8 - gcc version 3.4.6 20060404 (Red Hat 3.4.6-3) Regards, Gevik. 2.strftime.c.patch Description: Binary data

Re: [PATCHES] Fix for compiler warnings on MSVC

2008-02-19 Thread Gevik Babakhani
Argh for delays in the mailinglist delivery and my reading :-) I've just applied one identical and one very similar patch to yours for these two issues. But thanks anyway :-) Thank you :) ---(end of broadcast)--- TIP 6: explain analyze

Re: [PATCHES] lc_time and localized dates

2008-02-26 Thread Gevik Babakhani
Attached is a patch that replaces the lc_messages with lc_time when using to_char in translation mode (TM) [1]. It doesn't change the output behaviour. Per discussion [2], it's using some cache mechanism so we don't need to call setlocale() all the time. Have you tested this patch on

Re: [PATCHES] lc_time and localized dates

2008-02-26 Thread Gevik Babakhani
Magnus, Please look at this patch before you check my last patch about the locale. It seems that Euler's solution also fixes the windows locale bug that I was trying to fix. Replacing the lc_messages with lc_time when using to_char seems to be the correct direction. I have compiled and tested

Re: [PATCHES] lc_time and localized dates

2008-02-26 Thread Gevik Babakhani
No. [Looking at the code...] I think it only affects the LC_MESSAGES 'cause setlocale(LC_MESSAGES) don't work on Windows. In order to make setlocale(LC_MESSAGES) affect on windows some additional steps must be taken. I don't go deep in that now. I have a fix with description etc. etc. Is it

Re: [PATCHES] lc_time and localized dates

2008-02-26 Thread Gevik Babakhani
This is what you get when you copy a proprietary, poorly specified interface. The to_char functions are supposed to be Oracle-compatible, so we need to check what Oracle does. Whether that is useful in practice is a bit secondary. I'm beginning to think, if you want formatting

Re: [PATCHES] lc_time and localized dates

2008-02-26 Thread Gevik Babakhani
But as Peter remarks nearby, this discussion is wasted anyway, because there is only one correct answer: whatever Oracle does with these cases is what to_char() should do. ++1 ---(end of broadcast)--- TIP 7: You can help support the

Re: [PATCHES] V1.1 patch for TODO Item: SQL-language reference parameters by name.

2008-03-27 Thread Gevik Babakhani
Thank you for your comments. I will start working on a new version and send a patch for review when ready. Regards, Gevik. -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2008 9:49 PM To: Gevik Babakhani Cc: pgsql-patches@postgresql.org