[PATCHES] ISO year.

2003-12-18 Thread Kurt Roeckx
This patch allows you to use I as format specifier to get the
ISO year, the year correspondeing to the ISO week number (IW).


Kurt

Index: doc/src/sgml/func.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/func.sgml,v
retrieving revision 1.182
diff -u -r1.182 func.sgml
--- doc/src/sgml/func.sgml  16 Dec 2003 15:27:58 -  1.182
+++ doc/src/sgml/func.sgml  18 Dec 2003 15:29:28 -
@@ -3981,6 +3981,10 @@
last digit of year


+   I
+   ISO year (The first Thursday of the new year is in week 1.)
+   
+   
BC or B.C. or
AD or A.D.
era indicator (upper case)
Index: src/include/utils/timestamp.h
===
RCS file: /projects/cvsroot/pgsql-server/src/include/utils/timestamp.h,v
retrieving revision 1.32
diff -u -r1.32 timestamp.h
--- src/include/utils/timestamp.h   29 Nov 2003 22:41:16 -  1.32
+++ src/include/utils/timestamp.h   18 Dec 2003 15:29:28 -
@@ -248,5 +248,6 @@
 
 extern void isoweek2date(int woy, int *year, int *mon, int *mday);
 extern int date2isoweek(int year, int mon, int mday);
+extern int date2isoyear(int year, int mon, int mday);
 
 #endif   /* TIMESTAMP_H */
Index: src/backend/utils/adt/formatting.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/adt/formatting.c,v
retrieving revision 1.70
diff -u -r1.70 formatting.c
--- src/backend/utils/adt/formatting.c  29 Nov 2003 19:51:58 -  1.70
+++ src/backend/utils/adt/formatting.c  18 Dec 2003 15:29:30 -
@@ -544,6 +544,7 @@
DCH_WW,
DCH_W,
DCH_Y_YYY,
+   DCH_I,
DCH_,
DCH_YYY,
DCH_YY,
@@ -582,6 +583,7 @@
DCH_ww,
DCH_w,
DCH_y_yyy,
+   DCH_i,
DCH_,
DCH_yyy,
DCH_yy,
@@ -659,6 +661,7 @@
{"HH12", 4, dch_time, DCH_HH12, TRUE},
{"HH", 2, dch_time, DCH_HH, TRUE},
{"IW", 2, dch_date, DCH_IW, TRUE},  /* I */
+   {"I", 5, dch_date, DCH_I, TRUE},
{"J", 1, dch_date, DCH_J, TRUE},/* J */
{"MI", 2, dch_time, DCH_MI, TRUE},
{"MM", 2, dch_date, DCH_MM, TRUE},
@@ -699,6 +702,7 @@
{"hh12", 4, dch_time, DCH_HH12, TRUE},
{"hh", 2, dch_time, DCH_HH, TRUE},
{"iw", 2, dch_date, DCH_IW, TRUE},  /* i */
+   {"i", 5, dch_date, DCH_I, TRUE},
{"j", 1, dch_time, DCH_J, TRUE},/* j */
{"mi", 2, dch_time, DCH_MI, TRUE},  /* m */
{"mm", 2, dch_date, DCH_MM, TRUE},
@@ -2444,6 +2448,41 @@
tmfc->year += (cc * 1000);
 
return strdigits_len(inout) + 3 + SKIP_THth(suf);
+   }
+   break;
+   case DCH_I:
+   if (flag == TO_CHAR)
+   {
+   if (tm->tm_year <=  && tm->tm_year >= -9998)
+   sprintf(inout, "%0*d",
+   S_FM(suf) ? 0 : 4, 
+   YEAR_ABS(date2isoyear(
+   tm->tm_year,
+   tm->tm_mon,
+   tm->tm_mday)));
+   else
+   sprintf(inout, "%d",
+   YEAR_ABS(date2isoyear(
+   tm->tm_year,
+   tm->tm_mon,
+   tm->tm_mday)));
+
+   if (S_THth(suf))
+   str_numth(p_inout, inout, S_TH_TYPE(suf));
+   return strlen(p_inout) - 1;
+   }
+   else if (flag == FROM_CHAR)
+   {
+   if (S_FM(suf) || is_next_separator(node))
+   {
+   sscanf(inout, "%d", &tmfc->year);
+   return strdigits_len(inout) - 1 + 
SKIP_THth(suf);
+   }
+   else
+   {
+   sscanf(inout, "%04d", &tmfc->year);
+   return 3 + SKIP_THth(suf);
+   }
}
break;
case DCH_:
Index: src/backend/utils/adt/timestamp.c
===
RCS file: /projects/cvs

