Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Karel Zak
On Tue, Aug 22, 2006 at 01:11:22PM -0400, Andrew Dunstan wrote:
 There's nothing hidden (unless it's also hidden from me ;-) )
 
 I take it that when you talk about we did this you are referring to 
 the patch from Karel Zak.

 Hans has been original author of COPY VIEW idea and I've wrote it for
 his customer (yes, it was sponsored work).

Karel

-- 
 Karel Zak  [EMAIL PROTECTED]

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Leaving... (was: Re: [HACKERS] [PATCHES] COPY view)

2006-08-23 Thread Karel Zak

 Hi all,

 seriously... I don't have time to work on PostgreSQL. It's time to
 say that I'm leaving this project. So, if you found some my broken
 code or whatever in PostgreSQL you should go and fix it. It's
 community-driven project. It's about collaboration -- don't ask why
 should I help -- go and help!

 It was nice time and really big experience, but in the world is more
 projects and many of them need more help than already stable (do you
 remember PostgreSQL 6.5? :-) and very reliable PostgreSQL.

 Good bye!
Karel

On Tue, Aug 22, 2006 at 11:12:21PM -0400, Tom Lane wrote:
 The patch submitter has neither provided an updated patch nor defended
 his original submission as being the right thing.  If he doesn't take it
 seriously enough to have done any followup, why should the rest of us?

-- 
 Karel Zak  [EMAIL PROTECTED]

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [PATCHES] [HACKERS] to_char and i18n

2005-12-26 Thread Karel Zak
On Sun, 2005-12-25 at 17:56 -0300, Euler Taveira de Oliveira wrote:
 --- Euler Taveira de Oliveira [EMAIL PROTECTED] escreveu:
 
  I have a patch like this. But this was for 7.4.x. I have to take a
  look
  at it.
 
 The patch is attached. It implements day and month i18n. I fixed a few
 misspelling comments. Docs is attached too.
 
 template1=# select to_char(now(), 'Day, DD Month ');
to_char
 --
  Sunday   , 25 December  2005
 (1 registro)
 
 template1=# select to_char(now(), 'TMDay, DD TMMonth ');
   to_char  
 ---
  Domingo, 25 Dezembro 2005
 (1 registro)
 
 template1=# 
 
 
 Comments?

I think it looks like a good patch. There's small problem that the
current to_char() output is possible use as argument for to_timestamp()
or to_date() function. It means you should implement vice-versa
conversion from string with TMMonth/TMDay to timestamp.

   to_timestamp('Domingo, 25 Dezembro 2005', 'TMDay, DD TMMonth ')

Or.. at least describe in the docs that this way is unsupported
for 'TM' prefix.

Karel

-- 
Karel Zak [EMAIL PROTECTED]


---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


[PATCHES] COPY view

2005-09-29 Thread Karel Zak

 Hi,

attached is a patch that implements COPY view TO feature.

Karel

Example:

test=# CREATE VIEW vvv AS SELECT a.id, a.data AS d1, b.data AS d2 FROM
tab a, tab2 b WHERE a.id=b.fk;
CREATE VIEW
test=# COPY vvv TO '/tmp/test';
COPY
test=# \! cat /tmp/test
1   aaa AAA
2   bbb BBB
3   ccc CCC
4   ddd DDD


-- 
Karel Zak [EMAIL PROTECTED]


pgsql-copyview-29092005.patch.gz
Description: GNU Zip compressed data

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [PATCHES] Implementing SELECT FOR UPDATE [NOWAIT]

2005-07-01 Thread Karel Zak

 This is new version of SELECT FOR UPDATE NOWAIT patch.

Karel



On Sat, 2005-06-25 at 08:40 +0200, Hans-Juergen Schoenig wrote:
 yes, i think we can do it in time.
 
 regards,
 
hans
 
 
 
 Bruce Momjian wrote:
 
 Are you working on a updated version of this?
 
 ---
 
 Bruce Momjian wrote:
   
 
 Uh, seems the code has drifted too much and now I can't apply this. 
 Would you redo this against current CVS?  Thanks.
 
 ---
 
 Hans-Juergen Schoenig wrote:
 
 
 Folks,
 
 We have implemented SELECT FOR UPDATE NOWAIT for PostgreSQL.

-- 
Karel Zak [EMAIL PROTECTED]


