If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to [EMAIL PROTECTED]
To report any other bug, fill out the form below and e-mail it to
[EMAIL PROTECTED]
If you not only found the proble
Sean Chittenden:
I have been trying to contact you through your various e-mail
addresses over the course of more than two months, but you have not
replied. So I'm butting in here in hopes that you'll take notice. This
is in regards to the unauthorized posting to your website of
copyrighted materia
Rod Taylor <[EMAIL PROTECTED]> writes:
> NEXT VALUE FOR and CURRENT VALUE FOR where CURRENT is an unreserved
> keyword and VALUE is not reserved in any way (ident with comparison to
> "value").
I see one pretty big problem with this: the SQL2003 spec says clearly
that multiple occurrences of NEXT
On Fri, 2004-05-07 at 14:38, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > NEXT VALUE FOR and CURRENT VALUE FOR where CURRENT is an unreserved
> > keyword and VALUE is not reserved in any way (ident with comparison to
> > "value").
>
> I see one pretty big problem with this: the SQL
Bruce Momjian wrote:
> Agreed we have to show both. The question is whether we should prefer
> single quotes and switch to $$ only when a single quote exists in the
> body, or use $$ in most cases. Of course CREATE FUNCTION should show
> that both are possible, as well as $tag$.
My take: If there
> How we do what the spec wants isn't entirely clear, but maybe we could
> link all the supposed-to-track-each-other occurrences of NEXT VALUE FOR
> late in the planning stage or during executor startup, somewhat like
> what happens with aggregate functions.
Isn't there a statement level memory lo
Here's a patch that will allow external modules like pl to set
additional flags for the dlltool and dllwrap commands. More info here:
http://archives.postgresql.org/pgsql-hackers/2004-05/msg00350.php
regards,
Thomas Hallgren
--
A ship in harbor is safe, but that is not what ships are built for.
Rod Taylor <[EMAIL PROTECTED]> writes:
> Does that mean the below insert should give both col1 and col2 the same
> value?
> CREATE TABLE test (
> col1 integer DEFAULT NEXT VALUE FOR t_seq,
> col2 integer DEFAULT NEXT VALUE FOR t_seq
> );
> INSERT INTO TABLE DEFAULT VALUES;
AFAICS tha
Rod Taylor <[EMAIL PROTECTED]> writes:
> Isn't there a statement level memory location that we could shove a
> boolean variable?
Not per se, and anyway remember that this behavior is per sequence
generator not global.
I was just mentally designing something that I think might work. We
need two d
Bruce Momjian wrote:
> I have applied the attached patch to fix this problem. Sample output
> is:
>
> test=> set log_statement_stats = true;
> SET
> test=> set log_parser_stats = true;
> ERROR: Can not enable parameter when "log_statement_stats" is true.
According to mess
[ Very off topic - very funny, but very off topic ]
[ Please keep replies off list ]
Um, sorry about that folks. My SPAM filter had tagged this guy's
messages as SPAM. I was mirroring a copy of the following:
http://objective.jesussave.us/creationsciencefair.html
because I didn't want these pr
> This all assumes that associating the NEXTVALUE state with an EState
> is a good approximation of the spec's statements about how often to
> advance the sequence counter. I think it is all right for simple cases
That is an awful lot of work to do in order to avoid implementing
IDENTITIES and GE
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > I have applied the attached patch to fix this problem. Sample output
> > is:
> >
> > test=> set log_statement_stats = true;
> > SET
> > test=> set log_parser_stats = true;
> > ERROR: Can not enable parameter when "log_statement_st
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Thanks:
> errmsg("cannot enable parameter when \"log_statement_stats\" is true.")));
> errmsg("cannot enable \"log_statement_stats\" when \"log_parser_stats\",\n"
> "\"log_planner_stats\", or \"log_executor_stats\" is true.")));
Still
Patch withdrawn by author.
---
Rod Taylor wrote:
> It would appear the spec was approved of before we got foo.nextval, so
> here it is again.
>
> NEXT VALUE FOR and CURRENT VALUE FOR where CURRENT is an unreserved
> keyword
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Thanks:
>
> > errmsg("cannot enable parameter when \"log_statement_stats\" is true.")));
> > errmsg("cannot enable \"log_statement_stats\" when \"log_parser_stats\",\n"
> > "\"log_planner_stats\", or \"log_executor_sta
16 matches
Mail list logo
