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
> 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 Postgre
> 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
> 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
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 Eul
> 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
> 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 anal
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
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
> 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
> 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) differen
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.or
> 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
ish names :)
(My fault, hee hee, I haven't completed nl.po translations yet.)
TODO:
- Provide/complete the day and month names for all supported locales.
- Create docs for supported locale names on Windows. (Values of the static
table)
Regards,
Gevik Babakhani
--
a pretty trivial patch, but seeing how late we are
> in the 8.3
> >> 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
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
regression
- the main logic 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
> "Gevik Babakhani" <[EMAIL PROTECTED]> writes:
> > So where do we go from here?
> > a. .
> > b. .
> > c. ':'
> > d. just
>
> We must support both a and d.
Then a and d it is :)
Regards,
Gevik
-
and ':' as parameter but not a target_list item.
option a and b would make the source more readable
but extra documentation has to be provided to describe
how to refer arguments by name.
Regards,
Gevik
----
Gevik Babakhani
PostgreSQL NL http
> 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
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
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:
p
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
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:
http://archives.postgres
> 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$
*
*-
> Also remove the whitespace at the end of lines.
Done. AFAICS
>
> Make some reasonable effort to align the catalog entries for
> readability.
>
Done.
Any more comments?
Regards,
Gevik.
#######
# Patch created by Postgre
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
#
# D
> 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 elsewhere...(cl
> 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 cha
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
>
> 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
> 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 i
> 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
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
***
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 ca
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 imple
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 exp
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 guaran
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
On Sun, 2006-04-30 at 15:29 -0400, Tom Lane wrote:
> Bruce Momjian 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 not nouns.
> Unle
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
41 matches
Mail list logo