pgsql-nowait-07012005.patch.gz
Description: GNU Zip compressed data

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] Implementing SELECT FOR UPDATE [NOWAIT]

2005-06-27 Thread Karel Zak
 
   --- 302,308 
 T_CompositeTypeStmt,
 T_InhRelation,
 T_FunctionParameter,
   + T_ForUpdate,
 
 /*
  * TAGS FOR FUNCTION-CALL CONTEXT AND RESULTINFO NODES (see 
   fmgr.h)
   diff -r -c postgresql-8.0.0rc2.orig/src/include/nodes/parsenodes.h 
   postgresql-8.0.0rc2/src/include/nodes/parsenodes.h
   *** postgresql-8.0.0rc2.orig/src/include/nodes/parsenodes.h   Fri Nov 
5 20:16:38 2004
   --- postgresql-8.0.0rc2/src/include/nodes/parsenodes.hMon Dec 27 
   10:56:52 2004
   ***
   *** 103,108 
   --- 103,110 
 
 List   *sortClause; /* a list of SortClause's */
 
   + bool   nowait;  /* are we in NOWAIT mode? */
   + 
 Node   *limitOffset;/* # of result tuples to skip */
 Node   *limitCount; /* # of result tuples to return 
   */
 
   ***
   *** 422,427 
   --- 424,439 
 Node   *arg;/* a (Value *) or a 
   (TypeName *) */
 } DefElem;
 
   + /*
   +  * ForUpdate -
   +  *   used in raw parsetrees output only
   +  */
   + typedef struct ForUpdate
   + {
   + NodeTag type;
   + List*update_list;   /* list of tables */
   + boolnowait; /* NOWAIT option */
   + } ForUpdate;
 
 
   /
  *  Nodes for a Query tree
   ***
   *** 686,692 
 List   *sortClause; /* sort clause (a list of 
   SortBy's) */
 Node   *limitOffset;/* # of result tuples to skip */
 Node   *limitCount; /* # of result tuples to return 
   */
   ! List   *forUpdate;  /* FOR UPDATE clause */
 
 /*
  * These fields are used only in upper-level SelectStmts.
   --- 698,704 
 List   *sortClause; /* sort clause (a list of 
   SortBy's) */
 Node   *limitOffset;/* # of result tuples to skip */
 Node   *limitCount; /* # of result tuples to return 
   */
   ! Node   *forupdateClause;/* FOR UPDATE clause (ForUpdate 
   node) */
 
 /*
  * These fields are used only in upper-level SelectStmts.
   diff -r -c postgresql-8.0.0rc2.orig/src/include/storage/lmgr.h 
   postgresql-8.0.0rc2/src/include/storage/lmgr.h
   *** postgresql-8.0.0rc2.orig/src/include/storage/lmgr.h   Thu Sep 16 
   18:58:42 2004
   --- postgresql-8.0.0rc2/src/include/storage/lmgr.hMon Dec 27 
   10:56:52 2004
   ***
   *** 60,64 
   --- 60,65 
 extern void XactLockTableInsert(TransactionId xid);
 extern void XactLockTableDelete(TransactionId xid);
 extern void XactLockTableWait(TransactionId xid);
   + extern bool ConditionalXactLockTableWait(TransactionId xid);
 
 #endif   /* LMGR_H */
  
  -- 
Bruce Momjian|  http://candle.pha.pa.us
pgman@candle.pha.pa.us   |  (610) 359-1001
+  If your life is a hard drive, |  13 Roberts Road
+  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
  
  ---(end of broadcast)---
  TIP 4: Don't 'kill -9' the postmaster
  
 
 -- 
   Bruce Momjian|  http://candle.pha.pa.us
   pgman@candle.pha.pa.us   |  (610) 359-1001
   +  If your life is a hard drive, |  13 Roberts Road
   +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
 
 ---(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
-- 
Karel Zak [EMAIL PROTECTED]


---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] limiting connections per user/database

2005-06-27 Thread Karel Zak
On Sun, 2005-06-26 at 20:52 +0200, Petr Jelínek wrote:
 Alvaro Herrera wrote:
 
 I don't think this approach is very user-friendly.  I'd vote for the
 catalog approach, I think.
   
 
 Ok I am fine with both but catalog changes would mean more hacking of 
 ALTER DATABASE and ALTER USER.

