On Sat, Sep 02, 2006 at 06:22:49PM -0500, Jim C. Nasby wrote:
> On Thu, Aug 31, 2006 at 06:29:50PM -0400, Tom Lane wrote:
> > For backwards compatibility we should probably say that this
> > automatic lifting of base-table defaults happens only if the
> > INSERT rule is implicitly generated ... if
On Thu, Aug 31, 2006 at 06:29:50PM -0400, Tom Lane wrote:
> For backwards compatibility we should probably say that this automatic
> lifting of base-table defaults happens only if the INSERT rule is
> implicitly generated ... if you write a manual INSERT rule you need
> manual defaults too. Or sho
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> now that you're reviewing the updatable view patch, i think we must
> decide what you're position will be about if the updatable view should
> inherit the base table default values... or if we want to create
> default values for every view if we want t
Hi,
now that you're reviewing the updatable view patch, i think we must
decide what you're position will be about if the updatable view should
inherit the base table default values... or if we want to create
default values for every view if we want they match with the base
table ones... (fwiw, in
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Is anybody working on Bernd's updatable views patch? Right now I'm
> having a look at it -- mainly fixing some cosmetic issues right now,
> intending to eventually do an actual code review.
Great --- it's on my to-do list but I'm happy to have more eye
Alvaro Herrera wrote:
> Hi,
>
> Is anybody working on Bernd's updatable views patch? Right now I'm
> having a look at it -- mainly fixing some cosmetic issues right now,
> intending to eventually do an actual code review.
>
> I'll post an updated patch at some point -- if someone wants to have a
Hi,
Is anybody working on Bernd's updatable views patch? Right now I'm
having a look at it -- mainly fixing some cosmetic issues right now,
intending to eventually do an actual code review.
I'll post an updated patch at some point -- if someone wants to have a
look or do some intensive review, j
> > While I don't think that making WITH a fully reserved word would
cause
> > any great damage, I'm unwilling to do it just to save a couple of
lines
> > of code.
>
> I think we should go on and do promote WITH to a reserved keyword now
Oracle, MS-SQL, DB2, MySQL and Informix also have WITH res
Hannu Krosing <[EMAIL PROTECTED]> writes:
> I think we should go on and do promote WITH to a reserved keyword now
> because eventually we have to do it anyway.
> It is needed for recursive queries as well.
I'm unconvinced. Recursive queries have WITH at the front, not the
back, so the parsing iss
Ühel kenal päeval, R, 2006-05-26 kell 22:50, kirjutas Tom Lane:
> I wrote:
> > We can use the same technique that we used for UNION JOIN, but instead
> > join, say, WITH and TIME into one token and make the time datatype
> > productions look for "TIME WITHTIME ZONE" and so on. (I propose this
> >
I wrote:
> We can use the same technique that we used for UNION JOIN, but instead
> join, say, WITH and TIME into one token and make the time datatype
> productions look for "TIME WITHTIME ZONE" and so on. (I propose this
> rather than putting the ugliness into WITH CHECK OPTION, because this
> wa
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah, I just read the same in the bison manual. The thing that's
>> bothering me is that a GLR parser would hide that ambiguity from you,
> It doesn't really hide it. You still get the "N shift/reduce conflicts"
> warnings from b
Tom Lane wrote:
> Yeah, I just read the same in the bison manual. The thing that's
> bothering me is that a GLR parser would hide that ambiguity from you,
It doesn't really hide it. You still get the "N shift/reduce conflicts"
warnings from bison. You just know that they are being handled.
--
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> As I understand it, it runs one parser pretty much like the standard LALR(1)
> case, until it finds an ambiguity (shift/reduce or reduce/reduce) at which
> stage it clones the parser to take parallel paths, working in lockstep, and
> storing up semanti
Tom Lane said:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Andrew Dunstan wrote:
>>> "The GLR parsers require a compiler for ISO C89 or later. In
>>> addition, they use the inline keyword, which is not C89, but is C99
>>> and is a common extension in pre-C99 compilers. It is up to the user
>>
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> "The GLR parsers require a compiler for ISO C89 or later. In
>> addition, they use the inline keyword, which is not C89, but is C99
>> and is a common extension in pre-C99 compilers. It is up to the user
>> of these parsers to
Andrew Dunstan wrote:
> "The GLR parsers require a compiler for ISO C89 or later. In
> addition, they use the inline keyword, which is not C89, but is C99
> and is a common extension in pre-C99 compilers. It is up to the user
> of these parsers to handle portability issues."
We already use inline,
Peter Eisentraut said:
> Martijn van Oosterhout wrote:
>> Incidently, IIRC the default behaviour on conflict is a shift anyway,
>> so that what the patch already does anyway.
>>
>> So we get:
>>
>> CREATE VIEW foo AS SELECT expr :: TIME WITH TIME ZONE<-- OK
>> CREATE VIEW foo AS SELECT expr
Martijn van Oosterhout wrote:
> Incidently, IIRC the default behaviour on conflict is a shift anyway,
> so that what the patch already does anyway.
>
> So we get:
>
> CREATE VIEW foo AS SELECT expr :: TIME WITH TIME ZONE<-- OK
> CREATE VIEW foo AS SELECT expr :: TIME WITH CHECK OPTION <
Martijn van Oosterhout writes:
> So we get:
>
> CREATE VIEW foo AS SELECT expr :: TIME WITH TIME ZONE<-- OK
> CREATE VIEW foo AS SELECT expr :: TIME WITH CHECK OPTION <-- parse error
> CREATE VIEW foo AS SELECT (expr :: TIME) WITH CHECK OPTION <-- OK
I haven't really been followi
On Wed, May 24, 2006 at 01:13:06PM +0200, Peter Eisentraut wrote:
> CREATE VIEW foo AS SELECT expr :: TIME . WITH
>
> (where expr is a_expr or b_expr and TIME could also be TIMESTAMP or TIME(x)
> or
> TIMESTAMP(x)).
>
> The continuation here could be WITH TIME ZONE (calling for a shift) or WITH
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I had a quick look - I don't think there is an easy answer with the
> current proposed grammar. If we want to prevent shift/reduce conflicts I
> suspect we'd need to use a different keyword than WITH, although I can't
> think of one that couldn't be a
Peter Eisentraut wrote:
Am Mittwoch, 24. Mai 2006 20:42 schrieb Tom Lane:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
I have spent some time figuring out how to resolve the parsing conflicts
in Bernd Helmle's updatable views patch. The problem has now been
reduced to specifically this
Am Mittwoch, 24. Mai 2006 20:42 schrieb Tom Lane:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I have spent some time figuring out how to resolve the parsing conflicts
> > in Bernd Helmle's updatable views patch. The problem has now been
> > reduced to specifically this situation:
>
> Could
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I have spent some time figuring out how to resolve the parsing conflicts in
> Bernd Helmle's updatable views patch. The problem has now been reduced to
> specifically this situation:
Could we see the proposed patches for gram.y?
> If we can't get
Hannu Krosing wrote:
Can't we teach tokenized a new token "WITH TIME ZONE" ?
No, that's three tokens, not one. We surely don't want to start making
white space significant.
cheers
andrew
---(end of broadcast)---
TIP 6: explain analyze is
Ühel kenal päeval, K, 2006-05-24 kell 13:13, kirjutas Peter Eisentraut:
> I have spent some time figuring out how to resolve the parsing conflicts in
> Bernd Helmle's updatable views patch. The problem has now been reduced to
> specifically this situation:
>
> CREATE VIEW foo AS SELECT expr ::
I have spent some time figuring out how to resolve the parsing conflicts in
Bernd Helmle's updatable views patch. The problem has now been reduced to
specifically this situation:
CREATE VIEW foo AS SELECT expr :: TIME . WITH
(where expr is a_expr or b_expr and TIME could also be TIMESTAMP or T
28 matches
Mail list logo
