SEO

Redirecting from -general.

> > I'd like SYSDATE to work syntactically and semantically the same as
> > CURRENT_TIMESTAMP
>
> current_time and the like are hardcoded in the grammar. You'd have to
> do the same for sysdate.

Okay, I patched. The patch follows. Please comment. In particular,
I've just copied the CURRENT_TIMESTAMP code block in gram.y. Is this
the best approach? I saw similar code copying between a couple of the
other time-related functions in gram.y. Can't keywords share code
blocks in bison?

I found it interesting that gram.c and parse.h already supported SYSDATE.
I patched only gram.y and keywords.c

> I'd question the hassle of having to patch all the Postgres
> installations you're going to want to run your code on.

Yeah, and I don't expect that they'll be a rush to commit this to head
anytime soon. I'll be happy enough tracking this locally. I think it's
a win for my situation.

================================================== =================
RCS file: /projects/cvsroot/pgsql/src/backend/parser/gram.y,v
retrieving revision 2.568
diff -c -r2.568 gram.y
*** gram.y 5 Nov 2006 22:42:09 -0000 2.568
--- gram.y 17 Nov 2006 23:36:35 -0000
***************
*** 419,425 ****
SERIALIZABLE SESSION SESSION_USER SET SETOF SHARE
SHOW SIMILAR SIMPLE SMALLINT SOME STABLE START STATEMENT
STATISTICS STDIN STDOUT STORAGE STRICT_P SUBSTRING SUPERUSER_P SYMMETRIC
! SYSID SYSTEM_P

TABLE TABLESPACE TEMP TEMPLATE TEMPORARY THEN TIME TIMESTAMP
TO TRAILING TRANSACTION TREAT TRIGGER TRIM TRUE_P
--- 419,425 ----
SERIALIZABLE SESSION SESSION_USER SET SETOF SHARE
SHOW SIMILAR SIMPLE SMALLINT SOME STABLE START STATEMENT
STATISTICS STDIN STDOUT STORAGE STRICT_P SUBSTRING SUPERUSER_P SYMMETRIC
! SYSDATE SYSID SYSTEM_P

TABLE TABLESPACE TEMP TEMPLATE TEMPORARY THEN TIME TIMESTAMP
TO TRAILING TRANSACTION TREAT TRIGGER TRIM TRUE_P
***************
*** 7540,7545 ****
--- 7540,7559 ----
n->location = @1;
$$ = (Node *)n;
}
+ | SYSDATE
+ {
+ /*
+ * Translate as "now()", since we have a function that
+ * does exactly what is needed.
+ */
+ FuncCall *n = makeNode(FuncCall);
+ n->funcname = SystemFuncName("now");
+ n->args = NIL;
+ n->agg_star = FALSE;
+ n->agg_distinct = FALSE;
+ n->location = @1;
+ $$ = (Node *)n;
+ }
| CURRENT_TIMESTAMP '(' Iconst ')'
{
/*
***************
*** 8893,8898 ****
--- 8907,8913 ----
| SESSION_USER
| SOME
| SYMMETRIC
+ | SYSDATE
| TABLE
| THEN
| TO
Index: keywords.c
================================================== =================
RCS file: /projects/cvsroot/pgsql/src/backend/parser/keywords.c,v
retrieving revision 1.177
diff -c -r1.177 keywords.c
*** keywords.c 7 Oct 2006 21:51:02 -0000 1.177
--- keywords.c 17 Nov 2006 23:36:35 -0000
***************
*** 324,329 ****
--- 324,330 ----
{"substring", SUBSTRING},
{"superuser", SUPERUSER_P},
{"symmetric", SYMMETRIC},
+ {"sysdate", SYSDATE},
{"sysid", SYSID},
{"system", SYSTEM_P},
{"table", TABLE},

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

Matt,

> > > I'd like SYSDATE to work syntactically and semantically the same as
> > > CURRENT_TIMESTAMP

Huh? Is SYSDATE part of the standard somewhere?

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Matt Miller wrote:
> Can't keywords share code

Code blocks belong to productions. the way to do what you want I think is
like this:

foo: bar_or_baz
{ code block }
;

bar_or_baz: bar | baz ;


cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

"Matt Miller" <pgsql@mattmillersf.fastmail.fm> writes:
> I found it interesting that gram.c and parse.h already supported SYSDATE.

Only after you ran bison ;-). They're derived files.

regards, tom lane

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

Matt Miller wrote:

> Yeah, and I don't expect that they'll be a rush to commit this to head
> anytime soon. I'll be happy enough tracking this locally. I think it's
> a win for my situation.
>
Why should we add this Oraclism to PostgreSQL? I doesn't add any new
feature.
I suggest you to contribute this kind of code to orafce project [1]
because it's not standardized.

[1] http://pgfoundry.org/projects/orafce/

--
Euler Taveira de Oliveira
http://www.timbira.com/


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

Euler Taveira de Oliveira wrote:
> Matt Miller wrote:
> > Yeah, and I don't expect that they'll be a rush to commit this to
> > head anytime soon. I'll be happy enough tracking this locally. I
> > think it's a win for my situation.
>
> Why should we add this Oraclism to PostgreSQL? I doesn't add any new
> feature.

Certainly, this feature falls well within the class of completely
gratuitous proprietary extensions that we typically reject.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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

> > Can't keywords share code
>
> the way to do what you want I think is
> like this:
>
> foo: bar_or_baz
> { code block }
> ;
>
> bar_or_baz: bar | baz ;

I'll try that, thanks.

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

> I suggest you to contribute this kind of code to orafce project [1]

Thanks, I'll go play over there for a while.

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

> > I found it interesting that gram.c and parse.h already supported SYSDATE.
>
> Only after you ran bison ;-). They're derived files.

Well, so much for my conspiracy theory.

Thanks for the bison lesson.

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

> > Why should we add this Oraclism to PostgreSQL? I doesn't add any new
> > feature.
>
> Certainly, this feature falls well within the class of completely
> gratuitous proprietary extensions that we typically reject.

I now agree completely. My purpose is to migrate Oracle databases to
Posgres, and I had thought that Oracle didn't support CURRENT_DATE,
CURRENT_TIMESTAMP, and so on. However, I've just learned otherwise. So,
I think the proper migration process for a production database would be
to first change the Oracle DB to use CURRENT_DATE (or some other
standard psuedo column), since that will work properly under both Oracle
and Postgres.

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