IMHO Oracle has better solution for per-user setting:

CREATE PROFILE name
   SESSIONS_PER_USER int
   CONNECT_TIME int 
   IDLE_TIME int;

ALTER USER name PROFILE name;


karel

-- 
Karel Zak [EMAIL PROTECTED]


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] AllocSetReset improvement

2005-05-16 Thread Karel Zak
On Thu, 2005-05-12 at 11:26 -0400, Tom Lane wrote:

 I have another idea though: in the case you are looking at, I think
 that the context in question never gets any allocations at all, which
 means its blocks list stays null.  We could move the MemSet inside the
 if (blocks) test --- if there are no blocks allocated to the context,
 it surely hasn't got any chunks either, so the MemSet is unnecessary.

 Good point. There's same MemSet in AllocSetDelete() too.

Karel

-- 
Karel Zak [EMAIL PROTECTED]


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [PATCHES] [BUGS] CC Date format code defaults to current centry

2005-03-17 Thread Karel Zak
On Sun, 2005-03-13 at 21:24 -0500, Bruce Momjian wrote:
 Joe Brown wrote:
  joe= select to_date('19450323','CCYYMMDD');
to_date  
  
   2045-03-23
  (1 row)
  
  joe= select to_date('19450323','MMDD');
to_date  
  
   1945-03-23
  (1 row)
  
  I thought the former would be more correct.  But it seems I am mistaken.
 
 Uh, 1945 _is_ in the 20th century, but I can see how it is confusing.

It ignored CC value if there was YY (, ..). And YY=45 is 2045:

 /*
  * 2-digit year
  */
 if (tmfc-year  70)
   tmfc-year += 2000;
 else
   tmfc-year += 1900;


 I think it's very special case when you define YY and CC and code
should detects it and counts year as (CC-1)*100+YY. The right answers:

CC+YY

test=# select to_date('20450112', 'CCYYDDMM');
  to_date

 1945-12-01

CC+Y

test=# select to_date('2090112', 'CCYDDMM');
  to_date

 1909-12-01


For YYY/ it ignore CC option.

The patch (with docs changes) is in the attachment.

Karel


-- 
Karel Zak [EMAIL PROTECTED]


formatting-17032005.patch.gz
Description: GNU Zip compressed data

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [PATCHES] Implementing RESET CONNECTION ...

2005-01-04 Thread Karel Zak
On Mon, 2005-01-03 at 20:27 -0500, Tom Lane wrote:

 I'm inclined to think that we'd have to add a protocol message that
 reports RESET CONNECTION to really answer objections of this type.
 That seems to bring the thing into the category of stuff that forces
 a protocol version bump :-(
 
 Perhaps RESET CONNECTION should be a protocol-level operation instead
 of a SQL command?  That would prevent user-level code from causing it
 without the driver knowing.

I still don't see a big difference between DEALLOCATE and RESET -- both
can break the JDBC driver. I'm not sure if we need prevent bad usage of
PG tools (JDBC in this case). The DEALLOCATE/RESET usage is under user's
full control and everything can be described in docs.

I think each PG command returns some status. For example in libpq it's
possible check by PQcmdStatus(). I think JDBC can checks this status (by
own PQcmdStatus() implementation) and if PG returns string CONNECTION-
RESETED it can deallocate internal stuff. This solution doesn't require
touch the protocol.

Karel

-- 
Karel Zak [EMAIL PROTECTED]


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] Implementing RESET CONNECTION ...

2005-01-04 Thread Karel Zak
On Wed, 2005-01-05 at 01:33 +1300, Oliver Jowett wrote:
 Karel Zak wrote:
  I think each PG command returns some status. For example in libpq it's
  possible check by PQcmdStatus(). I think JDBC can checks this status (by
  own PQcmdStatus() implementation) and if PG returns string CONNECTION-
  RESETED it can deallocate internal stuff. This solution doesn't require
  touch the protocol.
 
 That could work. It's a bit ugly, though, as currently drivers don't 
 need to parse command status strings (unless they want an insert OID)

I think command status is common and nice feedback for client. I think
it's more simple change something in JDBC than change protocol that is
shared between more tools.

We need some common way how detect on client what's happen on server --
a way that doesn't mean change protocol always when we add some
feature/command to backend. The command status is possible use for this.

Karel

-- 
Karel Zak [EMAIL PROTECTED]


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