Re: [PATCHES] ISO year.

2003-12-18 Thread Tom Lane
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?

regards, tom lane

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

   http://archives.postgresql.org


Re: [PATCHES] ISO year.

2003-12-18 Thread Kurt Roeckx
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?

I have no idea if this in Oracle or not.  But it's something I
needed, and other people in the past asked about it too.

You could use the normal year instead of the iso year, but around
newyear this always gives problems.


Kurt


---(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] ISO year.

2003-12-18 Thread Peter Eisentraut
Kurt Roeckx wrote:
> I have no idea if this in Oracle or not.  But it's something I
> needed, and other people in the past asked about it too.

It is in Oracle, but you aren't exactly on the spot.  It should be

IYYY - 4 digits  ('2003')
IYY  - 3 digits  ('003')
IY   - 2 digits  ('03')
I- 1 digit   ('3')


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


Re: [PATCHES] ISO year.

2003-12-18 Thread Kurt Roeckx
On Thu, Dec 18, 2003 at 06:47:41PM +0100, Peter Eisentraut wrote:
> Kurt Roeckx wrote:
> > I have no idea if this in Oracle or not.  But it's something I
> > needed, and other people in the past asked about it too.
> 
> It is in Oracle, but you aren't exactly on the spot.  It should be
> 
> IYYY - 4 digits  ('2003')
> IYY  - 3 digits  ('003')
> IY   - 2 digits  ('03')
> I- 1 digit   ('3')

I'll update the patch to support all of them.


Kurt


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


Re: [PATCHES] ISO year.

2003-12-18 Thread Kurt Roeckx
On Thu, Dec 18, 2003 at 06:47:41PM +0100, Peter Eisentraut wrote:
> Kurt Roeckx wrote:
> > I have no idea if this in Oracle or not.  But it's something I
> > needed, and other people in the past asked about it too.
> 
> It is in Oracle, but you aren't exactly on the spot.  It should be
> 
> IYYY - 4 digits  ('2003')
> IYY  - 3 digits  ('003')
> IY   - 2 digits  ('03')
> I- 1 digit   ('3')

Here is an updated patch that does that.


Kurt

Index: doc/src/sgml/func.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/func.sgml,v
retrieving revision 1.182
diff -u -r1.182 func.sgml
--- doc/src/sgml/func.sgml  16 Dec 2003 15:27:58 -  1.182
+++ doc/src/sgml/func.sgml  18 Dec 2003 18:57:56 -
@@ -3981,6 +3981,22 @@
last digit of year


+   IYYY
+   ISO year (4 and more digits)
+   
+   
+   IYY
+   last 3 digits of ISO year
+   
+   
+   IY
+   last 2 digits of ISO year
+   
+   
+   I
+   last digits of ISO year
+   
+   
BC or B.C. or
AD or A.D.
era indicator (upper case)
Index: src/include/utils/timestamp.h
===
RCS file: /projects/cvsroot/pgsql-server/src/include/utils/timestamp.h,v
retrieving revision 1.32
diff -u -r1.32 timestamp.h
--- src/include/utils/timestamp.h   29 Nov 2003 22:41:16 -  1.32
+++ src/include/utils/timestamp.h   18 Dec 2003 18:57:57 -
@@ -248,5 +248,6 @@
 
 extern void isoweek2date(int woy, int *year, int *mon, int *mday);
 extern int date2isoweek(int year, int mon, int mday);
+extern int date2isoyear(int year, int mon, int mday);
 
 #endif   /* TIMESTAMP_H */
