Update the phenomenon does not exists in 8.2.0 but exists in 8.2.5.
On Jan 11, 2008 12:28 PM, Rajesh Kumar Mallah <[EMAIL PROTECTED]> wrote:
> Hi ,
>
> looks like constraint exclusion is being too aggressive in excluding null
> values
> although its well known that check constraints apply on no
Hi ,
looks like constraint exclusion is being too aggressive in excluding null values
although its well known that check constraints apply on not null values only.
Hope the minimal test session below explains the problem we facing.
BTW: we are very impressed with the performance gains we achieved
Hi,
Is there any way to define a SQL stored function that inserts a row in a
table and returns the serial generated?
CREATE TABLE matchmaking_session
(
session_id bigint NOT NULL DEFAULT
nextval('seq_matchmaking_session_id'),
...
);
CREATE FUNCTION create_matchmaking_sesssion(...)
RETURNS
Colin Wetherbee wrote:
Phillip Smith wrote:
As a side note - all the IATA codes are unique for each airport -
wouldn't it be better to use these as the Primary Key and Foreign
Keys? Then you wouldn't have to even join the tables unless you
wanted the port names (not just the code)
This is true
Phillip Smith wrote:
As a side note - all the IATA codes are unique for each airport -
wouldn't it be better to use these as the Primary Key and Foreign
Keys? Then you wouldn't have to even join the tables unless you
wanted the port names (not just the code)
This is true, but FWIW, my applicati
Try something like this where we alias the joined tables:
SELECT departure_date,
j1.code AS departure_code,
j2.code AS arrival_code
FROM jsjourneys
LEFT OUTER JOIN jsports AS j1 ON jsjourneys.departure_port = j1.id
LEFT OUTER JOIN jsports AS j2 ON jsjourneys.arrival_port = j2.id;
Paul Lambert wrote:
Colin Wetherbee wrote:
I would like to construct a query on the flight table that returns the
names of both the departure port and the arrival port.
The following query shows how I would get just the departure port.
js=# SELECT departure_date, jsports.code AS departure_cod
js=# SELECT departure_date, departure.code AS departure_code, arrival.code as
arraival_codeFROM jsjourneys JOIN jsports as departure ON
jsjourneys.departure_port = departure.id JOIN jsports as arrival on
jsjourneys.arraival_port = arraival.id LIMIT4;
Regards,Daniel Hernández.San
Colin Wetherbee wrote:
Greetings.
I have two tables I'm having a little trouble figuring out how to JOIN.
One contains a list of airports along with their IATA codes, cities,
names, and so forth. This table also contains an id column, which is a
serial primary key.
The other table contains
Greetings.
I have two tables I'm having a little trouble figuring out how to JOIN.
One contains a list of airports along with their IATA codes, cities,
names, and so forth. This table also contains an id column, which is a
serial primary key.
The other table contains a list of flights, each
[EMAIL PROTECTED] (Tom Lane) writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Gerardo Herzig escribió:
>>> Yes, the TRUNCATE statement is not sql ansi, maybe is a more low level
>>> thing than i think.
>
>> TRUNCATE currently does not fire triggers, but that doesn't mean it's
>> impossible
I’ve a data set in a text file which uses the U+ syntax for UCS
characters which I want to enter into a (utf8) db, using the actual
characters rather than the codepoint names.
The docs give the impression that eg E'\x91D1' ought to be the same
as '金', but my tests show that \x only accepts 2 h
Alvaro Herrera wrote:
> My thinking is that a TRUNCATE trigger is a per-statement trigger which
> doesn't have access to the set of deleted rows.
> In that way it would be different from a per-statement trigger for
> DELETE.
Completely agree.
A truncate trigger should run a different function
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> My thinking is that a TRUNCATE trigger is a per-statement trigger which
> doesn't have access to the set of deleted rows (Replicator uses it that
> way -- we replicate the truncate action, and replay it on the replica).
> In that way it would be differen
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Gerardo Herzig escribió:
Yes, the TRUNCATE statement is not sql ansi, maybe is a more low level
thing than i think.
TRUNCATE currently does not fire triggers, but that doesn't mean it's
impossible to do it. I thin
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Gerardo Herzig escribi�:
> >> Yes, the TRUNCATE statement is not sql ansi, maybe is a more low level
> >> thing than i think.
>
> > TRUNCATE currently does not fire triggers, but that doesn't mean it's
> > impossible to do it. I
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Gerardo Herzig escribió:
>> Yes, the TRUNCATE statement is not sql ansi, maybe is a more low level
>> thing than i think.
> TRUNCATE currently does not fire triggers, but that doesn't mean it's
> impossible to do it. I think it would be fairly easy to
Gerardo Herzig escribió:
> Yes, the TRUNCATE statement is not sql ansi, maybe is a more low level
> thing than i think.
TRUNCATE currently does not fire triggers, but that doesn't mean it's
impossible to do it. I think it would be fairly easy to add support
for that.
Currently, Mammoth Replica
Pavel Stehule wrote:
On 08/01/2008, Chris Browne <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] (Gerardo Herzig) writes:
Hi all. Acording to the docs, TRUNCATE will not fire a DELETE trigger
on the table being truncated.
There is a way to capture a TRUNCATE in any way?
I think th
--- On Wed, 1/9/08, Chinyi Woo <[EMAIL PROTECTED]> wrote:
> Does Postgresql support query like SELECT *TOP 3* * FROM
> Individual ? If I use ORDER BY, I have to write non-sql
> code to get the first row in the result set, which I try
> to avoid.
As you have seen, PostgreSQL's implementation of L
On Thu, Jan 10, 2008 at 02:19:43PM +1100, Phillip Smith wrote:
> SELECT *
>
> FROM Individual
>
> LIMIT 3
Note that you will have to add an 'order by' clause to guarantee
predictable results...
--
__
"Nothing is as subjective as reality"
Reino
Ken Johanson wrote:
Interesting thread(s)!
What I didn't see discussed was the possibility of making a server
and/or session option, where we could elect to turn-off the old behavior
(PG specific behavior) and enable the standard/shorthand syntax. Users
need a migration path.
I personally c
22 matches
Mail list logo