[PATCHES] pg_dumplo schema support

2004-11-25 Thread Karel Zak

Hi,

it looks users still use pg_dumplo from contrib tree:

On Thu, 2004-11-18 at 17:45 +0100, Düster Horst wrote:
 Hallo Karel

 I tried to use your pg_dumplo but it seems, that the version 
 contributed with pg-7.4.5 does not support schemas.

here is a patch with:

* support absolute paths in dump index 
* support for schemas
* queries to catalog uses pg_catalog. prefix
* default directory is $PWD or .
* check index file format
* schema support is backward compatible (default schema is public)

Maybe it's too late for 8.0, but I think nobody test it during beta
releases. I tested it now with this patch and it works for me. If you
think that 8.1 will better, please apply it to 8.1.

Thanks,
Karel

-- 
Karel Zak [EMAIL PROTECTED]


pg_dumplo-schema-11232004.patch.gz
Description: GNU Zip compressed data

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


[PATCHES] sign parsing (was: Re: [HACKERS] to_char/to_number loses sign)

2004-10-27 Thread Karel Zak
On Tue, 2004-10-26 at 13:27 -0400, Tom Lane wrote:
 Karel Zak [EMAIL PROTECTED] writes:
  Yes, you're right. It strange, but NUM_S missing there. The conversion
  from string to number is less stable part of formatting.c...
 
  The patch is in the attachment.
 
 This patch causes the regression tests to fail.  I think you need to
 consider the to_char() side of it more carefully.

Sorry of this in beta version... 

The problem was bigger than I expected. I hope it's fixed in actual
patch. All regression tests pass.

The patch changes two lines in regression test too. It's because old
version of to_number() allows to use wrong number input and this input
was in regression test. The call to_char(-0.01, ' 9 9 . 9 9 S'); never
produced ' . 0 1 -' but always ' . 0 1-' only.

-SELECT '' AS to_number_13, to_number(' . 0 1 -', ' 9 9 . 9 9 S');
+SELECT '' AS to_number_13, to_number(' . 0 1-', ' 9 9 . 9 9 S');
^^^
 'S' = locale sign and it must be always anchored to last or first
number.

Again sorry,
  Karel

-- 
Karel Zak
http://home.zf.jcu.cz/~zakkr


pgsql-formatting-10272004.patch.gz
Description: GNU Zip compressed data

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [PATCHES] 8.0-NLS: czech

2004-10-27 Thread Karel Zak
On Wed, 2004-10-27 at 13:24 +0200, Peter Eisentraut wrote:

 Please make available the individual PO files, not a patch.  The patch 
 you supplied does not apply cleanly.

 OK. Please don't forget add cs to src/bin/pg_config/nls.mk

  http://people.redhat.com/kzak/pg-nls-cs-10272004.tar.gz

Karel

-- 
Karel Zak
http://home.zf.jcu.cz/~zakkr


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


[PATCHES] 8.0-NLS: czech

2004-10-21 Thread Karel Zak

 Hi,

on URL:
http://people.redhat.com/kzak/pg-nls-cs-21102004.patch.gz

is new Czech translation of PostgreSQL messages. It's too big for e-mail
attachment and mailing list limit.

 Thanks,
Karel

-- 
Karel Zak
http://home.zf.jcu.cz/~zakkr


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [PATCHES] Again!! locale per column for postgreSQL

2004-09-15 Thread Karel Zak
On Wed, 2004-09-15 at 07:01 -0700, Mahmoud Taghizadeh wrote:
 Qustion: is this approach is suitable for solving the need for locale
 per column in PostgreSQL ?
 
 There is a function I attached to this mail. this function is similar
 to nls_sort.  this function is written by Karel Zak, I dont know if he
 had tried to submit this code or not.

I think good place for this function is in the PG's contrib tree. The
final solution for main tree have to be something different. I agree
with you that this function can be useful for multi-language databases.

Lates version is available at:
http://www.fi.muni.cz/~adelton/l10n/postgresql-nls-string/

Karel

-- 
Karel Zak
http://home.zf.jcu.cz/~zakkr/


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


[PATCHES] NLS: czech

2004-08-30 Thread Karel Zak
Hi,

attached is patch with Czech .po files updates (some files are new).

Tested with actual CVS:

patch -p1nls-cs-08292004.patch  

