At 09:20 AM 2/12/2008, [EMAIL PROTECTED] wrote:
Date: Mon, 11 Feb 2008 11:56:33 -0500
From: Tom Lane <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: pgsql-sql@postgresql.org
Subject: Re: Usage of UUID with 8.3 (Windows)
Message-ID: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
> Now, what do I hav
Shavonne Marietta Wijesinghe wrote:
Even though n_gen is defined as a serial I can't let it handle the
progressive key by its self since there is the need that some records
should have the same value.
Of course you can - the default is only provided if you don't provide
your own.
That's
Even though n_gen is defined as a serial I can't let it handle the
progressive key by its self since there is the need that some records should
have the same value. That's why i use 3 primary keys.
A | B | C
---+---+---
1 | 1 | 1
2 | 1 | 3
2 | 2 | 3
2 | 3 | 3
3 | 1 | 2
3
Shavonne Marietta Wijesinghe wrote:
Thanks for the replies.. But my problem still continues even after
setting the isolation level.
Set oRs = oConn.Execute("SELECT N_GEN FROM MY_TABLE ORDER BY N_GEN::INT
DESC")
If err <> 0 then 'If table not found
GetFieldValue = "1"
WriteToFile logfilepath,
Thanks for the replies.. But my problem still continues even after setting
the isolation level.
Set oRs = oConn.Execute("SELECT N_GEN FROM MY_TABLE ORDER BY N_GEN::INT
DESC")
If err <> 0 then 'If table not found
GetFieldValue = "1"
WriteToFile logfilepath, date & " " & time & " -- no table Nu
> > I think Windows has its own UUID generator, so the best bet would be to
> > make that work.
>
> Only if it can be made to present the same SQL-level API as we have for
> OSSP. Otherwise we'll be faced with boatloads of platform-dependent
> client code ...
I'm just curious, but why aren't tho
Bryce Nesbitt wrote:
And indeed, most stuff works, but \d for a specific table fails. Has
there been talk of making a backwards compatibility nod here? I don't
want to downgrade my development machine, and I don't control the remote
machine. How fundamentally different is the protocol -- and w
(because our legacy application, which won't change, is using the
underlying tables. We can't do step #5).
Bryce Nesbitt wrote:
Yes, the view approach has some advantages. But it still leaves the
underlying tables naked to modification.
And since the most likely error is... well... me (or
Yes, the view approach has some advantages. But it still leaves the
underlying tables naked to modification.
And since the most likely error is... well... me (or another admin) at
the SQL prompt, we want underlying tables protected also.
chester c young wrote:
> instead of triggers I use update-a
I'm getting the dreaded psql warning:
WARNING: You are connected to a server with major version 8.1,
but your psql client is major version 8.2. Some backslash commands,
such as \d, might not work properly.
And indeed, most stuff works, but \d for a specific table fails. Has
there been ta
10 matches
Mail list logo
