Here's one Mysql developer's response to adding (fixing) the
integer/bigint/tinyint types to their CAST function:
http://bugs.mysql.com/bug.php?id=34562
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropria
I'd like to see a list o t he various approaches, and a poll as to which
are best and why, for naming table and columns and constraints. We've
all seen several variations, but the most common (and pg used) seems to be:
columns:
primary key: _pk OR _id OR _rowid
foreign key: _fk OR _join
indexe
Paul Lambert wrote:
Ken Johanson wrote:
I notice PG doesn't allow shorthand column labels -- it requires the
'AS' operand.
SELECT col1 foo, ...; -> ERROR: syntax error at or near "foo"
Briefly discussed a couple of weeks ago.
See http://archives.postgres
I notice PG doesn't allow shorthand column labels -- it requires the
'AS' operand.
SELECT col1 foo, ...; -> ERROR: syntax error at or near "foo"
For compatibility with other databases, what objections might be argued
in allowing this syntax in the future?
On the 'pros' side I think it eases
Bruce Momjian wrote:
Tom Lane wrote:
The real bottom line, though, is that this community has little respect
for proposals that involve moving away from the SQL spec rather than
closer to it; and that's what you're asking us to do. The spec is not
at all vague about the case-sensitivity of ide
Martijn van Oosterhout wrote:
I think you're missing the point that clients will be using languages
that are case sensetive. Consider the following Perl code:
$dbh->do("CREATE TEMP TABLE foo (Bar int4)");
$dbh->do("INSERT INTO foo VALUES (1)");
my $sth = $dbh->prepare("SELECT Bar FROM foo");
$s
Tom Lane wrote:
Ken Johanson <[EMAIL PROTECTED]> writes:
-*If* the option to turn on case-insenetive behavior were selectable at
the DB or session level, the existing apps could continue to use the
case sensitve mode and be completely unaffected.
Ken, you clearly fail to understa
Martijn van Oosterhout wrote:
On Sat, Dec 02, 2006 at 11:08:51AM -0700, Ken Johanson wrote:
And my vote is to not have such an option. But I'm not the one who
decide so don't worry about what I think :-) I would like to have an
option to upper case the identifiers instead of lower c
Dennis Bjorklund wrote:
So my vote would remain for having a config-option to ignore case,
even on quoted identifiers..
And my vote is to not have such an option. But I'm not the one who
decide so don't worry about what I think :-) I would like to have an
option to upper case the identifiers
Dennis Bjorklund wrote:
Ken Johanson skrev:
Has your experience with PG been different? If so I presume you have
have found a config that allows?:
SELECT
pers.firstName,
pers.lastname,
As long as you don't create the columns using quotes you can use that
kind of names. For ex
Martijn van Oosterhout wrote:
On Sat, Dec 02, 2006 at 12:41:37AM -0700, Ken Johanson wrote:
1: It seems like this behavior of case sensitive-or-not-identifiers
could/should be a config option -- either globally for the server,
database, or at the connection/session level. Other databases *do
Chuck McDevitt wrote:
At Teradata, we certainly interpreted the spec to allow case-preserving,
but case-insensitive, identifiers.
Users really liked it that way
My 2 thoughts:
1: It seems like this behavior of case sensitive-or-not-identifiers
could/should be a config option -- either globall
Unix time stamps, short (int) or long res, are always supposed to GMT
based, as far as I know - I never seen anything different, except maybe
in homebrew software. So it should be both calendar and P.I.T. And you
wouldn't need the TZ storage if the date-number and number-> translation
itself ta
and the fact that I want the same value from the data base that I put
into it.
"same" in which sense? The same absolute point in time? Or the same point
on a calendar? Obviously if the timezone doesn't change, then the two are
equivalent; but which one is your application actually looking for? (I
Well, for the docs to list every possible conditional-statement for an
order by clause would just about include them all, so be all the more
confusing. Sub queries, IN, aggregate functions, aliases.. the list goes
on and on. I'd say that knowledge (that most conditionals can be used in
an order
15 matches
Mail list logo