patching file src/bin/initdb/nls.mk
patching file src/bin/initdb/po/cs.po
patching file src/bin/pg_controldata/po/cs.po
patching file src/bin/pg_ctl/nls.mk
patching file src/bin/pg_ctl/po/cs.po
patching file src/bin/pg_resetxlog/po/cs.po
patching file src/interfaces/libpq/po/cs.po

.. so nothing dangerous.

Karel

PS. thanks to Michal Taborsky [EMAIL PROTECTED] who translated all in
this patch.

-- 
Karel Zak  [EMAIL PROTECTED]
http://home.zf.jcu.cz/~zakkr/


nls-cs-08292004.patch.gz
Description: GNU Zip compressed data

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [PATCHES] Updated COPY CSV patch

2004-04-14 Thread Karel Zak
On Tue, Apr 13, 2004 at 10:43:35AM -0400, Tom Lane wrote:
 Andrew Dunstan [EMAIL PROTECTED] writes:
  Thinking about this some more  maybe the right rule would be quote 
  all non-numeric non-null values.
 
 And how would you define numeric?

 And don't  forget that  number format depend  on locale. Now  we ignore
 LC_NUMERIC, but  maybe at  some time  in future  we will  support it. I
 think the best solution is quote all values including numerics too.

 123,456  (in Czech this is one number with decimal point ;-)

Karel

-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] [HACKERS] Dates BC.

2004-03-29 Thread Karel Zak
On Mon, Mar 29, 2004 at 03:37:07PM -0500, Bruce Momjian wrote:
 Karel Zak wrote:
  On Fri, Dec 19, 2003 at 01:12:08AM -0800, Dann Corbit wrote:
   There is no zero calendar year.  The first year of Anno Domini is 1.  It's 
   ordinal, not cardinal.
  
   I agree. But  the follow quoted  code is  not use in  date_part() there
   Kurt  found bug. It's  used  in to_timestamp()  _only_,  and it  works,
   because tm2timestamp() and date2j() work with zero year.
 
 I have also add a doc mention to my patch that mentions that there is no
 0 AD, and therefore subtraction of BC years from AD years must be done
 with caution.

 The patch seems good for me. Thanks.

Karel

-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] pstrndup()

2004-03-21 Thread Karel Zak
On Sun, Mar 21, 2004 at 11:45:18PM -0500, Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  Karel, do you plan to use pstrndup for some purpose?  I assume so.

 I   thinkPostgreSQL   should   supports   basicoperation   with
 allocation/strings if  it's open for  users' C functions and  we expect
 our own memory system usage.

 I am not familiar with strndup.  If the spec is like strncpy, I would
 vote against including it ... strncpy is so broken that we had to invent
 our own variant ...

 POSIX strncpy()  is different,  a result from  strncpy needn't  be zero
 terminated. You're right it's horrible function.
 
 The result of  strndup() is always zero terminated. It's  more safe and
 strndup() is  binary safe because  it doesn't check something  in input
 string. The pstrndup() is based on PostgreSQL memory managment.

Karel

-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/

---(end of broadcast)---
TIP 8: explain analyze is your friend


[PATCHES] pstrndup()

2004-03-17 Thread Karel Zak

 Hi guys,

 we have pstrdup(char *string) and this tiny patch adds 
 pstrndup(char *sting, Size len).

 By the  way, I  a little  played with the  apache memory  managment and
 they  have the  others interesting  routines like  ap_pstrcat(...) that
 concatenate  all  arguments  (last  must  be  NULL)  to  new  allocated
 string. Is something like this interesting for PostgreSQL?

Karel

-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/


pstrndup-7.5-03172004.patch.gz
Description: GNU Zip compressed data

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] ISO year.

2003-12-19 Thread Karel Zak
On Thu, Dec 18, 2003 at 04:33:44PM +0100, Kurt Roeckx wrote:
 + DCH_I,
  ^^^
   DCH_,
   DCH_YYY,
   DCH_YY,

 There  is  a bug..  it's  wrong  position. Please,  add the  enum  of
 DCH_I to same position as you  have I in next array. It means
 enum DCH_I must  be behind DCH_IW. If you will add  others IY the
 order must be:

 DCH_IW
 DCH_I
 DCH_IYYY
 DCH_IYY
 DCH_IY

 .. and same for lower case version:

 @@ -582,6 +583,7 @@
   DCH_ww,
   DCH_w,
   DCH_y_yyy,
 + DCH_i,
  ^

 Thanks! 
