>>
>> I'd want it to error out on "INSERT foo (bar.col)", though ;-)
>>
>
> And on "INSERT foo (bar.foo.col)" as well.
Why accept above at all ? Seems much too error prone, I would eighter
accept table with schema or without schema, mixing both cases seems
unnecessarily confusing and error pr
On Mon, 18 Mar 2002, Fernando Nasser wrote:
> Vince Vielhaber wrote:
> >
> > On Thu, 14 Mar 2002, Rod Taylor wrote:
> >
> > > Out of curiosity, does SyBase allow you to qualify it with
> > > schema.table.column?
> >
> > Just tried it... Yes.
> >
>
> What if you give it a bogus schema name? Does
Vince Vielhaber wrote:
>
> On Thu, 14 Mar 2002, Rod Taylor wrote:
>
> > Out of curiosity, does SyBase allow you to qualify it with
> > schema.table.column?
>
> Just tried it... Yes.
>
What if you give it a bogus schema name? Does it error out or just
ignore it?
--
Fernando Nasser
Red Hat
Tom Lane wrote:
>
> I'd want it to error out on "INSERT foo (bar.col)", though ;-)
>
And on "INSERT foo (bar.foo.col)" as well.
This means we will have to take this check down to the analyze
phase (where the schema where foo is located is finally known,
if it was not specified explicitly).
We
Vince Vielhaber wrote:
>
> Looks like Sybase ignores the bar:
>
> 1> create table foo(a int)
> 2> go
> 1> insert into foo(bar.a) values(1)
> 2> go
> (1 row affected)
> 1> select * from foo
> 2> go
> a
> ---
>1
>
> (1 row affected)
> 1>
>
This looks like a parser error to
On Fri, 15 Mar 2002, Tom Lane wrote:
> Vince Vielhaber <[EMAIL PROTECTED]> writes:
> > On Fri, 15 Mar 2002, Thomas Lockhart wrote:
> >> But I *really* don't see the benefit of that (.)
> >> syntax. Especially when it cannot (?? we need a counterexample) lead to
> >> any additional interesting ben
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> On Fri, 15 Mar 2002, Thomas Lockhart wrote:
>> But I *really* don't see the benefit of that (.)
>> syntax. Especially when it cannot (?? we need a counterexample) lead to
>> any additional interesting beneficial behavior.
> The only benefit I can come
Sorry for the previous sarcastic response.
But I *really* don't see the benefit of that (.)
syntax. Especially when it cannot (?? we need a counterexample) lead to
any additional interesting beneficial behavior.
- Thomas
---(end of broadcast)--
> > > Looking at the entire message noted
> > > above the list of other dbs that support it is now Oracle, Sybase,
> > > MS-SQL and mysql. If "other dbs" ends up the equivilent of "everything
> > > but PostgreSQL" then which one is non-standard?
The one(s) that intentionally violate or gratuitou
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> There are really no other decent CMSs available that support
> PostgreSQL.
bricolage.thepirtgroup.com/
Mike.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgr
On Thu, 14 Mar 2002, Tom Lane wrote:
> Vince Vielhaber <[EMAIL PROTECTED]> writes:
> >> What's your definition of "other dbs"? The above statement is quite
> >> clearly in violation of the SQL92 and SQL99 specifications:
>
> > And nowhere does it say that cannot be qualified with
> > the table
Vince Vielhaber <[EMAIL PROTECTED]> writes:
>> What's your definition of "other dbs"? The above statement is quite
>> clearly in violation of the SQL92 and SQL99 specifications:
> And nowhere does it say that cannot be qualified with
> the table name in front of it.
Au contraire, that is EXACT
On Thu, 14 Mar 2002, Stephan Szabo wrote:
>
> ::= !! See the Syntax Rules
>
> ::=
>
> |
> identifier start is a simple latin letter, a letter in the character
> repertoire that's in use, a syllable in the repertoire or an ideograph in
> the repe
On Thu, 14 Mar 2002, Vince Vielhaber wrote:
> On Thu, 14 Mar 2002, Rod Taylor wrote:
>
> > As snipped from:
> > http://archives.postgresql.org/pgsql-bugs/2000-10/msg00030.php (All
> > my stuff is in paper form)
> > What's your definition of "other dbs"? The above statement is quite
> > clearl
On Thu, 14 Mar 2002, Rod Taylor wrote:
> Out of curiosity, does SyBase allow you to qualify it with
> schema.table.column?
Just tried it... Yes.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http:/
ECTED]>
Cc: "Peter Eisentraut" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, March 14, 2002 9:39 AM
Subject: Re: [HACKERS] insert statements
> On Thu, 14 Mar 2002, Rod Taylor wrote:
>
> > As snipped from:
> > http://archives.postgresql.org/pgsql-
ial view of the voices in my head
>
> - Original Message -
> From: "Vince Vielhaber" <[EMAIL PROTECTED]>
> To: "Rod Taylor" <[EMAIL PROTECTED]>
> Cc: "Peter Eisentraut" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sen
;[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, March 14, 2002 9:08 AM
Subject: Re: [HACKERS] insert statements
> On Thu, 14 Mar 2002, Rod Taylor wrote:
>
> > Why not send in your changes to PostNuke along with the
appropriate
> > section from the SQL specs?
>
section?
> --
> Rod Taylor
>
> This message represents the official view of the voices in my head
>
> - Original Message -
> From: "Vince Vielhaber" <[EMAIL PROTECTED]>
> To: "Peter Eisentraut" <[EMAIL PROTECTED]>
> Cc: <[EMAI
into foo (a) as
well.
--
Rod Taylor
This message represents the official view of the voices in my head
- Original Message -
From: "Vince Vielhaber" <[EMAIL PROTECTED]>
To: "Peter Eisentraut" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday,
On Wed, 13 Mar 2002, Peter Eisentraut wrote:
> Vince Vielhaber writes:
>
> > For example:
> >
> > insert into foo(foo.a) values(1);
> >
> > fails because the table name is used. Update statements also include the
> > table name. Both fail. Does anyone know of a workaround?
>
> Completely loudl
21 matches
Mail list logo