Index: src/backend/utils/adt/formatting.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/adt/formatting.c,v
retrieving revision 1.70
diff -u -r1.70 formatting.c
--- src/backend/utils/adt/formatting.c  29 Nov 2003 19:51:58 -  1.70
+++ src/backend/utils/adt/formatting.c  18 Dec 2003 18:57:58 -
@@ -525,6 +525,10 @@
DCH_HH12,
DCH_HH,
DCH_IW,
+   DCH_IYYY,
+   DCH_IYY,
+   DCH_IY,
+   DCH_I,
DCH_J,
DCH_MI,
DCH_MM,
@@ -565,6 +569,10 @@
DCH_hh12,
DCH_hh,
DCH_iw,
+   DCH_iyyy,
+   DCH_iyy,
+   DCH_iy,
+   DCH_i,
DCH_j,
DCH_mi,
DCH_mm,
@@ -659,6 +667,10 @@
{"HH12", 4, dch_time, DCH_HH12, TRUE},
{"HH", 2, dch_time, DCH_HH, TRUE},
{"IW", 2, dch_date, DCH_IW, TRUE},  /* I */
+   {"IYYY", 4, dch_date, DCH_IYYY, TRUE},
+   {"IYY", 3, dch_date, DCH_IYY, TRUE},
+   {"IY", 2, dch_date, DCH_IY, TRUE},
+   {"I", 1, dch_date, DCH_I, TRUE},
{"J", 1, dch_date, DCH_J, TRUE},/* J */
{"MI", 2, dch_time, DCH_MI, TRUE},
{"MM", 2, dch_date, DCH_MM, TRUE},
@@ -699,6 +711,10 @@
{"hh12", 4, dch_time, DCH_HH12, TRUE},
{"hh", 2, dch_time, DCH_HH, TRUE},
{"iw", 2, dch_date, DCH_IW, TRUE},  /* i */
+   {"iyyy", 4, dch_date, DCH_IYYY, TRUE},
+   {"iyy", 3, dch_date, DCH_IYY, TRUE},
+   {"iy", 2, dch_date, DCH_IY, TRUE},
+   {"i", 1, dch_date, DCH_I, TRUE},
{"j", 1, dch_time, DCH_J, TRUE},/* j */
{"mi", 2, dch_time, DCH_MI, TRUE},  /* m */
{"mm", 2, dch_date, DCH_MM, TRUE},
@@ -2447,12 +2463,26 @@
}
break;
case DCH_:
+   case DCH_IYYY:
if (flag == TO_CHAR)
{
if (tm->tm_year <=  && tm->tm_year >= -9998)
-   sprintf(inout, "%0*d", S_FM(suf) ? 0 : 4, 
YEAR_ABS(tm->tm_year));
-   else
-   sprintf(inout, "%d", YEAR_ABS(tm->tm_year));
+   sprintf(inout, "%0*d",
+   S_FM(suf) ? 0 : 4,
+   arg == DCH_ ?
+   YEAR_ABS(tm->tm_year) :
+   YEAR_ABS(date2isoyear(
+   tm->tm_year,
+   tm->tm_mon,
+   tm->tm_mday)));
+   else
+   sprintf(inout, "%d",
+   arg == DCH_ ?
+   YEAR_ABS(tm->tm_year) :
+   YEAR_ABS(date2isoyear(
+   tm->tm_year,
+

Re: [PATCHES] [GENERAL] restore error - language "plperlu" is not trusted

2003-12-18 Thread Peter Eisentraut
Attached is my proposed patch for this problem, to be put in 7.4.1.  
Please someone give it a quick check.

Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Uh, no, because you can say something like
> >> revoke all on language plperlu from public;
> >> and end up with non-null lanacl (because it instantiates the
> >> default assumption that the owner has all privileges).
> >
> > OK, that needs to be disallowed.
>
> Fair enough.  I thought it was a bit odd to disallow GRANT but allow
> REVOKE anyway.
>
> >> We could possibly hack the backend to avoid that, but I think
> >> pg_dump will need the special-case test anyway since it has to be
> >> able to cope with existing databases, wherein lanacl may be
> >> non-null.
> >
> > So far we know of 1 such database.  I'd like to see some more
> > before we bother about it.
>
> It's a one-line addition --- just put the dumpACL call inside
> "if (lanpltrusted)".  I think it is a reasonable change.  We'd have
> to do something anyway, because the existing pg_dump code is
> certainly broken for dumping untrusted languages from pre-7.3
> databases (it assumes a nonempty lanacl setting in that case).
diff -cr ../cvs-pgsql/src/backend/catalog/aclchk.c ./src/backend/catalog/aclchk.c
*** ../cvs-pgsql/src/backend/catalog/aclchk.c	Sat Nov  1 02:52:13 2003
--- ./src/backend/catalog/aclchk.c	Thu Dec 18 20:20:08 2003
***
*** 592,601 
  			aclcheck_error(ACLCHECK_NO_PRIV, ACL_KIND_LANGUAGE,
  		   NameStr(pg_language_tuple->lanname));
  
! 		if (!pg_language_tuple->lanpltrusted && stmt->is_grant)
! 			ereport(ERROR,
! 	(errcode(ERRCODE_WRONG_OBJECT_TYPE),
! 	 errmsg("language \"%s\" is not trusted", langname)));
  
  		/*
  		 * If there's no ACL, substitute the proper default.
--- 592,613 
  			aclcheck_error(ACLCHECK_NO_PRIV, ACL_KIND_LANGUAGE,
  		   NameStr(pg_language_tuple->lanname));
  
! 		if (!pg_language_tuple->lanpltrusted)
! 		{
! 			if (stmt->is_grant)
! 			{
! ereport(ERROR,
! 		(errcode(ERRCODE_WRONG_OBJECT_TYPE),
! 		 errmsg("language \"%s\" is not trusted", langname)));
! 			}
! 			else
! 			{
! /* do nothing (like revoking a non-existing privilege) */
! ReleaseSysCache(tuple);
! heap_close(relation, RowExclusiveLock);
! continue;
! 			}
! 		}
  
  		/*
  		 * If there's no ACL, substitute the proper default.
diff -cr ../cvs-pgsql/src/bin/pg_dump/pg_dump.c ./src/bin/pg_dump/pg_dump.c
*** ../cvs-pgsql/src/bin/pg_dump/pg_dump.c	Thu Oct 30 21:24:39 2003
--- ./src/bin/pg_dump/pg_dump.c	Thu Dec 18 21:10:09 2003
***
*** 3488,3493 
--- 3488,3494 
  	int			i_lanacl = -1;
  	char	   *lanoid;
  	char	   *lanname;
+ 	bool	lanpltrusted;
  	char	   *lanacl;
  	const char *lanplcallfoid;
  	const char *lanvalidator;
***
*** 3528,3533 
--- 3529,3535 
  		lanoid = PQgetvalue(res, i, i_oid);
  		lanplcallfoid = PQgetvalue(res, i, i_lanplcallfoid);
  		lanname = PQgetvalue(res, i, i_lanname);
+ 		lanpltrusted = (PQgetvalue(res, i, i_lanpltrusted)[0] == 't');
  		if (fout->remoteVersion >= 70300)
  		{
  			lanvalidator = PQgetvalue(res, i, i_lanvalidator);
***
*** 3580,3586 
  		  fmtId(lanname));
  
  		appendPQExpBuffer(defqry, "CREATE %sPROCEDURAL LANGUAGE %s",
! 		  (PQgetvalue(res, i, i_lanpltrusted)[0] == 't') ?
  		  "TRUSTED " : "",
  		  fmtId(lanname));
  		appendPQExpBuffer(defqry, " HANDLER %s",
--- 3582,3588 
  		  fmtId(lanname));
  
  		appendPQExpBuffer(defqry, "CREATE %sPROCEDURAL LANGUAGE %s",
! 		  lanpltrusted ?
  		  "TRUSTED " : "",
  		  fmtId(lanname));
  		appendPQExpBuffer(defqry, " HANDLER %s",
***
*** 3605,3611 
  	 "PROCEDURAL LANGUAGE", deps,
  	 defqry->data, delqry->data, NULL, NULL, NULL);
  
! 		if (!aclsSkip)
  		{
  			char	   *tmp = strdup(fmtId(lanname));
  
--- 3607,3613 
  	 "PROCEDURAL LANGUAGE", deps,
  	 defqry->data, delqry->data, NULL, NULL, NULL);
  
! 		if (!aclsSkip && lanpltrusted)
  		{
  			char	   *tmp = strdup(fmtId(lanname));
  

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


Re: [PATCHES] [GENERAL] restore error - language "plperlu" is not trusted

2003-12-18 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Attached is my proposed patch for this problem, to be put in 7.4.1.  
> Please someone give it a quick check.

The aclchk change looks okay if that's the behavior you want, but I
wonder why you don't just make it raise error in both the GRANT and
REVOKE cases.

The pg_dump change looks okay for the 7.4 branch.  It will not apply to
HEAD but I think you can just add

if (plang->lanpltrusted)

before the dumpACL call in that case.

regards, tom lane

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