Karel


-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [PATCHES] ISO year.

2003-12-19 Thread Karel Zak
On Thu, Dec 18, 2003 at 11:41:18AM -0500, Tom Lane wrote:
 Kurt Roeckx [EMAIL PROTECTED] writes:
  This patch allows you to use I as format specifier to get the
  ISO year, the year correspondeing to the ISO week number (IW).
 
 The purpose of to_char() as I understand it is to be 100% Oracle
 compatible, not to invent new features at random.  Is this duplicating
 some Oracle functionality that was left out?

 Oracle has I too. So thanks to  Kurt, because now we approximate to
 100% compatibity :-)

 BTW,  I'm open  for to_char()  PostgreSQL  extensions if  it will  good
 described in docs and marked as PostgreSQL extension.

Karel

-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] ISO year.

2003-12-19 Thread Karel Zak
On Thu, Dec 18, 2003 at 08:18:08PM +0100, Kurt Roeckx wrote:
   DCH_IW,
 + DCH_IYYY,
 + DCH_IYY,
 + DCH_IY,
 + DCH_I,

 It's better :-) This patch is OK for me.

Karel

-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PATCHES] psql-current italian translation updates

2003-12-12 Thread Karel Zak
On Thu, Dec 11, 2003 at 10:48:14PM +0100, Peter Eisentraut wrote:
 
 This work is pretty much wasted at this time, because we're about one 
 year away from making a new release, and who knows what will be changed 
  ^^
 Man, you're pretty pessimistic :-))

Karel

-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


[PATCHES] 7.4: pg_dumplo fix

2003-10-09 Thread Karel Zak

 Hi,

 someone report  me small  bug in contrib/pg_dumplo  today. It's problem
 with a little dirty snprintf() usage which I used some years ago:
 
snprintf(path, BUFSIZ, %s/lo_dump.index, path);
 
 Thanks,
Karel

-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/


pg_dumplo-7.4-10092003.patch.gz
Description: GNU Zip compressed data

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [PATCHES] [BUGS] to_timestamp not stable if date string shorter than

2003-09-03 Thread Karel Zak

On Wed, Sep 03, 2003 at 12:15:47AM -0400, Tom Lane wrote:

 that as a full fix.  Karel, the ball's in your court ...

 Fixed. All tests  passed. My court  is without  ball now. The  patch is
 attached.

 Thanks, it was good find!

Karel

-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/


formatting-09032003.patch.gz
Description: GNU Zip compressed data

---(end of broadcast)---
TIP 8: explain analyze is your friend


[PATCHES] 7.3: [BUGS] to_timestamp not stable if date string shorter than

2003-09-03 Thread Karel Zak
On Wed, Sep 03, 2003 at 11:53:35AM -0400, Tom Lane wrote:
 Karel Zak [EMAIL PROTECTED] writes:
   Hmm..  but  the patch  fix  another  small  bug  which I  found  today.
 
 Okay.  Please send a patch against 7.3 tip and I'll throw it in.

 The patch for REL7_3_4 is attached.

Karel

-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/


formatting-7.3-09032003.patch.gz
Description: GNU Zip compressed data

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] Czech NLS

2003-07-23 Thread Karel Zak
On Wed, Jul 23, 2003 at 11:48:19AM +0200, Peter Eisentraut wrote:
 Karel Zak writes:
 
   the patch contains complete messages transaltion of:
 
 Installed.  Nice work.

 Thanks. What time will freeze backend messages? I think after beta
 release.

Karel

-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


[PATCHES] Czech NLS

2003-07-22 Thread Karel Zak

 Hi,

 the patch contains complete messages transaltion of:

libpq
pg_controldata
pg_resetxlog
psql
pg_dump
pgscripts

 Beacuse this patch is a little greater than pgsql-patches list limit
 I put it to my FTP instead to mail attachement. Please, load it from
 following URL:

 ftp://ftp2.zf.jcu.cz/users/zakkr/pg/nls-cs-07222003.patch.gz

 Thanks,
Karel

 PS. Is pgsql-patches list limit 40Kb?

-- 
 Karel Zak  [EMAIL PROTECTED]
 http://home.zf.jcu.cz/~zakkr/

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html