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
"john huttley" <[EMAIL PROTECTED]> writes:
>> We've had parameterized triggers for years. Maybe you attach some
>> meaning to that term beyond what I do?
> I'm referring to the manual that says functions used for triggers must
> have no parameters and return a type Opaque.
The function has to b
At 06:00 PM 11/23/00 +1300, John Huttley wrote:
>1. Calculated fields in table definitions . eg.
>
> Create table test (
>A Integer,
>B integer,
> the_sum As (A+B),
>);
...
>These are _extraordinarily_ useful for application development.
>
>If anyone has a
At 12:28 PM 11/23/00 +0100, Zeugswetter Andreas SB wrote:
>
>> Reason: I want to know if any of these features are scheduled.
>>
>> 1. Calculated fields in table definitions . eg.
>>
>>Create table test (
>> A Integer,
>> B integer,
>>the_sum As (A+B),
At 18:00 23/11/00 +1300, John Huttley wrote:
>
>1. Calculated fields in table definitions . eg.
>
Can't really do this - you might want to consider a view with an insert &
update rule. I'm not sure how flexible rules are and you may not be able to
write rules to make views functions like tables,
> Reason: I want to know if any of these features are scheduled.
>
> 1. Calculated fields in table definitions . eg.
>
>Create table test (
> A Integer,
> B integer,
>the_sum As (A+B),
> );
This is currently easily done with a procedure that takes a t
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "John Huttley" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, 23 November 2000 19:05
Subject: Re: [HACKERS] Please advise features in 7.1
> "John Huttley" <
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "John Huttley" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, 23 November 2000 19:05
Subject: Re: [HACKERS] Please advise features in 7.1
> "John Huttley" <
"John Huttley" <[EMAIL PROTECTED]> writes:
> Reason: I want to know if any of these features are scheduled.
> 1. Calculated fields in table definitions . eg.
>Create table test (
> A Integer,
> B integer,
>the_sum As (A+B),
> );
You can do that now (an
Hello,
I've looked at the resources available through the web page to CVS and other
stuff,
however I cant find a statement of whats likely to be in 7.1 and what is planned
for later.
Reason: I want to know if any of these features are scheduled.
1. Calculated fields in table definitions . eg.
23 matches
Mail list logo
