At 05:24 AM 11/30/00 +, Thomas Lockhart wrote:
>> Is "if" clause support in PG?
>> for example:
>> "drop table aa if exist"
>> "insert into aa values(1) if not exists select * from aa where i=1"
>
>No. afaict it is not in any SQL standard, so is unlikely to get much
>attention from developers.
On Thu, 30 Nov 2000, Thomas Lockhart wrote:
> > Is "if" clause support in PG?
> > for example:
> > "drop table aa if exist"
> > "insert into aa values(1) if not exists select * from aa where i=1"
>
> No. afaict it is not in any SQL standard, so is unlikely to get much
> attention from developer
> Is "if" clause support in PG?
> for example:
> "drop table aa if exist"
> "insert into aa values(1) if not exists select * from aa where i=1"
No. afaict it is not in any SQL standard, so is unlikely to get much
attention from developers.
- Thomas
AIL PROTECTED]>
Sent: Tuesday, November 28, 2000 9:04 AM
Subject: [HACKERS] Please advise features in 7.1 (SUMMARY)
> Thanks for your help, everyone.
>
> This is a summary of replies.
>
> 1. Calculated fields in table definitions . eg.
>
> Create
From: "Ross J. Reedstrom" <[EMAIL PROTECTED]>
> On Tue, Nov 28, 2000 at 05:19:45PM +0100, Zeugswetter Andreas SB wrote:
> > > I guess it depends on what you're using it for -- disk space
> > > is cheap and
> > > abundant anymore, I can see some advantages of having it
> > > computed only once
>
> > So, having _both_ is the best thing.
>
> Absolutely, that's always what I meant -- we already have views and views
> can do this type of stuff at SELECT time can't they? So it's not a change,
> just an addition
And the precalculated and stored on disk thing can be done with triggers.
A
> So, having _both_ is the best thing.
Absolutely, that's always what I meant -- we already have views and views
can do this type of stuff at SELECT time can't they? So it's not a change,
just an addition
-Mitch
On Tue, Nov 28, 2000 at 05:19:45PM +0100, Zeugswetter Andreas SB wrote:
> > I guess it depends on what you're using it for -- disk space
> > is cheap and
> > abundant anymore, I can see some advantages of having it
> > computed only once
> > rather than X times, where X is the number of SELECTs
> I guess it depends on what you're using it for -- disk space
> is cheap and
> abundant anymore, I can see some advantages of having it
> computed only once
> rather than X times, where X is the number of SELECTs as that
> could get
> costly on really high traffic servers.. Costly not so much
]>
Sent: Tuesday, November 28, 2000 7:50 AM
Subject: AW: [HACKERS] Please advise features in 7.1 (SUMMARY)
>
> > > This is a summary of replies.
> > >
> > > 1. Calculated fields in table definitions . eg.
> > >
> > > Create tab
> > This is a summary of replies.
> >
> > 1. Calculated fields in table definitions . eg.
> >
> > Create table test (
> > A Integer,
> > B integer,
> > the_sum As (A+B),
> > );
> >
> > This functionality can be achieved through the use of views.
>
On Tue, Nov 28, 2000 at 02:04:01PM +1300, John Huttley wrote:
> Thanks for your help, everyone.
>
> This is a summary of replies.
>
> 1. Calculated fields in table definitions . eg.
>
> Create table test (
> A Integer,
> B integer,
> the_sum As (A+B)
On Tue, 28 Nov 2000, John Huttley wrote:
> 3. Stored Procedures returning a record set.
>
> Dream on!
This is something I would be really interested to see working. What are the
issues? my understanding is that it is technically feasible but too
complicated to add to PL/PGsql? it seems to me
Thanks for your help, everyone.
This is a summary of replies.
1. Calculated fields in table definitions . eg.
Create table test (
A Integer,
B integer,
the_sum As (A+B),
);
This functionality can be achieved through the use of views.
Implementing th
14 matches
Mail list logo
